Hello Dave, 2017-03-29 21:38 GMT+02:00 Dave Fisher <[email protected]>:
> Hi - Svante. > > > On Mar 29, 2017, at 11:56 AM, Svante Schubert <[email protected]> > wrote: > > > > I have prepared the RC3 (not voting yet due to some questions left), you > > may find updated links at the end of the mail. > > > > The main changes were > > > > - using now SHA-512 instead of SHA-1 for Apache distribution > > The signatures are still named *.sha1. > On the Maven NEXUS artifacts it is sha1, but the Apache distribution ( https://dist.apache.org/repos/dist/dev/incubator/odftoolkit/0.6.2-incubating/) has .sha files with a long key. Not certain what part of the pom.xml is being used for Nexus deployment. In additiion I had a typo in the pom.xml stating "sha512" instead of "sha-512", which I fixed for the very last step of release deployment doing the Apache package build. Likely Nexus deployment was earlier and instead of stopping the deployment, just used sha-1 as fallback. > > > - updated the README files of most subprojects > > - added Tom to the CHANGES.txt as a mentor > > > > Aside of this, I have updated our incubator project website > > <http://incubator.apache.org/projects/odftoolkit.html> (e.g. the > previous > > release was not mentioned). > > Great. > > > > > Before I start a vote, I have got some general release questions I could > > not find the answers to on the online documentation: > > > > 1. There is a DEPENDENCIES file at the root of our release source > bundle > > (22,5 MB) > > <https://dist.apache.org/repos/dist/dev/incubator/ > odftoolkit/0.6.2-incubating/odftoolkit-0.6.2-incubating-source-release.zip > >. > > > > The DEPENDENCIES file is basically empty, is this meant to be, fix it > or > > shall remove it? > > I think that you should remove that file. NOTICE and LICENSE cover any > required legal notice. > > It is not in the SVN sources of our repository (see https://svn.apache.org/repos/asf/incubator/odf/tags/odftoolkit-0.6.2-incubating/ ) It is being generated but I do not find any documentation about it. > > The comment within states that the file should list the transitive > > dependencies (in other words: the dependencies of our project > dependencies) > > gathered by Maven via the pom. > > I would expect the content might be similar to anyone could receive > when > > calling > > ' mvn -f pom.xml dependency:tree' > > from our project root directory. > > And this does the rest. It may be good to include this information on. The > polling website with a release. > > On one hand everyone can gather this with a command, it is not quite readable and far easier to read in the pom.xml under dependencies. On the other, who ever is generating this, should at least to it right ;) So, where to search for it? > > 2. Does the JAR accessible via Maven have to include NOTICE, README, > > DISCLAIMER files as well? I heard gossip, but could not find any > > documentation about it. > > If so, a pointer to another Maven using incubator project would be > > helpful to apply their handling. > > Disclaimer is required of all Incubator podlings. > > Readme that is provided is a nice to have and I think it is good, but it > should refer to the LICENSE, NOTICE, and DISCLAIMER without including any > text. > > The whole legal directory should be removed as that information is at the > top level. > > I think that the LICENSE and NOTICE files in the subproject are probably > OK, but they need to be specific to each sub-project. > > > 3. Like the BIN and DOC artefacts in a folder and the source and root > > level? Is this the way it should be? > > The question is one of taste. Do you want to have a single jar in future > versions or continue with the sub-projects? Really a question for the next > release. > > I am ok with the current structure. I think that the README file should > include the version of Java used to build the convenience binary artifacts, > but that is not a requirement. > > > 4. Does anyone have pointers to scripts doing automated Apache > > (incubating) release testing? > > What testing do you mean? Signature? All present? Given the large number > of artifacts I would suggest a *nix shell script that uses the find command > to locate the artifacts and check hashes and signatures. > > I doubt that any of the above should be considered a blocker to release by > anyone on IPMC. > Okay, I will see if someone else is answering in the next 12-18 hours and will start a vote or do some fixes and another round. Thanks for your help, Dave! Svante > Regards, > Dave > > > > > > > Updated references for RC3 are: > > > > Source artefacts: > > https://dist.apache.org/repos/dist/dev/incubator/ > > odftoolkit/0.6.2-incubating > > > > Staged artefacts: > > > > https://repository.apache.org/content/repositories/ > orgapacheodftoolkit-1007 > > > > SVN source: > > https://svn.apache.org/repos/asf/incubator/odf/tags/o > dftoolkit-0.6.2-incubating > > > > Issues fixed: > > https://issues.apache.org/jira/secure/IssueNavigator.jspa? > > reset=true&jqlQuery=project+%3D+ODFTOOLKIT+AND+fixVersion+% > > 3D+0.6.2-incubating+ORDER+BY+status+DESC%2C+priority+DESC&mode=hide > > > > Release Notes: > > https://svn.apache.org/repos/asf/incubator/odf/tags/o > > dftoolkit-0.6.2-incubating/CHANGES.txt > > > > The artefacts have been signed using my Apache PGP key 862EA1DEE2EC7D45 > being > > the last in our KEYS > > <https://svn.apache.org/repos/asf/incubator/odf/tags/ > odftoolkit-0.6.2-incubating/KEYS> > > file. > > > > Best regards, > > Svante > > ᐧ > > ᐧ
