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 <[email protected]>: > 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
