Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Debian Development (http://www.linux-archive.org/debian-development/)
-   -   PPA (was: Bits from the Release Team - Kicking off Wheezy) (http://www.linux-archive.org/debian-development/520690-ppa-bits-release-team-kicking-off-wheezy.html)

Andreas Barth 05-01-2011 01:34 PM

PPA (was: Bits from the Release Team - Kicking off Wheezy)
 
* Pierre Habouzit (madcoder@madism.org) [110501 01:32]:
> - link that PPA stuff to the main repository in a way that "merging"
> PPA into unstable is just a matter of one single command, or a few.
>
> - make it easy for users to subscribe to PPAs, meaning you have to
> have some kind of directory of PPAs with categorization (quite
> stable, very experimental, gnome stuff, mozilla stuff, …whatever any
> valuable information for the user IOW).
>
> - PPA should focus on:
> * co-installability when endurable;
> * documented and working rollback to unstable (IOW downgrading a
> package to unstable when co-installability is not possible
> should work well enough, idealy using pinning and apt, but a
> documented procedure is good enough too).
>
> - get rid of experimental that would mostly become useless as PPA
> would clearly be a superset of the features.
>
> - make it easy to create new PPA repositories (aka "forks") for every
> DD. Of course some attention not to overload buildd resources is
> important so maybe "forks" should be restricted to a few
> architectures instead of all of them.
>
> - link anything that is uploaded to this PPA-like stuff tied to a
> public VCS with some kind of VCS-agnostic wrapper that allow
> maintainers to look at the patches corresponding to a given "forked"
> PPA, allowing him to cherry-pick/merge IOW take what he thinks is
> worthwhile.
>
> - ideal build on top of that some kind of publish/notify (merge
> requests in github) feature so that the "upstream" maintainer
> doesn't have to know about who forks him to be notified when someone
> has worked on a patch for his package.
>
> - last but not least, make it sure that the PPA-like infrastructure
> works with software that can be installed elsewhere, not
> necessarily on Debian infrastructure, so that non DDs can set-up
> their one PPA-like setup and fork Debian PPAs into them and still be
> able to submit "merge requests". This would be distributed-PPAs, and
> would be git "git" of packaging.


All that sounds very good to me.

Now, there are a few points that we could start tackling:

1. How to push from a vcs (git, svn, ...) to ppa? (This should be
coordinated with ftp-masters, so that the same method could be used
later on for uploading into unstable.)

2. How could we create new ppa repositories easy enough, how do we
hold the data, how do we make sure that dependencies are there?
(Basically "how do we extend dak for ppa?")

3. How do we extend authentication concepts for apt to ppa? (So that
one could say "please give me this and that repository from ppa", and
one doesn't need to add custom apt-keys.)

4. How do we get a good interface to see which patches are where, and
which bugs are found (or fixed) where?

5. After 2. is done, setting up autobuilding for ppa. (I'll be happy
to help with this part, but 2. needs to be done first.)

6. After 4. and 5. are done, adding links to the relevant build logs.

Any takers?



Andi


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110501133444.GF15003@mails.so.argh.org">http://lists.debian.org/20110501133444.GF15003@mails.so.argh.org


All times are GMT. The time now is 04:50 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.