On 9/20/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote: > > +1 on the proposal. I think a cleaning up the components to a shortlist > will be nice. > > Thanks > > - Venkat > > On 9/20/07, Simon Laws <[EMAIL PROTECTED]> wrote: > > > > ---------- Forwarded message ---------- > > From: Venkata Krishnan <[EMAIL PROTECTED]> > > Date: Sep 20, 2007 8:16 AM > > Subject: Re: Change freeze on 1.0 branch > > To: [email protected], [EMAIL PROTECTED] > > > > +1... makes lot of sense to me > > > > - Venkat > > > > On 9/20/07, ant elder <[EMAIL PROTECTED]> wrote: > > > > > > Just a reminder there is still a change freeze on the 1.0 branch. > > > > > > Its still possible we may need to respin for some reason, but how > about > > > also > > > planning on doing some 1.0.x releases after 1.0 is out? If we keep > > changes > > > in the branch to an absolute minimum it should be easy to do > > 1.0.xreleases > > > after all the 1.0 reviewing so we can just show a small diff of 1.0 - > > > 1.0.xand review/voting should be painless so we could do > > > 1.0.x release every 1 or 2 weeks if necessary. With that in mind how > > about > > > we switch to Review-Then-Commit mode on the branch - so all changes > get > > > attached as diff to a JIRA and can only be applied to the branch with > 3 > > > +1s > > > on the ML? > > > > > > ...ant > > > > > > On 9/19/07, ant elder <[EMAIL PROTECTED]> wrote: > > > > > > > > Looks like 1.0 is getting pretty close now so can we have a change > > > freeze > > > > on the 1.0 branch to avoid any last minute regressions please - no > > > updates > > > > to it without asking first. > > > > > > > > We need an RC4 to fix the missing xquery sample and the ws.zonesrepo, > > > but > > > > i'd hope RC4 can be the final one. Please continue reviewing RC3 and > > > raising > > > > jira's for any issues you find (and finding fixes for the issues!), > > and > > > i'll > > > > cut an RC4 late today. Lets try to keep the RC4 vote thread clean - > so > > > just > > > > +1/-1 and anything else in a jira. If you do find a serious issue be > > > great > > > > if you could say something like "+1 as long as jira xxx is > resolved". > > > > > > > > Thanks! > > > > > > > > ...ant > > > > > > > > > > > > > Hi > > > > It feels like we have been getting better at using JIRA in the run up to > > 0.99 and 1.0 release in terms of the consistency with which we raise bug > > reports and assign them to releases. Based on Ant's branch freeze > > suggestion > > how about we now > > > > 1/ create the following versions in JIRA > > JAVA-SCA-1.1 - as the trunk target > > JAVA-SCA-1.0.1 - as the 1.0 branch target in case we need it > > > > 2/ Review the JIRA components to make them match the modules we > currently > > have. Several options here, e.g. > > a/ add a component for any module we have in svn that is not > represented > > b/ stick with the shorter list, as we have now, making sure we have > one > > for each extension and general ones for Itests, samples, demos , > > distribution etc. > > > > 3/ Continue the theme of creating JIRAs for the bug/enhancements we see > > and > > assigning them to the release where we want them to be fixed. > > > > B.t.w I'm happy to do admin tasks as appropriate. > > > > Simon > >
I've added the new version numbers and will fix the component list tomorrow. How about we go roughly with the top level structure that we have + a few extra categories for orthogonal issues as appropriate Java SCA Implementation (modules) Java SCA Integration Tests (Itest) Java SCA Samples (samples) Java SCA Demos (demos) Java SCA Build (distribution) Java SCA Tools (tools) Java SCA Website Java SCA Problem Determination ? any others. It's not clear to me that any greater fidelity is adding value at the moment. There is value if we start having owners for particular modules or it the bug structure matches the build structure in any meaningful way. Simon
