On Fri, Nov 15, 2013 at 1:53 AM, Ben de Groot <[email protected]> wrote: > > I don't really want to bring up this episode again, but it is a > telling example, which you asked for.
I appreciate that. I did ask for an example. I'll also limit my comments just to things that I think are more helpful moving forward. > > As can be seen from the ChangeLog, I was the primary maintainer. Depends on your definition of maintainer. If you define maintainer as somebody who has actually been doing work on a package, then you were. If you define it as the person listed in metadata.xml, then you weren't. Ideally those should match, so that when projects have to go running around the tree making changes they don't have to read between the lines to figure out who is the right contact for any particular package. They match now, which is good. > > 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). Well, make sure you talk to the OTHER maintainer for that package, which is the multilib team, before doing that. You don't own the package - you just help to maintain it. I don't want to rehash the thread from last summer - I do appreciate your feelings and I'm trying to find a balance. I want to appreciate the fact that maintainers have the largest investment in their packages, but at the same time those working on projects are investing in Gentoo as well. >> >> 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. You're both "actual" maintainers now. Certainly I agree that you should be talking to each other. :) I'd hope that things are going better now, but if they aren't I'd hope that Comrel would provide some assistance here. > > I am also cautiously optimistic about a renewed QA team, which could > be involved more in this kind of issues. I tend to agree here, but their role isn't to pick winners so much as to defend the general integrity of the tree. I think the challenge is figuring out how good, "good enough," is before these packages end up in ~arch (which IS intended for TESTING packages, but packages that are fairly likely to work with some maintainer testing already). > 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. Should we pick an init system while we're at it? :) Honestly, I don't think we can really choose anything at this point as none of the solutions are really fully-baked. If the Council simply pronounced support for one of them the only result would be that people might stop working on the other two, with no further progress on the chosen one. Then if that one dies on the vine we're stuck. I do have thoughts around things that could be improved, but I don't think either of the new options are at the point where they make sense. Both options really have to progress further on their own before we can think about standardizing/etc. Rich
