Re-Defining team and herd
Fabian Groffen wrote:
> On 17-06-2008 09:54:46 +0200, Tiziano Müller wrote:
>> From the GLEP:
>> 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)
> 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
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
email@example.com mailing list