Re: DAK Commands for Bikesheds
On 14070 March 1977, Anthony Towns 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?
Convention, we don't enforce it. Though we keep the right to do it,
should we suddenly end up with loads of collisions or something.
> ] 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?
Dito.
> ] 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?
Correct.
> -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".
The shortcut mostly comes from lazyness, bs is less to type. I've
renamed access-bs to acl-bs, acl is a much better fit.
And renamed all commands from foo-bs to bikeshed-foo.
> I kind of think "Bikeshed: foo" might be better than "Name: foo" ?
> We have "Package: foo" not "Name: foo" in the Packages file, eg.
Accepted.
> ] 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.
Hrm, I think its nicer to "help along". They want a bikeshed, they get
one, even if someone else ended up having a similar one already.
But it makes it easier in code, so gone the postfix is.
> ] 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
> ?
I think it's cleaner to have one per package tag, but its either that or
only one line, comma-seperated. No preference here.
> If "Master:" is specified, is the uploader implicitly considered a
> master as well, or do they need to specify themselves?
Yes, any Master: value is added on top of the default uploader.
> (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. Master IMO shows better what the
intended value of it is - the ones with access to change around its
settings. (Got to that from the MASTER role in irc.debian.orgs chanserv).
> ] including dropping a bikeshed
> (Demolishing would be a more amusing verb :)
Adjusted, added demolish-bs as an alias for the drop-bs command.
> (Likewise, "modify-bs" should clearly be "paint-bikeshed" given it only
> changes things that have no technical effect...)
Similar here. Also, if my CSS guru doesn't deny its possibility, both
create and modify will gain either a color or a style option, so you can
have your own color/style in the bikeshed overview page later on, so
modify will change things with technical effect (HTML "code"!), and
paint-bikeshed fits so much more then too. :)
> 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.
> ] (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
> Has the Auto-Update / mergeback stuff been implemented yet? It doesn't
> seem like it quite makes sense as is:
None of it has. I defined all the commands going through the spec trying
to get up with something useful, then getting people to comment on all
that I missed / may be better done different, while starting to
implement it (there is enough support changes around that this works
out nicely).
> ] 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...
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.
> 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).
And yes, intention is that the full set of packages from the bikeshed
can be merged back, following the normal set of archive rules (say,
version constraints) we have. A failure shouldn't create a mess by
pushing only half over.
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.
> ] 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.
> 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)
I think there shouldn't be, correct.
> 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.
> 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.
Done.
I've updated https://ftp-master.debian.org/users/joerg/README.commands
with hopefully not too many new errors. :)
--
bye, Joerg
Kids, you tried your best and you failed miserably. The lesson is, never try.
Reply to: