What worked well in the release?

• problems with staging repo disappeared
• see  https://community.jboss.org/wiki/Richfaces4Xreleasetestingprocess for sample settings.xml
• mock release helped much

What did not work well, held you up, or caused blockages?

• I experienced several outages in infrastructure (SVN, Nexus, Hudson)
• there were some problems with Maven - couldn't download cargo plugin, solved by changing Hudson slave & cleaning local Maven repo
• Metamer uses CLI plugin which isn't in JBoss Maven repo
  - I worked it around in settings.xml
  - Lukas suggested to remove it
  - would it be possible to add http://twdata-m2-repository.googlecode.com/svn to Nexus?
• there were too many bugs which should be found before tagging

How can we change M3 to make development easier, faster, more stable?

• prolong time between code freeze and tagging
• eliminate respins - I spent too much time with it (because of mentioned outages)

Updates to build - working for you, did not notice, could be improved more?

• works well for me

Planning, prep, and jira updates - where can we improve?

• no comments

Palo

What did not work well, held you up, or caused blockages?

• Metamer uses CLI plugin which isn't in JBoss Maven repo
  - I will push to upload the dependency to JBoss Repository since it is currently in proprietary repository

What worked well in the release?

Process improved much since ALPHA's and now dev and release process was much smoother and convenient. Milestones seems fits really good and we are have clean vision of goals and progress for now.

Discussions normally provides much feedback and most of wiki stuff created being kept up to date.

Jira process upgrades also seems provides more easier way to see the components statuses at any time.

What did not work well, held you up, or caused blockages?

and

How can we change M3 to make development easier, faster, more stable?

1) There was not enough time to prepare demo or make  final review of functionality at demos before the tagging. Mainy because the components were in sandbox till the last moment and then was moved together to ui and there was not much time remained. Does it possible - to perform works in next way:

• developer makes component base version and moves some extended features which requires more time but planned to release to separate tasks.
• base component getting reviewied and posted to trunk as it stable and provides base functionality
• branch for remained complex features created and could be merged when ready.
  • ideally if there are more than one complex feature - separate branches should be created in order to work under next feature when the first also merged to trunk for review

That will gaves definitelly more time for QE, doc team and me.

2) We still not using some CDK features properly and because of that sometimes have to review some parts for all the components every release:

example - taglib.xml generated still contains errors related to non-existent attributes there or even the components which present at wrong taglib.

3) Developer has to check the component base functionality (and for sure the fact that it rendered fine and without any w3c validation errors) in all supported browsers prior to making them ready for QE, demo usage. E.g. - a few iteration components contained issues like "do not rendered in XXX browser at all" because of wrong html, or inplace component which design was changed in last days (That work ideally should be done during desing provided from Lex review.) We should not pass to QE functionality which not checked on our own carefully. And in combination with 1)  influenced the process of release finalization as much issues were found.

4) documentation issue - we still has no official approach to reviews for that M. Pre-M2 review by emails was not really convenient for me.

But that should be solved already for M3 (at least in theory ) - by using new jira's from policy - "Create drraft docs", "review and update docs" and "promote". Just need to see how it will works.

Updates to build - working for you, did not notice, could be improved more?

Now seems really good and convenient.

Planning, prep, and jira updates - where can we improve?

I will check your opinions on my faults there As for me - I satisfied with the handling of the general design in public, the reviews and feedback there and having many small local discussions on some impl specific questions with concrete developers.