[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Idea for maintaining packages up for adoption

Last Thursday 21 July 2005 07:41, Lucas Nussbaum was like:
> First post on -qa for me, I am not a DD and I joined the list after
> Raphael's QA talk at RMLL.

> On Thu, Jul 21, 2005 at 08:19:57AM +0200, Raphael Hertzog 
<raphael@ouaza.com> wrote:
> > Le mercredi 20 juillet 2005 à 17:52 -0700, Thomas Bushnell BSG a écrit :
> > > Raphael Hertzog <raphael@ouaza.com> writes:
> > > > But building packages from a suvbersion repository can be done
> > > > automatically. So yes, we could provide automatically unofficial
> > > > packages to the users.
> > >
> > > I'm fine with that, but I'm against making them official packages.
> >
> > That's not your call. The DD who checks the package decides if he wants
> > to upload it or not.
> What's the difference between your proposal and :
> - Some DDs with free time decide to co-maintain packages which :
>   - don't require too much work
>   - are orphaned or not well maintained
>   - have (power-)users willing to help with the maintainership
> - To do so, they use a mailing list, a wiki, etc, and a SVN repository
> - Write access to this SVN repository is given to the (power-)users
>   willing to help
> - DDs will try to rely mostly on the (non-DD) users for package
>   maintenance tasks. Ideally, they would only be in charge of the
>   package uploads.
> Presented like that, it might look less world-changing.

It's really worth looking at the Custom Debian Distros here. This is roughly 
what A/DeMuDi does already for multimedia packages.

> The issue that hasn't been raised yet (I think) is granularity :
> - How many alioth projects ? One for all packages ? One per package ?
> - How many mailing lists ? One global for all packages ? One per
>   package + one global ?
> - How many SVN repositories ? One for all packages ? One per package ?

See above. Most packages can be grouped by top-level debtags, which ideally is 
the same as a top-level menu listing. The 'sound' subgroup involves 
approximately 30 DDs, five of whom maintain the majority of packages, sorry 
one of those major players is still waiting to get through NM. These five are 
the most likely to pick up mm orphans, because the skills and issues are very 
specific, there is often only one DD in the chain who is practically able to 
upload a working package. This makes the process of cycling changes and 
improvements back to the main Debian tree rather prone to bottlenecking.

Although DeMuDi is no longer on alioth it still uses the Trac wiki so RSS 
export is possible. see - http://demudi.agnula.org/report/2 - So basically 
one project / mailing list / repository for each interest group, which would 
be building on the current structure. I think it's better to think in terms 
of fostering orphans than releasing zombies into the wild. These projects 
also represent a good place for non DD users like us to start getting 
involved in a low-pressure environment. This means the sponsoring DD is 
checking and uploading an already well tested package and has a support 
network to refer to. It doesn't involve subverting Debian Policy and 
releasing zombies.

My perspective is necessarily limited. Please correct any wrong assumptions.


tim hall

Reply to: