[project-template VOTE]: Merge governance and release docs at 56abe1227eaf11066fa0005d955b376cbd4883a5 (closes 2016-07-19 19:00 UTC)

[Brandon Philips]

Hello Everyone-

If accepted this vote will merge the governance and release process PR[1][2] which ends in commit 56abe122. The goal of the document is to outline a standard process for how releases are made. The most recent image-spec release used this process as a practice run.

The 18 of us represent the image-spec, runtime-spec, and runc maintainers. This vote will be accepted when 12 people reply with LGTM.

This document has gone through many revisions based on mailing list, GitHub, and phone discussions over the last 30+ days and I feel that through those conversations we have arrived at a workable process.

Please reply with either an LGTM or a REJECT with your reasons.

Cheers,

Brandon

[1] https://github.com/philips/project-template/blob/56abe1227eaf11066fa0005d955b376cbd4883a5/RELEASES.md

[2] https://github.com/philips/project-template/blob/56abe1227eaf11066fa0005d955b376cbd4883a5/GOVERNANCE.md

[Brandon Philips]

LGTM

[Mrunal Patel]

LGTM

LGTM

--
You received this message because you are subscribed to the Google Groups "dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev+uns...@opencontainers.org.

[Tianon Gravi]

LGTM

♥,
- Tianon
4096R / B42F 6819 007F 00F8 8E36 4FD4 036A 9C25 BF35 7DD4

[Brendan Burns]

LGTM

---

From: Tianon Gravi <admw...@gmail.com>
Sent: Tuesday, July 12, 2016 1:09:11 PM
To: Brandon Philips
Cc: Aleksa Sarai; Morozov; Vagin; Dao Quang Minh; Bouzane; John Starks; Boulle; Crosby; Patel; Huang; Jnagal; Stephen Day; Marmol; Vincent Batts; Kannan; Brendan Burns; dev; Technical Oversight Board
Subject: Re: [project-template VOTE]: Merge governance and release docs at 56abe1227eaf11066fa0005d955b376cbd4883a5 (closes 2016-07-19 19:00 UTC)

 

[Aleksa Sarai]

> Hello Everyone-
>
> If accepted this vote will merge the governance and release process
> PR

> <https://github.com/opencontainers/project-template/pull/15>[1][2] which

> ends in commit 56abe122. The goal of the document is to outline a
> standard process for how releases are made. The most recent
> image-spec release used this process

> <https://groups.google.com/a/opencontainers.org/d/msg/dev/FoYcImNQg4c/Re0guPPHBQAJ>

> as a practice run.
>
> The 18 of us represent the image-spec, runtime-spec, and runc
> maintainers. This vote will be accepted when 12 people reply with LGTM.
>
> This document has gone through many revisions based on mailing list,
> GitHub, and phone discussions over the last 30+ days and I feel that
> through those conversations we have arrived at a workable process.
>
> Please reply with either an LGTM or a REJECT with your reasons.

My only outstanding issue is that we don't specify that tags should be
signed by maintainers. This is something we should start doing more
seriously to make sure that downstream distributors of the code can
verify that the maintainers actually LGTM'd the code they're downloading.

So, REJECT. The wording would just have to be something like:

The lead maintainer MUST sign the every image tag created as part of the
release process using their GPG key.

--
Aleksa Sarai
Software Engineer (Containers)
SUSE Linux GmbH
https://www.cyphar.com/

[Qiang Huang]

LGTM

[W. Trevor King]

On Wed, Jul 13, 2016 at 10:17:11AM +1000, Aleksa Sarai wrote:
> So, REJECT. The wording would just have to be something like:
>
> The lead maintainer MUST sign the every image tag created as part of
> the release process using their GPG key.

The “Chief Maintainer” construct may only apply to runC [1]. I'd
settle for a tag signed by any of the project maintainers. There
should be sufficient key-signing between maintainers for the
particular signing maintainer to not matter particularly much.

Cheers,
Trevor

[1]: https://github.com/opencontainers/project-template/issues/4#issuecomment-223066777

--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

[Aleksa Sarai]

> The “Chief Maintainer” construct may only apply to runC [1].  I'd
> settle for a tag signed by any of the project maintainers.  There
> should be sufficient key-signing between maintainers for the
> particular signing maintainer to not matter particularly much.

I didn't mean the chief maintainer, I meant the maintainer that proposed the release. Sorry for the confusion. ;)

[W. Trevor King]

Ah, that's a requirement that could work for all OCI Projects
(although I still don't see much reason to require a particular
maintainer to do the signing).

Cheers,
Trevor

[Jonathan Boulle]

LGTM

[Dao Quang Minh]

LGTM

[Brandon Philips]

On Tue, Jul 12, 2016 at 5:17 PM Aleksa Sarai <asa...@suse.de> wrote:

>     Please reply with either an LGTM or a REJECT with your reasons.

My only outstanding issue is that we don't specify that tags should be
signed by maintainers. This is something we should start doing more
seriously to make sure that downstream distributors of the code can
verify that the maintainers actually LGTM'd the code they're downloading. 

So, REJECT. The wording would just have to be something like:

I agree with the sentiment. Can you document this in the runC release process and use it for a few releases and then we can amend this document with this recommendation?

Based on the conversation I think we need to establish a few things around release signing:

1) What key is used to tag the release?

2) What goes into the tag commit?

3) Where is the public key published for third parties to verify?

If runC comes up with good answers to these I am certain to this we can add the signing recommendation with little issue. Would that work for you? If so would you mind changing your vote to LGTM so we can continue making releases of the projects? If I go through another round of edits to add this we will need to throw out the 7 LGTM votes so far and delay having any process in place for a week or two more.

Thank You,

Brandon

[Vincent Batts]

LGTM

I like the idea of the signed tags, but this can be added later. It
also gets into trusting trust. Up to this point, it has been my GPG
key doing the signatures of the tags, and no questions have come up on
the absoluteness that it my key. So just an initial requirement of
signature wouldn't quite cover the assurance desired there.

[Vishnu Kannan]

LGTM

[Krishnamurthy, Anush]

LGTM

Thanks & Regards

Anush Krishnamurthy

--
You received this message because you are subscribed to the Google Groups "Technical Oversight Board" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tob+uns...@opencontainers.org.

[Aleksa Sarai]

> 1) What key is used to tag the release?

The maintainer who decides to cut the release should be the one that
signs it.

> 2) What goes into the tag commit?

You don't need to sign the commit that is tagged, you can just sign the
tag itself. IMO we should probably include what maintainer cut the
release (and possibly who LGTM'd it). Also, the changelog would be a
good thing to add.

> 3) Where is the public key published for third parties to verify?

To keep with the theme of runC, the MAINTAINERS file seems like a good
idea to store the keyid of each maintainer. If that's not practical we
can always do a keysiging party. ;)

[Vincent Batts]

On Jul 14, 2016 13:22, "Aleksa Sarai" <asa...@suse.de> wrote:
>>
>> 1) What key is used to tag the release?
>
>
> The maintainer who decides to cut the release should be the one that signs it.
>
>
>> 2) What goes into the tag commit?
>
>
> You don't need to sign the commit that is tagged, you can just sign the tag itself. IMO we should probably include what maintainer cut the release (and possibly who LGTM'd it). Also, the changelog would be a good thing to add.
>
>
>> 3) Where is the public key published for third parties to verify?
>
>
> To keep with the theme of runC, the MAINTAINERS file seems like a good idea to store the keyid of each maintainer. If that's not practical we can always do a keysiging party. ;)
>

BTW Aleksa and I just signed keys ...

[Aleksa Sarai]

>> To keep with the theme of runC, the MAINTAINERS file seems like a good
> idea to store the keyid of each maintainer. If that's not practical we
> can always do a keysiging party. ;)
>>
>
> BTW Aleksa and I just signed keys ...

And Vincent looks *nothing* like his passport photo. ;)

[Tianon Gravi]

On 13 July 2016 at 21:56, Vincent Batts <vba...@redhat.com> wrote:
> BTW Aleksa and I just signed keys ...

IMO this discussion is orthogonal -- I agree that signed tags are a
good idea, but I think we can add that to the official process later
(especially since it's already something we've been doing thanks to
Vincent).

That being said, I'm happy to coordinate signing keys with folks who
need an excuse to come to Las Vegas. ;)

[Aleksa Sarai]

> IMO this discussion is orthogonal -- I agree that signed tags are a
> good idea, but I think we can add that to the official process later
> (especially since it's already something we've been doing thanks to
> Vincent).

After Vincent and Chris got me sufficiently plastered, I think I agreed
to LGTM this despite not having signed tags. I still feel we should
codify this, but it's not a blocker.

So LGTM. Let's get this over with. ;)

[Rohit Jnagal]

Taking Victor and myself out as we transferred our votes to Jason and Vish. 

Just making sure no one is waiting on us to vote :)

[Victor Marmol]

LGTM!

On Fri, Jul 15, 2016 at 11:25 AM, Aleksa Sarai <asa...@suse.de> wrote:

[W. Trevor King]

On Fri, Jul 15, 2016 at 11:31:14AM -0700, 'Rohit Jnagal' via dev wrote:
> Taking Victor and myself out as we transferred our votes to Jason and Vish.
>
> Just making sure no one is waiting on us to vote :)

You were removed from being runtime-spec maintainers [1], but you're
still runC maintainers [2], and I think Brandon is polling all OCI
Project maintainers here.

Cheers,
Trevor

[1]: https://github.com/opencontainers/runtime-spec/pull/223/files
Subject: Adding Vishnu Kannan as a Maintainer.
[2]: https://github.com/opencontainers/runc/blob/41b12c095b0cde82a8f22718bc15ceede5f60b0f/MAINTAINERS#L2-L3

[Rohit Jnagal]

LGTM

Thanks Brandon and Trevor. I read through the proposal and discussion. It looks fine to me.

[Brandon Philips]

Hello Everyone-

Just a quick update on this vote, it is passing with 12/18 LGTM votes but we have 6 folks abstaining. We have four more days for the vote and I would love to get those abstaining to speak up. So, please speak up.

+12: Brandon Philips, Mrunal Patel, Tianon Gravi, Brendan Burns, Qiang Huang, Jonathan Boulle, Daniel Dao, Vincent Batts, Vishnu Kannan, Aleksa Sarai, Victor Marmol, Rohit Jnagal

-0

#6: Alexandr Morozov, Andrey Vagin, John Starks, Michael Crosby, Stephen Day, Jason Bouzane

Thank You,

Brandon

On Tue, Jul 12, 2016 at 12:26 PM Brandon Philips <brandon...@coreos.com> wrote:

[Alexander Morozov]

I read it through and everything seems logical and clear. Thanks for your work.
LGTM

> --
> You received this message because you are subscribed to the Google Groups

> "dev" group.

> To unsubscribe from this group and stop receiving emails from it, send an

> email to dev+uns...@opencontainers.org.

[Stephen Day]

LGTM

Thanks for getting this through!

[Brandon Philips]

Hello Everyone-

This vote has passed and we will merge 56abe122 into the project-template. The final vote at 2016-07-19 19:00 UTC:

+13: Brandon Philips, Mrunal Patel, Tianon Gravi, Brendan Burns, Qiang Huang, Jonathan Boulle, Daniel Dao, Vincent Batts, Vishnu Kannan, Aleksa Sarai, Victor Marmol, Rohit Jnagal, Alexander Morozov

-0

#5: Andrey Vagin, John Starks, Michael Crosby, Stephen Day, Jason Bouzane

Stephen Day came in with an LGTM but it was a few hours too late. Just for precedent I want to keep to the original deadline.

runC, runtime-spec, and image-spec should all be released using this method moving forward. I will work with ChrisA to merge this today.

Thanks!

Brandon

[Stephen Day]

If we want to get technical, the vote should have closed as of 2016-07-19 19:26 UTC, since the motion was sent out at Tue, 12 Jul 2016 12:26:51 -0700 (PDT).

Stephen.

[Brandon Philips]

On Wed, Jul 20, 2016 at 1:50 PM Stephen Day <steph...@docker.com> wrote:

If we want to get technical, the vote should have closed as of 2016-07-19 19:26 UTC, since the motion was sent out at Tue, 12 Jul 2016 12:26:51 -0700 (PDT).

Stephen-

Ha, good point. :) I started the draft email and wrote the subject starting at noon but didn't send until I finished the body. As no emails came in between the 26 minute delta I think it is OK. In the future we should probably just pad for a few hours forward.

I really appreciate all of your feedback on the process. And I know that the abstained vote thing is pedantic. But, I want to set a precedent that the week long vote trains run on time. And our first train is the best place to set it.

This process could break down otherwise. For example if we get an adopted vote for a release, the release starts to get tagged, and the before the tag gets pushed someone changes their vote on the release. Human race conditions, like the subject thing you point out :)

Anyways, given this is the first use of the process only hitting two buglets seems OK.

Thanks Again,

Brandon

[Vincent Batts]

:-D

[Stephen Day]

No worries. My response was intended to be humorous. ;)

The policy was applied accurately. My vote was indeed late and I sent it anyways to be clear that I approved.

As a matter of practice, we may want to put pad into our motions.

Thanks for getting all of this up and running!

Stephen.