On 7/29/06, Manoj Srivastava <[EMAIL PROTECTED]> wrote:
On Sat, 29 Jul 2006 02:49:34 +0000, Gustavo Franco <[EMAIL PROTECTED]> said:
> On 7/29/06, Manoj Srivastava <[EMAIL PROTECTED]> wrote:
>> On Fri, 28 Jul 2006 14:11:03 -0300, Henrique de Moraes Holschuh
>> <[EMAIL PROTECTED]> said:
>>
>> > On Fri, 28 Jul 2006, martin f krafft wrote:
>> >> also sprach Matthew Garrett <[EMAIL PROTECTED]>
>> >> [2006.07.28.1737 +0100]:
>> >> > If Debian had slightly less of a culture of "Keep your hands
>> >> > off my package", I'd do it here instead.
>> >>
>> >> I've been thinking about this a lot for the past week.
>> >>
>> >> Is there any way this could be changed?
>>
>> > Yes, and we could start by really enforcing co-maintainership.
>> > Make it 100% mandatory for all essential, required and base
>> > packages at first.
>>
>> Err, I am not sure co-maintaining packages actually unequivocally
>> improves packaging quality or response times. There are teams that
>> work well for a packagfe, and then there are packages where team
>> maintainence has not worked out.
> It won't improve packages from the first day, but in my experience
> it has improved the way i can communicate with people. It's easier
> for me talk with a member or two in a group and sometimes join them
> temporarily and help. The one-man approach, when this one-man is a
> freak hurts the project, and when the person is sane and the
> package(s) needs more work, you end with a group maintanance even if
> itsn't official.
If the person is sane and has a package that needs more help,
the person get co-maintainers. ANd even then, sometimes, adding
maintainers does not reduce the laod on the primary. This is also
from experience.
Speak by yourself.
> You wrote that there are teams that work well for a package, and
> then there are packages where team maintenance has not worked
> out. These packages where team maintenance has not worked out were
> well maintained by one person before or what? If not, i disagree.
Yes, and in a recent case, that single maintainer was thinking
of taking the package back, in order to improve maintainance.
Well, wasn't he in that group?
>> > Co-maintainers are much closer to what is being done in a package
>> > than joe-random developer. Also, co-maintainership is far less
>> > prone to fire-and-forget uploads that hose things, and are nicer
>> > to people who feel very strongly about their packages.
>>
>> Co-maintainerships require communication, and ability and desire to
>> share decisions, can result in a culture of "it is someone elses
>> problem (neat aphorism in german, I believe)", and if the team does
>> not trust one of the members, then things can turn ugly.
>>
>> Sometimes, too many cooks do indeed spoil the broth.
> I think the debian-installer guys can tell you otherwhise.
Ha ha ha ha. I can only suspect you do not have access to
-private.
You know i've. AFAIK, d-i is going well, even with all the problems, i
can tell you about Debian Python Modules Team but you would say "it
isn't core, i don't care, yadda, yadda, ...". Do you see d-i as a
project where Joey or Frans do everything almost alone and others just
send patches using the BTS ?
>> > IMO, if we could reach a better level of resilience, lower
>> > response times, and agility with co-maintainership, it would be
>> > better than going to the extreme Ubuntu did.
>>
>> I am not yet convinced that that is the case universally,
>> especially if you force people to work in teams.
> Hello, i thought Debian project was a big team. If people here don't
> want to work in a team, we're going nowhere.
> I think that force is the wrong term, we should encourage and in
> some cases require to avoid single point of failure, IMHO.
There is no difference between requiring a team and forcing a
team on people. And that does not work.
That's great how you ignored my answer for your first comment, but ok.
There's a big difference in Manoj maintaining his package foo and
Gustavo maintaining glibc alone, do you see?
regards,
-- stratus
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]