From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <gentoo-dev+bounces-86919-garchives=archives.gentoo.org@lists.gentoo.org>
Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by finch.gentoo.org (Postfix) with ESMTPS id CAC05138334
for <garchives@archives.gentoo.org>; Wed, 3 Apr 2019 22:52:23 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id 8DC95E099B;
Wed, 3 Apr 2019 22:52:19 +0000 (UTC)
Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(No client certificate requested)
by pigeon.gentoo.org (Postfix) with ESMTPS id B55FFE098A
for <gentoo-dev@lists.gentoo.org>; Wed, 3 Apr 2019 22:52:18 +0000 (UTC)
Received: by mail-lj1-x231.google.com with SMTP id h16so297414ljg.11
for <gentoo-dev@lists.gentoo.org>; Wed, 03 Apr 2019 15:52:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gentoo-org.20150623.gappssmtp.com; s=20150623;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
bh=Snz+kT94WWLiD38IDeSWmyDozXdtYbeL54iyqVvzI2o=;
b=LWTTGUa5JCb4sGYH+KgJdgGlVTeepFPXISDYIZ1i24tFgDbuXrzXW4u623EHiEs1fC
BkhqAzpb/pve+nndGcwpxABX5ifmxpBAVLOa109KQs+Y0WnWtcaVRVZCbwwwrMmzYNjq
WrO3fhSQUhgLuVyZI4HL478TTRzLn8BJeP+AOBjtKwUqK/AfcoaqyxV5HN5+aV89QfTN
4e3cW8Ewxqzs8IMtjtd603M0bMSLJV0INCjLZVW7ZHxt/ehBoBvwCvRJJGFJFhnDJ6ZO
CrrrZ1cgpqaRoq/dfANKfsJdh9f17DkCd2sufq7JHjteWjV5t9nuclDUSUEJK2qMqmxb
tFBw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to;
bh=Snz+kT94WWLiD38IDeSWmyDozXdtYbeL54iyqVvzI2o=;
b=E9+pLqWA2Ntmi4u6Tf4O8ODwkfwP3YloQw/JlVkJNY6DJkkqeE0bT+sk3mCKOc3W7E
hzSAH0Aoa4AwmpKcNHWythWSdNsaGPJns46qz6865yw1zl0SFmWTad6MhLMqFQ+TVSOM
5TGY7EMTZ4nYwfeQuLLk64jExV0MYBeqbk0u63CfOY51aaWK+NMlaIZUymPYVi94QsnD
2Q4+mv1tUA/6tFyLOV6r9w8uuqG0bw26shP/MWBO9FuTdbttztX1GXfBI4B8bJDxGZ+v
4mGQSXeDxujcz0WwSqylHl9dC+BB5CJllllCsgjsnziH7Sqiu+IzBo+8Hd5xe3c1Ujdc
/f2Q==
X-Gm-Message-State: APjAAAX3BwV6W8niEiZRIoyOD/MOoZpNVrfQG+dEUluuhc0DaNx1DLWJ
xHvEcxpZSeM2f1xrnZvnFQ3K+s5dpmJiyZEOEiKU4hKT
X-Google-Smtp-Source: APXvYqxJbno/PkF7vHKm2bZOeQkyOWtVPaY2C8Dtvfvh+2XFPuimmw9p5KaCftTpxvH9u/pM+RIGcQ9dBjCkA1VWl8I=
X-Received: by 2002:a2e:9e47:: with SMTP id g7mr1437910ljk.48.1554331936457;
Wed, 03 Apr 2019 15:52:16 -0700 (PDT)
Precedence: bulk
List-Post: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
X-BeenThere: gentoo-dev@lists.gentoo.org
Reply-to: gentoo-dev@lists.gentoo.org
X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply
MIME-Version: 1.0
References: <7d39ee7fcb0f03f18533e7ab51653e76567c5d4c.camel@gentoo.org>
In-Reply-To: <7d39ee7fcb0f03f18533e7ab51653e76567c5d4c.camel@gentoo.org>
From: Alec Warner <antarus@gentoo.org>
Date: Wed, 3 Apr 2019 18:52:05 -0400
Message-ID: <CAAr7Pr93Wkqg2-_bdCePmchwbLubZzRYxgokobvpbE-xFz-qTA@mail.gmail.com>
Subject: Re: [gentoo-dev] Killing herds, again
To: Gentoo Dev <gentoo-dev@lists.gentoo.org>
Content-Type: multipart/alternative; boundary="000000000000ef9d630585a81a3f"
X-Archives-Salt: 30a7d671-88e9-418f-b776-e1762952dd65
X-Archives-Hash: 533c6eb1a6135f0d9bd3cbf08cd7d5d2
--000000000000ef9d630585a81a3f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Wed, Apr 3, 2019 at 1:36 PM Micha=C5=82 G=C3=B3rny <mgorny@gentoo.org> w=
rote:
> Hello, everyone.
>
> Back in 2016, we've killed the technical representation of herds. Some
> of them were disbanded completely, others merged with existing projects
> or converted into new projects. This solved some of the problems with
> maintainer declarations but it didn't solve the most important problem
> herds posed. Sadly, it seems that the spirit of herds survived along
> with those problems.
>
> Herds served as a method of grouping packages by a common topic,
> somewhat similar (but usually more broadly) than categories. In their
> mature state, herds had either their specific maintainers, or were
> directly connected to projects (which in turn provided maintainers for
> the herds). Today, we still have many herds that are masked either
> as complete projects, or semi-projects (i.e. project entries without
> explicit lead, policies or anything else).
>
>
> What's wrong with herds?
> ------------------------
> The main problem with herds is that they represent an artificial
> relation between packages. The only common thing about them is topic,
> and there is no real reason why a group of people would maintain all
> packages regarding the same topic. In fact, it is absurd -- say, why
> would a single person maintain 10+ competing cron implementations?
> Surely, there is some common knowledge related to running cron,
> and it is entirely possible that a single person would use a few
> different cron implementations on different systems. But that doesn't
> justify creating an artificial project to maintain all cron
> implementations.
>
> Mapping this to reality, projects usually represent a few developers,
> each of them interested in a specific subset of packages maintained by
> the project. In some cases, this is explicitly noted as project member
> roles; in other, it is not stated clearly anywhere. In both cases,
> there is usually some group of packages that are assigned to
> the specific project but not maintained by any of the project members.
>
> Less structured projects often have problems tracking member activity.
> More than once a project effectively died when all members became
> inactive, yet effectively hid the fact that the relevant packages were
> unmaintained and sometimes discouraged more timid developers from fixing
> bugs.
>
I'm not sure I follow this logic.
1) We know who is in every project.
2) We know the state of every developer.
We should be able to detect if:
a) A project has empty.
b) A project has no active developers.
I don't see how this is markedly different from a package, assigned to no
maintainer. Or a package assigned to a maintainer who is not active.
So the solution here seems to be to fix the tools to detect this situation
and make it clearer that the package has no active maintainer?
(I tend to agree with your general thrust of the rest of the proposal, but
I think in general limiting how projects are used on a statutory basis
seems incorrect.)
>
>
> What kind of projects make sense?
> ---------------------------------
> If we are to fight herd-like projects, I think it is important to
> consider a bit what kind of projects make sense, and what form herd-like
> trouble.
>
> The two projects maintaining the largest number of packages in Gentoo
> are respectively the Perl project and the Python project. Strictly
> speaking, both could be considered herd-like -- after all, they maintain
> a lot of packages belonging to the same category. To some degree, this
> is true. However, I believe those make sense because:
>
> a. They maintain a central group of packages, eclasses, policies etc.
> related to writing ebuilds using the specific programming language,
> and help other developers with it. The existence of such a project is
> really useful.
>
> b. The packages maintained by them have many common properties,
> frequently come from common sources (CPAN, pypi) and that makes it
> possible for a large number of developers to actually maintain all
> of them.
>
> The Python project I know better, so I'll add something. It does not
> accept all Python packages (although some developers insist on adding us
> to them without asking), and especially not random programs written in
> the Python language. It specifically focuses on Python module packages,
> i.e. resources generally useful to Python programmers. This is what
> makes it different from a common herd project.
>
> The third biggest project in Gentoo is -- in my opinion -- a perfect
> example of a problematic herd-project. The games project maintains
> a total of 877 packages, and sad to say many are in a really bad shape.
> Even if we presumed all developers were active, this gives us 175
> packages per person, and I seriously doubt one person can actively
> maintain that many programs. Add to that the fact that many of them are
> proprietary and fetch-restricted, and only the people possessing a copy
> can maintain it, and you see how blurry the package mapping is.
>
> Let's look at the next projects on the list. Proxy-maint is very
> specific as it proxies contributors; however, it is technically valid
> since all project members can (and should) actively proxy for any
> maintainers we have. Though I have to admit the number of maintained
> packages simply overburdens us.
>
> Haskell, Java, Ruby are other examples of projects focused on
> programming languages. KDE and GNOME projects generally make sense
> since packages maintained by those projects have many common features,
> and the core set has common upstream and sometimes synced releases. It
> is reasonable to assume members of those projects will maintain all, or
> at least majority of those packages.
>
> The next project is Sound -- and in my experience, it involves a lot of
> poorly maintained or unmaintained packages. Again, the problem is that
> the packages maintained by the project have little in common -- why
> would any single person maintain a dozen audio players, converters,
> libraries, etc. Having multiple people in project may increase
> the chance that they would happen to cover a larger set of competing
> packages but that's really more incidental than expected.
>
> This is basically how I'd summarize a difference between a valid
> project, and a herd-project. A valid project maintains packages that
> have many common properties, where it really makes sense for
> an arbitrarily chosen project member to take care of an arbitrary chosen
> package maintained by the project. A herd-project maintains packages
> that have only common topic, and usually means that an arbitrarily
> chosen project member maintains only a small subset of all packages
> maintained by the project.
>
> Looking further through the list, projects that seem to make sense
> include ROS, Emacs, maybe base-system, SELinux, ML, X11 (after all, it
> maintains core Xorg and nobody sets them as 'backup' maintainers for
> random X11 programs), PHP, vim...
>
> Project that are herd-like include science (possibly with all its
> flavors), netmon, video, desktop-misc (this is a very example of 'random
> programs'), graphics...
>
>
> What do I propose?
> ------------------
> I'd like to propose either disbanding herd-like projects entirely, or
> transforming them into more proper projects. Not only those that are
> clearly dysfunctional but also those that incidentally happen to work
> (e.g. because they maintain a few packages, or because they represent
> a single developer with wide interest).
>
> More specifically, I'd like each of the affected projects to choose
> between:
>
> a. disbanding the project entirely and finding individual maintainers
> for all packages,
>
> b. reducing the packages maintained by the project to a well-defined
> 'core set' whose maintenance by a group of developers makes sense,
> and finding individual maintainers for the remaining packages,
>
> c. splitting one or more smaller projects with well-defined scope from
> the project, and doing a. or b. for the remaining packages.
>
> Let's take a few examples. For a start, cron project. Previously, it
> maintained a number of different cron implementations (most having their
> individual maintainers by now), a cronbase package and cron.eclass.
> In this context, option a. means disbanding the project entirely. Some
> packages already have maintainers, others go maintainer-needed.
>
> Option b. would most likely involve leaving a cron project as small
> entity to provide policies for consistent cron handling, and maintain
> cronbase package and cron.eclass. Different cron implementation would
> go to individual maintainers anyway.
>
> A similar example can be made for the PAM project that maintained
> pambase, Linux-PAM, pam.eclass and some PAM modules. Here a. means
> giving all packages away, and b. means leaving a minimal project that
> maintains policies, pambase, Linux-PAM and the eclass. The individual
> modules (except for maybe very common, if there were some) would find
> individual maintainers.
>
> A good example for the c. option is the recently revived VoIP project.
> Again, this is an example of herd-project that tries to maintain
> an arbitrary set of loosely related packages. To some, it might make
> sense, especially since there's only a few VoIP packages left in Gentoo.
> Nevertheless, there is no reason why a single project member would
> maintain multiple competing VoIP stacks.
>
> Here, the c. option would mean creating project(s) for specific stacks
> of interest. For example, if there was specific project-level interest
> for maintaining Asterisk packages, an Asterisk project would make more
> sense than generic 'VoIP'.
>
>
> Why, again?
> -----------
> As I said before, the main problem with herds is that they introduce
> artificial and non-transparent relation between packages and package
> maintainers.
>
So back to this goal (which again I think is laudable.)
>
> Firstly, they usually tend to include packages that none of the project
> members is actually interested in maintaining. This also includes
> packages added by other developers (let's shove it in here, it matches
> their job description!) or packages leftover from other developers
> (where the project was backup maintainer). This means having a lot of
> packages that seem to have a maintainer but actually don't.
>
I have a lot of empathy for this point FWIW. Tooling can find empty /
abandoned projects, but we cannot do things like clearly say "This package
shouldn't be in this project"
or "This package is not actually maintained by a project".
One rule we might use here is that packages always need at least a single
human maintainer, and the project just an annotation; but doesn't affected
maintainer status.
So e.g. if there are 8 competing cron implementations, "cron-team" can't
maintain all 8, they have to find individual humans to vouch for each[0].
>
> Secondly, they frequently lack proper structure and handling of leaving
> members. Therefore, whenever a member maintaining a specific set of
> packages leaves, it is possible that the number of not-really-maintained
> packages increases.
>
> Thirdly, they tend to degenerate and become defunct (much more than
> projects that make sense). Then, the number of not-really-maintained
> packages ends up being really high.
>
> My goal here is to make sure that we have clear and correct information
> about package maintainers. Most notable, if a package has no active
> maintainer, we really need to have 'up for grabs' issued and package
> marked as maintainer-needed, rather than hidden behind some project
> whose members may not even be aware of the fact that they're its
> maintainers.
>
>
> What do you think?
>
>
[0] This is itself a question the project needs to decide for itself; does
every package need to be maintained actively? Some might answer no, and
maybe running for months / years without a maintainer is OK for Gentoo. Its
not an opinion I personally hold, but I suspect some community members do
hold it. Herds / Projects help Gentoo scale and enable 160 humans to
maintain 19,600 packages. Taking this away will likely affect the number of
packages in the tree as maintainers scale down their stake in the tree.
-A
> --
> Best regards,
> Micha=C5=82 G=C3=B3rny
>
>
--000000000000ef9d630585a81a3f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Wed, Apr 3, 2019 at 1:36 PM Micha=
=C5=82 G=C3=B3rny <<a href=3D"mailto:mgorny@gentoo.org">mgorny@gentoo.or=
g</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"=
>Hello, everyone.<br>
<br>
Back in 2016, we've killed the technical representation of herds.=C2=A0=
Some<br>
of them were disbanded completely, others merged with existing projects<br>
or converted into new projects.=C2=A0 This solved some of the problems with=
<br>
maintainer declarations but it didn't solve the most important problem<=
br>
herds posed.=C2=A0 Sadly, it seems that the spirit of herds survived along<=
br>
with those problems.<br>
<br>
Herds served as a method of grouping packages by a common topic,<br>
somewhat similar (but usually more broadly) than categories.=C2=A0 In their=
<br>
mature state, herds had either their specific maintainers, or were<br>
directly connected to projects (which in turn provided maintainers for<br>
the herds).=C2=A0 Today, we still have many herds that are masked either<br=
>
as complete projects, or semi-projects (i.e. project entries without<br>
explicit lead, policies or anything else).<br>
<br>
<br>
What's wrong with herds?<br>
------------------------<br>
The main problem with herds is that they represent an artificial<br>
relation between packages.=C2=A0 The only common thing about them is topic,=
<br>
and there is no real reason why a group of people would maintain all<br>
packages regarding the same topic.=C2=A0 In fact, it is absurd -- say, why<=
br>
would a single person maintain 10+ competing cron implementations? <br>
Surely, there is some common knowledge related to running cron,<br>
and it is entirely possible that a single person would use a few<br>
different cron implementations on different systems.=C2=A0 But that doesn&#=
39;t<br>
justify creating an artificial project to maintain all cron<br>
implementations.<br>
<br>
Mapping this to reality, projects usually represent a few developers,<br>
each of them interested in a specific subset of packages maintained by<br>
the project.=C2=A0 In some cases, this is explicitly noted as project membe=
r<br>
roles; in other, it is not stated clearly anywhere.=C2=A0 In both cases,<br=
>
there is usually some group of packages that are assigned to<br>
the specific project but not maintained by any of the project members.<br>
<br>
Less structured projects often have problems tracking member activity. <br>
More than once a project effectively died when all members became<br>
inactive, yet effectively hid the fact that the relevant packages were<br>
unmaintained and sometimes discouraged more timid developers from fixing<br=
>
bugs.<br></blockquote><div><br></div><div>I'm not sure I follow this lo=
gic.</div><div><br></div><div>1) We know who is in every project.</div><div=
>2) We know the state of every developer.</div><div><br></div><div>We shoul=
d be able to detect if:</div><div><br></div><div>a) A project has empty.</d=
iv><div>b) A project has no active developers.</div><div><br></div><div>I d=
on't see how this is markedly different from a package, assigned to no =
maintainer. Or a package assigned to a maintainer who is not active.</div><=
div><br></div><div>So the solution here seems to be to fix the tools to det=
ect this situation and make it clearer that the package has no active maint=
ainer?</div><div><br></div><div>(I tend to agree with your general thrust o=
f the rest of the proposal, but I think in general limiting how projects ar=
e used on a statutory basis seems incorrect.)</div><div>=C2=A0<br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
What kind of projects make sense?<br>
---------------------------------<br>
If we are to fight herd-like projects, I think it is important to<br>
consider a bit what kind of projects make sense, and what form herd-like <b=
r>
trouble.<br>
<br>
The two projects maintaining the largest number of packages in Gentoo<br>
are respectively the Perl project and the Python project.=C2=A0 Strictly<br=
>
speaking, both could be considered herd-like -- after all, they maintain<br=
>
a lot of packages belonging to the same category.=C2=A0 To some degree, thi=
s<br>
is true.=C2=A0 However, I believe those make sense because:<br>
<br>
a. They maintain a central group of packages, eclasses, policies etc.<br>
related to writing ebuilds using the specific programming language,<br>
and help other developers with it.=C2=A0 The existence of such a project is=
<br>
really useful.<br>
<br>
b. The packages maintained by them have many common properties,<br>
frequently come from common sources (CPAN, pypi) and that makes it<br>
possible for a large number of developers to actually maintain all<br>
of them.<br>
<br>
The Python project I know better, so I'll add something.=C2=A0 It does =
not<br>
accept all Python packages (although some developers insist on adding us<br=
>
to them without asking), and especially not random programs written in<br>
the Python language.=C2=A0 It specifically focuses on Python module package=
s,<br>
i.e. resources generally useful to Python programmers.=C2=A0 This is what<b=
r>
makes it different from a common herd project.<br>
<br>
The third biggest project in Gentoo is -- in my opinion -- a perfect<br>
example of a problematic herd-project.=C2=A0 The games project maintains<br=
>
a total of 877 packages, and sad to say many are in a really bad shape. <br=
>
Even if we presumed all developers were active, this gives us 175<br>
packages per person, and I seriously doubt one person can actively<br>
maintain that many programs.=C2=A0 Add to that the fact that many of them a=
re<br>
proprietary and fetch-restricted, and only the people possessing a copy<br>
can maintain it, and you see how blurry the package mapping is.<br>
<br>
Let's look at the next projects on the list.=C2=A0 Proxy-maint is very<=
br>
specific as it proxies contributors; however, it is technically valid<br>
since all project members can (and should) actively proxy for any<br>
maintainers we have.=C2=A0 Though I have to admit the number of maintained<=
br>
packages simply overburdens us.<br>
<br>
Haskell, Java, Ruby are other examples of projects focused on<br>
programming languages.=C2=A0 KDE and GNOME projects generally make sense<br=
>
since packages maintained by those projects have many common features,<br>
and the core set has common upstream and sometimes synced releases.=C2=A0 I=
t<br>
is reasonable to assume members of those projects will maintain all, or<br>
at least majority of those packages.<br>
<br>
The next project is Sound -- and in my experience, it involves a lot of<br>
poorly maintained or unmaintained packages.=C2=A0 Again, the problem is tha=
t<br>
the packages maintained by the project have little in common -- why<br>
would any single person maintain a dozen audio players, converters,<br>
libraries, etc.=C2=A0 Having multiple people in project may increase<br>
the chance that they would happen to cover a larger set of competing<br>
packages but that's really more incidental than expected.<br>
<br>
This is basically how I'd summarize a difference between a valid<br>
project, and a herd-project.=C2=A0 A valid project maintains packages that<=
br>
have many common properties, where it really makes sense for<br>
an arbitrarily chosen project member to take care of an arbitrary chosen<br=
>
package maintained by the project.=C2=A0 A herd-project maintains packages<=
br>
that have only common topic, and usually means that an arbitrarily<br>
chosen project member maintains only a small subset of all packages<br>
maintained by the project.<br>
<br>
Looking further through the list, projects that seem to make sense<br>
include ROS, Emacs, maybe base-system, SELinux, ML, X11 (after all, it<br>
maintains core Xorg and nobody sets them as 'backup' maintainers fo=
r<br>
random X11 programs), PHP, vim...<br>
<br>
Project that are herd-like include science (possibly with all its<br>
flavors), netmon, video, desktop-misc (this is a very example of 'rando=
m<br>
programs'), graphics...<br>
<br>
<br>
What do I propose?<br>
------------------<br>
I'd like to propose either disbanding herd-like projects entirely, or<b=
r>
transforming them into more proper projects.=C2=A0 Not only those that are<=
br>
clearly dysfunctional but also those that incidentally happen to work<br>
(e.g. because they maintain a few packages, or because they represent<br>
a single developer with wide interest).<br>
<br>
More specifically, I'd like each of the affected projects to choose<br>
between:<br>
<br>
a. disbanding the project entirely and finding individual maintainers<br>
for all packages,<br>
<br>
b. reducing the packages maintained by the project to a well-defined<br>
'core set' whose maintenance by a group of developers makes sense,<=
br>
and finding individual maintainers for the remaining packages,<br>
<br>
c. splitting one or more smaller projects with well-defined scope from<br>
the project, and doing a. or b. for the remaining packages.<br>
<br>
Let's take a few examples.=C2=A0 For a start, cron project.=C2=A0 Previ=
ously, it<br>
maintained a number of different cron implementations (most having their<br=
>
individual maintainers by now), a cronbase package and cron.eclass.<br>
In this context, option a. means disbanding the project entirely.=C2=A0 Som=
e<br>
packages already have maintainers, others go maintainer-needed.<br>
<br>
Option b. would most likely involve leaving a cron project as small<br>
entity to provide policies for consistent cron handling, and maintain<br>
cronbase package and cron.eclass.=C2=A0 Different cron implementation would=
<br>
go to individual maintainers anyway.<br>
<br>
A similar example can be made for the PAM project that maintained<br>
pambase, Linux-PAM, pam.eclass and some PAM modules.=C2=A0 Here a. means<br=
>
giving all packages away, and b. means leaving a minimal project that<br>
maintains policies, pambase, Linux-PAM and the eclass.=C2=A0 The individual=
<br>
modules (except for maybe very common, if there were some) would find<br>
individual maintainers.<br>
<br>
A good example for the c. option is the recently revived VoIP project. <br>
Again, this is an example of herd-project that tries to maintain<br>
an arbitrary set of loosely related packages.=C2=A0 To some, it might make<=
br>
sense, especially since there's only a few VoIP packages left in Gentoo=
.<br>
Nevertheless, there is no reason why a single project member would<br>
maintain multiple competing VoIP stacks.<br>
<br>
Here, the c. option would mean creating project(s) for specific stacks<br>
of interest.=C2=A0 For example, if there was specific project-level interes=
t<br>
for maintaining Asterisk packages, an Asterisk project would make more<br>
sense than generic 'VoIP'.<br>
<br>
<br>
Why, again?<br>
-----------<br>
As I said before, the main problem with herds is that they introduce<br>
artificial and non-transparent relation between packages and package<br>
maintainers.<br></blockquote><div><br></div><div>So back to this goal (whic=
h again I think is laudable.)</div><div>=C2=A0</div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,=
204,204);padding-left:1ex">
<br>
Firstly, they usually tend to include packages that none of the project<br>
members is actually interested in maintaining.=C2=A0 This also includes<br>
packages added by other developers (let's shove it in here, it matches<=
br>
their job description!) or packages leftover from other developers<br>
(where the project was backup maintainer).=C2=A0 This means having a lot of=
<br>
packages that seem to have a maintainer but actually don't.<br></blockq=
uote><div><br></div><div>I have a lot of empathy for this point FWIW. Tooli=
ng can find empty / abandoned projects, but we cannot do things like clearl=
y say "This package shouldn't be in this project"</div><div>o=
r "This package is not actually maintained by a project".</div><d=
iv><br></div><div>One rule we might use here is that packages always need a=
t least a single human maintainer, and the project just an annotation; but =
doesn't affected maintainer status.</div><div>So e.g. if there are 8 co=
mpeting cron implementations, "cron-team" can't maintain all =
8, they have to find individual humans to vouch for each[0].</div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Secondly, they frequently lack proper structure and handling of leaving<br>
members.=C2=A0 Therefore, whenever a member maintaining a specific set of<b=
r>
packages leaves, it is possible that the number of not-really-maintained <b=
r>
packages increases.<br>
<br>
Thirdly, they tend to degenerate and become defunct (much more than<br>
projects that make sense).=C2=A0 Then, the number of not-really-maintained<=
br>
packages ends up being really high.<br>
<br>
My goal here is to make sure that we have clear and correct information<br>
about package maintainers.=C2=A0 Most notable, if a package has no active<b=
r>
maintainer, we really need to have 'up for grabs' issued and packag=
e<br>
marked as maintainer-needed, rather than hidden behind some project<br>
whose members may not even be aware of the fact that they're its<br>
maintainers.<br></blockquote><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1=
ex"><br>
<br>
What do you think?<br>
<br></blockquote><div><br></div><div>[0] This is itself a question the proj=
ect needs to decide for itself; does every package need to be maintained ac=
tively? Some might answer no, and maybe running for months / years without =
a maintainer is OK for Gentoo. Its not an opinion I personally hold, but I =
suspect some community members do hold it. Herds / Projects help Gentoo sca=
le and enable 160 humans to maintain 19,600 packages. Taking this away will=
likely affect the number of packages in the tree as maintainers scale down=
their stake in the tree.</div><div><br></div><div>-A</div><div>=C2=A0</div=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left:1px solid rgb(204,204,204);padding-left:1ex">
-- <br>
Best regards,<br>
Micha=C5=82 G=C3=B3rny<br>
<br>
</blockquote></div></div>
--000000000000ef9d630585a81a3f--