Apply consistent project template across OCI about project-template HOT 16 CLOSED

@opencontainers/tdc-maintainers

Any comments/concerns on these docs because we need consistent rules across projects around contributing and how the maintainer system works so that it is explicit.

We had previous comments on the individual PRs but no one transferred their concerns here when asked. Please take a look.

from project-template.

On Thu, May 19, 2016 at 02:00:09PM -0700, Michael Crosby wrote:

We had previous comments on the individual PRs but no one
transferred their concerns here when asked.

How should the concerns be transferred? I'm happy to open PRs
addressing my comments from opencontainers/runtime-tools#56.

from project-template.

@wking you can open PRs but remember that these documents should apply across all OCI projects. Be conservative with the changes you want to make because these are the rules that have already applied for years and have worked well scaling the projects. We are just trying to make them generally applicable across all the projects.

from project-template.

I think that the way we have a "Conventions" section in CONTRIBUTING.md, but nobody appears to follow the whole "name the branch after the issue you're fixing" is something we should fix. There's also other stylistic things there that shouldn't super important to mention ("commits short messages should be capitalized" -- I don't agree).

IMO we should spend a bit of time removing cruft from there (which nobody is following anyway, but it confuses future contributors).

from project-template.

On Thu, May 19, 2016 at 04:55:41PM -0700, Aleksa Sarai wrote:

I think that the way we have a "Conventions" section in
CONTRIBUTING.md, but nobody appears to follow the whole "name the
branch after the issue you're fixing" is something we should fix.

Covered by #6?

from project-template.

I agree we can consist these docs and apply them to all OCI projects, they just need to be well reviewed and discussed.

from project-template.

largely this SGTM. Could we imagine a future scenario where a project starts with these templates but then deviates? (silly example, but like requiring 3 LGTMs)

from project-template.

@vbatts We could but I think that is probably like a last resort. There are a lot of benefits to keep consistency across the projects as it is helpful for the maintainers and contributors especially since all they projects are related to one another and have many of the same people working on them.

from project-template.

understood.

On Mon, May 23, 2016 at 4:12 PM Michael Crosby [email protected]
wrote:

@vbatts https://github.com/vbatts We could but I think that is probably
like a last resort. There are a lot of benefits to keep consistency across
the projects as it is helpful for the maintainers and contributors
especially since all they projects are related to one another and have many
of the same people working on them.

—
You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub
#4 (comment)

from project-template.

@crosbymichael I think we have enough consensus here that we should apply this across all OCI projects, I think we have runtime-spec and runc covered, I'll file a request for image-spec

from project-template.

@caniszczyk This template is not valid for OCI yet. It has language about a Chief Maintainer which is not relevant to OCI. I can post a PR to address parts of the template that are not relevant to the OCI projects.
Is there a deadline before which this template needs to be finalized?

from project-template.

@vishh no strong deadline, would be nice to have in place before v1.0

Feel free to send a PR in

from project-template.

On Fri, Apr 06, 2018 at 10:13:44AM -0700, Chris Aniszczyk wrote:

Closed #4.

Is this no longer a goal?

from project-template.

from project-template.

I'd rather you send PRs to those repos.

I haven't had much luck with that in the past ;). Checking on current compat:

$ for repo in project-template image-spec image-tools go-digest runc runtime-spec runtime-tools selinux; do echo -n "$repo " && (cd $repo && git fetch -q origin && git describe --always origin/master && git ls-tree origin/master -- RELEASES.md || true); done
project-template 61d73a3
100644 blob 028ec265df9c8de9781051f4460d7fdf88d0095f    RELEASES.md
image-spec v1.0.0-33-g8e82844
100644 blob e220042c89008275b86f44c967983675f39f968e    RELEASES.md
image-tools v0.2.0-86-gc95f76c
100644 blob e220042c89008275b86f44c967983675f39f968e    RELEASES.md
go-digest v1.0.0-rc1
runc v1.0.0-rc5-27-gcc4307ab
runtime-spec v1.0.1-28-ga1998ec
100644 blob a28e086a7ca3009d099a4e81027d5a084e578bc6    RELEASES.md
runtime-tools fcd5b23
selinux 76b408a

So go-digest, runc, runtime-tools, and selinux have no local RELEASES.md, and nobody is current with this repository.

I'd rather you send PRs to those repos

I'd done that with opencontainers/go-digest#20 (which was closed in favor of a simpler PR that never materialized) and opencontainers/runtime-tools#274 (which was rejected without mentioning future plans). I haven't attempted to file pull requests against runc or selinux, and it doesn't look like anyone else has yet either. But we might have better luck if someone else tilts at this particular windmill ;). I'm happy to file update PRs against the projects which do have existing copies of the docs, though.

from project-template.

I'm happy to file update PRs against the projects which do have existing copies of the docs, though.

I've filed opencontainers/runtime-spec#966 to test my luck at narrowing the gap between runtime-spec and this repo. I'll wait and see how that goes before filing similar narrowings for the other projects which already include part of the template content.

from project-template.