On 9/17/15 6:32 AM, Michał Górny wrote:

Dnia 17 września 2015 11:07:43 CEST, "Anthony G. Basile" <bluen...@gentoo.org> 
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-sys...@gentoo.org</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>bluen...@gentoo.org</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-sys...@gentoo.org 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>bluen...@gentoo.org</email>
    <proxy/>
</maintainer>
<maintainer>
    <email>b...@bergstroem.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    : bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA


Reply via email to