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