On Tue, 29 Sept 2026 at 08:17, <[email protected]> wrote:
>
>
> Am 28.09.2026 um 12:49 schrieb sebb:
> > On Sat, 26 Sept 2026 at 13:27, Jim Jagielski <[email protected]> wrote:
> >> I am calling a VOTE on releasing the source and complimentary community 
> >> builds of Apache OpenOffice 4.1.17-RC1 (Git hash 0x8b0c57b6af) as GA.
> >>
> >> These artifacts can be found at:
> >>
> >>    https://dist.apache.org/repos/dist/dev/openoffice/4.1.17-RC1/
> > There is some missing information needed by reviewers:
> >
> > What is the immutable source tag for checking the contents of the
> > source artifacts?
> > Where is the KEYS file for checking sigs?
>
> https://dist.apache.org/repos/dist/release/openoffice/KEYS
>

It would be better to use the downloads.a.o link; but it is important
that the link is provided in the vote email

> >
> > Also, for provenance, some way of immutably identifying the RC is
> > needed (an SVN tag is not immutable).
> > It needs to be possible to irrefutably tie the published release back
> > to the vote.
>
> Commit 8b0c57b6a should been used. Where is that to be documented?

In the vote email, so it can be checked by reviewers, and used for
provenance later.

> we had some logic that backed that into the about message, but not sure
> if that is still the case.
>
> >
> >> Please cast your vote:
> >>
> >> The Release Candidate is good for production/GA:
> >>    [ ] yes / +1
> >>    [ ] no / -1
> >>
> >> My vote is based on:
> >>    [ ] binding (member of PMC)
> >>    [ ] I have built and tested the RC from source on platform [ ]
> >>    [ ] I have tested the binary RC on platform [ ]
> > I think the following also need to be checked:
> >
> > [ ] I have checked that the LICENSE and NOTICE entries agree with the
> > contents of their respective artifacts
> what do you mean by this? What is to do here?

The LICENSE and NOTICE files must be present in each released
artifact, and must correspond with the contents of the artifact. e.g.
if there is some 3rd party code that is included, it may require
LICENSE or NOTICE entries.

> > [ ] I have checked that the source archive contents matches the source
> > tag, and does not contain any spurious content
>
> how can you check that? we have tons of files. i could repeat the source
> packaging and compare a sha value.

If comparison failed, it would indicate a problem in the packaging,
but success would not prove anything.

> Any other ideas?

The way I usually do it is to extract the contents from the source
archive and compare it with a checkout of the source tag from SVN or
Git. This can be done with a suitable diff utility.

There should be no files in the archive that do not match a
corresponding file in the source, and most files in the source should
be in the archive (some ancillary files e.g. .gitignore and doap.rdf
don't belong)

>
> > [ ] I have checked that the binary release does not contain additional
> > entries that are not AL 2.0 compatible
>
> I an not sure if we have reproducible builds. I think we did have issues
> with that.
>
> At least i remember some discussions.
> And i have no idea how to test this.

Visual inspection of the archive listing can reveal if an unexpected
file is present.

> >
> >> This vote will be open for 14 days to allow for sufficient time for 
> >> testing, review, and voting.
> >> --
> >> Jim
> >>    "Ow, chicka-chicka-ow-- OW! Man, my hat's on fire!"
> >>                                  - The Spirit of Jazz
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [email protected]
> >> For additional commands, e-mail: [email protected]
> >>
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [email protected]
> > For additional commands, e-mail: [email protected]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to