Re: Idea for maintaining packages up for adoption
Le Tue, Jul 12, 2005 at 04:32:30PM +0200, Frank Lichtenheld:
[ I previously sent a "private" answer to Frank, because I didn't know I
was allowed to post to the mailing lists. Sorry if you receive some of
the informations twice. ]
> I'm still not convinced that this is really superior to just let them
> submit patches to the BTS, especially when considering the overhead
> of maintaining the repository and recording changes there. Not to
> give a false impression: I would certainly never try to really maintain
> a package without using a VCS but in the case of orphaned packages were
> I will in most cases only make one or two uploads that is a real
> overhead IMHO.
I have no opinion on the technical solution to use, neither on the
precise way to manage this. My point is rather simple: there are
packages that are not maintained. For those packages, if you submit a bug
report with a patch, the report can stand there for years. The one I
submitted about dvidvi did stand 14 months. When I submit my patch, some
bugs where opened since 4 or 5 years.
Another aspect is that those unmaintained packages tend to become of no
use, they work less and less from year to year, and at one point they
usually dispear from Debian for wrong reasons:
- don't work at all anymore, so is used by nobody (it seems obvious that
an unmaintained piece of software will stop working and will then not
be used anymore)
- someone beleive another program does the same job (sometimes wrongly)
- etc.
I do understand the difficulty to find people to maintain those
packages. More over I understand this in my area: my main "skill" in
free software is about TeX, and we are not many to be skilled in that
area. To find people being skilled in TeX *and* in Debian and having
enough time to do both jobs is hard.
The idea we discussed with Raphael is quite simple: for packages with
few users(1), which are not maintained, and for which there are
troubles, it's better to have an informal contribution than to have
nothing at all.
(1): packages having a lot of users *will* have maintainers, because in
all those users, there are good chances that a few of them will know
Debian enough to wish to help.
Another way to say it: if someone provides a patch, and if there is
no maintainer, the patch should be applied, instead of leaving a bug
alive.
The rest of the duscussion was about finding a good way to do so,
something with less burden than becoming a Debian developper, but with a
bit of control to try to avoid a "silly patch" to be applied blindly.
This is from that point that he thinked of experts: if someone that is well
known as being a perl hacker provides a patch for a perl module, he's
probably right, and if he claims a patch from an unknown guy is wrong,
he's probably right too. In fact, this is probably the way maintainers
do handle their job: when someont more skilled in the area of the
packahe provides input, he's listened carefuly. But of course it cannot
work when there is no maintainer anymore.
For the details on the way to do it, as I said, I have no idea. Perhaps
a single large project "unmaintained packages" where everybody can
submit, and with some skilled people helping to check what is
provided can be a good solution. For the way to choose the skilled
people, this does not seem to be that difficult: a few volunteers from
the Debian developpers for the debian-specific problems (e.g. respect of
the policy, helping in the packaging process, etc), and you'll easily
find volunteers in each area, as long as you do not put too much burden
on them (I guess each Debian maintainer already know several skilled
people in the area of his packages).
I agree with you on that point: to have one project for each orphaned
package is too much an overhead. This is why the proposition of Raphael
seems good.
But I disagree on your conclusion: if people just submit patches to the
bug tracking system, the patches will not find a way to the users, since
there is no maintainer to do it.
Hope this will help making things clear :-)
Regards,
Benjamin.
Reply to: