On 14071 March 1977, Anthony Towns wrote: >> > For the "Master" and "Uploader" fields, it would probably be nice if >> > you could specify DDs by uid instead of just fingerprint. (Especially >> > so that updates to the keyring were automatically reflected in bikeshed >> > permissions) >> Fingerprint handling is way easier, especially when taking DMs in >> account, so that is noted, but will probably not be in the very first >> version. > I think uid handling would be pretty easy:
I look into that when I'm there, sure. > Happy to have another look when there's enough code to suggest an > actual patch. Looking at current speed, that will be end of this month. It's going slow, but at least it's going. > I'm assuming that an upload to a bikeshed gets REJECTed if: > - uploader isn't in the acl for the bikeshed while acl != "freeforall" > - it's not a listed package for the bikeshed Now that shows a different understanding of listing the packages. One thats also valid and interesting, but one that for example Thomas (and me) had different: (Note, always talking about source package) Current, according to docs: -> Packages as listed on create or add time are added to the bikeshed on create (or add) time, newer version put in if so selected by auto-update. Yours, to fit the REJECT rule: -> Only packages listed, regardless of auto-update, may ever be uploaded. Which could both be valid. Hrm. > - it's not in the overrides for unstable (or base-suite?) Initially my answer was "base suite", but that hurts backports. But just unstable also hurts, for the same reason: Overrides change enough over the lifetime of a release, that I think the best will be a combination, so "base-suite + unstable" overrides. That would allow all thats in base-suite but may have been removed in unstable, but also allow all new additions to unstable to get backported. > - it fails standard corruption checks (bad tarball, lintian) > - it has an older version that what's already in the bikeshed > - it has an older version that what's already in the base-suit ? Ack. May actually want to see if we make the lintian checks configurable, ie. ability to turn off at least the soft rejects for it. >> Right, so, the mergeback feature is intended for transitions and bigger >> $whatevers in Debian that need longer preparation. And it needs the >> "base-suite" to cooperate, that is, it needs to be turned on in the base >> suite (so I think unstable and possibly testing will support it, I doubt >> that stable ever will). > I could imagine proposed-updates supporting it? > I think for testing, it would be better to have britney pull from a > bikeshed (similarly to how it pulls from testing-proposed-updates) > rather than let people push to testing. Ack, but I leave that decision to the actual people responsible for those suite. >> Your -pull-from is basically my -add, just with an added suite. My way >> of thinking is coming from a way more limited usage, so I adjusted add >> to optionally take Suite as parameter, now one can select from where the >> package comes. > Hmm. I was thinking of "add" as just changing what's allowed to be > uploaded. That goes with what I wrote above, different understanding of what the listed packages mean. >> I think so, yes. If the whole of the project wants to adjust that, I >> wouldn't be against it, but I think its too far a change from the >> concept of DM as we have now that I just want to put it in. > So the reason I think DMs shouldn't create bikesheds directly is mostly > about permissions: > - DM creates bikeshed > - DD uploads package DM doesn't have perms to upload in unstable > - DM merges package into unstable It should fail at the last point then. > You could put in extra checks to ensure DMs can only create bikesheds > for packages they're allowed to play with, or to ensure mergebacks check > DM ACLs when invoked by a DM, but all-in-all it seems to me if a DM is > clever enough to be playing with bikesheds, it's about time they became > a DD anyway. Ay. > (Maybe we should have called DM's "Debian Apprentices" to emphasise DMs > should become DDs after a while... If nothing else, would have allowed > a Sith model of package maintenance which would be amusing) Well, there are people who are happy to be "just" a DM. We shouldn't block them from getting DD, but if they like DM, sure, maintain your package and be happy :) -- bye, Joerg
