Fabian Groffen wrote: > On 17-06-2008 09:54:46 +0200, Tiziano Müller wrote: >> From the GLEP: >> *snip* >> The biggest differences to the current system are: >> * A team is not implicitly defined as the people who maintain the >> packages in a certain herd >> * A herd is really only a logical unit of packages and may therefore >> _not_ possess any ressources >> * A team may maintain more than one herd (respectively the packages >> within them) >> *snip* > > While you're at redefining the terms `herd' and `team', I'd like your > GLEP to address the maintenance issue as well. With teams being allowed > to maintain a package, and the team being ``a denoted group of people'' > you block out potential maintenance from others. No I don't. The GLEP doesn't mention whether packages may be maintained by others. The GLEP only says that in addition to being maintained by single people a package may also be maintained by a team.
> > With Gentoo being a project with some devs, of which many quite limited > involved, I argue productivity for some of our devs is limited by the > barrier of the ``maintainer''. > > Recently I've noticed that maintainer-needed and maintainer-wanted > ebuilds are outlawed and hence can be maintained by anyone. In maintainer-needed should not be used in the tree directly (it can be used in an overlay though => sunrise). > particular treecleaners seem to have started handling the trivial bugs > on those packages, which I consider a positive movement. While > maintainer-needed and maintainer-wanted have a negative taste, I feel > they potentially aren't as negative as they sound. I think there are > many more devs just wasting their time in IRC because none of ``their'' > packages have ``solveable'' bugs. Would be nice if that'd be true. All maintainers who have no work to do: please ping me, I've got enough for all of you. > > Dropping explicit maintenance for packages that are not critical (which > are many IMO) would allow for a new ``team'' consisting of all of our > bored devs that feel like harvesting the low hanging fruit by doing > trivial version bumps, cleanups and trivial patches. Sure, let's create a team "janitors". > > In other words, I would like your proposal to: > - make a difference between ``must be maintained'' packages (e.g. > base-system) and the rest > - for the non-critical packages define a group of ``experts'' that does > not exclude ``foreign'' maintenance -- what if a herd is understaffed? > - have a structure (e.g. time-out rule) that allows the ``experts'' to > do full maintenance of their packages if they are active > > Your GLEP as it is now doesn't have any added value to me, as it seems > only to change things into other terminology, more files, and cause an > avalanche of other GLEPs without a clear rationale. > Well, I kept it short by intention since I really do believe that we first have to make things clear. I think you underestimate the proposal a little (although it may depend on how you implicitly understand our metastructure): a) It is completely unclear what a team is or what it's allowed to do currently. b) from an organizational and linguistic point of view it doesn't make sense that a ``herd`` has an alias. c) it doesn't make sense to assign bugs to a ``herd`` (neither organizational nor linguistical). I've added a section "Motivation" to the GLEP to explain this. Now about what you suggest: Write a GLEP containing what you propose above because I agree that it's currently unclear what happens to a package where the maintainer got retired or doesn't want to maintain it anymore. In the GLEP you can also write down that everybody can fix & bump packages with no maintainer. -- gentoo-dev@lists.gentoo.org mailing list
