Re: Let's be friends. (Non-maintainer uploads made easier)
Hi,
>>"Joost" == Joost Kooij <kooij@mpn.cp.philips.com> writes:
>> We already _can_ make non-maintainer uploads just fine.
>>
>> > > Joost> People can be "friend" for multiple packages, which
>> should improve communication between packages.
>>
>> They don't need a Friends: listing for that, they can already do it
>> today.
Joost> Yes, I agree that they can. The proposal should facilitate
Joost> it. There is nothing wrong with that is there?
This is what I don't understand. How exactly is it
"facilitating" it when I can already make a non-maintainer upload to
*any* package if it is required?
Also, now you are selecting a efw people who can be "freinds",
and excluding all others from making an non-maintainer upload. I just
don't see this as helping.
>> > > Joost> Packages can have a "friend" who _does_ still have a
>> libc5 system to develop on.
>>
>> They don't need a Friends: listing for that, they can already do it
>> today.
Joost> Yes, but how often does it happen? Wouldn't it be better if it
Joost> would be done with a better chance of a more active cooperation
Joost> from the maintainer?
Same problem. Why do you think a list of people kept somewhere
makes active co-operation more likely?
I'm beginning to think that
a) the idea does not go far enough: we do seem to need
co-maintainers, dpkg has them, I wanted one on the ill fated
xearth file project, and I was going to co-maintain a HTML
validation service (buying houses plays havoc with
plans). Co-maintainance can help shift the burden around, but
then the people involved are *partners*, and an arrangement has
been reached by mutual consent before hand.
b) By making *all* packages have friends by default, this idea goes
too far; the default now is that anybody can make non-maintainer
uploads after discussion, and I like that
c) An apprenticeship program is also interesting, but I think a
friends list is the wrong approach. A tutoring mind set is better
than this, in which maintainers that are willing can hang out
their shingle to answer questions, look at control and rules
files, offer tips, and double check initial packages
I have a feeling that there are better solutions to everything
that this approach appears to address; but nobody seems to have
thought it important enough so far to think about a solution, until
this topic came up.
We apparently have concerns that need to be addressed. I would
prefer a solution to be crafted to the problem, not, as it appears in
this case, grab one that seems to have appeared serendipitously (and,
at least in my opinion, is not a great fit for any problem
addressed).
It appears, though, that I am the only one with this opinion,
and if such is the case, I'll shut up and withdraw from the
discussion. I've other things to worry about at the moment, including
where are we going to put the furniture while the floor is being
refinished.
manoj
--
"The country couldn't run without Prohibition. That is the
industrial fact." Henry Ford, 1929
Manoj Srivastava <srivasta@acm.org> <http://www.datasync.com/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: