[gentoo-dev] RFC: Deprecating and killing the concept of herds

[gentoo-dev] RFC: Deprecating and killing the concept of herds

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1419 bytes --]

Hello,

Let's keep it short: I think herds don't serve any special purpose
nowadays. Their existence is mostly resulting in lack of consistency
and inconveniences.

In particular:

1. We have two different tags in metadata.xml that serve a similar
purpose -- <herd/> and <maintainer/>, with <herd/> being less
descriptive. For this reason, sometimes herd's associated e-mail is
listed as <maintainer/>, and sometimes even the same thing is listed
using both tags.

2. The common use of <herd/> and <maintainer/> thingies forces
a particular maintainership model. In particular, we always assume
<maintainer/> comes first, and <herd/> serves as a backup. You can't
properly say otherwise using both tags.

3. The project member and herd member lists are constantly outdated.
In fact, most of the herds don't even list members -- just point out to
outdated project pages :).

4. The whole indirection is just irritating. You can't assign a bug
using metadata.xml without fetching herds.xml that's in a different CVS
repo.

I believe it would be benfiicial to just deprecate and eventually drop
<herd/> in favor of explicit <maintainer/> using the alias. I don't know
if someone has other use of herds.xml but it the contents are either
outdated or redundant. Therefore, I would suggest eventually getting
rid of that file as well.

What do you think?

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds

[Rich Freeman]

On Tue, Sep 9, 2014 at 3:45 PM, Michał Górny <mgorny@gentoo.org> wrote:
>
> Let's keep it short: I think herds don't serve any special purpose
> nowadays. Their existence is mostly resulting in lack of consistency
> and inconveniences.
>

The original design was that packages belong to herds, and developers
belong to projects.  Projects might maintain a herd.

The problem is that this isn't followed with 100% rigor, and the extra
level of indirection probably doesn't make bug things easier.

I'm not sure what we lose by getting rid of herds vs just listing
projects as maintainers.  Maybe herds are useful as a form of tag, but
if we really wanted that it would make more sense to just have tags of
some kind.

--
Rich

Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds

[Anthony G. Basile]

On 09/09/14 15:56, Rich Freeman wrote:
> On Tue, Sep 9, 2014 at 3:45 PM, Michał Górny <mgorny@gentoo.org> wrote:
>> Let's keep it short: I think herds don't serve any special purpose
>> nowadays. Their existence is mostly resulting in lack of consistency
>> and inconveniences.
>>
> The original design was that packages belong to herds, and developers
> belong to projects.  Projects might maintain a herd.
>
> The problem is that this isn't followed with 100% rigor, and the extra
> level of indirection probably doesn't make bug things easier.
>
> I'm not sure what we lose by getting rid of herds vs just listing
> projects as maintainers.  Maybe herds are useful as a form of tag, but
> if we really wanted that it would make more sense to just have tags of
> some kind.

I can live with collapsing herds into projects as long as we keep some 
system where groups of packages come under the care of groups of 
developers.  Eg. coreutils is maintained by base-system, or drupal is 
maintained by web-app, etc.   But we do loose something. I like being on 
the bugzilla cc list of lots of herd where I'm not really a member of 
the project taking care of that herd.  I'm on both base-system@ and 
web-app@ aliases, but I'm not a member of base-system while I am a 
member of web-app.

>
> --
> Rich
>


-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1823 bytes --]

Dnia 2014-09-09, o godz. 16:46:29
"Anthony G. Basile" <blueness@gentoo.org> napisał(a):

> On 09/09/14 15:56, Rich Freeman wrote:
> > On Tue, Sep 9, 2014 at 3:45 PM, Michał Górny <mgorny@gentoo.org> wrote:
> >> Let's keep it short: I think herds don't serve any special purpose
> >> nowadays. Their existence is mostly resulting in lack of consistency
> >> and inconveniences.
> >>
> > The original design was that packages belong to herds, and developers
> > belong to projects.  Projects might maintain a herd.
> >
> > The problem is that this isn't followed with 100% rigor, and the extra
> > level of indirection probably doesn't make bug things easier.
> >
> > I'm not sure what we lose by getting rid of herds vs just listing
> > projects as maintainers.  Maybe herds are useful as a form of tag, but
> > if we really wanted that it would make more sense to just have tags of
> > some kind.
> 
> I can live with collapsing herds into projects as long as we keep some 
> system where groups of packages come under the care of groups of 
> developers.  Eg. coreutils is maintained by base-system, or drupal is 
> maintained by web-app, etc.   But we do loose something. I like being on 
> the bugzilla cc list of lots of herd where I'm not really a member of 
> the project taking care of that herd.  I'm on both base-system@ and 
> web-app@ aliases, but I'm not a member of base-system while I am a 
> member of web-app.

I don't understand your concern. I'm only saying we should stop relying
on that stupid out-of-repository herds.xml file and put the e-mail
address directly in metadata.xml. Bugzilla and bug assignment would
work pretty much the same -- except that you wouldn't have to scan one
more file to get the e-mail you're looking for.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 848 bytes --]

On 10 September 2014 10:23, Michał Górny <mgorny@gentoo.org> wrote:

> I don't understand your concern. I'm only saying we should stop relying
> on that stupid out-of-repository herds.xml file and put the e-mail
> address directly in metadata.xml. Bugzilla and bug assignment would
> work pretty much the same -- except that you wouldn't have to scan one
> more file to get the e-mail you're looking for.
>

That sounds less like you're trying to deprecate the use of herds, and more
like you're trying to deprecate the use of herds /in metadata.xml/.

The latter strikes me as an easier sell, just the markup is more effort.

If it was possible to write <herd>perl</herd>  and have some process that
automatically upscaled that to a <maintainer> tag, that'd be cool.

-- 
Kent

*KENTNL* - https://metacpan.org/author/KENTNL

[-- Attachment #2: Type: text/html, Size: 1498 bytes --]

Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds

[Pacho Ramos]

El mar, 09-09-2014 a las 21:45 +0200, Michał Górny escribió:
[...]
> I believe it would be benfiicial to just deprecate and eventually drop
> <herd/> in favor of explicit <maintainer/> using the alias. I don't know
> if someone has other use of herds.xml but it the contents are either
> outdated or redundant. Therefore, I would suggest eventually getting
> rid of that file as well.
> 
> What do you think?
> 

I agree with this but we would need to cover the case of people being in
a determined mail alias but don't really wanted to be considered a
"maintainers" of the involved packages as they are in the alias to keep
track on that issues. This problem has usually raised when a herd starts
to become inactive as no one is really maintaining that packages. We can
erroneously think that the herd is still active because there are people
in the alias... but they are really not taking care of them at all. We
discussed this in the past (I think it was a gentoo-dev ML thread
related with media-optical herd being empty) and we agreed on only
considering people listed in herds.xml as maintainers, not people in
mail alias.

Personally I would vote for simply have a <maintainer> tag pointing to
the alias but we would still need to keep a list of real maintainers for
that alias as usually not all people listed in the alias are willing to
maintain the packages.

Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds

[Rich Freeman]

On Tue, Sep 9, 2014 at 6:54 PM, Kent Fredric <kentfredric@gmail.com> wrote:
>
> On 10 September 2014 10:23, Michał Górny <mgorny@gentoo.org> wrote:
>>
>> I don't understand your concern. I'm only saying we should stop relying
>> on that stupid out-of-repository herds.xml file and put the e-mail
>> address directly in metadata.xml. Bugzilla and bug assignment would
>> work pretty much the same -- except that you wouldn't have to scan one
>> more file to get the e-mail you're looking for.
>
>
> That sounds less like you're trying to deprecate the use of herds, and more
> like you're trying to deprecate the use of herds /in metadata.xml/.
>
> The latter strikes me as an easier sell, just the markup is more effort.
>
> If it was possible to write <herd>perl</herd>  and have some process that
> automatically upscaled that to a <maintainer> tag, that'd be cool.

If the only thing we're using herds for is as a way to populate the
maintainer field, then they really should go away.

I'd think that the whole point of having herds is so that you could
group packages together in a way OTHER than by maintainer.  We already
have the maintainer attribute to track who maintains a package. Herds
were supposed to be about grouping related packages together (like a
herd), and not keeping track of who the cattle rustlers were.

IMHO herds aren't working because:
1.  They're basically being used as another form of project, so in
addition to mail alias members and project pages it is yet another
version of who is working on what which differs from the other ways of
finding out who is working on what.

2.  They're supposed to be used to group related packages together,
but we already have categories, and there isn't just "one true way" to
group packages together anyway.  It sounds like they're a 1:many form
of tagging.

--
Rich

Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds

[Rich Freeman]

On Wed, Sep 10, 2014 at 7:33 AM, Pacho Ramos <pacho@gentoo.org> wrote:
>
> Personally I would vote for simply have a <maintainer> tag pointing to
> the alias but we would still need to keep a list of real maintainers for
> that alias as usually not all people listed in the alias are willing to
> maintain the packages.
>

I think the solution to this is that maintainers can be either:
1.  Devs - identified by their email address.  (simple enough)
or
2.  Projects - identified by their email alias.
or
3.  A proxy maintainer identified by email address (in which case
either a dev or project must also be listed, potentially including the
proxy maintainer project).

A project must have:
1.  A mail alias.  Anybody can monitor if the project is OK with it,
but it isn't the definitive member list.
2.  A project page on the wiki with a member list.  This is the
definitive list of who is a member.
3.  An annually-elected lead.

The lead should clean up the member list from time to time.  An
inactive project should be treated the same as an inactive dev as far
as maintainership goes - target for cleanup.  Special projects like
archs/infra/comrel/etc should probably be escalated to council if they
appear dead.

Herds are just collections of packages - a package being in a herd
says nothing about whether it is maintained, just as a package being
in a category says nothing about it being maintained.

--
Rich

Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds

[Tom Wijsman]

On Tue, 9 Sep 2014 21:45:49 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> Let's keep it short: I think herds don't serve any special purpose
> nowadays. Their existence is mostly resulting in lack of consistency
> and inconveniences.

+1; to summarize my thoughts: Herds misrepresent manpower.

Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1139 bytes --]

Dnia 2014-09-10, o godz. 07:53:31
Rich Freeman <rich0@gentoo.org> napisał(a):

> On Wed, Sep 10, 2014 at 7:33 AM, Pacho Ramos <pacho@gentoo.org> wrote:
> >
> > Personally I would vote for simply have a <maintainer> tag pointing to
> > the alias but we would still need to keep a list of real maintainers for
> > that alias as usually not all people listed in the alias are willing to
> > maintain the packages.
> >
> 
> I think the solution to this is that maintainers can be either:
> 1.  Devs - identified by their email address.  (simple enough)
> or
> 2.  Projects - identified by their email alias.
> or
> 3.  A proxy maintainer identified by email address (in which case
> either a dev or project must also be listed, potentially including the
> proxy maintainer project).

4. A mail alias that is not project :). For example, we have clang@ for
easily aggregating all clang-related build failures and other bugs but
it isn't a formal team.

It's hard if such a thing has proper member list. But in any case, is
there a reason for needing to have definitive member list?

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

[gentoo-dev] Re: RFC: Deprecating and killing the concept of herds

[Steven J. Long]

On Wed, Sep 10, 2014 at 07:53:31AM -0400, Rich Freeman wrote:
> On Wed, Sep 10, 2014 at 7:33 AM, Pacho Ramos <pacho@gentoo.org> wrote:
> >
> > Personally I would vote for simply have a <maintainer> tag pointing to
> > the alias but we would still need to keep a list of real maintainers for
> > that alias as usually not all people listed in the alias are willing to
> > maintain the packages.
> >
> 
> I think the solution to this is that maintainers can be either:
> 1.  Devs - identified by their email address.  (simple enough)
> or
> 2.  Projects - identified by their email alias.
> or
> 3.  A proxy maintainer identified by email address (in which case
> either a dev or project must also be listed, potentially including the
> proxy maintainer project).
> 
> A project must have:
> 1.  A mail alias.  Anybody can monitor if the project is OK with it,
> but it isn't the definitive member list.
> 2.  A project page on the wiki with a member list.  This is the
> definitive list of who is a member.
> 3.  An annually-elected lead.
> 
> The lead should clean up the member list from time to time.  An
> inactive project should be treated the same as an inactive dev as far
> as maintainership goes - target for cleanup.  Special projects like
> archs/infra/comrel/etc should probably be escalated to council if they
> appear dead.
> 
> Herds are just collections of packages - a package being in a herd
> says nothing about whether it is maintained, just as a package being
> in a category says nothing about it being maintained.
> 

Thanks for that lucid explanation. It's clear the metadata is useful,
for keeping track of apps cross-tree, but it's being confused with a
project, as you outlined in your other mail. Perhaps this is because
people are considered members of herds, when really they should just
be on the mail alias. Additionally, herd metadata should be seen as
*strictly* about cross-tree categorisation, and cleaned up on that
basis (whether there are still any packages, or the grouping is
still relevant), reviewed by tree-cleaners.

(If they're not already; idk your procedures, ofc.)

I think the confusion is understandable though, as people are
constantly checking who's on the alias for a herd with willikins.
That leads to the conception that a herd is a group of devs/proxy,
not a group of packages. It's hard to shake when you're constantly
looking up a group of devs based on !herd[1], or reading it (with
the list of _people_) in channel after channel.

It would be better if people were checking projects, from what you
wrote above. I would recommend reworking that to !project, with
!herd supplying a link to the listing of _packages_ belonging to
the herd on the website, instead. Since as you say, a herd is a
group of packages, whereas a project is a group of developers.

Either that, or give up and let a herd of cats, be a herd of cats ;)

Regards,
steveL

[1] eg: /msg willikins herd kde
-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds

[Rich Freeman]

On Wed, Sep 10, 2014 at 10:18 AM, Michał Górny <mgorny@gentoo.org> wrote:
> Dnia 2014-09-10, o godz. 07:53:31
> Rich Freeman <rich0@gentoo.org> napisał(a):
>
>> On Wed, Sep 10, 2014 at 7:33 AM, Pacho Ramos <pacho@gentoo.org> wrote:
>> >
>> > Personally I would vote for simply have a <maintainer> tag pointing to
>> > the alias but we would still need to keep a list of real maintainers for
>> > that alias as usually not all people listed in the alias are willing to
>> > maintain the packages.
>> >
>>
>> I think the solution to this is that maintainers can be either:
>> 1.  Devs - identified by their email address.  (simple enough)
>> or
>> 2.  Projects - identified by their email alias.
>> or
>> 3.  A proxy maintainer identified by email address (in which case
>> either a dev or project must also be listed, potentially including the
>> proxy maintainer project).
>
> 4. A mail alias that is not project :). For example, we have clang@ for
> easily aggregating all clang-related build failures and other bugs but
> it isn't a formal team.
>
> It's hard if such a thing has proper member list. But in any case, is
> there a reason for needing to have definitive member list?

I don't think we should allow #4 in the absence of #1-2, because mail
aliases shouldn't be maintainers.  What #4 says is "I'd like to know
what is going on with a package, but don't look at me if it breaks."

The challenge is that people are going to fail to distinguish between
these aliases and ones that belong to projects, because they look the
same.  Why should we have a clang email alias if there isn't a clang
project?  Why not just make it into a project?  It sounds like you
have a bunch of devs who want to stay on top of clang so that it is
well-supported in the tree, and that is basically the definition of a
project.  You don't need to have meetings, agendas, minutes, and
bylaws to be a project - just a common purpose.

I'm not opposed to finding better ways to keep people informed.  I
just don't want to equate a desire to be informed with a commitment to
maintain something - which we've already identified as a problem.

Also, you spoke about clang-related build failures.  You probably
wouldn't be tagging packages with that alias in that case - you'd just
have it as a CC alias on bugs.  You're more interested in specific
bugs than specific packages.

--
Rich

Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds

[Markos Chandras]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 09/10/2014 03:01 PM, Tom Wijsman wrote:
> On Tue, 9 Sep 2014 21:45:49 +0200 Michał Górny <mgorny@gentoo.org>
> wrote:
> 
>> Let's keep it short: I think herds don't serve any special
>> purpose nowadays. Their existence is mostly resulting in lack of
>> consistency and inconveniences.
> 
> +1; to summarize my thoughts: Herds misrepresent manpower.
> 
true and false. undertakers often remove dead herds. And herds in need
for more people should really make use of this wiki page

https://wiki.gentoo.org/wiki/Project:Gentoo/Staffing_Needs

how do you expect to get more people on board if you don't make it
known where help is actually needed?

- -- 
Regards,
Markos Chandras
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQF8BAEBCgBmBQJUELLEXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGRDlGMzA4MUI2MzBDODQ4RDBGOEYxMjQx
RjEwRUQ0QjgxREVCRjE5AAoJEB8Q7UuB3r8Z1WAIAKW0Q1KipbiIGsOZ/R9vjgIQ
fA7gJx5D+YcFyJdqPQUm5qt9WqxQv8p8TD5tacihxIF13WCS8BnMxDUf3BbErWJF
8RBPR2/T2L303YJ3xq/hTsdI2MoEiaKaOSUSDIbT18pNyLLNRabIBDLpM8jRPl0i
cLK70yUwkht70y8tI8NiCQCtSk6dMZpzgvq9JFNyDO+jPlSt3NMMIO6KsCg7ZfH1
8pqiAUW9T3BwrX0nWGWgnUguuZ6+Q5UJXVvELWtHDeyuVq02MNdJqPLfTEeo9U+6
SMCquUU7/Owg2cXLCVG0arrEeJEgoWR7qtPMZqkxmIH1c1OlS81WEHoH/29uqAQ=
=Dijl
-----END PGP SIGNATURE-----

[gentoo-dev] Re: RFC: Deprecating and killing the concept of herds

[Duncan]

Markos Chandras posted on Wed, 10 Sep 2014 21:21:24 +0100 as excerpted:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> On 09/10/2014 03:01 PM, Tom Wijsman wrote:
>> On Tue, 9 Sep 2014 21:45:49 +0200 Michał Górny <mgorny@gentoo.org>
>> wrote:
>> 
>>> Let's keep it short: I think herds don't serve any special purpose
>>> nowadays. Their existence is mostly resulting in lack of consistency
>>> and inconveniences.
>> 
>> +1; to summarize my thoughts: Herds misrepresent manpower.
>> 
> true and false. undertakers often remove dead herds. And herds in need
> for more people should really make use of this wiki page
> 
> https://wiki.gentoo.org/wiki/Project:Gentoo/Staffing_Needs
> 
> how do you expect to get more people on board if you don't make it known
> where help is actually needed?

You fell into the same initial trap as I did, thus demonstrating the 
point. =:^\

The above is a PROJECT page, not a HERD page.  Herds are groups of 
packages, not people, and shouldn't, at least directly, be "in need of 
more people".

And if herds are groups of packages, shouldn't it be tree-cleaners, not 
undertakers, removing dead herds?

Of course that confusion is the point of the thread.  Why not simply 
deprecate and eventually kill herds and assign packages directly to 
projects, instead of assigning them to herds which must then cross-
checked against an entirely different file in ordered to find the 
responsible project.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds

[Tom Wijsman]

On Wed, 10 Sep 2014 21:21:24 +0100
Markos Chandras <hwoarang@gentoo.org> wrote:

> On 09/10/2014 03:01 PM, Tom Wijsman wrote:
> > 
> > +1; to summarize my thoughts: Herds misrepresent manpower.
> > 
> true and false.

More true than false.

> undertakers often remove dead herds.

How often? What is considered dead? How about semi-dead? How about the
misrepresented ones? Are metrics like commit and bug ratios considered?

Relevant: http://www.gossamer-threads.com/lists/gentoo/dev/258463

> And herds in need for more people should really make use of this wiki
> page
> 
> https://wiki.gentoo.org/wiki/Project:Gentoo/Staffing_Needs

They do and don't.

Those that do, are drowned in a long list that rarely attracts new devs;
those that don't, don't have time for it as they are drowned in work.

The recruitment process is too lengthy compared to the amount of
people that can actively recruit new developers; as a result, this
contributes to the rarity of attracting new developers to that list.

This lengthy process is also unattractive to new recruiters; whom are
not kept in the loop when showing interest, eg. I've watched a few
sessions and then heard nothing (because there barely are recruiters?).

If we want to thrive, both the student and recruiter recruitment
processes need to be revised; at this moment, 13 students are in the
queue. Some of them have been waiting for weeks or months...

> how do you expect to get more people on board if you don't make it
> known where help is actually needed?

This acknowledges that the herds concept hides where help is needed;
but as revealed in the last paragraphs, that's not the only problem.

Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds

[Markos Chandras]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 09/11/2014 07:30 PM, Tom Wijsman wrote:
> On Wed, 10 Sep 2014 21:21:24 +0100 Markos Chandras
> <hwoarang@gentoo.org> wrote:
> 
>> On 09/10/2014 03:01 PM, Tom Wijsman wrote:
>>> 
>>> +1; to summarize my thoughts: Herds misrepresent manpower.
>>> 
>> true and false.
> 
> More true than false.
> 
>> undertakers often remove dead herds.
> 
> How often? What is considered dead? How about semi-dead? How about
> the misrepresented ones? Are metrics like commit and bug ratios
> considered?
> 
> Relevant: http://www.gossamer-threads.com/lists/gentoo/dev/258463
> 
>> And herds in need for more people should really make use of this
>> wiki page
>> 
>> https://wiki.gentoo.org/wiki/Project:Gentoo/Staffing_Needs
> 
> They do and don't.
> 
> Those that do, are drowned in a long list that rarely attracts new
> devs; those that don't, don't have time for it as they are drowned
> in work.
> 
> The recruitment process is too lengthy compared to the amount of 
> people that can actively recruit new developers; as a result, this 
> contributes to the rarity of attracting new developers to that
> list.
> 
> This lengthy process is also unattractive to new recruiters; whom
> are not kept in the loop when showing interest, eg. I've watched a
> few sessions and then heard nothing (because there barely are
> recruiters?).
> 
> If we want to thrive, both the student and recruiter recruitment 
> processes need to be revised; at this moment, 13 students are in
> the queue. Some of them have been waiting for weeks or months...
> 
>> how do you expect to get more people on board if you don't make
>> it known where help is actually needed?
> 
> This acknowledges that the herds concept hides where help is
> needed; but as revealed in the last paragraphs, that's not the only
> problem.
> 

please do not go offtopic discussing the recruitment process. I simply
mentioned one of the designated ways we have to ask for help. If you
don't like it, propose a better method.

- -- 
Regards,
Markos Chandras
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQF8BAEBCgBmBQJUEf9QXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGRDlGMzA4MUI2MzBDODQ4RDBGOEYxMjQx
RjEwRUQ0QjgxREVCRjE5AAoJEB8Q7UuB3r8Z5S4H/RzX++Z/slhMjpYwGqu4zA1P
DgByLHnINhQPFpNYIxfgvAFCjVp+drCllRvzvE3IdCdfR1HsLUYeLNMDby8SQlAr
axHklrtQGeSXK9rd9leYvfa/lCzNahFj5PWbPeJFco1j7V7BDJCYKS1FxQpQhAyg
H5MiBFDRZK403qt8U4JsOCGEpI5Uy+US+xTAXHTV0u0YKW0u8S/znju6TM2WVWy2
qFTTQvH4vNf38zj6+UVzFa16xw5wYeIajMHLm7cTg98pDU4UcVEbeeZ0vEUX6DS8
XSlGO93haF9E4v4giMaQXXHtRmJzhHXdx78mnir4u1tdIfqG3Q8bjGnNVmu7GWU=
=UyIv
-----END PGP SIGNATURE-----

Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds

[Tom Wijsman]

On Thu, 11 Sep 2014 21:00:16 +0100
Markos Chandras <hwoarang@gentoo.org> wrote:

> please do not go offtopic discussing the recruitment process. I simply
> mentioned one of the designated ways we have to ask for help. If you
> don't like it, propose a better method.

Please do not go offtopic about your own "getting people on board". I
simply suggested improvements to one of the designated ontopic problems
that can be seen in herds. If you don't like it, write a better reply.

Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds

[W. Trevor King]

[-- Attachment #1: Type: text/plain, Size: 2222 bytes --]

On Wed, Sep 10, 2014 at 04:18:40PM +0200, Michał Górny wrote:
> Dnia 2014-09-10, o godz. 07:53:31 Rich Freeman napisał(a):
> > On Wed, Sep 10, 2014 at 7:33 AM, Pacho Ramos wrote:
> > > Personally I would vote for simply have a <maintainer> tag pointing to
> > > the alias but we would still need to keep a list of real maintainers for
> > > that alias as usually not all people listed in the alias are willing to
> > > maintain the packages.
> > 
> > I think the solution to this is that maintainers can be either:
> > 1.  Devs - identified by their email address.  (simple enough)
> > or
> > 2.  Projects - identified by their email alias.
> > or
> > 3.  A proxy maintainer identified by email address (in which case
> > either a dev or project must also be listed, potentially including the
> > proxy maintainer project).
> 
> 4. A mail alias that is not project :). For example, we have clang@ for
> easily aggregating all clang-related build failures and other bugs but
> it isn't a formal team.

As an incremental solution, what about a <watcher> tag in metadata.xml
with the same format as <maintainer> except that being a watcher
doesn't imply a willingness to *do* anything about a project, it just
means you want to be notified of changes and added to the CC list.
Then devs can sign up to maintain or watch packages without using
herds.  Folks who find herds convenient can continue to use them with
as implied maintainers [1] (or implied watchers, I don't really care).
Folks who don't find herds convenient can leave them and just add
their maintainer/watcher tags directly.  Then reap herds if/when they
go empty.  I don't see the need for a dramatic change here, or even
one that requires much consensus building.  Or is a <watcher> tag
controversial?  I'm not sure how the bugzilla CC lists are generated,
maybe it would be terribly complicated to iterate over maintainers +
watchers?

Cheers,
Trevor

[1]: http://article.gmane.org/gmane.linux.gentoo.devel/92877
     id:1410348781.5850.7.camel@gentoo.org

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds

[Rich Freeman]

On Wed, Sep 24, 2014 at 12:31 PM, W. Trevor King <wking@tremily.us> wrote:
> On Wed, Sep 10, 2014 at 04:18:40PM +0200, Michał Górny wrote:
>>
>> 4. A mail alias that is not project :). For example, we have clang@ for
>> easily aggregating all clang-related build failures and other bugs but
>> it isn't a formal team.
>
> As an incremental solution, what about a <watcher> tag in metadata.xml
> with the same format as <maintainer> except that being a watcher
> doesn't imply a willingness to *do* anything about a project, it just
> means you want to be notified of changes and added to the CC list.

I'd given some thought to this as well, but didn't think it was a good idea.

First, you can already create queries in bugzilla.

Second, if we wanted something more robust than being interested in a
package isn't something that is limited to devs.  If you're just going
to look at bugs but not do anything about them, then you are really
just a user who might happen to also have commit access.  Do we really
need to have a developer-only way of getting bug CC's for people who
don't actually want to fix the bugs?  Or, would it make more sense to
find a way for anybody to follow issues in packages, assuming bugzilla
queries aren't enough?

Now, if something like clang@ isn't a formal team but does consist of
people who are actually doing something, why not just make it a
project?  After all, a group of people interested in actually doing
something basically is the definition of a project.  Being a project
isn't some kind of huge commitment. and I think it makes sense to just
have devs and groups of devs instead of having 12 different kinds of
groups of devs and we can't keep straight which kinds of groups do (or
more typically don't do) what.

--
Rich

Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds

[W. Trevor King]

[-- Attachment #1: Type: text/plain, Size: 1515 bytes --]

On Thu, Sep 25, 2014 at 11:00:32AM -0400, Rich Freeman wrote:
> On Wed, Sep 24, 2014 at 12:31 PM, W. Trevor King wrote:
> > On Wed, Sep 10, 2014 at 04:18:40PM +0200, Michał Górny wrote:
> >>
> >> 4. A mail alias that is not project :). For example, we have
> >> clang@ for easily aggregating all clang-related build failures
> >> and other bugs but it isn't a formal team.
> >
> > As an incremental solution, what about a <watcher> tag in
> > metadata.xml with the same format as <maintainer> except that
> > being a watcher doesn't imply a willingness to *do* anything about
> > a project, it just means you want to be notified of changes and
> > added to the CC list.
> 
> I'd given some thought to this as well, but didn't think it was a
> good idea.
> 
> First, you can already create queries in bugzilla.

Not all package activity has an associated bugzilla entry, but maybe
enough of it does?

> Or, would it make more sense to find a way for anybody to follow
> issues in packages, assuming bugzilla queries aren't enough?

What about a <list> entry in metadata.xml that points people to the
suggested mailing list for discussing a package?  Bugzilla could
automatically add the list to its CC list, and both devs and non-devs
could join the list without adding a lot of email addresses to the
tree.

Cheers,
Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds

[Rich Freeman]

On Thu, Sep 25, 2014 at 11:29 AM, W. Trevor King <wking@tremily.us> wrote:
>
> What about a <list> entry in metadata.xml that points people to the
> suggested mailing list for discussing a package?  Bugzilla could
> automatically add the list to its CC list, and both devs and non-devs
> could join the list without adding a lot of email addresses to the
> tree.
>

Yeah, I was thinking about something like an automatic per-package
email list or something like that, but I'm not sure how much use it
would get, and it would of course fragment discussions all over the
place.

I do prefer things like lists to aliases in general though, since
they're more public and archived.

--
Rich

Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds

[W. Trevor King]

[-- Attachment #1: Type: text/plain, Size: 1137 bytes --]

On Thu, Sep 25, 2014 at 11:49:53AM -0400, Rich Freeman wrote:
> On Thu, Sep 25, 2014 at 11:29 AM, W. Trevor King <wking@tremily.us> wrote:
> > What about a <list> entry in metadata.xml that points people to
> > the suggested mailing list for discussing a package?  Bugzilla
> > could automatically add the list to its CC list, and both devs and
> > non-devs could join the list without adding a lot of email
> > addresses to the tree.
> 
> Yeah, I was thinking about something like an automatic per-package
> email list or something like that, but I'm not sure how much use it
> would get, and it would of course fragment discussions all over the
> place.

The benefit to a <list> entry is that it doesn't need to be
per-package.  Everything currently in the python herd could be pushed
to gentoo-python@.  If the folks running that list thing
dev-python/somepackage is too noisy, they can kick them off, and make
them spin up their own list.

Cheers,
Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds

[Jeroen Roovers]

On Tue, 9 Sep 2014 21:45:49 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> Hello,
> 
> Let's keep it short: I think herds don't serve any special purpose
> nowadays. Their existence is mostly resulting in lack of consistency
> and inconveniences.
> 
> In particular:
> 
> 1. We have two different tags in metadata.xml that serve a similar
> purpose -- <herd/> and <maintainer/>, with <herd/> being less
> descriptive. For this reason, sometimes herd's associated e-mail is
> listed as <maintainer/>, and sometimes even the same thing is listed
> using both tags.

Herds are groups of people that the Gentoo Project knows about. There
may be other aliases, but these particular ones are bound to a
@gentoo.org alias. That is what the <herd> tags convey. In April 2008 we
came to some sort of agreement about the way bugs are assigned (first
<maintainer> is assignee, rest is CC'd, first <herd> is assignee when
no <maintainer> is mentioned) and that works quite well (especially
because the assignee is now not the person "blamed" for a bug report).

A <herd> is a group of people, and a <maintainer> is not. If a new
developer Devon comes along and is allowed to choose a nick like
"gentoo-devs" (he considers himself a member of "Gentoo" (wat?) and
"Devs" is what everyone already calls him), then the difference in
tags should make a clear distinction:

<herd>gentoo-devs</herd> <!-- This is a group of people -->
<maintainer><email>gentoo-devs</email></maintainer> <!-- This speaks
for itself -->

If there is any lack of clarity here, herd members should clear up which
is which.

As the way <herd> and <maintainer> tags are listed in metadata.xml is
important, people have got creative with that format, and that's how we
ended up reading this thread. We could change that first, and simply
change the rules for bug assignment:

1) First <herd> or <maintainer> is the Assignee.
2) The rest is CC'd.

People will still insist on adding comments and attributes that state
exceptions, but that's fine.

> 2. The common use of <herd/> and <maintainer/> thingies forces
> a particular maintainership model. In particular, we always assume
> <maintainer/> comes first, and <herd/> serves as a backup. You can't
> properly say otherwise using both tags.

How is that an inconvenience (since it is done consistently)? It's
good to know whether you are addressing a single individual or a group.
Conversely it is already good practice to not post to mailing lists and
use the bug tracker in the name of a whole team (there have been
instances where someone was accidentally logged in under a herd title -
that's a bad thing).

> 3. The project member and herd member lists are constantly outdated.
> In fact, most of the herds don't even list members -- just point out
> to outdated project pages :).

So these should be automagically updated to reflect the alias' list of
real e-mail addresses? Sure, it's inconvenient the way it is now (and
has been for years), but that doesn't mean we should drop herds
altogether.

> 4. The whole indirection is just irritating. You can't assign a bug
> using metadata.xml without fetching herds.xml that's in a different
> CVS repo.

I seem to recall lamenting the lack of a proper link between the two
years ago, arguing that either a) bugzilla should automatically expand
<herd> with @gentoo.org (which fails when projects inexplicably choose
username strings that are different from the respective <herd> strings),
or that b) in metadata.xml the full e-mail address should be used
instead of a keyword that needs to be looked up.

> What do you think?

Right now, CC'ing a single alias is inconvenient, but under your
proposal, you might need to CC a dozen or more people instead of that
alias.

Herd aliases (and e-mail aliases in general) are convenient in that you
don't need to constantly update who is CC'd on mail and bugzilla. You
haven't shown a convenient alternative for that.

If herds are just that - aliases - and nothing more, then I say we keep
them and fix the indirection in <herd> <=> alias instead of dropping
the whole concept.


        jer

Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds

[Rich Freeman]

On Sat, Sep 27, 2014 at 4:58 AM, Jeroen Roovers <jer@gentoo.org> wrote:
>
> Right now, CC'ing a single alias is inconvenient, but under your
> proposal, you might need to CC a dozen or more people instead of that
> alias.
>

That is incorrect.  Herds would be replaced with projects, not with
lists of individual (non-)maintainers.

I don't think that anybody thinks that having groups of devs isn't
useful.  The problem is that we have two different mechanisms for
having groups of people, and one of them seems to make more sense than
the other.

Answer this:  5 developers want to maintain a group of packages
together.  Should they form a herd, or a project?  Under what
circumstances should they choose one vs the other?

I don't think the distinction is particularly useful, and projects at
least have a straightforward governance model.

--
Rich

Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds

[Jeroen Roovers]

On Sat, 27 Sep 2014 06:25:28 -0400
Rich Freeman <rich0@gentoo.org> wrote:

> On Sat, Sep 27, 2014 at 4:58 AM, Jeroen Roovers <jer@gentoo.org>
> wrote:
> >
> > Right now, CC'ing a single alias is inconvenient, but under your
> > proposal, you might need to CC a dozen or more people instead of
> > that alias.
> >
> 
> That is incorrect.  Herds would be replaced with projects, not with
> lists of individual (non-)maintainers.

No, it's entirely correct. Killing <herd> but keeping <maintainer> with
its current denotation and connotation would mean listing separate
actual maintainers.

Luckily we can instead choose to replace the contents of <herd> with
the alias listed in herds.xml. We would then be changing the meaning of
<maintainer> in addition to removing <herd>.

It all depends on how you interpret the "using the alias" in the
original thread starter, I guess.

> I don't think that anybody thinks that having groups of devs isn't
> useful.  The problem is that we have two different mechanisms for
> having groups of people, and one of them seems to make more sense than
> the other.

Right. And nobody was contesting that.


     jer

Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds

[Rich Freeman]

On Sat, Sep 27, 2014 at 6:51 AM, Jeroen Roovers <jer@gentoo.org> wrote:
> On Sat, 27 Sep 2014 06:25:28 -0400
> Rich Freeman <rich0@gentoo.org> wrote:
>
>> On Sat, Sep 27, 2014 at 4:58 AM, Jeroen Roovers <jer@gentoo.org>
>> wrote:
>> >
>> > Right now, CC'ing a single alias is inconvenient, but under your
>> > proposal, you might need to CC a dozen or more people instead of
>> > that alias.
>> >
>>
>> That is incorrect.  Herds would be replaced with projects, not with
>> lists of individual (non-)maintainers.
>
> No, it's entirely correct. Killing <herd> but keeping <maintainer> with
> its current denotation and connotation would mean listing separate
> actual maintainers.
>

Is there some policy that says that a project cannot be a maintainer?
How do we currently handle packages that are maintained by a project
which doesn't have a corresponding herd?

Why not just stick the project alias in the maintainer field?

I can't find any "denotation" that states that this isn't acceptable,
but if there is one I'm all ears.

--
Rich

[gentoo-dev] Re: RFC: Deprecating and killing the concept of herds

[Michael Palimaka]

On 09/27/2014 08:51 PM, Jeroen Roovers wrote:
> On Sat, 27 Sep 2014 06:25:28 -0400
> Rich Freeman <rich0@gentoo.org> wrote:
> 
>> On Sat, Sep 27, 2014 at 4:58 AM, Jeroen Roovers <jer@gentoo.org>
>> wrote:
>>>
>>> Right now, CC'ing a single alias is inconvenient, but under your
>>> proposal, you might need to CC a dozen or more people instead of
>>> that alias.
>>>
>>
>> That is incorrect.  Herds would be replaced with projects, not with
>> lists of individual (non-)maintainers.
> 
> No, it's entirely correct. Killing <herd> but keeping <maintainer> with
> its current denotation and connotation would mean listing separate
> actual maintainers.
> 
> Luckily we can instead choose to replace the contents of <herd> with
> the alias listed in herds.xml. We would then be changing the meaning of
> <maintainer> in addition to removing <herd>.
> 
> It all depends on how you interpret the "using the alias" in the
> original thread starter, I guess.

Don't forget that presence or lack thereof on an alias is no indication
of a person's project membership. In KDE project for example we have
people on our alias that are not part of the project, and people not
that are.

Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds

[Jeroen Roovers]

On Sat, 27 Sep 2014 09:11:57 -0400
Rich Freeman <rich0@gentoo.org> wrote:

> Is there some policy that says that a project cannot be a maintainer?

I guess you missed an interesting discussion on #gentoo-dev today.


     jer

Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds

[Tom Wijsman]

On Sat, 27 Sep 2014 06:25:28 -0400
Rich Freeman <rich0@gentoo.org> wrote:

> On Sat, Sep 27, 2014 at 4:58 AM, Jeroen Roovers <jer@gentoo.org>
> wrote:
> >
> > Right now, CC'ing a single alias is inconvenient, but under your
> > proposal, you might need to CC a dozen or more people instead of
> > that alias.
> >
> 
> That is incorrect.  Herds would be replaced with projects, not with
> lists of individual (non-)maintainers.
> 
> I don't think that anybody thinks that having groups of devs isn't
> useful.  The problem is that we have two different mechanisms for
> having groups of people, and one of them seems to make more sense than
> the other.
> 
> Answer this:  5 developers want to maintain a group of packages
> together.  Should they form a herd, or a project?  Under what
> circumstances should they choose one vs the other?
> 
> I don't think the distinction is particularly useful, and projects at
> least have a straightforward governance model.
> 
> --
> Rich
> 

Herds cannot be replaced by projects, because projects can contain
multiple herds; iotw, there's no one-to-one mapping between them.

I don't think having multiple mechanisms to form groups is a problem;
from my previous paragraph, it becomes clear that it is a solution.

Answer: The project model has some concepts that herds do not have.

I don't think discussing this is useful, projects are documented.

Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds

[Tom Wijsman]

On Sat, 27 Sep 2014 09:11:57 -0400
Rich Freeman <rich0@gentoo.org> wrote:

> Is there some policy that says that a project cannot be a maintainer?

Is there some policy that says that a herd cannot be a herd?

Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 440 bytes --]

Am Samstag, 27. September 2014, 23:41:04 schrieb Tom Wijsman:
> On Sat, 27 Sep 2014 09:11:57 -0400
> 
> Rich Freeman <rich0@gentoo.org> wrote:
> > Is there some policy that says that a project cannot be a maintainer?
> 
> Is there some policy that says that a herd cannot be a herd?

Only for sufficiently small values of 1/0.

-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfridge@gentoo.org
http://www.akhuettel.de/


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 951 bytes --]

Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds

[Anthony G. Basile]

On 09/27/14 17:35, Tom Wijsman wrote:
> On Sat, 27 Sep 2014 06:25:28 -0400
> Rich Freeman <rich0@gentoo.org> wrote:
>
>> On Sat, Sep 27, 2014 at 4:58 AM, Jeroen Roovers <jer@gentoo.org>
>> wrote:
>>> Right now, CC'ing a single alias is inconvenient, but under your
>>> proposal, you might need to CC a dozen or more people instead of
>>> that alias.
>>>
>> That is incorrect.  Herds would be replaced with projects, not with
>> lists of individual (non-)maintainers.
>>
>> I don't think that anybody thinks that having groups of devs isn't
>> useful.  The problem is that we have two different mechanisms for
>> having groups of people, and one of them seems to make more sense than
>> the other.
>>
>> Answer this:  5 developers want to maintain a group of packages
>> together.  Should they form a herd, or a project?  Under what
>> circumstances should they choose one vs the other?
>>
>> I don't think the distinction is particularly useful, and projects at
>> least have a straightforward governance model.
>>
>> --
>> Rich
>>
> Herds cannot be replaced by projects, because projects can contain
> multiple herds; iotw, there's no one-to-one mapping between them.
The hardened project has two herds: hardened and hardened-kernel, the 
former for toolchain related stuff and the latter for the kernel.  We 
really need to keep that distinction.  So mapping herds to projects 
doesn't work.  But, mapping hardened/hardened-kernel to our 
*subprojects* structure does.  Perhaps that might be a more natural 
solution in general, not just for hardened.

We might proceed by associating each herd to a project, and then letting 
them decide whether to absorb the herd(s) into their project level, or 
break it down to subprojects.  So as another example, ppc and ppc64 
teams are merging into one team (powerpc) with one lead (currently 
jmorgan).  There also we want to keep two herds for the two different 
arches for keywording/stabilizing requests.  If we just say "ppc and 
ppc64 herds belong to powerpc team", then it will be easy to change 
"herd" to "subproject" requiring nothing more than just a webpage put up 
if it doesn't already exist.

>
> I don't think having multiple mechanisms to form groups is a problem;
> from my previous paragraph, it becomes clear that it is a solution.
>
> Answer: The project model has some concepts that herds do not have.
>
> I don't think discussing this is useful, projects are documented.
>


-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds

[Tom Wijsman]

On Sat, 27 Sep 2014 17:54:48 -0400
"Anthony G. Basile" <blueness@gentoo.org> wrote:

> The hardened project has two herds: hardened and hardened-kernel, the 
> former for toolchain related stuff and the latter for the kernel.  We 
> really need to keep that distinction.  So mapping herds to projects 
> doesn't work.  But, mapping hardened/hardened-kernel to our 
> *subprojects* structure does.  Perhaps that might be a more natural 
> solution in general, not just for hardened.
> 
> We might proceed by associating each herd to a project, and then
> letting them decide whether to absorb the herd(s) into their project
> level, or break it down to subprojects.  So as another example, ppc
> and ppc64 teams are merging into one team (powerpc) with one lead
> (currently jmorgan).  There also we want to keep two herds for the
> two different arches for keywording/stabilizing requests.  If we just
> say "ppc and ppc64 herds belong to powerpc team", then it will be
> easy to change "herd" to "subproject" requiring nothing more than
> just a webpage put up if it doesn't already exist.

Yes, if you do create a one-on-one mapping then it becomes possible.
The question becomes "does every herd want to become a (sub)project?".

Ideally, they should! Theoretically, there is no problem. Practically,
for some herds it'll involve extra work setting up the project related
stuff and so on when there is no need for it.

Example: If I were to create a MATE herd, that doesn't mean I want a
MATE project; documentation wise, the Gentoo Wiki article suffices.

Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2122 bytes --]

Dnia 2014-09-28, o godz. 00:13:15
Tom Wijsman <TomWij@gentoo.org> napisał(a):

> On Sat, 27 Sep 2014 17:54:48 -0400
> "Anthony G. Basile" <blueness@gentoo.org> wrote:
> 
> > The hardened project has two herds: hardened and hardened-kernel, the 
> > former for toolchain related stuff and the latter for the kernel.  We 
> > really need to keep that distinction.  So mapping herds to projects 
> > doesn't work.  But, mapping hardened/hardened-kernel to our 
> > *subprojects* structure does.  Perhaps that might be a more natural 
> > solution in general, not just for hardened.
> > 
> > We might proceed by associating each herd to a project, and then
> > letting them decide whether to absorb the herd(s) into their project
> > level, or break it down to subprojects.  So as another example, ppc
> > and ppc64 teams are merging into one team (powerpc) with one lead
> > (currently jmorgan).  There also we want to keep two herds for the
> > two different arches for keywording/stabilizing requests.  If we just
> > say "ppc and ppc64 herds belong to powerpc team", then it will be
> > easy to change "herd" to "subproject" requiring nothing more than
> > just a webpage put up if it doesn't already exist.
> 
> Yes, if you do create a one-on-one mapping then it becomes possible.
> The question becomes "does every herd want to become a (sub)project?".
> 
> Ideally, they should! Theoretically, there is no problem. Practically,
> for some herds it'll involve extra work setting up the project related
> stuff and so on when there is no need for it.
> 
> Example: If I were to create a MATE herd, that doesn't mean I want a
> MATE project; documentation wise, the Gentoo Wiki article suffices.

I don't know if you know it but setting up the project wiki page takes
less time than reaching into depths of CVS and editing herds.xml.

You just convinced me that we should definitely drop herds. Otherwise,
we'll never going to get out of the dumb distinction what project
and herd is and isn't, and when one or the other, or both should be
used.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds

[Rich Freeman]

On Sat, Sep 27, 2014 at 6:13 PM, Tom Wijsman <TomWij@gentoo.org> wrote:
> The question becomes "does every herd want to become a (sub)project?".
>

So, there was some discussion on -dev, apparently some discussion I
wasn't a part of, and some that I was (such is the nature of IRC).

I think it would make sense to take a step back and ask what we'd do
if we were starting with a blank slate.  Aliases, herds, and projects
are all ways of grouping people, but they are used in different ways,
sometimes.

My real problem with herds isn't the idea of having more than one way
to group people.  My real issue is that we have several ways of
grouping people and no consistent way of doing so.  You have to look
in different places to find out who is on an alias/herd/project.  We
have cases where more than one of these are loosely associated, but
membership is inconsistent.  We have inactive examples of all three.

So, let's step back and think about why developers would want to be
part of a group, forget about what we call these groups, and then
figure out what kind of model makes the most sense and how to get
there.  In the final design we might want to not split groupings up
all over the place (wiki vs herds.xml vs alias files that nobody but
devs can read).

So, one level of association might be registering an interest - such
as what is sometimes done with a mail alias.  A developer, or even a
non-developer, might want to be informed about what is going on with a
package or group of packages, but they are not making any kind of
commitment to actually taking care of them.

The opposite would be a project as defined in GLEP 39.  This is a
formal association of developers that elects a lead, and acts as a
unit.  The project could establish policies and it is generally
expected that they be followed (we can escalate to the Council if
there is a problem).  This is especially valuable for core
dependencies like toolchain, frameworks, etc where good planning makes
everybody's lives easier.

Then you have groups of people who sort-of maintain peripheral
packages, which is what I think is what many herds are (but their use
is totally inconsistent, so this isn't true everywhere).  My issue
with this sort of thing is that it is really hard to tell if a package
is actually maintained.  Devs basically drop-in to scratch an itch and
then abandon things.  Emails to aliases get ignored, since nobody in
particular is in charge.

That is my main issue with herds - they're dumping grounds for bugs
that nobody seems to care about, at least in some cases.

With a project you can at least ask "have you selected a lead in the
last year" and get some kind of pulse on activity.  Herds are nice
from the standpoint that they cost nothing to maintain, but that also
means that there is no way to gauge commitment.  Having an election is
a big like some proposals to charge $1 to register a copyright renewal
- it isn't about the cost so much as just making somebody actually do
something to prevent de-listing.

I guess my question is when is something like a herd the best solution
to a problem, and what is that problem?

I don't want to change for the sake of change.  If we stay the same
I'd like it to be because what we're doing actually makes sense.

If we do keep something like herds, I'd still consider some way to
consolidate herd/project membership lists so that tools can scan a
single location.  Whether a group is a herd/project/alias could be an
attribute.  This is no different than not having separate ldap servers
for devs vs staff vs infra, and so on.

--
Rich

Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 1102 bytes --]

>>>>> On Sun, 28 Sep 2014, Tom Wijsman wrote:

> Yes, if you do create a one-on-one mapping then it becomes possible.
> The question becomes "does every herd want to become a
> (sub)project?".

Another example: The Emacs project maintains two herds "emacs" and
"xemacs", for GNU Emacs and XEmacs related packages, respectively.
Otherwise, most resources (like overlay and wiki documentation) are
shared.

There certainly is no need to split the project into further
(third-level) subprojects, which would unsettle our project pages in
the wiki, and some of which would have only a single dev as a member.
OTOH, emacs and xemacs herds should be kept separate, because these
are clearly separated groups of packages, and because of assignment of
bugs in bugzilla.

> Ideally, they should! Theoretically, there is no problem.
> Practically, for some herds it'll involve extra work setting up the
> project related stuff and so on when there is no need for it.

+1

"Not everything (or everyone) needs a project", says GLEP 39. If the
extra work will add no value, then there should be no project.

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds

[Tom Wijsman]

On Sun, 28 Sep 2014 00:21:43 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> I don't know if you know it but setting up the project wiki page takes
> less time than reaching into depths of CVS and editing herds.xml.

Editing and committing a change to herds.xml takes me less characters
than this quoted paragraph, done in under a minute; in comparison, a
project wiki page involves a browser, waiting time and more characters.

> Otherwise, we'll never going to get out of the dumb distinction what
> project and herd is and isn't, and when one or the other, or both
> should be used.

The documentation and GLEP(s) are pretty clear about that; as for how
to use it, that are semantics that are up for the projects and herds.

This has worked fine for ages, point me to old threads discussing this
if you claim that to not be the case. Recent assumptions make it look
like it is a problem, but a history of experience tell us otherwise...

Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds

[Tom Wijsman]

On Sat, 27 Sep 2014 18:45:12 -0400
Rich Freeman <rich0@gentoo.org> wrote:

> So, there was some discussion on -dev, apparently some discussion I
> wasn't a part of, and some that I was (such is the nature of IRC).

Knowledge codification is nice; otherwise, this is just-another-thread.

> I think it would make sense to take a step back and ask what we'd do
> if we were starting with a blank slate.  Aliases, herds, and projects
> are all ways of grouping people, but they are used in different ways,
> sometimes.

Looking at a blank slate hides the origin of these ways.

Aliases set up mails on the infrastructure. Herds assign multiple
relevant maintainers to multiple packages. Projects are a need for
serious organization.

This is what we have ended up with starting from that blank slate.
 
> My real problem with herds isn't the idea of having more than one way
> to group people.  My real issue is that we have several ways of
> grouping people and no consistent way of doing so.  You have to look
> in different places to find out who is on an alias/herd/project.  We
> have cases where more than one of these are loosely associated, but
> membership is inconsistent.

Aliases are there to support herds or projects, it shouldn't be seen as
a separate way to group people. The other groups are straight froward;
herds for groups that maintains packages, projects for groups that take
on a serious project. Projects that take on packages have created herds
(eg. proxy-maintainers, ...); so, this is or can be consistent.

> We have inactive examples of all three.

Yes, they capture inactivity; iotw, what's in a herd/project name? :)

> So, let's step back and think about why developers would want to be
> part of a group, forget about what we call these groups, and then
> figure out what kind of model makes the most sense and how to get
> there.  In the final design we might want to not split groupings up
> all over the place (wiki vs herds.xml vs alias files that nobody but
> devs can read).
> 
> So, one level of association might be registering an interest - such
> as what is sometimes done with a mail alias.  A developer, or even a
> non-developer, might want to be informed about what is going on with a
> package or group of packages, but they are not making any kind of
> commitment to actually taking care of them.
> 
> The opposite would be a project as defined in GLEP 39.  This is a
> formal association of developers that elects a lead, and acts as a
> unit.  The project could establish policies and it is generally
> expected that they be followed (we can escalate to the Council if
> there is a problem).  This is especially valuable for core
> dependencies like toolchain, frameworks, etc where good planning makes
> everybody's lives easier.
> 
> Then you have groups of people who sort-of maintain peripheral
> packages, which is what I think is what many herds are (but their use
> is totally inconsistent, so this isn't true everywhere).

If read and compared correctly, the origin paragraph is a TL;DR to this.

> My issue with this sort of thing is that it is really hard to tell if
> a package is actually maintained.  Devs basically drop-in to scratch
> an itch and then abandon things.  Emails to aliases get ignored,
> since nobody in particular is in charge.
> 
> That is my main issue with herds - they're dumping grounds for bugs
> that nobody seems to care about, at least in some cases.

+1, as some of us revealed; but note that projects can also hide
abandoned efforts, eg. the Council recently cleaning old dead projects.

> With a project you can at least ask "have you selected a lead in the
> last year" and get some kind of pulse on activity.

There are projects which haven't selected a new lead for years ...

> Herds are nice from the standpoint that they cost nothing to
> maintain, but that also means that there is no way to gauge
> commitment.  Having an election is a big like some proposals to
> charge $1 to register a copyright renewal - it isn't about the cost
> so much as just making somebody actually do something to prevent
> de-listing.

... thus it only works when some entity external to the project forces
new lead elections; as otherwise, projects have no such $1 ping-pong.

> I guess my question is when is something like a herd the best solution
> to a problem, and what is that problem?

Unnecessary stuff: Organization, knowledge codification, time, work, ...

> I don't want to change for the sake of change.  If we stay the same
> I'd like it to be because what we're doing actually makes sense.

It made sense to me from day #1 of contributing to Gentoo; it surprises
me that this all of the sudden is assumed to be a problem, it makes me
rather skeptic about whether a structure change is needed.

> If we do keep something like herds, I'd still consider some way to
> consolidate herd/project membership lists so that tools can scan a
> single location.  Whether a group is a herd/project/alias could be an
> attribute.  This is no different than not having separate ldap servers
> for devs vs staff vs infra, and so on.

That would be nice.

[gentoo-dev] RFC: Deprecating and killing herds in metadata.xml

[Jeroen Roovers]

On Tue, 9 Sep 2014 21:45:49 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> Hello,
> 
> Let's keep it short: I think herds don't serve any special purpose
> nowadays. Their existence is mostly resulting in lack of consistency
> and inconveniences.

On IRC we seem to have found some consensus about metadata.xml:

1 ) We should
1a) deprecate the <herd> tag in metadata.xml (that's 17,856 files or
    so?) in favour of 
1b) a conversion to their respective <maintainer> tags 
1c) where the <email> tag serves the same purpose as <herd> but
    bypasses herds.xml completely by just using the intended alias and
    not the name of the herd (which some developers might want to keep
in the <name> tag for whatever purpose).

2 ) Important to note is that this makes the order in which tags in
    metadata.xml are used in assigning bugs is made more explicit and
    simple. Previously the first <maintainer> or in its absence the
    first <herd> would be the Assignee, and the rest would be CC'd. This
    changes now to a much simpler scheme where
2a) the first <maintainer> is always the Assignee, and the rest is
    CC'd, so that
2b) instances where metadata.xml lists a <maintainer> tag after a
    <herd> tag would need to have the order fixed: the <herd> tags that
    are converted to <maintainer> tags should be moved to a place in
    the file after the original first <maintainer> tag.

3 ) We end up with metadata.xml files that have no <herd> tags and only
    <maintainer> tags.
3a) herds.xml is now unimportant in assigning bugs.
3b) Tools that use herds.xml no longer need a copy of herds.xml to look
    up who is responsible for a package.
3c) herds.xml can be safely kept up to date and used elsewhere and can
    be safely phases out in time.

4 ) We might achieve the <herd> => <maintainer> conversion by
4a) setting up repoman to deny commits that keep <herd> or
4b) setting up repoman to automatically convert the entire thing
4c) both of which might end up taking a good while to complete, or
4d) do an automated mass conversion of the entire gentoo-x86 tree.


5a) All ontological discussion of the meaning of herds and projects is
    entirely unrelated - we're just looking to make it much easier to
look
    up metadata about packages using as few resources as possible.
5b) All ontological discussion of the meaning of herds and projects is
    instantly rendered a lot less important. We have less need to bring
    this up every year or so.


Corrections and comment, please.


     jer

Re: [gentoo-dev] RFC: Deprecating and killing herds in metadata.xml

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 884 bytes --]

>>>>> On Mon, 29 Sep 2014, Jeroen Roovers wrote:

> On IRC we seem to have found some consensus about metadata.xml:

> 1 ) We should
> 1a) deprecate the <herd> tag in metadata.xml (that's 17,856 files or
>     so?) in favour of 
> 1b) a conversion to their respective <maintainer> tags 
> 1c) where the <email> tag serves the same purpose as <herd> but
>     bypasses herds.xml completely by just using the intended alias and
>     not the name of the herd (which some developers might want to keep
>     in the <name> tag for whatever purpose).

> [...]

> Corrections and comment, please.

This will lose the information if a maintainer is a project/team or an
individual developer, which I think is still useful.

Could we keep this information somehow? Maybe by adding an attribute
to the <maintainer> tag, or by using <project> or <team> instead of
<name> as the subtag?

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] RFC: Deprecating and killing herds in metadata.xml

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1109 bytes --]

Dnia 2014-09-29, o godz. 19:20:54
Ulrich Mueller <ulm@gentoo.org> napisał(a):

> >>>>> On Mon, 29 Sep 2014, Jeroen Roovers wrote:
> 
> > On IRC we seem to have found some consensus about metadata.xml:
> 
> > 1 ) We should
> > 1a) deprecate the <herd> tag in metadata.xml (that's 17,856 files or
> >     so?) in favour of 
> > 1b) a conversion to their respective <maintainer> tags 
> > 1c) where the <email> tag serves the same purpose as <herd> but
> >     bypasses herds.xml completely by just using the intended alias and
> >     not the name of the herd (which some developers might want to keep
> >     in the <name> tag for whatever purpose).
> 
> > [...]
> 
> > Corrections and comment, please.
> 
> This will lose the information if a maintainer is a project/team or an
> individual developer, which I think is still useful.
> 
> Could we keep this information somehow? Maybe by adding an attribute
> to the <maintainer> tag, or by using <project> or <team> instead of
> <name> as the subtag?

Or we can map that off the e-mail address.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-dev] RFC: Deprecating and killing herds in metadata.xml

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 567 bytes --]

>>>>> On Mon, 29 Sep 2014, Michał Górny wrote:

> Dnia 2014-09-29, o godz. 19:20:54
> Ulrich Mueller <ulm@gentoo.org> napisał(a):

>> This will lose the information if a maintainer is a project/team or
>> an individual developer, which I think is still useful.
>> 
>> Could we keep this information somehow? Maybe by adding an
>> attribute to the <maintainer> tag, or by using <project> or <team>
>> instead of <name> as the subtag?

> Or we can map that off the e-mail address.

I thought the intention was to get rid of indirection levels?

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] RFC: Deprecating and killing herds in metadata.xml

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 850 bytes --]

Dnia 2014-09-29, o godz. 20:13:19
Ulrich Mueller <ulm@gentoo.org> napisał(a):

> >>>>> On Mon, 29 Sep 2014, Michał Górny wrote:
> 
> > Dnia 2014-09-29, o godz. 19:20:54
> > Ulrich Mueller <ulm@gentoo.org> napisał(a):
> 
> >> This will lose the information if a maintainer is a project/team or
> >> an individual developer, which I think is still useful.
> >> 
> >> Could we keep this information somehow? Maybe by adding an
> >> attribute to the <maintainer> tag, or by using <project> or <team>
> >> instead of <name> as the subtag?
> 
> > Or we can map that off the e-mail address.
> 
> I thought the intention was to get rid of indirection levels?

For useful things, yes :). I don't see any sane use case for
team/person information, at least one that doesn't come with team
member list.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-dev] RFC: Deprecating and killing herds in metadata.xml

[Tom Wijsman]

On Mon, 29 Sep 2014 18:42:40 +0200
Jeroen Roovers <jer@gentoo.org> wrote:

> On IRC we seem to have found some consensus about metadata.xml:

IRC is huge; where did you manage to find consensus in there with whom?

> 1 ) We should
> 1a) deprecate the <herd> tag in metadata.xml (that's 17,856 files or
>     so?) in favour of 
> 1b) a conversion to their respective <maintainer> tags 
> 1c) where the <email> tag serves the same purpose as <herd> but
>     bypasses herds.xml completely by just using the intended alias and
>     not the name of the herd (which some developers might want to keep
> in the <name> tag for whatever purpose).

This loses information that denotes it to be a herd, not a maintainer.

> 2 ) Important to note is that this makes the order in which tags in
>     metadata.xml are used in assigning bugs is made more explicit and
>     simple. Previously the first <maintainer> or in its absence the
>     first <herd> would be the Assignee, and the rest would be CC'd.
> This changes now to a much simpler scheme where
> 2a) the first <maintainer> is always the Assignee, and the rest is
>     CC'd, so that
> 2b) instances where metadata.xml lists a <maintainer> tag after a
>     <herd> tag would need to have the order fixed: the <herd> tags
> that are converted to <maintainer> tags should be moved to a place in
>     the file after the original first <maintainer> tag.

This loses the lack of ordering, requiring unnecessary attention to it.

> 3 ) We end up with metadata.xml files that have no <herd> tags and
> only <maintainer> tags.
> 3a) herds.xml is now unimportant in assigning bugs.
> 3b) Tools that use herds.xml no longer need a copy of herds.xml to
> look up who is responsible for a package.
> 3c) herds.xml can be safely kept up to date and used elsewhere and can
>     be safely phases out in time.

This is nice to have, as automatic assignments reveal; but this makes it
harder for a herd to change its e-mail address, which happens sometimes.

> 4 ) We might achieve the <herd> => <maintainer> conversion by
> 4a) setting up repoman to deny commits that keep <herd> or
> 4b) setting up repoman to automatically convert the entire thing
> 4c) both of which might end up taking a good while to complete, or
> 4d) do an automated mass conversion of the entire gentoo-x86 tree.

We might not need a conversion; it also changes/requires another tool.

> 5a) All ontological discussion of the meaning of herds and projects is
>     entirely unrelated - we're just looking to make it much easier to
> look
>     up metadata about packages using as few resources as possible.
> 5b) All ontological discussion of the meaning of herds and projects is
>     instantly rendered a lot less important. We have less need to
> bring this up every year or so.

That important ontological discussion is related as it is the origin,
the proposal changes a fundamental file of the Gentoo Herds Project[1];
by doing so, you make changes in the meaning of a herd and its context.

Reading further, we interestingly see that per the project page[1]

 1) the metadata in metadata.xml must have a <herd> tag present,
 2) a herd in herds.xml is not required to have an e-mail address;

where the latter (2) is even confirmed by the herds.xml DTD[2].

 [1]: http://www.gentoo.org/proj/en/metastructure/herds/
 [2]: http://www.gentoo.org/dtd/herds.dtd

Re: [gentoo-dev] RFC: Deprecating and killing herds in metadata.xml

[Jeroen Roovers]

On Mon, 29 Sep 2014 23:16:32 +0200
Tom Wijsman <TomWij@gentoo.org> wrote:

> On Mon, 29 Sep 2014 18:42:40 +0200
> Jeroen Roovers <jer@gentoo.org> wrote:
> 
> > On IRC we seem to have found some consensus about metadata.xml:
> 
> IRC is huge; where did you manage to find consensus in there with
> whom?

I have no idea how to respond to that. It doesn't matter whether you
were there or not: this was the outcome we agreed on and here is a
proposal that should make working with the bug tracker a lot easier.

> > 1 ) We should
> > 1a) deprecate the <herd> tag in metadata.xml (that's 17,856 files or
> >     so?) in favour of 
> > 1b) a conversion to their respective <maintainer> tags 
> > 1c) where the <email> tag serves the same purpose as <herd> but
> >     bypasses herds.xml completely by just using the intended alias
> > and not the name of the herd (which some developers might want to
> > keep in the <name> tag for whatever purpose).
> 
> This loses information that denotes it to be a herd, not a maintainer.

<maintainer>
  <email>[address of the herd]</email>
  <name>[name of the herd]</name> <!-- if you like -->
</maintainer>

Please provide some examples of when and how that piece of information,
"herd", is important.

> > 2 ) Important to note is that this makes the order in which tags in
> >     metadata.xml are used in assigning bugs is made more explicit
> > and simple. Previously the first <maintainer> or in its absence the
> >     first <herd> would be the Assignee, and the rest would be CC'd.
> > This changes now to a much simpler scheme where
> > 2a) the first <maintainer> is always the Assignee, and the rest is
> >     CC'd, so that
> > 2b) instances where metadata.xml lists a <maintainer> tag after a
> >     <herd> tag would need to have the order fixed: the <herd> tags
> > that are converted to <maintainer> tags should be moved to a place
> > in the file after the original first <maintainer> tag.
> 
> This loses the lack of ordering, requiring unnecessary attention to
> it.

There has never been a lack of ordering. The way bugs are assigned
since 2008 is as described in 2a. It requires not reordering the XML
tags. 2b says the order of appearance denotes the Assignee.

> > 3 ) We end up with metadata.xml files that have no <herd> tags and
> > only <maintainer> tags.
> > 3a) herds.xml is now unimportant in assigning bugs.
> > 3b) Tools that use herds.xml no longer need a copy of herds.xml to
> > look up who is responsible for a package.
> > 3c) herds.xml can be safely kept up to date and used elsewhere and
> > can be safely phases out in time.
> 
> This is nice to have, as automatic assignments reveal; but this makes
> it harder for a herd to change its e-mail address, which happens
> sometimes.

Go back in history and tell us how often herds change their e-mail
address. And how many metadata.xml files would have been affected. And
how that reflects on the future. And then compare that with the everday
chore of doing the extra lookup in herds.xml that shouldn't be needed
at all if the only thing you need is an e-mail address.

> > 4 ) We might achieve the <herd> => <maintainer> conversion by
> > 4a) setting up repoman to deny commits that keep <herd> or
> > 4b) setting up repoman to automatically convert the entire thing
> > 4c) both of which might end up taking a good while to complete, or
> > 4d) do an automated mass conversion of the entire gentoo-x86 tree.
> 
> We might not need a conversion; it also changes/requires another tool.

The proposal says we convert <herd> to <maintainer> in metadata.xml.

4d explains how you wouldn't need changes to repoman.

> > 5a) All ontological discussion of the meaning of herds and projects
> > is entirely unrelated - we're just looking to make it much easier to
> > look
> >     up metadata about packages using as few resources as possible.
> > 5b) All ontological discussion of the meaning of herds and projects
> > is instantly rendered a lot less important. We have less need to
> > bring this up every year or so.
> 
> That important ontological discussion is related as it is the origin,
> the proposal changes a fundamental file of the Gentoo Herds
> Project[1]; by doing so, you make changes in the meaning of a herd
> and its context.

No, that's about changing herds.xml. This is about changing
metadata.xml. You can keep the herd information in herds.xml and make
metadata.xml a lot more easy to handle at the same time.

> Reading further, we interestingly see that per the project page[1]

Maybe that should be fixed, then (including outdated information and
factual errors). I don't see how it would stop progress. It just needs
some minor rethinking.


     jer

Re: [gentoo-dev] RFC: Deprecating and killing herds in metadata.xml

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 804 bytes --]

>>>>> On Tue, 30 Sep 2014, Jeroen Roovers wrote:

> <maintainer>
>   <email>[address of the herd]</email>
>   <name>[name of the herd]</name> <!-- if you like -->
> </maintainer>

The same tags shouldn't be used for different things. First of all,
the <name> tag is optional, so we cannot rely on its being present.
Second, for a given e-mail address, some information is needed where
to look it up. If it is a developer, their name can be found in the
developers' database. If it is a herd, its description can be found in
a different place, currently herds.xml.

Even if this information had only marginal importance, I don't see why
we should drop it.

> Please provide some examples of when and how that piece of
> information, "herd", is important.

Don't shift the burden of proof, please.

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] RFC: Deprecating and killing herds in metadata.xml

[Rich Freeman]

On Mon, Sep 29, 2014 at 7:09 PM, Ulrich Mueller <ulm@gentoo.org> wrote:
>>>>>> On Tue, 30 Sep 2014, Jeroen Roovers wrote:
>
>> Please provide some examples of when and how that piece of
>> information, "herd", is important.
>
> Don't shift the burden of proof, please.
>

Meh, knowing if the status quo is useful is as helpful as knowing if
changing it is useful.  Certainly reasons to change have been
presented.  If there are reasons not to change besides inertia it
would be helpful to know what they are...

--
Rich

Re: [gentoo-dev] RFC: Deprecating and killing herds in metadata.xml

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 1199 bytes --]

>>>>> On Mon, 29 Sep 2014, Rich Freeman wrote:

> On Mon, Sep 29, 2014 at 7:09 PM, Ulrich Mueller <ulm@gentoo.org> wrote:

[Restoring context omitted from quote.]
>> The same tags shouldn't be used for different things. First of all,
>> the <name> tag is optional, so we cannot rely on its being present.
>> Second, for a given e-mail address, some information is needed
>> where to look it up. If it is a developer, their name can be found
>> in the developers' database. If it is a herd, its description can
>> be found in a different place, currently herds.xml.

>> Even if this information had only marginal importance, I don't see
>> why we should drop it.

>>>>>>> On Tue, 30 Sep 2014, Jeroen Roovers wrote:
>> 
>>> Please provide some examples of when and how that piece of
>>> information, "herd", is important.
>> 
>> Don't shift the burden of proof, please.

> Meh, knowing if the status quo is useful is as helpful as knowing if
> changing it is useful.  Certainly reasons to change have been
> presented.  If there are reasons not to change besides inertia it
> would be helpful to know what they are...

I had just given some reasons above, in the part that you haven't
quoted.

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] RFC: Deprecating and killing herds in metadata.xml

[Jeroen Roovers]

On Tue, 30 Sep 2014 01:09:30 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:

> >>>>> On Tue, 30 Sep 2014, Jeroen Roovers wrote:
> 
> > <maintainer>
> >   <email>[address of the herd]</email>
> >   <name>[name of the herd]</name> <!-- if you like -->
> > </maintainer>
> 
> The same tags shouldn't be used for different things.

Then we might as well extend the DTD to have a required <email> tag
nested in each <herd> tag.


     jer

Re: [gentoo-dev] RFC: Deprecating and killing herds in metadata.xml

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 336 bytes --]

>>>>> On Tue, 30 Sep 2014, Jeroen Roovers wrote:

>> The same tags shouldn't be used for different things.

> Then we might as well extend the DTD to have a required <email> tag
> nested in each <herd> tag.

But IIUC, the DTD must be changed also if the <herd> tag is removed?
(Unless we want to leave a dead element in there.)

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] RFC: Deprecating and killing herds in metadata.xml

[Rich Freeman]

On Tue, Sep 30, 2014 at 3:00 AM, Ulrich Mueller <ulm@gentoo.org> wrote:
>
> I had just given some reasons above, in the part that you haven't
> quoted.
>

My main issue was with the "burden of proof" bit.  This isn't a court
- we're free to do whatever seems to make the most sense, and not
worry about what kind of precedent it sets, since the next Council can
do whatever makes the most sense at that time.  :)

I'm all for something that covers the bases but is a bit cleaner in
design.  Right now we have different sources for membership lists of
different kinds of groups, and that just seems like poor
normalization.

--
Rich

Re: [gentoo-dev] RFC: Deprecating and killing herds in metadata.xml

[Jeroen Roovers]

On Tue, 30 Sep 2014 13:01:35 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:

> >>>>> On Tue, 30 Sep 2014, Jeroen Roovers wrote:
> 
> >> The same tags shouldn't be used for different things.
> 
> > Then we might as well extend the DTD to have a required <email> tag
> > nested in each <herd> tag.
> 
> But IIUC, the DTD must be changed also if the <herd> tag is removed?
> (Unless we want to leave a dead element in there.)

If people are that attached to <herd> then we should apparently fix it
instead of removing it, possibly by making it closely resemble
<maintainer>.


      jer

Re: [gentoo-dev] RFC: Deprecating and killing herds in metadata.xml

[Tom Wijsman]

On Tue, 30 Sep 2014 00:40:50 +0200
Jeroen Roovers <jer@gentoo.org> wrote:

> On Mon, 29 Sep 2014 23:16:32 +0200
> Tom Wijsman <TomWij@gentoo.org> wrote:
> 
> > On Mon, 29 Sep 2014 18:42:40 +0200
> > Jeroen Roovers <jer@gentoo.org> wrote:
> > 
> > > On IRC we seem to have found some consensus about metadata.xml:
> > 
> > IRC is huge; where did you manage to find consensus in there with
> > whom?
> 
> I have no idea how to respond to that. It doesn't matter whether you
> were there or not: this was the outcome we agreed on and here is a
> proposal that should make working with the bug tracker a lot easier.

The outcome of what? Who agreed on it? If these questions have no
answers, the statements made have no meaning; they hide away the true
goal, which now becomes clear in "proposal to make bug tracker easier".

Then we arrive at the next question: What is so hard about bug tracking?

> > > 1 ) We should
> > > 1a) deprecate the <herd> tag in metadata.xml (that's 17,856 files
> > > or so?) in favour of 
> > > 1b) a conversion to their respective <maintainer> tags 
> > > 1c) where the <email> tag serves the same purpose as <herd> but
> > >     bypasses herds.xml completely by just using the intended alias
> > > and not the name of the herd (which some developers might want to
> > > keep in the <name> tag for whatever purpose).
> > 
> > This loses information that denotes it to be a herd, not a
> > maintainer.
> 
> <maintainer>
>   <email>[address of the herd]</email>
>   <name>[name of the herd]</name> <!-- if you like -->
> </maintainer>
> 
> Please provide some examples of when and how that piece of
> information, "herd", is important.

Knowing whether to contact one or more persons; eg., "/nick cjk" on
IRC can confuse this easily, where "!herd cjk" was as obvious as can be.

Note that the proposal involves trade-offs and consequences.

> > > 2 ) Important to note is that this makes the order in which tags
> > > in metadata.xml are used in assigning bugs is made more explicit
> > > and simple. Previously the first <maintainer> or in its absence
> > > the first <herd> would be the Assignee, and the rest would be
> > > CC'd. This changes now to a much simpler scheme where
> > > 2a) the first <maintainer> is always the Assignee, and the rest is
> > >     CC'd, so that
> > > 2b) instances where metadata.xml lists a <maintainer> tag after a
> > >     <herd> tag would need to have the order fixed: the <herd> tags
> > > that are converted to <maintainer> tags should be moved to a place
> > > in the file after the original first <maintainer> tag.
> > 
> > This loses the lack of ordering, requiring unnecessary attention to
> > it.
> 
> There has never been a lack of ordering. The way bugs are assigned
> since 2008 is as described in 2a. It requires not reordering the XML
> tags. 2b says the order of appearance denotes the Assignee.

A comparison reveals that ordering gets introduced by this proposal:

Before: <maintainer> always goes _before_ <herd>
After:  <maintainer> goes _before or after_ the new herd <maintainer>

Therefore there was a lack of ordering; whereas the maintainer vs herd
order was implicit before, the proposal makes the order explicit.

> > > 3 ) We end up with metadata.xml files that have no <herd> tags and
> > > only <maintainer> tags.
> > > 3a) herds.xml is now unimportant in assigning bugs.
> > > 3b) Tools that use herds.xml no longer need a copy of herds.xml to
> > > look up who is responsible for a package.
> > > 3c) herds.xml can be safely kept up to date and used elsewhere and
> > > can be safely phases out in time.
> > 
> > This is nice to have, as automatic assignments reveal; but this
> > makes it harder for a herd to change its e-mail address, which
> > happens sometimes.
> 
> Go back in history and tell us how often herds change their e-mail
> address. And how many metadata.xml files would have been affected. And
> how that reflects on the future. And then compare that with the
> everday chore of doing the extra lookup in herds.xml that shouldn't
> be needed at all if the only thing you need is an e-mail address.
>
> > > 4 ) We might achieve the <herd> => <maintainer> conversion by
> > > 4a) setting up repoman to deny commits that keep <herd> or
> > > 4b) setting up repoman to automatically convert the entire thing
> > > 4c) both of which might end up taking a good while to complete, or
> > > 4d) do an automated mass conversion of the entire gentoo-x86 tree.
> > 
> > We might not need a conversion; it also changes/requires another
> > tool.
> 
> The proposal says we convert <herd> to <maintainer> in metadata.xml.
> 
> 4d explains how you wouldn't need changes to repoman.

The proposal is unaware of the amount of metadata.xml files; the extra
mapped lookup in herds.xml is free, changing metadata.xml files is not.

> > > 5a) All ontological discussion of the meaning of herds and
> > > projects is entirely unrelated - we're just looking to make it
> > > much easier to look
> > >     up metadata about packages using as few resources as possible.
> > > 5b) All ontological discussion of the meaning of herds and
> > > projects is instantly rendered a lot less important. We have less
> > > need to bring this up every year or so.
> > 
> > That important ontological discussion is related as it is the
> > origin, the proposal changes a fundamental file of the Gentoo Herds
> > Project[1]; by doing so, you make changes in the meaning of a herd
> > and its context.
> 
> No, that's about changing herds.xml. This is about changing
> metadata.xml. You can keep the herd information in herds.xml and make
> metadata.xml a lot more easy to handle at the same time.

No, that[1]'s also about metadata.xml; furthermore, the proposal ignores
how the metadata.xml change will affect the meaning of a herd. Its
meaning is determined by its usage, which is affected by the proposal.

If you start using aliases instead, then what is there in a herd's name?

 [1]: http://www.gentoo.org/proj/en/metastructure/herds/#doc_chap4

> > Reading further, we interestingly see that per the project page[1]
> 
> Maybe that should be fixed, then (including outdated information and
> factual errors). I don't see how it would stop progress. It just needs
> some minor rethinking.

Does it? Progress isn't stopped, we've been doing fine for ages; YAGNI.

Re: [gentoo-dev] RFC: Deprecating and killing herds in metadata.xml

[Tom Wijsman]

On Tue, 30 Sep 2014 09:12:13 -0400
Rich Freeman <rich0@gentoo.org> wrote:

> On Tue, Sep 30, 2014 at 3:00 AM, Ulrich Mueller <ulm@gentoo.org>
> wrote:
> >
> > I had just given some reasons above, in the part that you haven't
> > quoted.
> >
> 
> My main issue was with the "burden of proof" bit.  This isn't a court
> - we're free to do whatever seems to make the most sense, and not
> worry about what kind of precedent it sets, since the next Council can
> do whatever makes the most sense at that time.  :)

Is it fine to replace something that has worked for years without proof?

> I'm all for something that covers the bases but is a bit cleaner in
> design.  Right now we have different sources for membership lists of
> different kinds of groups, and that just seems like poor
> normalization.

Why does it seem poor? How to have a single list for different kinds?
Is normalization necessary? Does normalization make it cleaner at all?

The groups are of a different kind for a reason; normalization, YAGNI.

Re: [gentoo-dev] RFC: Deprecating and killing herds in metadata.xml

[Tom Wijsman]

On Tue, 30 Sep 2014 23:03:51 +0200
Jeroen Roovers <jer@gentoo.org> wrote:

> On Tue, 30 Sep 2014 13:01:35 +0200
> Ulrich Mueller <ulm@gentoo.org> wrote:
> 
> > >>>>> On Tue, 30 Sep 2014, Jeroen Roovers wrote:
> > 
> > >> The same tags shouldn't be used for different things.
> > 
> > > Then we might as well extend the DTD to have a required <email>
> > > tag nested in each <herd> tag.
> > 
> > But IIUC, the DTD must be changed also if the <herd> tag is removed?
> > (Unless we want to leave a dead element in there.)
> 
> If people are that attached to <herd> then we should apparently fix it
> instead of removing it, possibly by making it closely resemble
> <maintainer>.

This sub proposal is a solution to most of the proposal disagreements.

+1

[gentoo-dev] Re: RFC: Deprecating and killing herds in metadata.xml

[Steven J. Long]

On Tue, Sep 30, 2014, Jeroen Roovers wrote:
> If people are that attached to <herd> then we should apparently fix it
> instead of removing it, possibly by making it closely resemble
> <maintainer>.

Well to do that you need to clear up that "ontological discussion"
which is nothing more than defining what it is you're tracking.
Your first mail effectively dealt with every listing of herd as a tag
for people (ie maintainer tag), and concluded with "we just want a way
to lookup packages."

I don't want a long debate about it either: it'd just be nice to know
what you're trying to do upfront. It seems like a herd is a group of
both packages (eg webapps) and the people who care about them, via the
mail alias, which could be users as well as developers.(?)

The latter is slightly different to a project, which is a group of
developers, afaict. Is that difference what was meant by "team" which
I read somewhere in this thread, or is that the project, or something
else altogether?

Anyhow, I'd just deal with the fact that herd means what it means, a
grouping of packages formally, *and* an associated mail alias, which
(i assume) is what people look up with willikins' !herd. (Conceptually
the latter would be cleaner as !team, and !herd would tell you the
packages or direct to a url if many, but it's a bit late for that;
usage habits are too ingrained.)

And ofc document that, as well as what a project etc mean in one
place; I'm sure I got much of the above wrong in factual terms, but
those are the definitions missing from the proposal, that make it
hard to follow. It's not clear what problem you're trying to solve,
apart from removing all herd tags from every ebuild's metadata.xml.

Regards
steveL
-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

Re: [gentoo-dev] Re: RFC: Deprecating and killing herds in metadata.xml

[Peter Stuge]

Steven J. Long wrote:
> it's a bit late for that

It's never too late to improve.


//Peter

Re: [gentoo-dev] Re: RFC: Deprecating and killing herds in metadata.xml

[Jeroen Roovers]

On Fri, 3 Oct 2014 03:51:41 +0100
"Steven J. Long" <slong@rathaus.eclipse.co.uk> wrote:

> It's not clear what problem you're trying to solve, apart from
> removing all herd tags from every ebuild's metadata.xml.

You must have read it wrong, then. 

The idea is to cut out herds.xml when looking up maintainers. Being
faced with a directory with ebuilds in it, you want to know everything
about it without looking elsewhere, including who is responsible for
the ebuilds, so under the (amended) proposal, e-mail addresses as
described in herds.xml will be used directly in metadata.xml, with the
<herd> tag being restructured as
<herd><email>foo@gentoo.org</email></herd> instead of the indirect
<herd>name</herd>.

I'll happily wait for you to catch up and /then/ read your expansive
reply.


     jer

Re: [gentoo-dev] Re: RFC: Deprecating and killing herds in metadata.xml

[Tom Wijsman]

On Sat, 4 Oct 2014 09:18:55 +0200
Jeroen Roovers <jer@gentoo.org> wrote:

> <herd><email>foo@gentoo.org</email></herd>

<herd><name>...</name><email>...</email></herd>
to keep willikins' !meta -v functionality working.

Re: [gentoo-dev] Re: RFC: Deprecating and killing herds in metadata.xml

[Jeroen Roovers]

On Sun, 5 Oct 2014 18:30:04 +0200
Tom Wijsman <TomWij@gentoo.org> wrote:

> On Sat, 4 Oct 2014 09:18:55 +0200
> Jeroen Roovers <jer@gentoo.org> wrote:
> 
> > <herd><email>foo@gentoo.org</email></herd>
> 
> <herd><name>...</name><email>...</email></herd>
> to keep willikins' !meta -v functionality working.

You mean we should design our organisational structures around an IRC
bot now?


     jer

Re: [gentoo-dev] Re: RFC: Deprecating and killing herds in metadata.xml

[Tom Wijsman]

On Sun, 5 Oct 2014 22:53:13 +0200
Jeroen Roovers <jer@gentoo.org> wrote:

> On Sun, 5 Oct 2014 18:30:04 +0200
> Tom Wijsman <TomWij@gentoo.org> wrote:
> 
> > On Sat, 4 Oct 2014 09:18:55 +0200
> > Jeroen Roovers <jer@gentoo.org> wrote:
> > 
> > > <herd><email>foo@gentoo.org</email></herd>
> > 
> > <herd><name>...</name><email>...</email></herd>
> > to keep willikins' !meta -v functionality working.
> 
> You mean we should design our organisational structures around an IRC
> bot now?

We should design metadata for our consumers; which include IRC bots, an
often used interface through which herd member list information is read.

If the name is omitted, then we lose that; that is not the way forward.

Re: [gentoo-dev] Re: RFC: Deprecating and killing herds in metadata.xml

[Jeroen Roovers]

On Wed, 8 Oct 2014 00:07:07 +0200
Tom Wijsman <TomWij@gentoo.org> wrote:

> If the name is omitted, then we lose that; that is not the way
> forward.

I'm pretty sure we already addressed this in another branch of this
thread. Bringing up the workings of IRC bots doesn't add anything.


     jer

Re: [gentoo-dev] Re: RFC: Deprecating and killing herds in metadata.xml

[Tom Wijsman]

On Wed, 8 Oct 2014 09:22:30 +0200
Jeroen Roovers <jer@gentoo.org> wrote:

> On Wed, 8 Oct 2014 00:07:07 +0200
> Tom Wijsman <TomWij@gentoo.org> wrote:
> 
> > If the name is omitted, then we lose that; that is not the way
> > forward.
> 
> I'm pretty sure we already addressed this in another branch of this
> thread.

No.

> Bringing up the workings of IRC bots doesn't add anything.

It is not about the workings, it is about the need for it to work; if
we break it, we also break our ability to use it! Don't omit anything.

Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds

[Rich Freeman]

> On Tue, 9 Sep 2014 21:45:49 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
>>
>> Let's keep it short: I think herds don't serve any special purpose
>> nowadays. Their existence is mostly resulting in lack of consistency
>> and inconveniences.
>>

Resurrecting this thread per the last council decision:

"The council is in favor of retiring herds, allowing non-maintainer
aliases to exist, and having a way to distinguish between individuals,
projects, and non-maintainer aliases in metadata.xml.  The details of
how to implement this will be worked out in the lists before the next
meeting."

Whether this gets worked out before the next meeting remains to be
seen.  However, the council is certainly interested in proposals and
discussion.

So, herds are going to go away.  That leaves maintainers (who can be
projects), and aliases (who are NOT maintainers, but can be listed in
addition to maintainers).

My proposal:


For the steady state:

1. For the maintainer tag in metadata, have a type attribute that can
be developer, project, or proxy.

2. Add a contacts tag in metadata that takes an email.

3. Package without maintainers (individuals or projects - regardless
of presence of aliases) get assigned to maintainer-needed and get
treecleaned as usual.

I'm also fine with normalizing this and just switching to a contact
tag that can have a type of developer, project, proxy, or contact.
That is a bigger change.  However, it would probably simplify
scripting and be a bit cleaner for the long-term.


For the transition to the steady state:

a. We generate a list of all current herds and email their aliases to
see if they want to be converted to a non-maintainer alias, or be
disbanded entirely.  One reply to the email is enough to keep the
alias around, no replies means retirement.

b. Anybody in Gentoo can start a project already by following GLEP 39.
It is encouraged for these projects to take over existing aliases
where they feel it is appropriate.  There is no need for all aliases
to have a project - just ones that want some kind of structure (ie
this is strictly voluntary).  When this is done the project will
remove the herd from metadata and add the project alias as a
maintainer with the agreed-upon tagging.

c. We generate a list of all current packages that do not have a
maintainer (either one or more individuals or projects (NOT herds)).
That gets posted so that individuals can claim them.  I suggest not
doing the usual treecleaning email since there could be a LOT of them.
Or we could do it herd-by-herd over time to ease the load.

d. We remove all herds from the existing packages.  Where aliases were
kept in (a) above they are converted to aliases with appropriate
tagging.  If no maintainer exists the package is handled per the
result of (c).


Comments, alternatives, etc?

--
Rich