On Thu, Jun 30, 2011 at 1:29 PM, Norman Maurer <nor...@apache.org> wrote: > Am 30.06.2011 14:27, schrieb Eric Charles: >> >> On 30/06/11 14:19, Norman Maurer wrote: >> (snip) >>>> >>>> The main issues for me are a slow development cycle caused by >>>> unnecessary integration and targeting a moving target. IMO eliminating >>>> this bottleneck will save more time than the cost of cutting the >>>> additional release. Once we have a smooth pipeline, if this call turns >>>> out to be wrong, we can just move the assembly back in. >>>> >>>> Robert >>> >>> I'm still not 100 % conviced.. Why not just freeze trunk for a few days ? >>> >> >> Or at least freeze pom's dependencies/plugins declarations. > > Yeah should be good enough..
In general, freezing is just working around a needless bottleneck in our release pipeline. The best approach is to fix the bottleneck by lengthening the pipe. Taking the application assembly out creates two project that will be easy to release from one that's proving difficult. In particular, manual auditing takes me quite a while. If I were fully recovered, this might not be such an issue but ATM my productivity is very sensitive. Freezing would allow me to audit and create appropriate manual legal stuff but this would need to be repeated before each release and again when checking the release. At my current capacity level, I think this is likely to be a significant drain on my resources and slow everyone else down. Pushing assembly downstream from the server would allow me to check and release the assembled application. I'm pretty sure that we'll get better throughput this way but if it's not working for us, it would be easy enough to move the assembly back as a module of server. Robert --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
