Merge branch 'master' of git://github.com/opencontainers/project-template into merge-project-template #274
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Chris Aniszczyk <caniszczyk@gmail.com>
…ing-guidelines Add contributing and maintainer guidelines.
And excessive trailing newlines. These came in with fcc7f42 (Add contributing and maintainer guidelines, 2016-05-03, opencontainers#1), because we don't have Git validation yet [1]. [1]: opencontainers/project-template#2 Signed-off-by: W. Trevor King <wking@tremily.us>
For small projects like ocitools a strict requirement would just be busywork. And the risk here (a submitted PR that would have been rejected or redirected in a leader issue) is a risk assumed by the submitter (who sunk time in the wrong direction) and not much cost to the maintainers. Signed-off-by: W. Trevor King <wking@tremily.us>
Folks have been dragging this around from the soft limit in git-commit(1) and git.git's Documentation/SubmittingPatches without believing it. Looking at the git.git history through v2.3.4 (git log --no-merges --format=%s v2.3.4), we have 29853 commits, with 56% ≤ 50 chars and 94% ≤ 70 chars. Projects that want limits should enforce them with CI tests (e.g. runtime-spec uses git-validation, which has a soft limit at 72 and a hard limit at 90 [1]). [1]: https://github.com/vbatts/git-validation/blob/be3aee994370184fd98e455abfe0948d6f45f793/rules/shortsubject/shortsubject.go#L24-L35 Signed-off-by: W. Trevor King <wking@tremily.us>
CONTRIBUTING: Make leader-issues optional
Small, young projects like ocitools may not have grown a test suite yet. Don't make writing a Go test suite a requirement for submitting a PR. Also allow for other test frameworks, since Go's framework may not be the best fit for all projects, which may not even include Go code. Signed-off-by: W. Trevor King <wking@tremily.us>
…mmary-limit CONTRIBUTING: Don't specify a 50-char limit
MAINTAINERS_GUIDE: Remove trailing whitespace
CONTRIBUTING: Make the test requirements contingent on an existing suite
For runtime-spec, there are often PRs that pickup and reroll another user's commits (e.g. opencontainers/runtime-spec#337). As long as the Signed-off-by entries are there (for the DCO) and the new PR references the earlier work (to avoid maintainer confusion), I see no problem with this sort of collaboration. I thought about replacing the old wording with words like the above paragraph, but it seemed overly prescriptive. Signed-off-by: W. Trevor King <wking@tremily.us>
CONTRIBUTING: Allow collaborative pull requests
Apart from being a sign of respect to other maintainers, it also ensures that *all* pull requests get equal amounts of review -- no matter who wrote them. Maintainers should know better than to make broken patchsets, but it's also a sign of respect to the community that all pull requests have equal treatment. Signed-off-by: Aleksa Sarai <asarai@suse.de>
MAINTAINERS: disallow self-LGTMs
This is a proposed process for approval of new releases of specifications and projects from the OCI. The creation of this process is designed to clarify how a release gets created and who needs to sign off.
I got some feedback from folks that some motivation early in the document might be helpful for why the process encourages regular communication.
Requiring applications wait 1 week to get feedback before making a release, removing "business day" wording @cyphar, @stevvooe, and @wking were in the discussion.[1] [1] opencontainers/tob#15 (comment)
Requiring the _minimum_ process for a major release to be 3 rcs and a final release. This will establish a _minimum_ timeline of 1 month to get to a release assuming zero required changes. @stevvooe, @wking were in this discussion. opencontainers/tob#15 (comment)
Changing the release goal for projects to a "SHOULD monthly release" from the original bi-weekly. @diogomonica, @stevvooe, @mrunalp, @RobDolinMS were in that discussion opencontainers/tob#15 (comment)
Fix up the language around REJECTs so it is easier to understand. The basic premise is that a release may continue with REJECTs if 2/3 of the maintainers vote to make the release. But, the maintainers SHOULD discuss and allow time for any REJECTs to become LGTMs. Spread over two discussions: [1](https://github.com/opencontainers/tob/pull/15/files/bdfa70d70f093146bc730be2576586ec8ed57cca#r66519789) and [2](https://github.com/opencontainers/tob/pull/15/files/bdfa70d70f093146bc730be2576586ec8ed57cca#r66668148)
The intention of the voting members language is to ensure that releases can proceed even if people are unresponsive, on vacation, etc without ambiguity. This is similar to how the TOB operates. Identified by @wking here: opencontainers/tob#15 (comment)
Based on discussion with wking and mrunalp participating and Stephen Day acking in IRC: opencontainers/tob#15 (comment)
This addresses @stevvooe's concern about GitHub issues being the only medium for discussion of a reject. @wking and @philips were involved in this discussion: opencontainers/tob#15 (comment)
Projects have a happy path and a slow path. The happy path is a release with maintainers agreeing and a timeout. The slow path has rejects and quorums. Based on discussion with @wking opencontainers/tob#15 (comment)
Instead of being prescriptive provide suggestions instead for how to provide release REJECTS feedback. Based on feedback from Stephen Day and @wking.
This is useful for more than release approval. For example, it's useful for updating the project governance document itself [1]. I've also tried to address Jason's other points, except for defining a "breaking change" (since that is tied up in [2]). New wording about motions and whatnot is pulled from Roberts' [3], see proposing a motion (RRoO I.4, p33) and seconding a motion (RRoO I.5, p36). The subject templates I just made up on my own after thinking over the initial proposal emails (e.g. [4]). I also pulled in the one-sentence pattern [5] since I was touching so much. [1]: https://groups.google.com/a/opencontainers.org/d/msg/dev/ik3MIDWq4Us/Zx1JUStXBAAJ Subject: Re: Vote Required: OCI Image Spec Release Process Date: Fri, 24 Jun 2016 16:58:58 -0700 Message-ID: <CAFi6z1HAkKbnMoAXubyGusQJ_MromgpQ4qHCQ3R9_NwZNYBX5w@mail.gmail.com> [2]: opencontainers/tob#16 [3]: http://archive.org/details/Robertsrulesofor00robe_201303 [4]: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/ik3MIDWq4Us Subject: Vote Required: OCI Image Spec Release Process Date: Thu, 23 Jun 2016 15:56:40 +0000 Message-ID: <CAD2oYtNnW+hP7Q3NPBdYHOKfigU0pvbgcphKPhRB=ZfQBwX8VA@mail.gmail.com> [5]: opencontainers/tob#15 (comment) Signed-off-by: W. Trevor King <wking@tremily.us>
Split files into governance and releases and outline the maintainers of the GOVERNANCE doc itself. Signed-off-by: Brandon Philips <brandon.philips@coreos.com>
…releases-docs Add governance and releases docs
Signed-off-by: Antonio Murdaca <runcom@redhat.com>
GOVERNANCE.md: fix typo
The sign-off requirement catches us up with fcc7f42 (Add contributing and maintainer guidelines, 2016-05-03, opencontainers#1). The author ignore catches us up with c82a2e7 (MAINTAINERS: disallow self-LGTMs, 2016-05-27, opencontainers#13). The push reset catches us up with opencontainers/runtime-spec@aa9f3a26 (Add PullApprove checks, 2016-05-26, opencontainers/runtime-spec#458), opencontainers/image-spec@95a46754d (Add PullApprove support to enforce review, 2016-06-01, opencontainers/image-spec#101) and opencontainers/runc@e2fd7c11 (Add PullApprove support, 2016-05-26, opencontainers/runc#847). Signed-off-by: W. Trevor King <wking@tremily.us>
.pullapprove.yml: Reset on push, ignore authors, and require sign-offs
…late into merge-project-template To fulfill the TOB's [1]: Both of the proposed projects would incorporate the Governance and Releases processes from the OCI project template: https://github.com/opencontainers/project-template. which was approved with this vote [2]. Generated with: $ git pull git://github.com/opencontainers/project-template.git master $ git checkout --ours .pullapprove.yml README.md $ git checkout --theirs CONTRIBUTING.md LICENSE MAINTAINERS_GUIDE.md $ git add .pullapprove.yml CONTRIBUTING.md LICENSE MAINTAINERS_GUIDE.md README.md $ git commit I think there are a few improvements we could make to these template docs [3,4,5], but the TOB vote happened before I'd floated those. If/when they land, we can pull the updated versions into this repository via a follow-up merge. * 'master' of git://github.com/opencontainers/project-template: (33 commits) .pullapprove.yml: Reset on push, ignore authors, and require sign-offs GOVERNANCE.md: fix typo GOVERNANCE and RELEASES: split the files project-governance: Make voting more generic proposals: release approval process explain security@ email proposal: fix a typo proposals: release-approval-process fix a grammar thing release-approval: Add non-spec unanimous quorum reduction release-approval: Shuffle to make more DRY proposals: release-approval-process: fixup additional typos proposals: release approval process: improve REJECT feedback proposals: release approval process: add information to projects proposals: release approval process: add language about mailing list proposals: release approval process: add quorum language proposals: release-approval-process: add voting members language proposals: release approval process: clarify utility of GitHub proposals: release approval process: use consistent language for rejects proposals: release approval process: one month pre-releases proposals: release approval process 3 rcs required proposals: release approval process to one week for apps ... Conflicts: .pullapprove.yml CONTRIBUTING.md LICENSE MAINTAINERS_GUIDE.md README.md [1]: https://github.com/opencontainers/tob/blob/8997b1aa221b3b61d4305bede41c257b879bdeeb/proposals/tools.md#governance-and-releases [2]: https://groups.google.com/a/opencontainers.org/forum/#!topic/tob/rZ4luMa-pxY Subject: VOTE Required: approve new projects: image-tools, runtime-tools Date: Wed, 07 Sep 2016 22:37:32 +0000 Message-ID: <CAD2oYtMLMFQouEVU7HTO-EKnW6vKu82dGT+0mziXZzCyqngj=A@mail.gmail.com> [3]: opencontainers/project-template#18 Subject: GOVERNANCE: Proposing a motion is a LGTM by default [4]: opencontainers/project-template#19 Subject: GOVERNANCE: Drop the co-sponsor requirement [5]: opencontainers/project-template#20 Subject: MAINTAINERS_GUIDE|CONTRIBUTING: Make generic enough for all OCI Projects Signed-off-by: W. Trevor King <wking@tremily.us>
wking
force-pushed
the
merge-project-template
branch
from
a65fab6
to
b78e865
Compare
|
The project-template history we're pulling in here is missing a number of Signed-off-bys, but I don't think there's anything we can do about that. All of the non-merge commits missing signoffs are authored by @philips and @caniszczyk. Both of them are long-time OCI contributors, and the missing Signed-off-bys are almost certainly accidental oversight. If it would help and they approve, I'm happy to add their Signed-off-bys to the merge commit at the tip of this PR. |
|
I know that you want to keep committers' records. But can we just add them ('GOVERNANCE.md' here for example) to runtime-tools? |
liangchenye
reviewed
Nov 18, 2016
| @@ -176,7 +175,18 @@ | |||
|
|
|||
| END OF TERMS AND CONDITIONS | |||
|
|
|||
| Copyright 2015 The Linux Foundation. | |||
There was a problem hiding this comment.
We don't need to change the current 'LICENSE' to a template 'LICENSE' o we will lose our copyright owner
There was a problem hiding this comment.
This section of LICENSE is introducing a per-file copyright blurb template, you don't have to update the entry in LICENSE itself. As a fairly canonical example, see here.
The copyright holder isn't actually the LF for most (any?) of the content. It should really be “{project} contributors” or “the OCI technical community” or some such.
| @@ -24,9 +24,13 @@ Fork the repo and make changes on your fork in a feature branch: | |||
| - If it's a feature branch, create an enhancement issue to announce your | |||
| intentions, and name it XXX-something where XXX is the number of the issue. | |||
|
|
|||
| Submit unit tests for your changes. Go has a great test framework built in; use | |||
|
On Fri, Nov 18, 2016 at 02:22:57AM -0800, 梁辰晔 (Liang Chenye) wrote:
I like keeping the commit records, but I also like easy updates when $ git pull git://github.com/opencontainers/project-template.git master Then Git can figure out what has changed (e.g. just GOVERNANCE.md, or So using the merge-based approach seems like it saves some work. Does |
|
I don't think it's a good idea to merge project-template. |
|
On Mon, Nov 21, 2016 at 09:38:20PM -0800, Ma Shimiao wrote:
Possibly true, but there are a few updated in the pipe which I think
I agree with @crosbymichael that it's good to avoid fragmentation as
What sort of problems? I think it makes staying in sync easier, but |
The security@opencontainers.org mailing list is for *maintainers only*, and is to be used for technical discussion about potential security issues. It is not a place for the TOB to have votes about specification-related business, simply because it is not sane to include people who are not maintainers of projects in critical security discussions of said projects. If in the future we discover that we need to have a place to vote on security issues, the TOB can do that on their own private mailing list. For now, we should focus on making sure that security disclosures on *actual shipping code* is actually done properly. Signed-off-by: Aleksa Sarai <asarai@suse.de>
…dling *: clarify how security issues are handled
Extending the earlier softening in 0548361 (CONTRIBUTING: Make leader-issues optional, 2016-05-19, opencontainers#6), because nobody cares about the XXX- prefix. Checking the recent history of all OCI project repos: $ for REPO in image-spec image-tools runc runtime-spec runtime-tools; > do > ( > cd "${REPO} && > git fetch origin && > BRANCHES=$(git log --first-parent --oneline origin/master | sed 's/^.* from //') && > echo "${REPO} branches: $(echo "${BRANCHES}" | wc -l)" && > echo "${REPO} numbered: $(echo "${BRANCHES}" | grep '/[0-9]' | wc -l)" > ); > done image-spec branches: 276 image-spec numbered: 1 image-tools branches: 27 image-tools numbered: 0 runc branches: 1299 runc numbered: 21 runtime-spec branches: 391 runtime-spec numbered: 4 runtime-tools branches: 232 runtime-tools numbered: 3 Signed-off-by: W. Trevor King <wking@tremily.us>
CONTRIBUTING: Remove branch-naming suggestions
…late into merge-project-template Generated with: $ git pull --log git://github.com/opencontainers/project-template.git master * 'master' of git://github.com/opencontainers/project-template: CONTRIBUTING: Remove branch-naming suggestions *: clarify how security issues are handled Signed-off-by: W. Trevor King <wking@tremily.us>
|
On Mon, Nov 21, 2016 at 09:52:38PM -0800, W. Trevor King wrote:
On Mon, Nov 21, 2016 at 09:38:20PM -0800, Ma Shimiao wrote:
> And in my opinion, project-template will not be frequent updated…
Possibly true, but there are a few updated in the pipe which I think
are useful [1].
And one of those just landed (opencontainers/project-template#27).
I've updated this PR (b78e865 → 9eec16d) to demonstrate the workflow I
expect folks will be using.
This also pulls in opencontainers/project-template#22, which I don't
think followed the appropriate approval process [1]. But if it gets ⅔
of runtime-tools maintainers approving it via this PR, it's still fine
to land here.
On the other hand, a PR along the lines of this one was recently
rejected in go-digest [2], I suspect partly because I was preserving
the history [3]. Other instances of history-preservation include
opencontainers/image-tools#1 (preserving image-spec history) and
opencontainers/project-template#3 (rejecting the CONTRIBUTING.md and
MAINTAINERS_GUIDE.md history from runC [4]). So if the runtime-tools
maintainers decide not to preserve history when landing
project-template updates, they certainly won't be alone (although I'm
still not clear on the benefits of truncating history).
[1]: opencontainers/project-template#22 (comment)
[2]: opencontainers/go-digest#20 (comment)
[3]: opencontainers/go-digest#20 (comment)
[4]: opencontainers/project-template#3 (comment)
|
|
Rejected |
wking
added a commit
to wking/opencontainer-runtime-spec
that referenced
this pull request
Apr 6, 2018
Generated with: $ git remote add project-template git://github.com/opencontainers/project-template.git $ git fetch project-template $ git show --oneline project-template/master 61d73a3 (project-template/master) Merge pull request opencontainers#40 from wking/minor-patch-bullet $ git merge --squash --allow-unrelated-histories project-template/master $ git checkout HEAD -- .pullapprove.yml MAINTAINERS README.md RELEASES.md $ git checkout project-template/master -- GOVERNANCE.md LICENSE $ emacs README.md CONTRIBUTING.md # unify around project-template's CONTRIBUTING.md approach $ emacs meeting.ics # update link to point at CONTRIBUTING.md#meetings $ git commit -sv I personally prefer non-squash merges to preserve history and ease future updates, but that approach has not been popular within the OCI [1,2], so I'm going with a squash-merge here. I'm sticking with the local RELEASES.md, because it uses four-space indents. I've filed [3] to upstream that change. I've also filed [4] upstreaming our local wording change from 70ba4e6 (meeting: Bump January meeting from the 3rd to the 10th, 2017-12-07, opencontainers#943). I've also fixed the GOVERNANCE.md security link in flight with [5]. I've left the other in-flight project-template changes alone [6]. I've wrapped the URL in meetings.ics to avoid [7]: Line length should not be longer than 75 characters near line opencontainers#33 Reference: RFC 5545 3.1. Content Lines [1]: opencontainers/go-digest#20 (comment) [2]: opencontainers/runtime-tools#274 (comment) [3]: opencontainers/project-template#54 [4]: opencontainers/project-template#55 [5]: opencontainers/project-template#34 [6]: https://github.com/opencontainers/project-template/pulls [7]: https://icalendar.org/validator.html Signed-off-by: W. Trevor King <wking@tremily.us>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
To fulfill the TOB's:
which was approved with this vote.
Generated with something like my earlier suggestion:
I think there are a few improvements we could make to these template docs, but the TOB vote happened before I'd floated those. If/when they land, we can pull the updated versions into this repository via a follow-up merge.