[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

Yours, to fit the REJECT rule:
-> Only packages listed, regardless of auto-update, may ever be

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

>  - 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.


> (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: