On 2/26/11 1:08 PM, Luc Maisonobe wrote: > Le 26/02/2011 18:29, Phil Steitz a écrit : >> On 2/26/11 11:47 AM, Luc Maisonobe wrote: >>> Le 26/02/2011 17:11, Phil Steitz a écrit : >>>> On 2/25/11 5:15 AM, Luc Maisonobe wrote: >>>>> Tag: >>>>> <http://svn.apache.org/repos/asf/commons/proper/math/tags/MATH_2_2_RC5/> >>>>> >>>>> All artifacts in Nexus staging repository: >>>>> <https://repository.apache.org/content/repositories/orgapachecommons-051/org/apache/commons/commons-math/2.2/> >>>>> >>>>> site: >>>>> <http://people.apache.org/builds/commons/math/2.2/RC5/> >>>>> >>>>> Clirr report: >>>>> <http://people.apache.org/builds/commons/math/2.2/RC5/clirr-report.html> >>>>> >>>>> Votes, please. This vote will close in 72 hours, 2011-02-28T11:00:00 UTC >>>>> >>>>> [ ] +1 Release these artifacts >>>>> [ ] +0 OK, but... >>>>> [ ] -0 OK, but really should fix... >>>>> [ ] -1 I oppose this release because... >>>>> >>>>> Thanks! >>>>> >>>>> Luc >>>>> >>>>> >>>> I am struggling a little on this one. The code is good. Builds and >>>> tests fine. Sigs are good. Release contents are good. But the user >>>> guide packaging is not as good as 2.0-2.1, IMO. The reason that I >>>> introduced the siteMods stuff in 2.0 was so that we could bundle >>>> just the user guide as a self-contained set of web pages in the >>>> binary distro. Just file filtering from a full site build results >>>> in broken links in the nav and the appearance of the whole site, >>>> with only the user guide content available. On the other hand, to >>>> fix this, you need to do what the build script does or something >>>> similar (at least I couldn't find a way to get it to work >>>> otherwise), which means you can't just have maven build and deploy >>>> the whole release without additional scripting or commands. The nav >>>> links in the user guide into the user guide itself work and the >>>> links from the user guide to the bundled javadoc work, so this is >>>> really just an appearance/useability issue. >>>> >>>> So I guess I am +0 on this RC. The broken links / appearance issues >>>> are not enough for -1, or even -0, but I would rather ship the >>>> cleaner version. I don't know how nexus works, but I would expect >>>> that it should be possible to generate just the binary distro and >>>> push it out there somehow if you decide to do another RC. >>> OK. Perhaps I could try what Sebb suggested: using the siteMods/pom.xml >>> and siteMods/site.xml stuff directly from maven. I could even do the >>> site manually with your script and later use mvn deploy. >>> >>> I will give it a try first without cancelling this RC vote. If I succeed >>> in having a fully functional menu with only the required links, then >>> I'll cancel the vote and push an RC6. >> If you just run the script, it will create the correctly bundled >> user guide. The previous RCs had it fine. You could then just push >> out the binary zip/tgz. I almost suggested that you just do that >> and restart the VOTE, since no changes to the tag are necessary to >> fix this. IIUC, Sebb's suggestion just simplifies the script. You >> still need to execute "mvn site" separately using the modified >> resources to get the user guide built. > Fine. I just check if I could do a mix by manually creating the site > using the script as a template and leaving it in the target/site > directory, then switch to mvn deploy. It seems to work, at least with a > local test-deploy. Great, just make sure to document the steps somewhere. Maybe add a release-process.txt describing the steps (can be done post-release) or just modify the script to end with a deploy. > So I cancel this vote now. > > I will still do an RC6 tag since I have to change the publish target > dates in changes.xml and doap_math.rdf (and hence the RC number in one > property of pom.xml also). > > I am really sorry to be so slow in getting this release out and force > everybody to vote again and again. Next time, I'll try to get it right > faster. Hey, nobody is dying here ;)
This last wrinkle was my fault - I just could not find a way to get the user guide bundled without some scripting and that, together with an old-fashioned approach to generating the artifacts, is what led me to create the script for 2.1. Thanks for *your* patience! Phil > Luc > >>> What should we do about the duplicate javadoc in binary ? Do we keep >>> both the jar and the expanded version in the binary zip or do we >>> suppress one of them ? If we suppress one, which one ? >> I am not one of them, but some users seem to like to have both >> source and javadoc jars included in the binary distributions. I am >> not sure why, but I think it has to do with IDE integration. It >> doesn't bother me personally to include these jars. It *would* >> bother me not to have apidocs in the distro itself, though. >> >> Phil >> >>> Luc >>> >>>> Phil >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>> >>>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
