FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 06-17-2008, 08:39 AM
Fabian Groffen
 
Default Re-Defining team and herd

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.

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

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.

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.


--
Fabian Groffen
Gentoo on a different level
--
gentoo-dev@lists.gentoo.org mailing list
 
Old 06-17-2008, 09:43 AM
Tiziano Müller
 
Default Re-Defining team and herd

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
 

Thread Tools




All times are GMT. The time now is 10:56 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org