FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 05-01-2011, 01:34 PM
Andreas Barth
 
Default 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
 

Thread Tools




All times are GMT. The time now is 02:34 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org