The feature to be able to do collaboration and transfer is making its way into the lower layers and foundations of the snappy infrastructure. As that happens I start think about the UX from a snapcraft command line experience and cannot think of a way to edit this assertion in a friendly way that wouldn’t be error prone or lead to exceedingly long command parameters.
With all that in mind the concept flow is that an invocation of:
snapcraft edit-collaborators <snap-name>
An alias of collaborators would be set in place as well.
Would lead to an editor instance, respecting $EDITOR to edit the list of developers that can collaborate on that snap. The mechanics are similar to visudo, on exit snapcraft will parse the contents, raise issues and allow you to resolve or abort.
# Change which developers may build or upload snaps on the publisher's behalf.
#
# Sample entry:
#
# developers:
# - developer-id: "dev-one" # Which developer
# since: "2017-02-10 08:35:00" # When contributions started
# until: "2018-02-10 08:35:00" # When contributions ceased (optional)
#
# All timestamps are UTC, and the "now" special string will be replaced by
# the current time. Do not remove entries or use an until time in the past
# unless you want existing snaps provided by the developer to stop working.
developers:
- developer-id: "dev-1"
since: "2017-02-10 08:35"
until: "2018-02-10 08:35"
- developer-id: "dev-2"
since: "now"
- developer-id: "dev-3-revoked"
since: "2017-02-10 08:35"
until: "2017-02-10 08:35"
Instead of developing an ncruses interface, which in most cases I’ve experienced tend to be cumbersome, I suggest opening an editor with a commented text file in a known format – given the context, yaml would be a good option. This file would not be the file you get from the store, but rather something tuned to make the publisher understand what’s going on, be properly commented, and also pleasant to edit. When the user’s preferred editor quits, snapcraft takes control back and validates the file. If something is amiss or likely dangerous to do, it shows a message pointing out the (probable) mistake, and gives the user a chance to immediately reopen the editor for fixing.
This makes it cheap for you to implement and evolve proper validation logic without worrying about the interface, and comfortable for the person handling it since it’s their own editor on a file format they’ll likely understand, given we already have other files in that same format.
Right, and I wouldn’t go any further in the command line. This will solve the problem appropriately instead of being a temporary hack. Later the store itself may offer a high-level user interface to those who’re not comfortable at the terminal.
No concerns in terms of that conversion. The yaml format is a superset of json, so everything may be represented, and you have a chance of rejecting the types you don’t want to handle. I’d also expect the fields we need to deal with to be mostly strings.
Great, I’ll poke you for the review of the “template” to edit.
I’ll investigate if there is a way to dump comments into the stream for the cases of an assertion that already exists and we want to load some hinting e.g.; about the effect of removing an entry from the developer list.
@niemeyer any opinion on the command to trigger? I am inclined to use
snapcraft edit-collaborators <snap-name>
The editor view is really just going to be a list of developers with some help on the top
# Add or remove contributors to your snap or transfer
# ownership to another publisher
#
# There are 2 mandatory and 1 optional field, these are:
# developer-id: the id for the developer you want to add (you should get this from the developer you want to add.
# since: a timestamp conforming to rfc3339 indicating when collaboration begins
# until: an optional timestamp conforming to rfc3339 indicating when collaboration ends.
#
# A timestamp for since equal to until means that collaboration for that developer has been revoked.
developers:
- developer-id: "dev-1"
since: "2017-02-10T08:35:00.390258Z"
until: "2018-02-10T08:35:00.390258Z"
- developer-id: "dev-2"
since: "2017-02-11T08:35:00.390258Z"
- developer-id: "dev-3-revoked"
since: "2017-02-10T08:35:00.390258Z"
until: "2017-02-10T08:35:00.390258Z"
So, the timestamp will be of the form conforming to rfc3339 (e.g. since: 2017-01-01T00:00:00.0Z).
Transferring ownership can not be done via snapcraft -> API path at present. That is a store admin action for now (I’m not sure if that’s going to change). This ‘collaborate’ feature is basically to add/remove contributors to a snap by its current publisher.
@mvo or @pedronis can you tell me when snap-developer will be available in a release? We have the groundworks for exposing this feature ready but need snapd/snap made available
@sergiusens that assertion type will be in 2.24, otoh I’m not quite sure the store bits are yet fully ready to advertise this (you might want to coord with @atomatt ?) , snapd itself will need to work with the assertion but that’s a later phase I think
I am coordinating with @atomatt … the functionality is already available on staging and we are waiting on full e2e integration to pull the switch. Thanks for the update, I guess 2.24 is almost out the door now.
Almost all functionality is now in place on staging, although we’re doing a bit more work on the API snapcraft uses and some preliminary data migrations.
But please note that nothing is switched on in prod yet. Prod needs to be handled carefully, e.g. final migrations, emails to existing users, etc, but we can’t really do that until everything else is ready.
So, I think it’s a bit soon to be announcing anything. We haven’t even had the chance to test everything together in staging yet.
Ok, so fisrt comes snapd available to the general populis, then we test snapcraft against staging, confirm it works as planned, and trigger the deploy to the production store, once that is there we can make it available in snapcraft.
The sentence about transference of ownership seems unrelated to the content at hand. I’d drop from there.
The timestamps don’t feel very human oriented. Seems better to have, for example, “2017-02-10 08:35:00” and mention in the text above that they are UTC. It’s okay to round up pre-existing numbers down (both since and until), since the race of less than single second is irrelevant in terms of the human interactions that this will control.
It’d be great to offer a “now” shorthand that may be entered in any of the fields, and then replace it by the current time after the editor exits.
Seems worth dropping the note that encourages people to use a matching since and until to revoke access. People will interpret this as being the way to have people no longer contributing, which is not the idea. This will kill every pre-existing snap signed by the given developer.
Same as the point above, we need to prevent people from removing entries as being done in the first sentence if they don’t intend to break old snaps.
In fact, the two previous points are problematic enough that I’d introduce a special mode via a command line flag, named clearly along the lines of –disable-old-snaps, and prevent people from moving the until time backwards from “now” unless they use this flag.
With those details in mind, suggested text for the header:
# Change which developers may build or upload snaps on the publisher's behalf.
#
# Sample entry:
#
# developers:
# - developer-id: "dev-one" # Which developer
# since: "2017-02-10 08:35:00" # When contributions started
# until: "2018-02-10 08:35:00" # When contributions ceased (optional)
#
# All timestamps are UTC, and the "now" special string will be replaced by
# the current time. Do not remove entries or use an until time in the past
# unless you want existing snaps provided by the developer to stop working.
As for the command, how about snapcraft edit-developers mysnap?
If we’re naming such collaborators as “developers”, we should try to be
consistent across the board.
Thanks, I was just discussing the whole idea about making the task adding timestamps more user friendly with some OLS folks. I’ll take your suggestions into account.
