On 15 November 2013 01:32, Rich Freeman <ri...@gentoo.org> wrote: > On Thu, Nov 14, 2013 at 11:38 AM, Ben de Groot <yng...@gentoo.org> wrote: >> I was particularly hit by this as maintainer of freetype, see bugs >> 455070 and 459352 for some of the mess that could have been avoided. > > Looks like 455070 was the source of problems there (the other is just > a tracker with the aftermath). The package had no maintainer at the > time, only a herd (per cvs). There was a request in the bug for > whether it was suitable to deploy to production. Somebody associated > with the herd gave a thumbs-up, apparently (I can only say that based > on your comment - I have no idea how that was communicated). Then > something went wrong. Since it caused problems, it was masked. Those > who run ~arch should be thanked for saving the stable users from > potential breakage! > > I'm not sure what should have been done differently. If the package > maintainer (in this case a herd) says that something is good to go, > why would anybody assume that it wasn't? You suggested testing in an > overlay 20 days earlier, but you weren't in any particularly > privileged position at the time (you were presumably just another > maintainer of the herd).
I don't really want to bring up this episode again, but it is a telling example, which you asked for. As can be seen from the ChangeLog, I was the primary maintainer. As a member of the herd I didn't feel it necessary to assert any kind of "privilege" any other way. I had already said "no, or at least wait" but that was circumvented by asking another herd member who hadn't touched the package in years. It would have been nice were I asked for my okay before making any changes. And as can be seen, the mess I feared for indeed took place. This could have been prevented, in my opinion, had this seen more extensive testing in an overlay. And this is exactly why I am now more weary for the next package about to be mangled: cairo (bug 488672). I am even tempted to undo the multilib changes to freetype, since it is still causing trouble (just search for freetype bugs and see how often multilib pops up). > I'm not pointing fingers here. This was apparently a > miscommunication, and part of the cause was a failure to document that > there was a primary maintainer of the package (something which was > subsequently corrected). Michał did offer to just maintain the status > quo on that package instead of migrating it, and apparently he thought > he had the all-clear to migrate it anyway. > > Michał did add the multilib project as a co-maintainer, taking > responsibility for dealing with the multilib-related issues long-term. > In my mind this is the sort of things projects should do. Indeed, but more communication with the current actual maintainers of the package in question should also be part of that. > I'm sure there were other issues, but issues will happen when projects > make changes. That's just the way things roll around here. If Michał > just committed a change to a package without conferring with the > maintainer at all or giving significant notice, I'd feel differently. > I think we just need to learn and move forward, and from the looks of > things we have. Gentoo always has been a fairly "disruptive" distro, > though it has settled down of late. I don't think we're erring on the > side of breaking systems too often right now, though I'm always for > preventing that as long as it doesn't require ossification. > > (Just a note - this is all based on what I could piece together from > cvs and bugzilla. I'm sure those who were personally involved could > contribute more detail. I'm not sure it is necessary that do so, but > I'll gladly defer to those with firsthand knowledge.) > >>> In the end, stuff only >>> gets done if people write code. Your power in any FOSS project really >>> comes down to your ability to write code or convince others to write >>> code on your behalf. > >> No, it's more about your ability to commit and get away with it. > > So, I'm 100% for what Donnie said and in general I tend to lean > towards saying "thanks, but no thanks" when a heavy contributor is > driving everybody nuts. However, the reality is that those who commit > more also tend to be allowed to get away with committing more. That's > just human nature - we all like our free toys and we're reluctant to > take too much objection when we're slapped around a little by the guy > who is giving us the free toys. There needs to be a balance, and from > the sound of things Markos is looking to step in and adjust the > balance if it gets out of line. Honestly, I just wish everybody would > do what they can to make his job easier, and I say that without > pointing my fingers in any direction. I think we have a really great > thing going here... > > Rich > Markos has shown initiative and good ideas, so I'm looking forward to positive changes. I am also cautiously optimistic about a renewed QA team, which could be involved more in this kind of issues. As I see it now, with respect to multilib, we have three competing solutions, but not a clear direction which way we want to go as a distro: 1: emul-* packages 2: multilib-portage 3: multilib.eclass I would like to vote for option 1, as it is the least intrusive and does what we need. If it is really felt we need a more complete solution, then my vote would be for 2, since 3 is too intrusive and more likely to break or complicate stuff for normal users. If you say council should take more of a leadership role, then maybe this issue can be decided by council and a clear direction be taken by the distro as a whole? Then those who oppose the choice made can either put up or shut up, and we can all work at implementing the chosen solution. -- Cheers, Ben | yngwin Gentoo developer
