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.
cheers,
tim hall
http://glastonburymusic.org.uk
Reply to: