Rajith,
> It looks like we are comming towards some concensus on the M1 release. > If there are no objections, I will cut a release candidate first thing > tomorrow morning. > > I would also like to propose an informal code freeze, so as to not rock > the boat by checking in any significant changes. > From now on until we cut the final release only critical bug fixes or > infrastrucutre details (license ..etc) should be checked in. In general, locking trunk for any significant amount of time is discouraged. Any of the commiters should be allowed to commit to trunk at any time. If a commiter goes on vacation for month and comes back, they should be able to pick up right where they left off with any stuff they were working on without worry about if a release is locking the trunk or not. If you need control in order to do a release, it is recommended to create a release branch and, as the release manager, selectively merge changes from trunk to the release branch if those commits meet your requirements for your release. No one said being a release manager is an easy job. :-) That all said, I would probably ask (politely) Steve to hold off on merging the maven stuff to trunk for a few days. Those changes are huge and would make other changes hard to merge to your release branch. The httpd project has a very good page describing their processes for the release manager: http://httpd.apache.org/dev/release.html In particular, read the section entitled: "How does an impending release affect development?" Enjoy! Dan > Once we cut the RC, I would expect some through testing to ensure we > want to move towards the M1 release. > I am open to suggestions as to how long we should have the RC around > before we cut the final release. > > Regards, > > Rajith > > On 11/14/06, Martin Ritchie <[EMAIL PROTECTED]> wrote: > > Just before close of day I just wanted to add my 2ยข. > > > > Just picking up from conversations since 5pm. > > > > The only thing that is missing from the head ant build is the > > separate preparation of client zip and tgz. I have the changes ready > > to commit but have not committed them until the M1 situation is > > resolved. > > > > I am very much in favour of releasing now as we are passed a well > > publicised deadline for M1 issues listed in JIRA. I think the idea of > > understanding the release process with this M1 java/python/ruby will > > be very informative and by the time it is done we will be near > > Christmas and have the new persistence model and a fully maven-ized > > truck that will be real value add for our clients/users and be a > > perfect time to M2 the entire project. > > > > I for one have not had much input on the maven branch as I have far > > more experience with ant but the coming weeks of maven-ization of the > > truck will help me understand more and give me time to aid resolving > > any issues that exist. > > > > I would really like to see us all working together as a cohesive > > project, which is what incubation diversity is all about, as I > > understand it. > > > > I think we all value the initial work that Steve has put in to > > getting maven working on the trunk. I just feel it is important for > > the project going forward that we have set goals that are clearly > > defined in JIRAs so that the community can see our direction and we > > can all understand when we are ready for next release. > > > > This will prevent any one party trying to add in new features before > > a release deadline unless the there is a binding vote that says > > otherwise. > > > > This is the only way that I can see to work if graduation from the > > incubator is our goal. > > > > -- > > Martin > > > > On 14/11/06, Robert Greig <[EMAIL PROTECTED]> wrote: > > > On 14/11/06, Steve Vinoski <[EMAIL PROTECTED]> wrote: > > > > I was about to respond with a similar suggestion, but even less > > > > aggressive in terms of features. What we'd like to see is an M2 > > > > starting essentially right away, shortly after Rajith branches > > > > for M1. We'd like to scope M2 to include maven, along with a move > > > > to junit3 so as to enhance the effectiveness of maven and enforce > > > > the jdk 1.4 constraint for client. > > > > > > What kind of timescale do you think is realistic for M2? My only > > > issue with the above is that it does not offer anything in the way > > > of extra functionality for our users so if due to the overhead of > > > the Apache release process that took a while we would be spending > > > time on admin etc. > > > > > > It's tangential to this discussion but for jdk 1.4 support IIRC > > > there was discussion about use of Retroweaver. I believe it would > > > actually be nice to further consolidate broker and client code > > > (there is stuff that is basically duplication) and that implies 1.5 > > > source. > > > > > > > What would specifically *not* be in M2, however, would be a move > > > > to the new rev of AMQP -- we'd push that off to M3 (note BTW that > > > > this requires going through JIRA to move all relevant issues > > > > related to AMQP version from M2 to M3). > > > > > > Yes, agreed. > > > > > > > Whether persistence and JMS could be in the picture, I hadn't > > > > considered. I don't know how close persistence is, nor how much > > > > work the JMS stuff is, but we can certainly talk about that. > > > > > > I will be able to give a better indication later this week on how I > > > think persistence is going (I think it's going well but wouldn't > > > want to state anything categorical until I had joined up all the > > > dots, and got some feedback from someone else). > > > > > > RG -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727 C: 508-380-7194 F:781-902-8001 [EMAIL PROTECTED]
