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

[Maciej (Matchek) Bliziński]

I didn't have the time to write a short email, so I wrote a long one instead. :)

2013/9/16 Maciej (Matchek) Bliziński <maciej at opencsw.org>:
> Going back to the original subject, we know of the following facts /
> relations of people to a given package:
>
> - people who made edits to the build recipe (can be taken from the
> repository, it's not available for all packages)
> - person who built the package / ran mgar (this information is
> embedded in the package)
> - person who inserted the package into a catalog (could be a different
> person in each catalog)
>
> The above are the things we know. None of these things is the list of
> the Maintainers Of The Package.

I'd like to compare it with what Peter wrote earlier:
http://lists.opencsw.org/pipermail/maintainers/2013-August/018444.html

> 1. the user who modified the recipe
> 2. the user who built the package
> 3. the user who uploaded the package
> 4. the user who owns the package, from Mantis stand point

Here are the considerations:

ad 1. we kind of have that information, but the users here are from a
different user name space, e.g. I'm "maciej" on the buildfarm, but
"wahwah" on SourceForge. We'd need a mapping to meaningfully match the
two user names.

ad 2. this information is stored in package's pkginfo file

ad 3. there is no single upload operation we can refer to. The
following operations exist: (1) a POST request which sends the .pkg.gz
file to the web zone, causing the file to be saved in the allpkgs
directory, (2) a PUT request to the releases_web.py app which creates
a row in one of the tables. The row binds together the specific
package file, and a specific catalog. This row later results in the
presence of that package in the specific catalog on the mirror.
Maintainers can insert packages into any catalogs: unstable as well as
kiel and/or dublin. In most cases the inserts into the testing
(currently: kiel) catalog are done by a different person than the
maintainer.

ad 4. this field is sourced directly from the user who built the
package, but it doesn't have to be that way in principle

Given how things currently work, I don't see an existing data that we
can use for a more meaningful True Maintainer. Here's an idea: we
could create an optional field in the recipe, which would be an
explicit list of maintainers of that package. If it's not present,
things work as previously. If it is there, it pins down the current
maintainer, and the package does go to a new owner. But we would
require a certain etiquette to use it. For example, I would put myself
down as the Python package maintainer. There would be other packages
that happened to rebuild, but I don't care as much as I do about the
main Python package. If somebody else was rebuilding one of packages I
also happened to rebuild earlier, I would not like them to put my name
down as the maintainer. In other words: you would be supposed to only
add your own name to that list.

Would it make things better? I'm not sure. If I understand correctly,
Peter's intention was to kind of hide the fact that you've rebuilt a
package; so you rebuild the package, but you don't change the
maintainer name associated with the package. But the problem is that
the currently associated name is already as bogus as your name. Let me
illustrate:

Joe rebuilds the CSWfoo package from version 1.1 to version 1.2, but
he doesn't want to take the ownership of that package. The current
state is this:

CSWfoo 1.1, maintainer: Jane

But is Jane the true maintainer? No! She only did a rebuild of CSWfoo
from 1.0 to 1.1, and the package was previously rebuilt by Bob. But
was Bob the true maintainer? No, he only did a rebuild from 0.9 to
1.0. It can be turtles all the way.

In other words, the package maintainer written on a package is not as
meaningful as people often take it to be. Let's start by admitting it,
then see if we can improve on that.

I believe that True Package Ownership can be beneficial, but it should
be an opt-in thing, and for all other packages we should continue the
"who last touched it" tracking.

Maciej