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 <[email protected]>wrote: > "Maciej (Matchek) Bliziński" <[email protected]> writes: > > > 2013/4/12 Peter FELECAN <[email protected]>: > >> In the pkginfo file we have this: > >> > >> VENDOR=http://leocad.googlecode.com/files/ packaged for CSW by Peter > Felecan > >> [email protected] > >> > >> We should have: > >> > >> VENDOR=http://leocad.googlecode.com/files/ > >> [email protected] > >> ... > >> 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 <[email protected]>, Jane Dow < > [email protected]> > > 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 > [email protected] > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. >
_______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
