Re: DAK Commands for Bikesheds
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
Reply to: