Re: DAK Commands for Bikesheds
On Sun, Sep 20, 2015 at 03:48:24PM +0200, Joerg Jaspert wrote:
> > That's unusual. Is having multiple packages on a single header also
> > valid? eg:
> > Package: glibc, systemd, sysvinit
> > ?
> I think it's cleaner to have one per package tag, but its either that or
> only one line, comma-seperated. No preference here.
*shrug* No real preference here either.
> > (It seems they are implicitly considered a master when updating the
> > bikeshed's ACLs) I would have thought "Owner:" would make more sense
> > than "Master:" fwiw.
> Then you end up having multiple owners.
I don't see a problem with that (eg, owner@bugs.d.o has multiple
recipients). But again, *shrug*.
> > 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:
- change the bikeshed_acl table from "suite, level, fingerprint"
(level being "master" or "uploader") to "suite, level, uid, fingerprint".
- add a "check" constraint on bikeshed_acl:
CHECK ((uid IS NULL AND fingerprint IS NOT NULL) OR
(uid IS NOT NULL AND fingerprint IS NULL))
- when querying fingerprints for a suite, instead of:
SELECT fingerprint FROM bikeshed_acl WHERE suite = {} AND level = {}
use
SELECT COALESCE(acl.fingerprint, fp.fingerprint)
FROM bikeshed_acl AS acl OUTER JOIN fingerprint AS fp ON
(acl.uid = fp.uid)
WHERE acl.suite = {} AND acl.level = {}
Happy to have another look when there's enough code to suggest an
actual patch.
> > ] (eg., DMs need an ACL set for their package).
> > It seems like it would be good to have some way of letting a DM hack on a
> > package that they can't do in unstable -- ie, where they can practice,
> > or demo their ideas, etc. This might be handy for "summer of code"
> > projects for example.
>
> Ack.
>
> > I wonder if it might be better to have two permissions arrangements: (a)
> > don't specify any fingerprints, and anyone who can upload to unstable
> > can upload to the bikeshed (same ACLs for DMs), or (b) do specify
> > fingerprints, and those keyholders can upload anything in the bikeshed
> > (no ACLs for DMs), but no one else can.
>
> So basically what it is now (set no uploader and its same as for
> unstable, set fingerprints and its those), except for the "DMs need an
> ACL" is turned into "DMs don't need an ACL for a package, if listed as
> an Uploader in this bikeshed"? That would allow them to upload all
> packages to that bikeshed.
>
> Alternative would be to add that as a third option, so one would have
>
> - free for all, ACLs for DMs (as unstable)
> - free for all listed, ACLs for DMs
> - free for all listed, no ACLs for DMs
Oh, yes! That would just be:
Action: bikeshed-acl
Bikeshed: bs-foo
DM-ACLs: off
Uploader: [dm fp]
Uploader: [dd fp]
> The idea is to say "Make me a bikeshed of packages foo and bar, keep em
> updated with my base suite, i'm rebuilding against them everytime they
> update". It's not thinking about the end user here, that sure can add
> both suites.
In that case you actually want a bikeshed of packages foo, bar and baz;
so that you can upload baz to the bikeshed when you rebuild it, no? But
then you also get new versions of baz if you set auto-update.
But I'm not seeing the advantage over setting the base-suite and just
listing baz for your bikeshed. Everytime foo/bar changes you upload a
new baz, and the autobuilders pull the new foo/bar from your base-suite
as build-deps, and you're done.
I'm assuming that an upload to a bikeshed gets REJECTed if:
- uploader isn't in the acl for the bikeshed
- it's not a listed package for the bikeshed
- it's not in the overrides for unstable (or base-suite?)
- 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 ?
> > To me, it seems more useful to have two commands:
> > Action: bikeshed-pull-from
> > Bikeshed: bs-my-awesome-thing
> > Suite: experimental
> > Packages: apt, xorg
> > and
> > Action: bikeshed-push-to-base
> > Bikeshed: bs-my-awesome-thing
>
> > The thinking being that you'd use a bikeshed like:
> > a) "bikeshed-create" -- voila, empty repo, with rules about what
> > can go into it, and a base-suite for resolving dependencies
> > b) "bikeshed-pull-from" -- add some packages from other suites (not
> > necessarily the base-suite)
> > c) upload -- add some of your own packages
> > d) "bikeshed-push-to-base" -- (mergeback) move some/all of the packages
> > in the bikeshed into the bikeshed's base suite
>
> > (Autobuilders would use the base-suite and the bikeshed to resolve build
> > dependencies; if the base-suite was a bikeshed itself, then recurse)
>
> > If "auto-update" let me say "if a new source for foo arrives in unstable,
> > rebuilt it in my bikeshed (with base-suite: stable) automatically",
> > that would be cool, but...
>
> > Are mergebacks atomic? ie if you try to mergeback 10 packages, and one of
> > them fails, do you get 0 merged back or 9? 0 would probably be better,
> > to avoid the case where the 1 that failed was a dependency of the 9
> > that succeeded.
>
> 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.
> 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.
> > ] Command files allow Debian Developers to handle various archive
> > ] related tasks without the help of a FTPMaster.
> > This forbids DMs from creating bikesheds, doing any "owner" actions on a
> > bikeshed, and doing mergebacks, no? (That seems like a good choice if so)
> 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
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)
> > If other bikesheds can be my bikeshed's base suite, I think it makes
> > more sense to hav the "bs-" prefix always appear in bikeshed names, fwiw.
> Do you mean that people should include the bs- prefix on their own?
> Well, actually its only create-bs that preprends it on its own, so
> possibly makes sense to not special case it anywhere and reject names
> without the bs-* in front from being created.
Yeah, +1.
Cheers,
aj
Reply to: