Mediatype of layers should be application/vnd.oci.image.layer.v1.tar+gz

[vsoch]

This is another thing I noticed this morning - the mediatype for layers should be in the layers family, but there were two tests (checking for other things) that had config types instead. Should this have been caught, or given that the tests were for failures for other things, it would have been caught had those other things not been wrong?

Signed-off-by: Vanessa Sochat [email protected]

[cyphar]

The tests are failing because your commit's subject line is too long -- you could just make it "schema: use correct media-types for layers in tests" or something and provide the information in the body of the commit message.

Otherwise,
LGTM

[vbatts]

LGTM

[vbatts]

@cyphar pattern-matcher is not catching your approval, if you will will bump that again

[jonjohnsonjr]

I'm not sure about this one. The spec says:

Manifests concerned with portability SHOULD use one of the above media types. An encountered mediaType that is unknown to the implementation MUST be ignored.

(the above media types being layer media types), but it doesn't forbid layer descriptors that point to config files.

[vbatts]

fair, but this is just in a test case

[jonjohnsonjr]

Yeah I could take this PR or leave it 🤷‍♂️

What's there isn't wrong, it's just weird.

[cyphar]

@vbatts The tests are failing because of the commit message -- @vsoch should fix that before we merge (since we use git-validation it will cause test failures for the rest of time 😉).

[vsoch]

What's wrong with the git message?

[vsoch]

Just a high level observation - it's really really really hard to contribute simple things here because of these rules.

[vbatts]

Fair. Though they are common formatting for git messages much beyond and unrelated to OCI

…

On Tue, Dec 17, 2019, 18:14 Vanessasaurus ***@***.***> wrote: Just a high level observation - it's really really *really* hard to contribute simple things here because of these rules. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#794?email_source=notifications&email_token=AAAQL2JM2QNXTOXLN62LT33QZFMM5A5CNFSM4JJXOFFKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHEI5TY#issuecomment-566791887>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAQL2JJAIOZKMREWOFO7HLQZFMM5ANCNFSM4JJXOFFA> .

[cyphar]

What's wrong with the git message?

The subject line (the first line of the message) is longer than 90 characters. This is the cause of the CI failure for this change.

Just a high level observation - it's really really really hard to contribute simple things here because of these rules.

I agree that these rules are frustrating (especially for drive-by contributors), but on the other hand there needs to be some limit to how long subject lines should be (because if they're too long, tools like git log start being quite hard to read in a terminal or small screen). 90 characters happens to be the limit we picked.

Now, I could also fix it for you -- but I personally don't like it when maintainers push to my tree -- so I don't do it to other people unless they've already given me permission to (annoyingly, GitHub has made "allow maintainers push to my tree" an opt-out option when creating a PR -- so I can't be sure if the person who submitted the PR actually has affirmatively given permission or if they didn't notice the option). Also, pushing to someone else's tree breaks the authorship and any signatures the author might have.

All of that being said -- we could drop using git-validation to not make this a hard requirement of PRs (personally I don't mind the length of this particular commit message). After all, we now use the DCO bot to check for Signed-off-by so we no longer need git-validation for that...

[vsoch]

okay I just did a git --amend (I hope I didn't mess it up!)

[vsoch]

@cyphar it's definitely an interesting conversation, because I have a colleague I was talking with recently about this, and he puts beautifully detailed (many lines) of message about the details of the work per commit for a large chunk of work. It's definitely a tradeoff between quality and quantity, and I do agree that it's probably best to put a reasonable limit and then try to make the message high quality. I am most certainly guilty of short, stupid and useless commit messages that could be better stated. :)

[vbatts]

LGTM

[cyphar]

LGTM.

[cyphar]

@vsoch Just to be clear, there isn't a limit on the total size of the commit message -- it's just the first line of the commit message which has a limit placed on it (in order to make it easier to reference and make git log easier to read).

Personally I found that the way the Linux kernel does git commit messages (write them as an email, with the subject line being the first line of the commit message) really helps you get a better undersanding of how to write a commit message which makes sense by itself. Unlike most projects, Linux doesn't have a formal bug tracker so all of the context for a commit is included in the message itself (as well as references to other commits).

[vsoch]

hooray! Thanks everyone :)