[Mageia-dev] Review Of Bugs

[Michael Scherer]

Le lundi 31 octobre 2011 à 22:16 +0000, Colin Guthrie a écrit :
> 'Twas brillig, and Michael Scherer at 31/10/11 21:44 did gyre and gimble:
> > Le lundi 31 octobre 2011 à 21:06 +0000, Colin Guthrie a écrit :
> >> 'Twas brillig, and Maarten Vanraes at 31/10/11 20:55 did gyre and gimble:
> >>> Op maandag 31 oktober 2011 21:34:04 schreef D.Morgan:
> >>> [...]
> >>>>> But seriously, if we can't maintain/fix something like chromium-browser,
> >>>>> we should just drop it completely, maybe have a get-chromium package
> >>>>> instead
> >>>>
> >>>> why ? i package it regularly and tvignaud too.
> >>>> what about dropping all packages that have bugs ?  this is just stupid
> >>>> and you should first ask ppl packaging it before giving such ideas
> >>>
> >>> ok, i get it, (allthough i did say "IF") I guess it's a misguided attempt of 
> >>> myself to get more maintainership...
> >>
> >> I think the attempts to get more official partnerships by Samuel and
> >> yourself are very valuable, but by the same token, I think we need to
> >> accept that having a single maintainer for some packages just doens't
> >> make sense.
> >>
> >> For example things like initscripts, udev, systemd etc. should be
> >> maintained by a "core" team, and IMO, not a single person (tho' if
> >> someone steps up and is proven to be reliable then this is obviously not
> >> a bad thing per-se!). I'm certainly happy to help out here.
> > 
> > Well, so far, the system do not support this.
> 
> Indeed.
> 
> > So either this supposed team is able to organise itself to have one of
> > the member to act as a gate to take maitainership and dispatch task
> 
> I think both socially and expectation wise, being a the gatekeeper in
> such context still carries a lot of responsibility that people would not
> feel too comfortable with, nor would there necessarily be the social
> hierarchy where said gatekeeper would feel sufficiently authorised to
> dish out tasks to others.
> 
> > or someone patch the maintdb script to have more than one person.
> 
> This would be better, or perhaps "team accounts" can be created which
> forward mail to the members rather than having multiple maintainers..

There would be several problem with that :

- that would would break the assumption we used in our ldap of 1 account
= 1 person, assumption that we used every where in the auth system. For
example, on the bugzilla settings, or seeing the bug that are assigned 

- that would also have the side effect of having some package not
managed while appearing as such. For example, unless all maintainer are
equally skilled, we will not 

- that doesn't solve the issues of "who decide who get in the group".
That's a basic gouvernance issue that I ask each time the question
arise, and that is never answered AFAIK.

The more important problem is not really technical, as I said in the
past, but really organisational. 

The proposal of a core team will just mean we have a 2 tier hierarchy of
maintainer, like we did in the past with main/contribs. Except that it
doesn't solve the issue of having thing not really maintained. 
( and that's not really very egalitarian IMHO )

If people in the core team cannot solve all problems, ie, if we have
specialization ( which seems unavoidable IMHO ), we still need to know
who can do something, hence some way to find who maintain something.

What if the team take care of gcc, glibc, systemd, but there is only 1
person knowing enough gcc out of X ? How do we see there is a problem
when this person say "I cannot do my work for now/I leave". 

Who ultimately decide if needed ?

> > As long as "being managed by several people" will be seen the same way
> > as "maintained by nobody", we will have the same problem as mandriva.
> 
> Personally I don't buy that explanation. Of course it can be true in
> some cases (everyone just waits for someone else to fix it) but I
> suspect the odds of things getting fixed is still much higher than when
> a package is officially maintained by nobody...

Yet, there is several studies on the social proof ( one of the most
affordable is the book from Robert Cialdiani, see the chapter about it
).

On a side note, the issue is not to put more packagers to solve more
bugs, but to put the right person in charge. The maintainer db is the
way we use for the first step for maintainer. Now if a packager want
help, he can simply ask. 

But in the end, if no step to do anything, the bug will still be there.
 
> > Being maintained officially by someone do not prevent others to help. 
> > So I do not see any good reason to have them marked as nobody.
> 
> I certainly don't expect a package maintained by a team to be marked as
> nobody (well, certainly not longer term).

Yet, that's exactly what happen at Mandriva since years, and that's the
problem. Ie, if we do not start to solve the issue now, it will just
stay as longer term as usual.

Ie, there is lots of rpm marked as unmaintained that are not, and lots
that are marked as maintained.

And for now, the choice are either "nobody", or "someone". Anything else
is not coded, and therefor do not exist.

>  But again, I think even
> allocating a gatekeeper or a team leader puts too many social pressures
> on that person, and imposes something of a hierarchy that really doesn't
> seem appropriate. Also things don't happen automatically - such as all
> the team members getting CC'ed on bugzilla etc which would make it quite
> a lot of admin work for said gatekeeper on top of the actual bug fixes
> which again I think is too much.

Without leader, who decide who access the group ? Who dispatch the work,
decide the software managed by the group ? And so how is this better
than now ?


-- 
Michael Scherer