Re: DAK Commands for Bikesheds
On Thu, Sep 17, 2015 at 01:42:58PM +0200, Joerg Jaspert wrote:
> Please check if I forgot something obvious or if there is some big error
> in it. Patches/git trees to merge from/... are welcome.
dcut from dput-ng uses $login-$timestamp rather than "EPOCH" per se. Does
this actually matter, or is it just convention though?
] The file needs to be signed by a valid key from the Debian uploader
] keyrings.
Does the $login in the filename have to correspond to the signing
key? Ditto the Uploader: field?
] This file has to be uploaded to ftp.upload.debian.org.
I presume dak-commands will be queue-able if anyone updates
queued? There's nothing fundamental preventing it, right?
-1 on abbreviated command names fwiw; it's a text file so
Action: create-bikeshed
seems fine to me. I'd be a little inclined to have "bikeshed-create"
personally, YMMV obviously. "update-bikeshed-acl" or "bikeshed-acl"
or similar might be clearer than "access-bikeshed".
I kind of think "Bikeshed: foo" might be better than "Name: foo" ?
We have "Package: foo" not "Name: foo" in the Packages file, eg.
] if the name conflicts with an existing bikeshed a
] random string will be appended to it.
Outright rejection would be better here, IMO. The user can always add
a random string themselves if that's what they actually want.
] Package: A name of a source package to import from the base-suite.
] Repeat as often as needed.
That's unusual. Is having multiple packages on a single header also
valid? eg:
Package: glibc, systemd, sysvinit
?
If "Master:" is specified, is the uploader implicitly considered a
master as well, or do they need to specify themselves? (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.
] including dropping a bikeshed
(Demolishing would be a more amusing verb :)
(Likewise, "modify-bs" should clearly be "paint-bikeshed" given it only
changes things that have no technical effect...)
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)
] (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.
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.
Has the Auto-Update / mergeback stuff been implemented yet? It doesn't
seem like it quite makes sense as is:
] Auto-Update: True or False. Automatically update packages imported
] from the base suite, whenever they get updated in the base suite. This
] may possibly break packages uploaded directly to the bikeshed.
This option doesn't really seem useful to me -- rather than say
"base-suite: jessie; auto-update:yes", why wouldn't you say "add both
jessie and bs-my-awesome-thing to your sources.list"? If the base-suite
is testing or unstable, users will have to have testing/unstable in
their sources list anyway in order to get library dependencies most of
the time...
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.
] 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)
There doesn't seem to be a command available to modify a bikeshed's
auto-update or base-suite settings. (I'm not sure there should be
though. If you can't change a bikeshed's base-suite after creation;
there's no possibility of loops where two bikesheds are both the other's
base-suite)
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.
Allowing suite aliases (unstable, experimental) for Base-Suite would
probably be a win -- just document that they're resolved at bikeshed
creation time, so release-time changes to testing/stable/oldstable won't
update the bikeshed, though.
Cheers,
aj
Reply to: