DAK Commands for Bikesheds

classic Classic list List threaded Threaded
33 messages Options
12
Reply | Threaded
Open this post in threaded view
|

DAK Commands for Bikesheds

Joerg Jaspert
Hi,

first off I haven't found a "Standard" document documenting the command
feature of dak as currently used for DMs, so if there is one, that
should be merged with what I wrote up now.

Second, the reason why I started writing: I defined the possible
commands for the upcoming bikeshed feature, which use the same command
interface as the DM commands do.

The whole document will end up our git repository[1], though currently
you need my bikeshed branch from [2] to see it (together wit a bit of
basic code for the commands). Without using git you can look at the
document at [3] - i try to keep that copy updated with changes.

Please check if I forgot something obvious or if there is some big error
in it. Patches/git trees to merge from/... are welcome.

Please reply to [hidden email] so we keep a possible
discussion at one place, easier to find again later. Thanks.

[1] git clone https://ftp-master.debian.org/git/dak.git
[2] git clone https://ftp-master.debian.org/users/joerg/dak.git/
[3] https://ftp-master.debian.org/users/joerg/README.commands

--
bye, Joerg

signature.asc (834 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: DAK Commands for Bikesheds

Raphael Hertzog-3
Hi,

On Thu, 17 Sep 2015, 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.

Please don't call this feature "Bikesheds" and don't hardcode this naming
in the suggested API. It was funny during one Debconf talk... but it won't
be funny in the long term.

I don't want to suggest bikeshedding on the name but stick to something
simple like "XXX Package (Repository|Archive)" with a XXX that makes sense
to you (Special, Developer, Custom, ...).

Thank you!
--
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Reply | Threaded
Open this post in threaded view
|

Re: DAK Commands for Bikesheds

Geert Stappers
On Thu, Sep 17, 2015 at 02:41:11PM +0200, Raphael Hertzog wrote:
> Hi,
>
> On Thu, 17 Sep 2015, 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.
>
> Please don't call this feature "Bikesheds" and don't hardcode this naming
> in the suggested API. It was funny during one Debconf talk... but it won't
> be funny in the long term.

+1


signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: DAK Commands for Bikesheds

Joerg Jaspert
In reply to this post by Raphael Hertzog-3
On 14067 March 1977, Raphael Hertzog 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.
> Please don't call this feature "Bikesheds" and don't hardcode this naming
> in the suggested API. It was funny during one Debconf talk... but it won't
> be funny in the long term.

I disagree.

--
bye, Joerg

Reply | Threaded
Open this post in threaded view
|

Re: DAK Commands for Bikesheds

wookey-4
In reply to this post by Raphael Hertzog-3
+++ Raphael Hertzog [2015-09-17 14:41 +0200]:
> Hi,
>
> On Thu, 17 Sep 2015, 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.
>
> Please don't call this feature "Bikesheds" and don't hardcode this naming
> in the suggested API. It was funny during one Debconf talk... but it won't
> be funny in the long term.

It wasn't supposed to be a joke. Bikeshed is an appropriate name, in
the unix tradition of mildly amusing/punny names.

Wookey
--
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/

Reply | Threaded
Open this post in threaded view
|

Re: DAK Commands for Bikesheds

Dominic Hargreaves-2
On Thu, Sep 17, 2015 at 04:39:43PM +0100, Wookey wrote:

> +++ Raphael Hertzog [2015-09-17 14:41 +0200]:
> > Hi,
> >
> > On Thu, 17 Sep 2015, 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.
> >
> > Please don't call this feature "Bikesheds" and don't hardcode this naming
> > in the suggested API. It was funny during one Debconf talk... but it won't
> > be funny in the long term.
>
> It wasn't supposed to be a joke. Bikeshed is an appropriate name, in
> the unix tradition of mildly amusing/punny names.

On the other hand, neither this thread nor any other d-d thread
that I can find explains what the feature is... so to those who weren't
aware of the name already, it doesn't mean anything :)

>From the context I take it to be a new name for "PPA"s - in which case
thank you for working on this feature!

Cheers,
Dominic.

Reply | Threaded
Open this post in threaded view
|

Re: DAK Commands for Bikesheds

Stefano Zacchiroli
In reply to this post by wookey-4
On Thu, Sep 17, 2015 at 04:39:43PM +0100, Wookey wrote:
> It wasn't supposed to be a joke. Bikeshed is an appropriate name, in
> the unix tradition of mildly amusing/punny names.

Not to mention that this bikeshed thread about the Bikeshed name is
going to be both epic and very meta.

--
Stefano Zacchiroli  . . . . . . .  [hidden email] . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »

signature.asc (828 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: DAK Commands for Bikesheds

Robert Edmonds-4
In reply to this post by wookey-4
Wookey wrote:

> +++ Raphael Hertzog [2015-09-17 14:41 +0200]:
> > Hi,
> >
> > On Thu, 17 Sep 2015, 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.
> >
> > Please don't call this feature "Bikesheds" and don't hardcode this naming
> > in the suggested API. It was funny during one Debconf talk... but it won't
> > be funny in the long term.
>
> It wasn't supposed to be a joke. Bikeshed is an appropriate name, in
> the unix tradition of mildly amusing/punny names.

Which tradition would that be?

Out of the few hundred or so Unix [0] and GNU [1] commands listed on
Wikipedia, the only vaguely amusing/punning names I can find are tac
("cat" backwards) and pinky (a lightweight "finger").

[0] https://en.wikipedia.org/wiki/List_of_Unix_commands

[1] https://en.wikipedia.org/wiki/GNU_Core_Utilities

RFC 1178 ("Choosing a Name for Your Computer", a reprint from a CACM
article) has some good advice about picking hostnames.  Some of it is
applicable to picking names for software, too, including:

      [...]

      Don't overload other terms already in common use.

         Using a word that has strong semantic implications in the
         current context will cause confusion.  This is especially true
         in conversation where punctuation is not obvious and grammar is
         often incorrect.

         For example, a distributed database had been built on top of
         several computers.  Each one had a different name.  One machine
         was named "up", as it was the only one that accepted updates.
         Conversations would sound like this: "Is up down?"  and "Boot
         the machine up." followed by "Which machine?"

         While it didn't take long to catch on and get used to this
         zaniness, it was annoying when occasionally your mind would
         stumble, and you would have to stop and think about each word
         in a sentence.  It is as if, all of a sudden, English has
         become a foreign language.

      [...]

      Don't use antagonistic or otherwise embarrassing names.

         Words like "moron" or "twit" are good names if no one else is
         going to see them.  But if you ever give someone a demo on your
         machine, you may find that they are distracted by seeing a
         nasty word on your screen.  (Maybe their spouse called them
         that this morning.)  Why bother taking the chance that they
         will be turned off by something completely irrelevant to your
         demo.

      [...]

      Use words/names that are rarely used.

         While a word like "typical" or "up" (see above) isn't computer
         jargon, it is just too likely to arise in discussion and throw
         off one's concentration while determining the correct referent.
         Instead, use words like "lurch" or "squire" which are unlikely
         to cause any confusion.

         You might feel it is safe to use the name "jose" just because
         no one is named that in your group, but you will have a problem
         if you should happen to hire Jose.  A name like "sphinx" will
         be less likely to conflict with new hires.

      [...]

--
Robert Edmonds
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: DAK Commands for Bikesheds

Josselin Mouette
In reply to this post by Stefano Zacchiroli
Le jeudi 17 septembre 2015 à 18:52 +0200, Stefano Zacchiroli a écrit :
> Not to mention that this bikeshed thread about the Bikeshed name is
> going to be both epic and very meta.

I herd you like bikesheds…

--
 .''`.      Josselin Mouette
: :' :
`. `'
  `-

Reply | Threaded
Open this post in threaded view
|

Re: DAK Commands for Bikesheds

Ian Jackson-2
In reply to this post by Raphael Hertzog-3
Wookey writes ("Re: DAK Commands for Bikesheds"):
> It wasn't supposed to be a joke. Bikeshed is an appropriate name, in
> the unix tradition of mildly amusing/punny names.

It's a lovely joke but unfortunately the word `bikeshed' already means
something else in a computer/geeky context.  So these things
shouldn't be called bikesheds for the same reason that a computer
shouldn't be called `down' or `internet'.

If we want to have a punny name, they could be called some other kind
of shed or hut or something.

Sorry to spoil the fun.

Ian.

Reply | Threaded
Open this post in threaded view
|

Re: DAK Commands for Bikesheds

Joerg Jaspert
On 14068 March 1977, Ian Jackson wrote:
> It's a lovely joke but unfortunately the word `bikeshed' already means
> something else in a computer/geeky context.  So these things
> shouldn't be called bikesheds for the same reason that a computer
> shouldn't be called `down' or `internet'.
> If we want to have a punny name, they could be called some other kind
> of shed or hut or something.
> Sorry to spoil the fun.

Or this could simply stop.

Unless someone objecting suddenly contributes a big pile of code to it,
it simply will be bikeshed as the name.

--
bye, Joerg
Somebody COULD get hurt … COULD … but chances are they won’t.

Reply | Threaded
Open this post in threaded view
|

Re: DAK Commands for Bikesheds

Joerg Jaspert
In reply to this post by Joerg Jaspert
On 14067 March 1977, Joerg Jaspert wrote:
> Second, the reason why I started writing: I defined the possible
> commands for the upcoming bikeshed feature, which use the same command
> interface as the DM commands do.

And there has been the very valid point that I haven't explained here
what the heck bikesheds are. Some people know it from being at DebConf
or watching the videos, but thats hardly all of -devel/-dak, so here it
goes:

Bikesheds are personal suites in an archive provided by the FTPMasters.
They have initially been described in [1] and a only slightly modified
version incorporating some feedback is what they will be based on.

They can be set up in whichever way the Creator (any DD, possibly also
DMs) can imagine (and that makes sense) and support package imports from
their base suite (say, import mailfilter from wheezy) and possibly
depended-on bikesheds, can support mergebacks into their base-suite (if
that one accepts such an option). The masters of a bikeshed can select
which architectures are supported, who exactly has upload rights[2],
remove packages, ... - basically do all modifications as needed, except
for NEW handling.

And if there aren't enough knobs to fiddle with and have just your own
version in the commands spec I sent out, I'm sure we can add more, now
and later on.

Also, to make them proper bikesheds, one can even set their color, maybe
even a full set of style information!


[1] https://lists.debian.org/debian-devel/2013/05/msg00131.html
[2] From the Debian keyring. A version allowing external people to
    upload will follow later, on a different host and archive. Called
    PPAEXT in that proposal.

--
bye, Joerg
"Gna, schon wieder Seti [...] Dabei ist es schon schwierig genug, auf
*diesem* Planeten intelligentes Leben zu finden."
[Charly Kuehnast in dasr]

Reply | Threaded
Open this post in threaded view
|

Re: DAK Commands for Bikesheds

Colin Tuckley-2
On 18/09/15 22:23, Joerg Jaspert wrote:

> what the heck bikesheds are.

What you seem to not be understanding, possibly because English is not
your first language, is that anything associated with the term
'bikeshed' is very *negative*.

They have strong derogatory connotations, so much so that I doubt any
native English speaker will be interested in them.

Colin

--
Colin Tuckley      |  +44(0)1223 830814  |  PGP/GnuPG Key Id
Debian Developer   |  +44(0)7799 143369  |     0x38C9D903

Reply | Threaded
Open this post in threaded view
|

Re: DAK Commands for Bikesheds

Philip Hands
Colin Tuckley <[hidden email]> writes:

> On 18/09/15 22:23, Joerg Jaspert wrote:
>
>> what the heck bikesheds are.
>
> What you seem to not be understanding, possibly because English is not
> your first language, is that anything associated with the term
> 'bikeshed' is very *negative*.
>
> They have strong derogatory connotations, so much so that I doubt any
> native English speaker will be interested in them.
Utter nonsense ... or are you trying to claim that Steve, Wookey, Neil,
Paul and I are not native English speakers now?

I dispute your claim that "bikesheds", as opposed to "bikeshedding", is
negative -- if it were, we'd store our velocipedes in the cycle lock-up.

Given that these things will reduce bikeshedding by providing as many
bikesheds as there are colour preferences, the name is perfect.

Regardless, the decision is neither yours nor mine, and judging by
Jeorg's responses to this thread, has already been made, so can we all
stop bikeshedding (in the purely negative sense) now please?

Cheers, Phil.
--
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/    http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,    GERMANY

signature.asc (834 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: DAK Commands for Bikesheds

Lucas Nussbaum-4
In reply to this post by Robert Edmonds-4
On 17/09/15 at 15:04 -0400, Robert Edmonds wrote:

> Wookey wrote:
> > +++ Raphael Hertzog [2015-09-17 14:41 +0200]:
> > > Hi,
> > >
> > > On Thu, 17 Sep 2015, 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.
> > >
> > > Please don't call this feature "Bikesheds" and don't hardcode this naming
> > > in the suggested API. It was funny during one Debconf talk... but it won't
> > > be funny in the long term.
> >
> > It wasn't supposed to be a joke. Bikeshed is an appropriate name, in
> > the unix tradition of mildly amusing/punny names.
>
> Which tradition would that be?
>
> Out of the few hundred or so Unix [0] and GNU [1] commands listed on
> Wikipedia, the only vaguely amusing/punning names I can find are tac
> ("cat" backwards) and pinky (a lightweight "finger").

seriously?
apt, aptitude, bash, bison (yacc replacement), curl, curses, flex, gawk,
glut, grub, lame, less, mutt, sane, tar, vim are all project names that
I find at least vaguely amusing.

However we can probably find something more amusing and less loaded than
'Bikeshed' for the project being discussed.
 
Lucas

Reply | Threaded
Open this post in threaded view
|

Re: DAK Commands for Bikesheds

Josselin Mouette
In reply to this post by Joerg Jaspert
Le jeudi 17 septembre 2015 à 13:42 +0200, Joerg Jaspert a écrit :
>  https://ftp-master.debian.org/users/joerg/README.commands

Thanks for the documentation (and for the code!).

How do you upload a package to a bikeshed? Just set bs-whatever as the
suite in the changes file?

--
 .''`.      Josselin Mouette
: :' :
`. `'
  `-

Reply | Threaded
Open this post in threaded view
|

Re: DAK Commands for Bikesheds

Anthony Towns-5
In reply to this post by Joerg Jaspert
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 | Threaded
Open this post in threaded view
|

Re: DAK Commands for Bikesheds

Joerg Jaspert
In reply to this post by Josselin Mouette
On 14070 March 1977, Josselin Mouette wrote:
> How do you upload a package to a bikeshed? Just set bs-whatever as the
> suite in the changes file?

Yes.

--
bye, Joerg
Old people don't need companionship. They need to be isolated and
studied so it can be determined what nutrients they have that might be
extracted for our personal use.

Reply | Threaded
Open this post in threaded view
|

Re: DAK Commands for Bikesheds

Joerg Jaspert
In reply to this post by Anthony Towns-5
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 | Threaded
Open this post in threaded view
|

Re: DAK Commands for Bikesheds

Stefano Zacchiroli
On Sun, Sep 20, 2015 at 03:48:24PM +0200, Joerg Jaspert wrote:
> I've updated https://ftp-master.debian.org/users/joerg/README.commands
> with hopefully not too many new errors. :)

Minor nit (assuming I've got the naming convention right).

--- README.commands.orig 2015-09-20 17:33:11.752599712 +0200
+++ README.commands 2015-09-20 17:33:31.772637265 +0200
@@ -121,7 +121,7 @@
 
 #+BEGIN_EXAMPLE
 Action: bikeshed-create
-Bikeshed: theoneandonly
+Bikeshed: bs-theoneandonly
 Description: This is all you need, ever
 Base-Suite: sid
 Package: mailfilter
@@ -129,7 +129,7 @@
 Breaks: bs-doesnotyetexistbutihateitalready
 Depends: bs-ohthisisevenbetter
 #+END_EXAMPLE
-Create theoneandonly bikeshed based on sid including the mailfilter
+Create bs-theoneandonly bikeshed based on sid including the mailfilter
 package from sid at time of creation. Uploads are allowed by anyone in
 the uploading keyrings, whenever mailfilter is updated in sid it will
 also be put into theoneandonly bikeshed automatically.


Cheers.
--
Stefano Zacchiroli  . . . . . . .  [hidden email] . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »

12