On Nov 27, 2012, at 3:57 PM, Thomas Mortagne <[email protected]> wrote:

On Tue, Nov 27, 2012 at 3:18 PM, Vincent Massol <[email protected]> wrote:

...

Hi devs,

Here are some notes I took while releasing XWiki 4.3 on how to improve the release process:

* We need to automate the generation of the CLIRR report. This is what takes the longest when releasing (not overall time but manual time required). IMO this can be done relatively easily by creating a patch for the CLIRR maven plugin itself to: ** Add support for wildcards in the new <difference> syntax ** Ensure that their report generation takes into account the <justification> element ** Possibly add a text report generation that we'll be able to copy paste in our RN

* Remove PURL generation for Tweets ** Tweets are ephemeral so no need to have permanent URLs ** Tweet clients already do URL shortening (It's complex to use the PURL UI too)

* Don't create RN summary for OW2, email and even blog post. This will win some more time. Instead just link to the RN page which contains a summary and all details. For example for the email it could be: " The XWiki development team is proud to announce the availability of XWiki Enterprise <version>.

You can download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download

Make sure to review the release notes: http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki<short version>

Thanks -The XWiki dev team "

* Put maven.xwiki.org:~/xwiki-release-scripts under Git and do a git reset before the ow2 step to be sure to have clean scripts

I don't understand this part, they are in git.

Yes they are in git but not on maven.xwiki.org -Vincent

...

WDYT?

Thanks -Vincent

Hi, On Tue, Nov 27, 2012 at 5:34 PM, Thomas Mortagne <[email protected]>wrote:

On Tue, Nov 27, 2012 at 4:00 PM, Vincent Massol <[email protected]> wrote:

...

On Nov 27, 2012, at 3:57 PM, Thomas Mortagne <[email protected]> wrote:

...

On Tue, Nov 27, 2012 at 3:18 PM, Vincent Massol <[email protected]> wrote:

...

Hi devs,

Here are some notes I took while releasing XWiki 4.3 on how to improve the release process:

* We need to automate the generation of the CLIRR report. This is what takes the longest when releasing (not overall time but manual time required). IMO this can be done relatively easily by creating a patch for the CLIRR maven plugin itself to: ** Add support for wildcards in the new <difference> syntax ** Ensure that their report generation takes into account the <justification> element ** Possibly add a text report generation that we'll be able to copy paste in our RN

* Remove PURL generation for Tweets ** Tweets are ephemeral so no need to have permanent URLs ** Tweet clients already do URL shortening (It's complex to use the PURL UI too)

* Don't create RN summary for OW2, email and even blog post. This will win some more time. Instead just link to the RN page which contains a summary and all details. For example for the email it could be: " The XWiki development team is proud to announce the availability of XWiki Enterprise <version>.

You can download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download

Make sure to review the release notes: http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki <short version>

Thanks -The XWiki dev team "

* Put maven.xwiki.org:~/xwiki-release-scripts under Git and do a git reset before the ow2 step to be sure to have clean scripts

I don't understand this part, they are in git.

Yes they are in git but not on maven.xwiki.org

I was talking about maven.xwiki.org.

~/xwiki-release-scripts is just a link in a sub folder of ~/xwiki-dev-tools which is the root of the repository.

That's valid only for agent-1, not maven.xwiki.org. On maven.xwiki.org you just have an "xwiki-release-scripts" directory with previous releasenotes.<version>.txt files and some release scripts (of which we only use push-release.sh, which is also included in xwiki-dev-tools/xwiki-release-scripts on git. We probably did not update our process and documentation and kept using this desynchronized script. Thanks, Eduard

...

-Vincent

...

...

WDYT?

Thanks -Vincent

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

Hi Sergiu, On Nov 27, 2012, at 10:01 PM, Sergiu Dumitriu <[email protected]> wrote:

On 11/27/2012 09:18 AM, Vincent Massol wrote:

...

Hi devs,

Here are some notes I took while releasing XWiki 4.3 on how to improve the release process:

* We need to automate the generation of the CLIRR report. This is what takes the longest when releasing (not overall time but manual time required). IMO this can be done relatively easily by creating a patch for the CLIRR maven plugin itself to: ** Add support for wildcards in the new <difference> syntax ** Ensure that their report generation takes into account the <justification> element ** Possibly add a text report generation that we'll be able to copy paste in our RN

+1.

...

* Remove PURL generation for Tweets ** Tweets are ephemeral so no need to have permanent URLs ** Tweet clients already do URL shortening (It's complex to use the PURL UI too)

-1. The PURL is not just about twits, it's about having some permanent links to our release notes. I really don't like that our URLs are so damn long (http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki44RC1 is 71 chars long), so I like to have something shorter.

You don't need PURL for that…. As i mentioned the tweet clients already shorten URLs… Check my tweet, you'll see it's not 71 chars long: https://twitter.com/xwikiorg/status/273180659521028096 (I didn't do anything specific to shorten the URL).

So far I seem to be the only one that sees the value of PURLs, so if you think that we don't want to maintain them in general (not just because tweets are ephemeral), we could do that.

They could have value in other places than tweets but then we don't do this for a lot more things like install documentation, download page, etc and those are way more important than release notes which are also very ephemeral. So my take is to drop them for release notes links.

Why do you need to use the purl.org UI? The push-release script is supposed to handle that automatically.

Check the documentation at http://dev.xwiki.org/xwiki/bin/view/ReleasePlans/ReleasePlanHelp#HAnnounceon... It says not to use it.

...

* Don't create RN summary for OW2, email and even blog post. This will win some more time. Instead just link to the RN page which contains a summary and all details.

I'm kind of -1 for this as well. The summary is for lazy or busy people that don't have time to read our lengthy release notes.

The summary is already in the release notes...

Not even our own devs (and the rest of the XWiki SAS employees) have time to read them fully. A very quick summary that takes 30 seconds to read is a good thing, at least a few more people will find the time to read those and notice how XWiki evolves.

The release notes ARE are summary. We take a lot of pain to make them nice looking and readable. Having a one line sentence about the release is detrimental IMO (and more time consuming for us when doing the release). We want people to click on the link and get to the release notes page.

...

For example for the email it could be: " The XWiki development team is proud to announce the availability of XWiki Enterprise <version>.

You can download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download

Make sure to review the release notes: http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki<short version>

Thanks -The XWiki dev team "

* Put maven.xwiki.org:~/xwiki-release-scripts under Git and do a git reset before the ow2 step to be sure to have clean scripts

I wanted to do that but git was not installed on the machine at that time. I see that it is now.

[Some time later]

I did this, committed the only changes that were present there. It's a read-only clone, so committing won't work directly from the machine unless extra steps are taken.

Great thanks! -Vincent

...

WDYT?

Thanks -Vincent

On Nov 28, 2012, at 1:07 AM, Sergiu Dumitriu <[email protected]> wrote:

On 11/27/2012 04:28 PM, Vincent Massol wrote:

...

Hi Sergiu,

On Nov 27, 2012, at 10:01 PM, Sergiu Dumitriu <[email protected]> wrote:

...

On 11/27/2012 09:18 AM, Vincent Massol wrote:

...

Hi devs,

Here are some notes I took while releasing XWiki 4.3 on how to improve the release process:

* We need to automate the generation of the CLIRR report. This is what takes the longest when releasing (not overall time but manual time required). IMO this can be done relatively easily by creating a patch for the CLIRR maven plugin itself to: ** Add support for wildcards in the new <difference> syntax ** Ensure that their report generation takes into account the <justification> element ** Possibly add a text report generation that we'll be able to copy paste in our RN

+1.

...

* Remove PURL generation for Tweets ** Tweets are ephemeral so no need to have permanent URLs ** Tweet clients already do URL shortening (It's complex to use the PURL UI too)

-1. The PURL is not just about twits, it's about having some permanent links to our release notes. I really don't like that our URLs are so damn long (http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki44RC1 is 71 chars long), so I like to have something shorter.

You don't need PURL for that…. As i mentioned the tweet clients already shorten URLs… Check my tweet, you'll see it's not 71 chars long: https://twitter.com/xwikiorg/status/273180659521028096 (I didn't do anything specific to shorten the URL).

Again, this is not about tweeter. PURLs aren't about length, they're about finding something in a reliable place, and involve maintenance work. There should be no broken PURL. I created a few other PURLs a long time ago, like purl.org/xwiki/repo/, purl.org/xwiki/ml/ and purl.org/xwiki/ml/archive, purl.org/xwiki/ci/ (which used to point to hudson).

Yes PURLs could be a good solution for specific important pages like the one you mention but they are adhoc and I don't believe those are required for temporary resources such as Release notes. Or you really need to make it transparent so that it doesn't cost more when doing releases. I spent 15 minutes trying to create a PURL when I did the release 2 days ago and in the end I didn't do it since it was too complex and I couldn't understand how to do it. [snip] Thanks -Vincent

On Nov 28, 2012, at 1:07 AM, Sergiu Dumitriu <[email protected]> wrote:

On 11/27/2012 04:28 PM, Vincent Massol wrote:

...

Hi Sergiu,

On Nov 27, 2012, at 10:01 PM, Sergiu Dumitriu <[email protected]> wrote:

...

On 11/27/2012 09:18 AM, Vincent Massol wrote:

...

Hi devs,

Here are some notes I took while releasing XWiki 4.3 on how to improve the release process:

* We need to automate the generation of the CLIRR report. This is what takes the longest when releasing (not overall time but manual time required). IMO this can be done relatively easily by creating a patch for the CLIRR maven plugin itself to: ** Add support for wildcards in the new <difference> syntax ** Ensure that their report generation takes into account the <justification> element ** Possibly add a text report generation that we'll be able to copy paste in our RN

+1.

...

* Remove PURL generation for Tweets ** Tweets are ephemeral so no need to have permanent URLs ** Tweet clients already do URL shortening (It's complex to use the PURL UI too)

-1. The PURL is not just about twits, it's about having some permanent links to our release notes. I really don't like that our URLs are so damn long (http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki44RC1 is 71 chars long), so I like to have something shorter.

You don't need PURL for that…. As i mentioned the tweet clients already shorten URLs… Check my tweet, you'll see it's not 71 chars long: https://twitter.com/xwikiorg/status/273180659521028096 (I didn't do anything specific to shorten the URL).

Again, this is not about tweeter. PURLs aren't about length, they're about finding something in a reliable place, and involve maintenance work. There should be no broken PURL. I created a few other PURLs a long time ago, like purl.org/xwiki/repo/, purl.org/xwiki/ml/ and purl.org/xwiki/ml/archive, purl.org/xwiki/ci/ (which used to point to hudson).

...

...

So far I seem to be the only one that sees the value of PURLs, so if you think that we don't want to maintain them in general (not just because tweets are ephemeral), we could do that.

They could have value in other places than tweets but then we don't do this for a lot more things like install documentation, download page, etc and those are way more important than release notes which are also very ephemeral. So my take is to drop them for release notes links.

...

Why do you need to use the purl.org UI? The push-release script is supposed to handle that automatically.

Check the documentation at http://dev.xwiki.org/xwiki/bin/view/ReleasePlans/ReleasePlanHelp#HAnnounceon... It says not to use it.

...

...

* Don't create RN summary for OW2, email and even blog post. This will win some more time. Instead just link to the RN page which contains a summary and all details.

I'm kind of -1 for this as well. The summary is for lazy or busy people that don't have time to read our lengthy release notes.

The summary is already in the release notes...

...

Not even our own devs (and the rest of the XWiki SAS employees) have time to read them fully. A very quick summary that takes 30 seconds to read is a good thing, at least a few more people will find the time to read those and notice how XWiki evolves.

The release notes ARE are summary. We take a lot of pain to make them nice looking and readable.

What kind of summary takes up 16 pages? That's how long is the PDF for the 4.3 release notes.

[snip] Ok I have a solution that will make both of us happy: * I plan to create the Release Application. It'll include the ability to create release notes (I want to be able to autogenerate the final release notes from the M1, M2, RC1, etc) and I'll put a summary field that will be displayed at the top of the release notes in view mode. We will then be able to update the release scripts to automatically get the summary from them, thus not breaking the automated release process and not loosing time. We'll also be able to fully autogenerate the email with this. Thanks -Vincent