Hello, Last commit broke the build. And will probably block the night team in VN :-) http://builder.exoplatform.org/hudson/view/All/job/gatein-portal-trunk/97... /home/hudson/hudson/jobs/gatein-portal-trunk/workspace/gatein/portal/trunk/component/pc/src/main/java/org/exoplatform/portal/pc/ExoKernelIntegration.java:[133,61] cannot find symbol symbol : variable LOCAL_PORTLET_INVOKER_ID location: interface org.gatein.pc.api.PortletInvoker *Questions:* How should we behave in such case ? Can we rollback the commit if the responsible is not present for few hours ? Or let it be and update to the last known stable state.

*Experimentation:* I'll send the build notifications (only failures and back to normal state) to the gatein-dev list. Tell me if that's not acceptable also.

Is there another target ML for that ?

The notification rules: 1. Every failed build triggers a new e-mail. 2. A successful build after a failed (or unstable) build triggers a new e-mail, indicating that a crisis is over. 3. An unstable build after a successful build triggers a new e-mail, indicating that there's a regression. 4. Unless configured, every unstable build triggers a new e-mail, indicating that regression is still there. Dimitri BAELI - eXo Platform SAS _______________________________________________ gatein-dev mailing list gatein-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/gatein-dev

On Oct 9, 2009, at 2:32 AM, Dimitri BAELI wrote: > Hello, > > Last commit broke the build. And will probably block the night > team in VN :-) > > http://builder.exoplatform.org/hudson/view/All/job/gatein-portal-trunk/97... it is a snapshot issue. Chris has taken the initiative to do a minor refactor of the portlet container (moving the LOCAL_PORTLET_INVOKER_ID constant from one class to another) that is not yet visible to the world depending on it. I see two issues here: 1/ modifying an API used by a consumer (outlined by org.gatein.pc.api package name) 2/ the usual issue of using snapshots with a random life cycle driven by trunk development > /home/hudson/hudson/jobs/gatein-portal-trunk/workspace/gatein/ > portal/trunk/component/pc/src/main/java/org/exoplatform/portal/pc/ > ExoKernelIntegration.java:[133,61] cannot find symbol > symbol : variable LOCAL_PORTLET_INVOKER_ID > > > location: interface org.gatein.pc.api.PortletInvoker > > Questions: > How should we behave in such case ? > Can we rollback the commit if the responsible is not present for > few hours ? Or let it be and update to the last known stable state. we do not have a general policy for that. but in this case it is related to the policy I want to put in place for using branches along with snapshots. > > Experimentation: > I'll send the build notifications (only failures and back to > normal state) to the gatein-dev list. Tell me if that's not > acceptable also. > Is there another target ML for that ? > sounds acceptable given the policy. I would add also that using a snapshot in the dependencies of a project should also send some kind of warn. > The notification rules: > Every failed build triggers a new e-mail. > A successful build after a failed (or unstable) build triggers a > new e-mail, indicating that a crisis is over. > An unstable build after a successful build triggers a new e-mail, > indicating that there's a regression. > Unless configured, every unstable build triggers a new e-mail, > indicating that regression is still there. > > > Dimitri BAELI - eXo Platform SAS > _______________________________________________ > gatein-dev mailing list > gatein-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/gatein-dev

On Oct 9, 2009, at 7:35 AM, Julien Viet wrote: Last commit broke the build. And will probably block the night team in VN :-) http://builder.exoplatform.org/hudson/view/All/job/gatein-portal-trunk/97... it is a snapshot issue. Chris has taken the initiative to do a minor refactor of the portlet container (moving the LOCAL_PORTLET_INVOKER_ID constant from one class to another) that is not yet visible to the world depending on it. Indeed. This was however fixed within the hour. I see two issues here: 1/ modifying an API used by a consumer (outlined by org.gatein.pc.api package name) That modification was prompted by the use of hardcoded PC implementation details in Portal and the subsequent effort to mitigate this issue. 2/ the usual issue of using snapshots with a random life cycle driven by trunk development True. We definitely need to setup a better development model for post-beta02. In the mean time, rollbacking is the way to go, with, if possible, an email sent to the offending committer to notify them that their last commit was rollbacked. Sorry about that. :( Cordialement / Best, Chris == Principal Software Engineer / JBoss Enterprise Middleware Red Hat, Inc. Follow JBoss Portal: http://jbossportal.blogspot.com / http://twitter.com/jbossportal Follow me: http://metacosm.codepuccino.com / http://twitter.com/metacosm