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

[Michał Górny]

Dnia 17 września 2015 12:57:08 CEST, "Anthony G. Basile" <blueness@g.o> napisał(a):
>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.

I can. Just pointing out the wrongs before some overenthusiastic developer commits it.

We should really be using the current maintainer element, possibly amended with new attributes. For compatibility with existing tools at least.

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

Just pointing out the previous outcomes. Gentoo developers aren't happy to sacrifice any kind of laziness for correctness.

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

The overkill is that you spam the repo every time someone changes his mind about following a package. Not to mention he needs a developer to commit the change for him.

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

Debating pipe dreams without basic understanding of technical aspects is a waste of time.

Even if we skip the part of implementing mail server changes, and making bugzilla happy about dynamically changing account list, there are major issues left.

There will be at least the delay between commit in git repo and propagating it to mail server and bugzie. In the meantime, you wouldn't be able to assign and send mail correctly. If it all falls apart, the inability will prolong.

Then, when package is removed, all assignments immediately become invalid. Mail threads can no longer be continued.

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

-- 
Best regards,
Michał Górny