RFC: Deprecating and killing the concept of herds

classic Classic list List threaded Threaded
64 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

RFC: Deprecating and killing the concept of herds

Michał Górny-5
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

signature.asc (968 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Deprecating and killing the concept of herds

Rich Freeman
On Tue, Sep 9, 2014 at 3:45 PM, Michał Górny <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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    : [hidden email]
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA


Reply | Threaded
Open this post in threaded view
|

Re: RFC: Deprecating and killing the concept of herds

Michał Górny-5
Dnia 2014-09-09, o godz. 16:46:29
"Anthony G. Basile" <[hidden email]> napisał(a):

> On 09/09/14 15:56, Rich Freeman wrote:
> > On Tue, Sep 9, 2014 at 3:45 PM, Michał Górny <[hidden email]> 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

signature.asc (968 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Deprecating and killing the concept of herds

Kent Fredric

On 10 September 2014 10:23, Michał Górny <[hidden email]> 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.

--
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Deprecating and killing the concept of herds

Pacho Ramos
In reply to this post by Michał Górny-5
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.


Reply | Threaded
Open this post in threaded view
|

Re: RFC: Deprecating and killing the concept of herds

Rich Freeman
In reply to this post by Kent Fredric
On Tue, Sep 9, 2014 at 6:54 PM, Kent Fredric <[hidden email]> wrote:

>
> On 10 September 2014 10:23, Michał Górny <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: RFC: Deprecating and killing the concept of herds

Rich Freeman
In reply to this post by Pacho Ramos
On Wed, Sep 10, 2014 at 7:33 AM, Pacho Ramos <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: RFC: Deprecating and killing the concept of herds

Tom Wijsman-2
In reply to this post by Michał Górny-5
On Tue, 9 Sep 2014 21:45:49 +0200
Michał Górny <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: RFC: Deprecating and killing the concept of herds

Michał Górny-5
In reply to this post by Rich Freeman
Dnia 2014-09-10, o godz. 07:53:31
Rich Freeman <[hidden email]> napisał(a):

> On Wed, Sep 10, 2014 at 7:33 AM, Pacho Ramos <[hidden email]> 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

signature.asc (968 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Deprecating and killing the concept of herds

Steven J. Long
In reply to this post by Rich Freeman
On Wed, Sep 10, 2014 at 07:53:31AM -0400, Rich Freeman wrote:

> On Wed, Sep 10, 2014 at 7:33 AM, Pacho Ramos <[hidden email]> 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 ;-)

Reply | Threaded
Open this post in threaded view
|

Re: RFC: Deprecating and killing the concept of herds

Rich Freeman
In reply to this post by Michał Górny-5
On Wed, Sep 10, 2014 at 10:18 AM, Michał Górny <[hidden email]> wrote:

> Dnia 2014-09-10, o godz. 07:53:31
> Rich Freeman <[hidden email]> napisał(a):
>
>> On Wed, Sep 10, 2014 at 7:33 AM, Pacho Ramos <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: RFC: Deprecating and killing the concept of herds

Markos Chandras-2
In reply to this post by Tom Wijsman-2
-----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 <[hidden email]>
> 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-----

Reply | Threaded
Open this post in threaded view
|

Re: RFC: Deprecating and killing the concept of herds

Duncan-42
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 <[hidden email]>
>> 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


Reply | Threaded
Open this post in threaded view
|

Re: RFC: Deprecating and killing the concept of herds

Tom Wijsman-2
In reply to this post by Markos Chandras-2
On Wed, 10 Sep 2014 21:21:24 +0100
Markos Chandras <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: RFC: Deprecating and killing the concept of herds

Markos Chandras-2
-----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
> <[hidden email]> 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-----

Reply | Threaded
Open this post in threaded view
|

Re: RFC: Deprecating and killing the concept of herds

Tom Wijsman-2
On Thu, 11 Sep 2014 21:00:16 +0100
Markos Chandras <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: RFC: Deprecating and killing the concept of herds

W. Trevor King-2
In reply to this post by Michał Górny-5
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:[hidden email]

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

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Deprecating and killing the concept of herds

Rich Freeman
On Wed, Sep 24, 2014 at 12:31 PM, W. Trevor King <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: RFC: Deprecating and killing the concept of herds

W. Trevor King-2
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

signature.asc (836 bytes) Download Attachment
1234