[csw-maintainers] Non-Maintainer Uploads (NMUs)
pfelecan at opencsw.org
Sun Aug 11 12:43:02 CEST 2013
Yann Rouillard <yann at pleiades.fr.eu.org> writes:
> I do not think the package ownership concept is obsolete.
> We can't ask everybody to feel concerned and competent about every package
> and some people might join the project just to maintain a few packages that
> they really care about.
> Whatever we do, the question in the end is: who feels responsible for
> dealing with bugs and updates for a package ?
> I don't really believe in the mode "there are no package maintainer,
> everybody can update every package", I think this lead to
> Even if we don't have any contract, I think there is an implicit commitment
> when you take ownership of a package. Debian even listed for instance what
> are the responsabilites of a maintainer:
> As a user of a package, it's also important to know wether the package you
> want to use has some maintainers behind or if it's in best effort mode by
> people who may even not use the package.
> What is obsolete I think is the to have one maintainer package that is the
> only one entitled to change the package (we already moved from that), we
> should instead:
> - promote team maintenance rather than one maintainer per package,
> - promote non-maintainer uploads with some rules,
> - have a special team for orphaned packages.
> Whatever the outcome, we will need anyway to change a bit the
> infrastructure because it is not adapted to either team maintenance or
> globally shared maintenance mode:
> - the bugtracker will always send the bugs to the last person that
> uploaded the package and the the bug summary page does the same
> - the qa page and maintainer page still list the packages last uploaded
> by someone like it was maintained by the person (it's still written
> "maintained by" by the way): http://www.opencsw.org/maintainers/maciej/
> 2013/8/11 Maciej (Matchek) Bliziński <maciej at opencsw.org>
>> The current notion throughout our code base is that the user who runs
>> mgar, and the user who owns the package is the same user. To separate
>> these two concepts, the code needs modifications in many places.
>> But I would also like to challenge Peter's not willing to inherit the
>> packages. I was hoping that the notion of package ownership has
>> already eroded. It was different in the times when package sources
>> were private. Other people did not have access to the build recipes,
>> so the only way to get the package modified, was to ask the sole
>> person who had the sources. Fortunately, we're in a different world
>> now, we share the code. Anybody can get the code and build it.
>> We're a volunteer organization, we do not hold any binding contracts
>> with regards to package maintenance. My name on a package means that I
>> was the last person to modify the package, which means I might know
>> something about the package and you have an idea of whom to talk to.
>> It does not entitle you to any demands with relation to the package. I
>> might have been the last person to upload the package, but I be no
>> longer willing to work on the package. Therefore, I would suggest we
>> do not embed in our infrastructure the outdated concept of package
>> Let's take a step back: what's wrong with having your name show up
>> next to a package to which you made a small change?
I was on the point to answer when Yann's message come in. He answers very
well my worries, especially the one about responsibility dilution.
I have no issues with working on as many packages as it gets --- have
done that a lot lately thus my set of "maintained" packages get bigger
and bigger without intentionallity of my part of a real care.
Until we have a way of collective maintainceship I think that my
proposition is worthy of implementation.
Even if we have a collective/group maintainceship the process of
entering that collective/group must be more than a NMU action which can
be motivated by other reasons than the intent of care for that package.
To come back to my proposition, in which part of the code is the
association made, i.e. uploader becomes maintainer? Answering this
question can simplify my life instead of wandering all the surface of
More information about the maintainers