Apply consistent project template across OCI #4
Comments
|
@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. |
|
On Thu, May 19, 2016 at 02:00:09PM -0700, Michael Crosby wrote:
How should the concerns be transferred? I'm happy to open PRs |
|
@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. |
|
I think that the way we have a "Conventions" section in IMO we should spend a bit of time removing cruft from there (which nobody is following anyway, but it confuses future contributors). |
|
On Thu, May 19, 2016 at 04:55:41PM -0700, Aleksa Sarai wrote:
Covered by #6? |
|
I agree we can consist these docs and apply them to all OCI projects, they just need to be well reviewed and discussed. |
|
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) |
|
@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. |
|
understood. On Mon, May 23, 2016 at 4:12 PM Michael Crosby notifications@github.com
|
|
@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 |
Ensure that OCI projects share the same approval settings. opencontainers/project-template#4 Signed-off-by: Chris Aniszczyk <caniszczyk@gmail.com>
|
@caniszczyk This template is not valid for OCI yet. It has language about a |
|
@vishh no strong deadline, would be nice to have in place before v1.0 Feel free to send a PR in |
Split files into governance and releases and outline the maintainers of the GOVERNANCE doc itself. Signed-off-by: Brandon Philips <brandon.philips@coreos.com>
Bump copyright year
Not all OCI Projects are primarily Go, and filling in off-topic formatting advice doesn't seem useful. One approach to this would be to require projects to support 'make fmt' to handle any auto-formatting. But an easier approach is to keep the document generic in this repository [1], and allow downstream projects to add their own project-specific content as they see fit. I don't expect a lot of churn in this document, so there shouldn't be many conflicts between those downstream changes and further project-template development. [1]: opencontainers#4 (comment) Signed-off-by: W. Trevor King <wking@tremily.us>
Current ocitools docs are the man pages under man/. No docs for building them yet beyond the Makefile rule, and that may be all we need ;). Because there is no downstream consensus on doc locations, remove the reference. Downstream repositories can add it (or similar content) back in as they see fit [1]. I don't expect a lot of churn in this document, so there shouldn't be many conflicts between those downstream changes and further project-template development. [1]: opencontainers#4 (comment) Signed-off-by: W. Trevor King <wking@tremily.us>
Not all OCI Projects are primarily Go, and filling in off-topic formatting advice doesn't seem useful. One approach to this would be to require projects to support 'make fmt' to handle any auto-formatting. But an easier approach is to keep the document generic in this repository [1], and allow downstream projects to add their own project-specific content as they see fit. I don't expect a lot of churn in this document, so there shouldn't be many conflicts between those downstream changes and further project-template development. [1]: opencontainers#4 (comment) Signed-off-by: W. Trevor King <wking@tremily.us>
Current ocitools docs are the man pages under man/. No docs for building them yet beyond the Makefile rule, and that may be all we need ;). Because there is no downstream consensus on doc locations, remove the reference. Downstream repositories can add it (or similar content) back in as they see fit [1]. I don't expect a lot of churn in this document, so there shouldn't be many conflicts between those downstream changes and further project-template development. [1]: opencontainers#4 (comment) Signed-off-by: W. Trevor King <wking@tremily.us>
Not all OCI Projects are primarily Go, and filling in off-topic formatting advice doesn't seem useful. One approach to this would be to require projects to support 'make fmt' to handle any auto-formatting. But an easier approach is to keep the document generic in this repository [1], and allow downstream projects to add their own project-specific content as they see fit. I don't expect a lot of churn in this document, so there shouldn't be many conflicts between those downstream changes and further project-template development. [1]: opencontainers#4 (comment) Signed-off-by: W. Trevor King <wking@tremily.us>
Current ocitools docs are the man pages under man/. No docs for building them yet beyond the Makefile rule, and that may be all we need ;). Because there is no downstream consensus on doc locations, remove the reference. Downstream repositories can add it (or similar content) back in as they see fit [1]. I don't expect a lot of churn in this document, so there shouldn't be many conflicts between those downstream changes and further project-template development. [1]: opencontainers#4 (comment) Signed-off-by: W. Trevor King <wking@tremily.us>
Email-based voting seems to be a blocker for Michael, who prefers PR-based voting for non-spec projects [1]. And the image-tools maintainers had a PR-only vote to add Aleksa as a maintainer [2]. Specifications are still recommended to only use dev@ (for increased visibility among folks with only peripheral involvement, e.g. spec consumers). But non-spec projects can backtrack more easily from decisions which have negative impacts, so we don't have to push them towards dev@ as firmly. Adopting this more-relaxed approach should help reduce barriers to non-spec projects adopting the vanilla governance procedures, which may move us towards more consistency between OCI projects [3]. [1]: http://ircbot.wl.linuxfoundation.org/eavesdrop/%23opencontainers/%23opencontainers.2017-03-20.log.html#t2017-03-20T19:54:38 [2]: opencontainers/image-tools#118 (comment) Subject: MAINTAINERS: add Aleksa Sarai [3]: opencontainers#4 Subject: Apply consistent project template across OCI Signed-off-by: W. Trevor King <wking@tremily.us>
Email-based voting seems to be a blocker for Michael, who prefers PR-based voting for non-spec projects [1]. And the image-tools maintainers had a PR-only vote to add Aleksa as a maintainer [2]. Specifications are still recommended to only use dev@ (for increased visibility among folks with only peripheral involvement, e.g. spec consumers). But non-spec projects can backtrack more easily from decisions which have negative impacts, so we don't have to push them towards dev@ as firmly. Adopting this more-relaxed approach should help reduce barriers to non-spec projects adopting the vanilla governance procedures, which may move us towards more consistency between OCI projects [3]. [1]: http://ircbot.wl.linuxfoundation.org/eavesdrop/%23opencontainers/%23opencontainers.2017-03-20.log.html#t2017-03-20T19:54:38 [2]: opencontainers/image-tools#118 (comment) Subject: MAINTAINERS: add Aleksa Sarai [3]: opencontainers#4 Subject: Apply consistent project template across OCI Signed-off-by: W. Trevor King <wking@tremily.us>
Not all OCI Projects are primarily Go, and filling in off-topic formatting advice doesn't seem useful. One approach to this would be to require projects to support 'make fmt' to handle any auto-formatting. But an easier approach is to keep the document generic in this repository [1], and allow downstream projects to add their own project-specific content as they see fit. I don't expect a lot of churn in this document, so there shouldn't be many conflicts between those downstream changes and further project-template development. [1]: opencontainers#4 (comment) Signed-off-by: W. Trevor King <wking@tremily.us>
Current ocitools docs are the man pages under man/. No docs for building them yet beyond the Makefile rule, and that may be all we need ;). Because there is no downstream consensus on doc locations, remove the reference. Downstream repositories can add it (or similar content) back in as they see fit [1]. I don't expect a lot of churn in this document, so there shouldn't be many conflicts between those downstream changes and further project-template development. [1]: opencontainers#4 (comment) Signed-off-by: W. Trevor King <wking@tremily.us>
Not all OCI Projects are primarily Go, and filling in off-topic formatting advice doesn't seem useful. One approach to this would be to require projects to support 'make fmt' to handle any auto-formatting. But an easier approach is to keep the document generic in this repository [1], and allow downstream projects to add their own project-specific content as they see fit. I don't expect a lot of churn in this document, so there shouldn't be many conflicts between those downstream changes and further project-template development. [1]: opencontainers#4 (comment) Signed-off-by: W. Trevor King <wking@tremily.us>
Current ocitools docs are the man pages under man/. No docs for building them yet beyond the Makefile rule, and that may be all we need ;). Because there is no downstream consensus on doc locations, remove the reference. Downstream repositories can add it (or similar content) back in as they see fit [1]. I don't expect a lot of churn in this document, so there shouldn't be many conflicts between those downstream changes and further project-template development. [1]: opencontainers#4 (comment) Signed-off-by: W. Trevor King <wking@tremily.us>
Not all OCI Projects are primarily Go, and filling in off-topic formatting advice doesn't seem useful. One approach to this would be to require projects to support 'make fmt' to handle any auto-formatting. But an easier approach is to keep the document generic in this repository [1], and allow downstream projects to add their own project-specific content as they see fit. I don't expect a lot of churn in this document, so there shouldn't be many conflicts between those downstream changes and further project-template development. [1]: opencontainers#4 (comment) Signed-off-by: W. Trevor King <wking@tremily.us>
Current ocitools docs are the man pages under man/. No docs for building them yet beyond the Makefile rule, and that may be all we need ;). Because there is no downstream consensus on doc locations, remove the reference. Downstream repositories can add it (or similar content) back in as they see fit [1]. I don't expect a lot of churn in this document, so there shouldn't be many conflicts between those downstream changes and further project-template development. [1]: opencontainers#4 (comment) Signed-off-by: W. Trevor King <wking@tremily.us>
Current ocitools docs for the man pages are under man/. No docs for building them yet beyond the Makefile rule, and that may be all we need ;). Because there is no downstream consensus on doc locations, remove the reference. Downstream repositories can add it (or similar content) back in as they see fit [1]. I don't expect a lot of churn in this document, so there shouldn't be many conflicts between those downstream changes and further project-template development. [1]: opencontainers#4 (comment) Signed-off-by: W. Trevor King <wking@tremily.us>
|
I consider it done unless you can find repos that need to be updated, but
I'd rather you send PRs to those repos.
…On Sat, Apr 7, 2018 at 2:18 AM, W. Trevor King ***@***.***> wrote:
On Fri, Apr 06, 2018 at 10:13:44AM -0700, Chris Aniszczyk wrote
<#4 (comment)>
:
Closed #4 <#4>.
Is this no longer a goal?
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
<#4 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAD5ITx47zqbRhRXneKiGEi-dQ4skiXLks5tl7GTgaJpZM4Ifmll>
.
--
Cheers,
Chris Aniszczyk
http://aniszczyk.org
+1 512 961 6719
|
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 76b408aSo go-digest, runc, runtime-tools, and selinux have no local
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. |
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. |
Ensure that OCI projects share the same approval settings. opencontainers/project-template#4 Signed-off-by: Chris Aniszczyk <caniszczyk@gmail.com>
Ensure that OCI projects share the same approval settings. opencontainers/project-template#4 Signed-off-by: Chris Aniszczyk <caniszczyk@gmail.com>
Ensure that OCI projects share the same approval settings. opencontainers/project-template#4 Signed-off-by: Chris Aniszczyk <caniszczyk@gmail.com>
Ensure that OCI projects share the same approval settings. opencontainers/project-template#4 Signed-off-by: Chris Aniszczyk <caniszczyk@gmail.com>
Ensure that OCI projects share the same approval settings. opencontainers/project-template#4 Signed-off-by: Chris Aniszczyk <caniszczyk@gmail.com>
@crosbymichael we should apply this across OCI projects once it's finalized
The text was updated successfully, but these errors were encountered: