[csw-maintainers] NMUs, non-maintainer uploads

[Jonathan Craig]

What about an entry in the Makefile along the lines of "MAINTAINER_LOCK =
maintainer_uname" that once set prevents anyone else from uploading a
package unless its cleared by an authorized admin.  This would put it in
the maintainers hands to lock the stuff they want locked.  I would still
like the ability to re-build others packages as a learning experience and
potentially allow me to create private copies of packages with different
choices for personal use.


On Sun, Apr 14, 2013 at 10:14 AM, Peter FELECAN <pfelecan at opencsw.org>wrote:

> "Maciej (Matchek) Bliziński" <maciej at opencsw.org> writes:
>
> > 2013/4/12 Peter FELECAN <pfelecan at opencsw.org>:
> >> In the pkginfo file we have this:
> >>
> >> VENDOR=http://leocad.googlecode.com/files/ packaged for CSW by Peter
> Felecan
> >> EMAIL=pfelecan at opencsw.org
> >>
> >> We should have:
> >>
> >> VENDOR=http://leocad.googlecode.com/files/
> >> EMAIL=pfelecan at opencsw.org
> >> ...
> >> OPENCSW_MAINTAINERS=Peter Felecan, Dagobert Michelsen
> >>
> >> The last variable contain the values of the multi-valuated attribute
> >> "maintainer". The user uploading the package is the value of the
> >> attribute "NMU" --- when I'm writing about "attribute" I'm thinking to
> >> the packages database schema.
> >
> > One more distinction: The user who uploads the package doesn't have to
> > be the same user who ran "mgar package". So we have:
> >
> > 1. users who are long-term maintainers of a given package
>
> These are in variable containing the list and which is in the recipe,
> i.e. Makefile and used to generate the corresponding information in the
> pkginfo file.
>
> > 2. user who ran "mgar package"
>
> Who cares? But if you find it useful, why not.
>
> > 3. user who uploaded the package (ran csw-upload-pkg)
>
> This is more important that one who runs mgar and should be recorded by
> the upload process.
>
> >
> >> The variable in the pkginfo file is generated at packaging time.
> >>
> >> The attributes are valuated at upload time.
> >
> > We can no longer modify the package contents at upload time, and I'm
> > guessing we want everything to be inside the package.
>
> At upload time, the database's attributes are valuated from what's in the
> package, isn't it?
>
> >> Does it seems reasonable?
> >>
> >> What thinks our data-base czar but not less enlightened colleague? :-)
> >
> > Looks like nobody wants to claim the title of DB czar! So I'll chime in.
>
> De facto.
>
> > The list of maintainers needs to be in one of the pkginfo fields,
> > that's simple. But I think it should be a list of user names, or a
> > list of valid (rich) email addresses:
> >
> > OPENCSW_MAINTAINERS=joe, jane
> >
> > or
> >
> > OPENCSW_MAINTAINERS=Joe Doe <joe at example.com>, Jane Dow <
> jane at example.com>
>
> Too complex from my POV but why not.
>
> > One more thing: different people have different attitudes towards
> > different packages. There are packages that are simple libraries,
> > there's little technical decisions involved there, e.g. Perl or Python
> > modules. You just build them, push them out, done. But then there are
> > larger packages, such as Perl or Python themselves, where there are
> > big decisions involved. For example, the horrible patch[1] for Python
> > that has screwed us up big time. Library rebuilds - I don't care,
> > anyone who wants can rebuild them. But screwing up Python like in [1]
> > ‒ over my dead body. So I'd put my name up as the Python package
> > maintainer, but not for Python modules. The package's maintainer list
> > has to be optional.
>
> Agree 100%
> --
> Peter
> _______________________________________________
> maintainers mailing list
> maintainers at lists.opencsw.org
> https://lists.opencsw.org/mailman/listinfo/maintainers
> .:: This mailing list's archive is public. ::.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20130414/2c830250/attachment.html>