[Mageia-dev] Review Of Bugs

Tue Nov 1 00:32:38 CET 2011

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
+
+