3 Replies Latest reply on Sep 7, 2010 10:44 AM by ilya_shaikovsky

    RichFaces 4.0.0.M2 Post-Mortem Meeting

    jbalunas

      Hello All,

       

      We are going to have our 4.0.0.M2 post-mortem meeting during next weeks team meeting ( Sept 7th ),  I have extended the meeting another hour, so two hours total.  We are going 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 the project team members really need to be there.  If for some reason you can not please leave your comments & answers to the questions below in this thread.  We'll go around the IRC channel and get feedback from everyone.

       

      Please be prepared and ready to provide 2 or 3 points to discuss for each of the questions below.  Please provide bullet points, and comments in this thread so we can get right to meat of the discussion.

       

      1. What worked well in the release?
      2. What did not work well, held you up, or caused blockages?
      3. How can we change M3 to make development easier, faster, more stable?
      4. Updates to build - working for you, did not notice, could be improved more?
      5. Planning, prep, and jira updates - where can we improve?

       

      Any other questions?  Feel free to add your own.

       

      Thanks,

      Jay

        • 1. Re: RichFaces 4.0.0.M2 Post-Mortem Meeting
          ppitonak

          What worked well in the release?

           

          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

          • 2. Re: RichFaces 4.0.0.M2 Post-Mortem Meeting
            lfryc

            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
            • 3. Re: RichFaces 4.0.0.M2 Post-Mortem Meeting
              ilya_shaikovsky

              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.