Andreas Metzler wrote:
> Of course, there are plenty of packages up for adoption.
Well. Guess why? Because noone cares about them. People giving away interesting
packages do so by asking on debian devel and adding that only maintainers are
asked. (Which is OK in itself, but makes the mix of orphaned packages on the
devel/wnpp even less attractive.) lilo is (quite explainable) not suited for a
inexperienced maintainer and knapster2 is hardly very attractive.
(While seeking an example I noticed that there was a cvs commit to gadfly since
the last time I looked, so maybe it's maintained upstream and worth taking.)
IMHO debian would benefit most if people took (prospective) applicants as
co-maintainers. For example, reportbug would be a package I'd love to work on
(and by it's buglist, it probably would benefit from some additional manpower,
too). However, when there is talk about maintainer having become inactive on
-devel and it's unclear whether he'd even want any help, I'd probably just waste
my time.
Summary: A much better way to have new people do something useful would be
having a list of *people* who want help with specific tasks or packages and
would take an "apprentice". This is something close to (my understanding of) the
original idea in this thread.
Need another example? I have a fix for 178203, which is not exactly critical,
but seems to be a high profile bug. I'd love to send it to someone who'd say
"this is wrong" or "this is ok, I'll integrate it". If I'll just attach it to
the bug list, a) I'll probably make myself a fool, b) it'll just get ignored.
Of course, b) wouldn't be any worse than now, but I'll avoid a) if the only
thing I can gain by it is b).
Yet another example?
I've tried to find something helpful to do on debian-boot also (this is one of
the other things people are frequently pointed at). Post to the list: Twice I
got responses. Then: No reply or a reply "has been fixed in CVS" two weeks after
I asked about the problem and two days after it had been fixed.
If you want newbies to help out, you need to deal with a not so good ideas, too.
I can't blame the d-i people, they've never said they need help, but nonetheless
this makes me think whether it's worth spending my time on this.
(And, in effect, it makes people loose courage to the point that they quit when
the ideas start to get better as the learning progresses.)
Again, when I communicated privately with Sebastian Ley (who is working on the
gtk frontend), I got responses, and I hope that I have at least provided some
valuable feedback.
> [...]
>>I have asked for a
>>NMU in August [1] on debian-python, but I got no relply at all.
> Perhaps it would have worked better if you had tried to do the NMU[1]
> yourself, it is possible to NMU via a sponsor, too.
[...]
> [1] Of course folowing the proper procedures as stated in developers'
> reference.
Instead of being smart about the "proper procedures as stated in developers'
reference", you could have read on. The part you have not quoted three lines
below the statement you cite:
>> (Note that this happened to me while I was just another user, so I did not
>> think about asking on mentors or anything.)
Now that we got the context:
a) If a user and I take the time to figure out the fix to a package, does he
really have to research also the procedures how to push a fix if the
maintainer is unresponsive for 7 months?
b) I asked on a debian list that was supposedly the most topical for the
problem. Other NMUs to python related packages are announced there. If it was
the wrong list, it wouldn't have taken 2 minutes to point to another.
What conclusion should be drawn other than that my message obviously just
fell under random noise not to bother about for the developers on the
debian-python list.
One thing can be said: That's just a single bug, anecdotal evidence, not empirical.
That's true, however it seems rather symptomatic for the type of experience one
has when trying to get involved even at the most basic level.
Maybe I'm just foolish or unlucky, but I've had several occasions on which I've
tried to get involved here and there and accumulated quite a bit more bad
experiences than I can attribute to my technical or procedural inability.
Each individually is quite explainable, but it is the sum that is quite
distressing. Fortunately, there also always is encouragement, and the amount is
increasing, too.
Cheers
T.
[0] dpkg-dev: dpkg-shlibdeps should report only the strictest of multiple
versioned dependencies on the same package
Attachment:
pgpxiM7JidPK2.pgp
Description: PGP signature