Hi all, And let me get this straight … not frustrated about Buildstream … I was referring to how “easy” it is to reply via the web-tool (Unfortunately you can’t beat a real email client ;-) )
Chris From: Christofer Dutz <[email protected]> Date: Wednesday, 19. October 2022 at 18:03 To: [email protected] <[email protected]> Subject: Re: Proposal for 2.0 stable release Hi Justin, thanks for that ... I was just staring to get frustrated with writing a response for an inline commented email in Ponymail ... I signed up for the list, that I can in future reply with a real mail-client. But I guess I have nothing to add to what Justin wrote. Thanks, Chris On 2022/10/19 15:48:33 Justin Mclean wrote: > Hi, > > Perhaps I can help. > > > I'm reading that published release artifacts MUST be signed, and that > > eligible voters in the voting stage MAY provide a signature. > > The release candidate needs to be signed so that someone reviewing the > release can check that it contains what it should and will be the same as the > released software. > > > FWIW, all of our release tags (internal or external) are signed tags, > > and in any case I can surely provide a signature of the tarball(s) in > > the next candidate proposal. > > A vote can't be on a GitHub tag (as that could change) it needs to be on an > artefact as the contents of LICENSE and NOTICE depend on what is in that > bundle. > > > I don't see any requirement for that in the policy, is this somehow a > > requirement ? > > Yes it is a requirement to have a signed artefact. See > https://www.apache.org/legal/release-policy.html#what-must-every-release-contain > for details. > > > It is our policy to never clutter these files with license statements > > That may be the case but it is not ASF policy, please see > https://www.apache.org/legal/src-headers.html. Note it mentions what files > need ASF headers and the limited exceptions. > > > It is my understanding that such derivative works must be listed in the > > NOTICE file, which `doc/bst2html.py` is certainly mentioned. > > This is not correct only limited things belong in a NOTICE file, all license > information goes in the LICENSE file. Please see > https://infra.apache.org/licensing-howto.html. Anything included that is MIT > or BSD licensed needs to be mentioned in LICENSE not NOTICE. > > > The tarballs are extremely lightweight are are only included as data to > > run tests against (they are essentially hello world programs, or just > > tarballs which contain data that tests expect). > > An ASF release cannot include compiled source code, not even compile hello > world programs. They could be download or compiled as part of the testing > process, if they are used for tests. See > https://www.apache.org/legal/release-policy.html#source-packages > > > Although I wonder how important this is given the lower case "should" > > (as opposed to "MUST")... > > This is a requirement only non ASF projects can use the other header. See > https://www.apache.org/legal/src-headers.html#headers > > > and perhaps this is acceptable if added to the NOTICE file in some way > > Only relocated copyright notices i.e. those where you have had permission > form the copyright owner to remove should be added to the NOTICE file. See > https://www.apache.org/legal/src-headers.html#header-existingcopyright > > > Right, these are all very easy to account for, but I could use some > > guidance as to how precisely to update the NOTICE file for this. > > In general you would not update the NOTICE file, you would update the LICENSE > file. If the 3rd party code is ALv2 and has a NOTICE file then some additions > to the NOTICE file may be required. See > https://infra.apache.org/licensing-howto.html#alv2-dep > > > It would strike me as very odd to modify the LICENSE file > > The LICNSE file needs to contain all of the license of bundles software in > the release artefact. See > https://infra.apache.org/licensing-howto.html#permissive-deps > > Kind Regards, > Justin >
