coapp-developers team mailing list archive

[Garrett Serack <garretts@xxxxxxxxxxxxx>]

CoApp Intends to:
    1) Provide a specification for package types and how applications are packaged, so that they can behave themselves in a common ecosystem.
    2) Provide tools to make packaging easier
    3) Shallow-fork a lot of OSS projects to provide clean, well-maintained Windows binaries
    4) provide tools to make shallow-forking & maintaining packages easier
    5 ) a user experience and a service that will allow end-users to manage their installed packages trivially (including updating...etc)
    6) a specification for metadata so that any publisher who conforms to the package specification can build and distribute packages using via the client tools (5)
    7) binary and source packages of applications and libraries forked in (3) 


Garrett Serack | Open Source Software Developer | Microsoft Corporation 
I don't make the software you use; I make the software you use better on Windows.


-----Original Message-----
From: coapp-developers-bounces+garretts=microsoft.com@xxxxxxxxxxxxxxxxxxx [mailto:coapp-developers-bounces+garretts=microsoft.com@xxxxxxxxxxxxxxxxxxx] On Behalf Of William A. Rowe Jr.
Sent: Wednesday, May 05, 2010 1:18 PM
To: Pierre Joye
Cc: coapp-developers@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Coapp-developers] What packages do you want to see?

On 5/5/2010 3:01 PM, Pierre Joye wrote:
> hi,
> 
> On Wed, May 5, 2010 at 9:45 PM, William A. Rowe Jr. <wmrowe@xxxxxxxxx> wrote:
> 
>> CoApp seeks to be one very specific way to do it.  If it happens to 
>> work for the upstream project, wonderful :)  If not, it's open 
>> source, and when it's broke we get to glue both pieces together.
> 
> That's what I would like to avoid as much as I can. At least for two things:
> 
> - naming convention (static vs dynamic .lib for example)
> - standard binary packages
> 
> If it fails for these two, then right, CoApp will be just another 
> project that brings nothing to upstream developers. And I really hope 
> that won't be the case :)

What is success?  Naming conventions?  Whatever we pick will be adopted by 10% of the world, decried by 10%, and ignored by 80%.

We don't disagree that the project authors upstream should be able to use the tools and create a build in CoApp conventions, and then they can choose to adopt or tweak their own schema accordingly, whatever it means to their effort.

Since CoApp publishes signed binaries, users can trust the providence of the source code to the build machine to the delivery package to the installation.  Most OSS projects aren't likely to go this far, you are lucky to have GPG sigs for many but not all of the OSS source packages you build.

> Except indeed if the CoApp goal is to be a distribution-like system.
> But then I would not have much interest to participate.

If the goal is to push out conventions which OSS developers are expected to adhere to, the project participants here can expect high blood pressure and burnout within 12 months of the effort.  If the goal is to offer conventions and then package much of the open source out there to follow those conventions and actually work out of the box for users and developers, the project's participants should be very satisfied with their success 12 months after the initial offering.


_______________________________________________
Mailing list: https://launchpad.net/~coapp-developers
Post to     : coapp-developers@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~coapp-developers
More help   : https://help.launchpad.net/ListHelp