[csw-maintainers] Non-Maintainer Uploads (NMUs)

[Peter FELECAN]

"Maciej (Matchek) Bliziński" <maciej at opencsw.org> writes:

> 2013/8/14 Peter FELECAN <pfelecan at opencsw.org>:
>> Laurent Blume <laurent at opencsw.org> writes:
>>
>>> On 14/08/13 16:12, Peter FELECAN wrote:
>>>> Each package has its set/group of maintainers. Is the simplest way.
>>>
>>> Is that easy to maintain, eg for recipe which create a bunch of packages?
>>
>> If we can do this for one, and we do, we certainly can do it for
>> many. Every operation that we have today for one maintainer can be reused
>> to manage another maintainer. Maybe Maciej can elaborate on this, he is
>> the guy who knows the code best.
>
> We still don't know how to implement it in details. The EMAIL field
> probably has to remain a single email address. We have to gradually
> develop an additional path of propagating maintainer information. For
> example:
>
> - a new pkginfo field MAINTAINERS
> - MAINTAINERS is a comma/space separated list of buildfarm user names
> - when a package is built, GAR makes a request to fetch the previous
> list from the buildfarm database, appends the currently building user
> to the list if not already there; put the list into the MAINTAINERS
> field
>   - this list in the buildfarm database is mutable; you can
> send a request to the buildfarm to remove a maintainer (themselves or
> another maintainer). When a maintainer is removed, the name is no
> longer returned by the query and upon the next package rebuild, the
> name is no longer on the list.
> - the EMAIL field is the fallback for MAINTAINERS
> - GAR side handling of EMAIL remains as it was
> - we gradually change the code everywhere to look at MAINTAINERS and
> not at EMAIL
>
> By the way - I'm not volunteering for implementing this. I'm focusing
> on another part of the code.

1. Your example is interesting but, from my point of view it's a little
   bit too complex and has the inconvenient of a query to the database
   during the package construction wich hinders an isolated usage.

   Let me simplify it by using a kind of poor man chronogram:

   1. In the beginning, a new package is built by an initial
      maintainer, lets name him m0.
	  
	  The package has the usual EMAIL field which is used to create
      the set of maintainers.
	  
	  The set of maintainers is { m0 }.

   2. Another maintainer, m1 does a NMU.
	  
	  Again, the EMAIL filed in the package contains the new
      maintainer's information. This is used to insert the new
      maintainer in the maintainers set.
	  
	  The set of maintainers is now { m0, m1 }.

   3. The first maintainers doesn't wish anymore to be aware of bug
      reports, retires or other whim.
	  
	  He or another responsible maintainer removes him from
      maintainers set using the safe_remove_package_maintainer tool.

	  The set of maintainers is now { m1 }.

   4. Eventually the package is removed from the catalog.
	  
	  Either safe_remove_package is used as today or
      safe_remove_package_maintainer on a set having a sole
      maintainer.

   As we can see, there is no need of a new package field, nor to
   query the database during the build to obtain the set of
   maintainers.

2. As for the persons implementing this, from an efficiency point of
   view, who are the best suited candidates in your opinion?
-- 
Peter