Ok then go ahead.... I just want to get the beta out soon enough Bye Norman 2011/6/30, Robert Burrell Donkin <robertburrelldon...@gmail.com>: > 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 > >
--------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
