RichFaces 4.0.0.M5 Post Mortem

[jbalunas]

As we are into a more rapid release structure with the CR releases we're not going to have meetings dedicated to the post-mortem's as we have had up to now.  We will instead provide and discuss feedback, and suggestions via the the forums for M5, CR1, and CR2.  After the final release we'll have a full post-mortem as before.

As usual I would like to discuss what worked, and what did not in the release.  Including what we can do to improve our process, and environment.  It is open to anyone, but I would like project team members to comment.  Lets all try to get our feedback in by the end of this week ( Jan 21st )

Here are some starter questions that might help you to organize your thoughts.

1. What worked well in the release?
2. What did not work well, held you up, or caused blockages?
3. How did Jira work for you?  Do we need a better way to organize?
4. Did you use the build messages from hudson?  If not why?
5. What should we change in the CR phases?

Any other questions?  Feel free to add your own.

[ppitonak]

Hi, here are my comments:

1. What worked well in the release?

* a lot of bugs were fixed

* a blocker bug in popupPanel causing ClassCastException fixed relatively fast

* Selenium tests provide stable results

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

* devs don't notify QE about big changes - components, facets, attributes renamed (only Anton B wrote an email about d-n-d)

* CDK is hasn't been buildable with OpenJDK for almost 3 months RF-9538 - probably requires a one-line fix

* huge amount of bugs in taglib

* RF-9926 and RF-9933 resolved without being fixed

* devs are not online on IRC, makes me use email = slow

* confusion about limitToList vs. limitRender vs. disableImplicitRender

* there was again confusion which version of Mojarra and Myfaces use for testing

5. What should we change in the CR phases?

* add documentation for attributes in taglib, attributes of accordion:

  @rendered : I don't know maybe some thing strange

   @binding: binding description

  @id: Long long text

* atm we have 1500+ Selenium tests from which 105 fails - imho it should be possible to have max. 60 failures for CR1, 30 for CR2 and 15 for Final

bonus question:

* Is there any practical reason why we still use 2 namespace for tags - a4j and rich?

Regards,

Palo

[ilya_shaikovsky]

1. What worked well in the release?

• stable bugfixing process.
• some required RFCs were completed quickly (RFCs which should not be done after final in order to be backward compatible)

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

• Build should be more stable.
• Lack of info for QE(reasons 1) before last M we simplified the requirements pages to just features lists 2) no info in taglibs) caused spending much time in IRC some days.
• CSV readinnes status and usage info was not available till the last days. Not much time to check and create demos.
• We still not deployed richfaces-showcase. I believe we lost much from community point of view because of that.

3. What should we change in the CR phases?

• It's really hard in short time.. But we have to review as much as possible to get all the architectural/naming changes prior to final. example - JS API, facets lists. attributes namings. After final - there will be no possibility to refactor things we will be able only to deprecate somthing and add new things. And that's will be harder to maintain.
• In the same time we should see difference between existent features RFCs and new feature requests. And second ones should not be considered in CR. We should concentrate on stability and consistency.
• Should provide online demo asap in order to see how things going with GAE before final. If all the guys will visit it first time in Final day and it will be crashed for some reasons - It will looks too bad.
• Should deploy Push demo asap in order the community to start checking it and provide feedback.

@Palo

bonus question:

* Is there any practical reason why we still use 2 namespace for tags - a4j and rich?

I believe things should be like that in future. As for JSF itself (f: and h: taglibs) we having rich UI components and ajax/behavioral/utility components.

But b.t.w. still questionable points there.. componentCotrol, validator, hashParam and need to check if there are more - should be a4j: tags from my point of view.. But seems it's too late already for such review.

* devs are not online on IRC, makes me use email = slow

* confusion about limitToList vs. limitRender vs. disableImplicitRender

Hm.. I talked with Lukas much prior to M5.. And I'm connecting to IRC automatically turning it off just when need to work on something fast and carefully So please do not wait for concrete dev's and ping me more in case of questions. The guys having much more coding work than me and that is pretty difficult to participate in discussions while working with code. In the same time I'm doing my best to keep all the functionality and latest changes in mind because anyway need to provide forum support and perform docs review.

[nbelaevski]

1) What worked well in the release?

• Community reports real issues - much thanks to everyone helping in making RF milestones better!
• Peer code reviews revealed some problems in source code - they were fixed

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

• RF-9661 took a lot of time - and still not convinced it's a common user configuration   
• Build failures still happen

3) How did Jira work for you?  Do we need a better way to organize?

JIRA worked fine for me... we just have a big number of unresolved issues there - it's causing problems by itself

4) Did you use the build messages from hudson?  If not why?

Look at them from time to time (usually when e-mail about build problems arrives)

5) What should we change in the CR phases?

• +1 to documentation & stabilization points
• IMHO, we need to deploy demo more often (e.g. on weekly basis)

[jbalunas]

1) What went well in the release?

• A lot of bugs were fixed
• Lots of community involvement!!
  • Good feedback, and even assistance to other groups

2) What did not?

• CSV was not ready, and delayed the release 1 week
  • Still not fully functional in M5
• Build stability was still a problem sometimes
• Missing base functionality, and tag lib completion still a big problem
• Showcase/push hosting is a big problem
• GAE work needs to be finalized

3) How did jira work for you?

• Worked fine, especially after post_4.F release created, and could organize jira's better

4) Build messages?

• Sometimes, but not often, and I suspect many others felt the same
  • I believe this is part of the disconnect discussed below with QE and docs. 
  • We need to review results of the selenium tests posted, and make that easier for Dev
  • Dev needs to act on them, and sync up with QE.

5) What to change?

• CSV needs to be functionally complete for CR1
  • Already discussed with team, and Alex and Pavel are focused on this.

• Get showcase hosted on GAE asap, and load tested by QE.
  • This should be targeted for mid CR2 in my opinion.
  • I like the idea of weekly refreshed of this
    • Perhaps Fridays starting next Friday
  • Remaining tasks
    • SessionCleaningServlet
    • Optimization steps & wiki page
    • Final load testing round

• Development needs to focus on fixing base functionality, and getting tag lib files accurate, and up to date.
  • This is mostly captured in jira already
    • Tag lib : https://issues.jboss.org/browse/RF-9936
    • Base Functionality component: http://bit.ly/ei8WQf
  • QE & dev should use it where appropriate
  • Dev needs to prioritize it

• Define release criteria and plans for 4.0.F
  • This we need to discuss as a team and it is related to QE/Dev sync up items below.
  • For CR1 this communication did not effectively happen, and QE is concerned about the # of enhancements and features added to a CR release.
  • For CR2 we need to define what is acceptable, and what makes in "ready" for both QE and dev. 

• QE and Dev Sync up
  • QE has many selenium tests setup and the builds are running.  However there are many failing tests - many already have jira's associated with them.  QE would like to use these tests and the % or # failing as release criteria.  I think that is a good idea as long as failures are published with accessible links for minsk team.  Iirc nearly every selenium test has a jira - but is there a way from jira to track that back?  i.e.  Identify what jira's are from what test, and failed?

• We need to agree on some release criteria ( not just the passing selenium tests ), and focus our energies there.  I know that Prabhat has outlined some in the test plan, but I think we as a group need to determine what is acceptable.

• Solving broken builds is just down to developer discipline at this point.  Development branches really did not help, especially given the how difficult they are with SVN.  That said we need to be more careful about breaking the builds.  It leaves everyone paralyzed.

[jbalunas]

Pavol Pitonak wrote:

Hi, here are my comments:

* devs don't notify QE about big changes - components, facets, attributes renamed (only Anton B wrote an email about d-n-d)

I agree with this, it was good to see Anton do this.  Post CR1 we should not see any/many "big changes".  The only one that might be is if there are significant issues found in client api review.

* CDK is hasn't been buildable with OpenJDK for almost 3 months RF-9538 - probably requires a one-line fix

Lets talk to Alex and see if we can get this resolved.

* RF-9926 and RF-9933 resolved without being fixed

These were resolved as "done", but should have been resolved as "Unable to Reproduce".  When you reopened it appears Alex K then resolved these.

* devs are not online on IRC, makes me use email = slow

The dev team typically uses yahoo IM, but agree we should all try to be on IRC more often, myself included.

* there was again confusion which version of Mojarra and Myfaces use for testing

This was resolved prior to freeze iirc.  There were some changes required because of AS 6 release.

* atm we have 1500+ Selenium tests from which 105 fails - imho it should be possible to have max. 60 failures for CR1, 30 for CR2 and 15 for Final

Agree we need to sync on this, and reference it in my section.

[jbalunas]

3. What should we change in the CR phases?

• It's really hard in short time.. But we have to review as much as possible to get all the architectural/naming changes prior to final. example - JS API, facets lists. attributes namings. After final - there will be no possibility to refactor things we will be able only to deprecate somthing and add new things. And that's will be harder to maintain.

Agree, and glad you are leading the client api review!  These need to be completed and reviewed.  If there are minor corrections for CR2 I'm ok with that, but if something comes up and it is a major changes across multiple components we'll all need to plan out.

• In the same time we should see difference between existent features RFCs and new feature requests. And second ones should not be considered in CR. We should concentrate on stability and consistency.
• Should provide online demo asap in order to see how things going with GAE before final. If all the guys will visit it first time in Final day and it will be crashed for some reasons - It will looks too bad.
• Should deploy Push demo asap in order the community to start checking it and provide feedback.

Agree to all above, as for push demo, where to host will be tricky.  Lets discuss this offline.

[jbalunas]

Nick Belaevski wrote:

1) What worked well in the release?

• Community reports real issues - much thanks to everyone helping in making RF milestones better!
• Peer code reviews revealed some problems in source code - they were fixed

Both excellent and agree!