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....@lists.launchpad.net
[mailto:coapp-developers-bounces+garretts=microsoft....@lists.launchpad.net] On
Behalf Of William A. Rowe Jr.
Sent: Wednesday, May 05, 2010 1:18 PM
To: Pierre Joye
Cc: coapp-developers@lists.launchpad.net
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. <wmr...@gmail.com> 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@lists.launchpad.net
Unsubscribe : https://launchpad.net/~coapp-developers
More help : https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~coapp-developers
Post to : coapp-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~coapp-developers
More help : https://help.launchpad.net/ListHelp
