Getting patches into packages, thought and ideas [Was: Re: About NM and Next Release]
Eduard Bloch <edi@gmx.de> writes:
> Moin Goswin!
> Goswin von Brederlow schrieb am Thursday, den 07. August 2003:
>
> > > > Working on boot-floppies and debian-installer is not realy fruitfull
> > > > as non-DD. cvs access goes a long way there.
> > >
> > > I must have severe reading and parsing problems today, because I don't
> > > understand what you are saying. The way we handle this in d-i, is that we
> > > encourage contributors to send patches to the mailing list. If the patches
> > > are good, we apply them. When we get tired of applying good patches, we
> > > get the person a pserver cvs account. When we get tired of uploading their
> > > packages, we bug them to become developers and carefully prod elmo about
> > > it, too.
> >
> > e.g. my devfs patches never got added to boot-floppies to my knowledge
> > and I never got told what would be wrong with them.
>
> Somehow I cannot remember devfs patches from you - was it in the time
> when Adam was the main developer? Currently BenC is working on basic
> devfs integration, feel free to help.
It was between potato and woody and I had a complete diff to make the
to be woody boot-floppies work with a 2.4.x kernel with devfs
including, a bit later, the neccessary patches for sysvinit and some
other tools to make devfs/non-devfs transparent to the config. But its
water under the bridge.
> > For the mklibs.py changes Falk Hueffner was luckily intrested and I
> > can prod him physically so he coauthored and got them added. Without
> > him I wouldn't have bothered trying to write patches due to my
> > boot-floppies experience.
>
> What we need is a database with simple mailing list function (similar to
> PTS) where willing sponsors for a certain package can subscribe and
> sponsorees with much motivation can send diffs for the next version
> upgrade. Easy to review and check, easy to build and upload. And easy to
> comment and communicate with other sponsors or co-maintainers.
Like the Patch Manager on Sourceforge?
Maybe an interface/filter for the bts that gives one a more easy
access to packages with patches pending would be a start. Or a system
like the translation system. When a patch is in BTS without a reaction
from the maintainer for some time its send to some idle maintainer for
review. If hes unresponsive within a week/month the patch is resend to the
next and so on.
Or that lengthily discussed wag-a-bug game where maintainers get
assigned older pending bugs and get points for fixing.
MfG
Goswin
Reply to: