Re: [gentoo-dev] Inconsistent and messy layout of team maintainership in Gentoo

[Anthony G. Basile]

On 9/17/15 6:32 AM, Michał Górny wrote:
>
> Dnia 17 września 2015 11:07:43 CEST, "Anthony G. Basile" <blueness@g.o> napisał(a):
>> On 9/17/15 4:35 AM, Justin (jlec) wrote:
>>> On 16/09/15 23:43, Matthew Thode wrote:
>>>> On 09/16/2015 04:25 PM, Michał Górny wrote:
>>>>> So, what are your thoughts for unmessing this?
>>>>>
>>>> Herds are groups of developers that can then be mapped to a package.
>>>>
>>> Herds are a group of packages, which are maintained my one or more
>> developers or
>>> a project team consisting of one or more developers.
>>>
>>>
>>>
>> Let's begin by eliminating herds.  We can do that by absorbing herds
>> into projects where that makes sense (eg base-system), or expanding the
>>
>> herd into the respective maintainers where a clear association between
>> herd and project does not make sense.  An ebuild can then have a
>> <project> tag in which case it is maintained by all members of a
>> project
>> or a maintainer list, or a combination of both.  It can also have an
>> observer tag for devs that want to track that pkg's maintenance while
>> not being a maintainer.
> This is not semantically correct for XML. Type of maintainer should be indicated by subelement or attribute, not three identical elements.

Are you saying you can't come up with semantic for XML to do this? C'mon 
what I have below isn't the best, but we can come up with something here.

>
>> Aliases can be associated with projects in the same way that ebuilds
>> are.  An alias can either belong to a project, in which case it expands
>>
>> to all the project members plus other added emails, or just a free
>> standing alias with just members.
>>
>> Eg1.  I'm not on base system, so an pkg with
>>
>> <project>
>>     <name>base-system</name>
>>     <email>base-system@g.o</email>
> People aren't going to be happy about this. Their VAX-11s may not be able to handle typing the extra bytes when they do their daily routine of writing 200 metadata.xml files.

I'm not sure what you mean here, but the initial migration would be 
automated.  I don't see why maintenance after that would be difficult.

>
>> </project>
>> <maintainer>
>>     <name>Anthony G. Basile</name>
>>     <email>blueness@g.o</email>
>> </maintainer>
>> <observer>
>>     <name>Devan Franchini</name>
>>     <email>twitch153@gentoo</email>
>> <observer>
> This looks like a serious overkill. Both in the terms of commits and effort required.

What's the overkill part?  The <observer> tag was just to coalesce the 
construction of an alias with the metadata.xml.

>
>> would be maintained by all of base system with alias
>> base-system@g.o and me.  twitch153 is listed as just an observer
>>
>> of the pkg and would receive emails but not technically be allowed to
>> maintain the package.  The email alias for this pkg is automatically
>> generated from the metadata.xml.
> This sounds like a lot of alias changes. What about package removals?  Do aliases get removed too?

Totally rethink the idea of emails aliases as something that is created 
on the fly.  We just need to know who should get emails for a package 
when it comes to bug reports.  Why can't that be calculated on the fly 
from the metadata.xml?

> What about synchronization delays? What about all the extra bugzie accounts?
Again, I think we can come up with something here.   Let's design 
something that'll be easy to work with and then figure out how to 
implement it.

>
>>
>> Eg2. A "free standing" ebuild could have
>>
>> <maintainer>
>>     <name>Anthony G. Basile</name>
>>     <email>blueness@g.o</email>
>>     <proxy/>
>> </maintainer>
>> <maintainer>
>>     <email>bugs@××××××××××.nu</email>
>>     <name>Johan Bergström</name>
>> </maintainer>
>>
>> Again the alias for this pkg is automatically generated from the
>> metadata.xml
>>
>> Thoughs?


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