Hi Nirmal, On your first point, I agree with you, changes after RC1 *were* allowed. Before we declare a code freeze we really should vote on when that code freeze takes effect from, then no committer will have excuses for posting fixes after that. A key part of that discussion would be what fixes should be done before the code freeze ... I think that's the key discussion we haven't had.
On your second point, I've been trawling through emails but can't find any annoucement from Alek or anyone of a code freeze. I agree, one is needed, so given that our mode of operation for post-RC1 was to submit bug fixes relatively unchecked, I think we need agreement that we change that mode of operation for post-RC2. And I think we should work like that after the discussion to determine which bugs fixes people really fell strongly enough about that they get fixed before final release. When do we stop making bug-fix commits? well that is something we need to have agreed amongst the committers ... agreement which I don't feel we yet have. I agree with you ... we do have (more than) a *fairly stable* product and I think we are very nearly there ... we do need to be inclusive of all our committers, different committers have different views of what is important and we need to make sure they get the opportunity to say what's important before the code freeze even if their views could get out-voted. Alek, Hi ... hope are having a good trip to Poland. It sounds like you have RC2 ready to go. To get through this phase may I propose you post it then we as committers take a vote: [VOTE] whether to freeze the code at the RC2 level (votes are by majority approval as in http://httpd.apache.org/dev/guidelines.html ... see release testing) ... if that is *yes* then we have ourselves a final 2.0 build! ... if *no* then we need the list of bugzillas that must get fixed before an RC3 If we go to an RC3 we should consider whether: [VOTE] RC3 uses trunk or WSIF_2_0_BRANCH ... this may depend on what bugzillas have been fixed in the trunk since the WSIF_2_0_BRANCH was spawned. This supercedes the previous vote which didn't take account of the fact Alek has an RC2 ready to go. Judging from the feeling amongst all committers I hope this means everyone feels they have the opportunity to put their point of view forward. If you feel I've missed something please speak up. I'll be voting after taking a look at the RC2. Thanks and happy RC2 testing. Jeremy ----- Original Message ----- From: "Nirmal Mukhi" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, January 20, 2003 4:57 PM Subject: Re: [WSIF] 2.0 release branch (WSIF_2_0_BRANCH) Hi, Just a couple of points I'd like to make. 1. The emails below make it sound like there were no code changes allowed after the RC1, when in fact the RC1 was cut four weeks ago and we have had new samples, new J2C stuff, new bug fixes, etc. So it's not like we agreed on allowing changes and then Alek went back on that. 2. There *has to be* a code freeze *some time* prior to a release. In the chat last week it was agreed that we would release at the end of this week. Given that I don't think it is unreasonable for Alek to announce a code freeze one week prior to that. Sure we didn't vote on when the code freeze would begin. In my view we have entrusted Alek to drive the release and we have to give him some leeway, not subject every single decision he makes to a vote. Moreover, when he realised that useful bug fixes are coming in (despite his asking for a code freeze), he decided to branch the code and cut a release there, then merge with the main branch after, which I think is perfectly reasonable. Why is it essential for the bug fixes being made now to go into the release? Were they cleared with the release manager? Were they in the release plans? We agreed on allowing bug fixes and other changes during the RCs (which we did do), but you have to realise you can't commit a bug fix a few days prior to a major release. When do we stop allowing such commits? A day before the release? Two hours before? Or should the two not have any correlation, i.e. keep making fixes and at some predecided time have Alek just cut the final release? I don't understand why we are making a big thing out of some bug fixes. Why are they so critical to the release? We have a great *fairly stable* product, support for so many protocols and backends...why shouldn't you want to release this right away? We've completed the release tasks we planned - improved docs, usability, etc. If you decide some bug fixes are worth moving the prior, agreed release date then when do we stop? Do you think we'll ever have a bug free product? Alek has posted the release and was going to make an announcement pending some testing on Windows. The RC2 was delayed because he had bandwidth problems from Poland; I was away at a conference so I couldn't help. Ant, did you try contacting Alek and offer help so that the RC2 wouldn't get delayed? This is a community process. It's not Alek's release, it is our's. Let's think with cool heads and commit to having a successful product, not cling to petty issues. Nirmal. "Anthony Elder" <[EMAIL PROTECTED]> 01/20/2003 11:16 AM Please respond to axis-dev To: [EMAIL PROTECTED] cc: Subject: Re: [WSIF] 2.0 release branch (WSIF_2_0_BRANCH) I agree. There has never been any discussion on a code freeze, the only reason people voted +1 to having and RC1 instead of a Beta2 was on the explicit understanding that we could continue making changes for now. Given this I really feel point A in the vote before is unwarranted but in the sake of compromise I'll vote +1 to it on the understanding that we keep making it easy to get changes till at least RC2. I'll post a list of the bugs I'd like included shortly. This list may not be complete as obviously as people doing testing discover new bugs new bugzillas may need to be added to the list. I vote +1 to point B below, we've already missed the planned RC2 date of last Tuesday so lets get these last bugzillas fixed this week and have an RC2 then (probably by this weekend?). There's also the changes to the build that we've already agreed should happen which I'd like that to happen this week, so it would good to for that to also be in RC2. ...ant Anthony Elder [EMAIL PROTECTED] Web Services Development IBM UK Laboratories, Hursley Park (+44) 01962 818320, x248320, MP208. "Jeremy Hughes" <[EMAIL PROTECTED]> on 20/01/2003 15:57:51 Please respond to [EMAIL PROTECTED] To: "axis-dev list" <[EMAIL PROTECTED]> cc: Subject: Re: [WSIF] 2.0 release branch (WSIF_2_0_BRANCH) Hi Alek, I'm curious as to why you've branched the code here. I would have expected the final release for 2.0 be point in time on the trunk, so at a later date anyone can get this tagged level off the trunk and don't have to search around a branch to find that level. On creating the WSIF_2_0_BRANCH, as you say, you've backed out the fix to bugzilla #16196. You say this is a big change, but we haven't actually agreed to a code freeze yet - changes to code since RC1 are allowed and this was agreed by you (and other committers) on an IRC chat: [10:47] <antElder> so if theres an RC1 can I continue with changes? [10:48] <piotrp> That's my assumption, all the bug fixes have to go in [10:48] <alek_s> Anr: yes if it is RC you cancontinue with changessuch as bug fixes ... [10:51] <piotrp> provided we can still put in changes... [10:51] <alek_s> thwew was 4x +1, one +0 [10:51] <piotrp> provided we can still put in changes... [10:51] <antElder> well some of those +1 WAS TO EITHER [11:02] <piotrp> +1 to RC1 provided changes are possible after Jan 6th [11:03] <Hesham> u took the words right out of my mouth Piotr :) [11:04] <alek_s> (chnages are always possible and even required I really feel we should have a discussion on the mailing list before backing out another committer's change. Also, lets have the discussion on when we should freeze the code ... essentially which bugzillas need to be fixed before we have an RC2. I feel then if there are no major new bugzillas straight after that we should make that the final 2.0 build. In summary, I propose this as a way forward (votes, comments please): a) committers who feel a currently open bugzilla should be fixed before RC2 build say so now. Together we'll figure out which will get done. b) after this set of bugzillas has been fixed, use the CVS trunk to generate the RC2 which will include bugzilla fix # (this will help CVS users find and extract the correct level of files used for the RC2 and final build of 2.0) ... lets discuss and vote on this BTW: I vote: +1 on a) & propose bugzilla #16196 (already fixed and passes unit test bucket) +1 to b) Thanks and regards, Jeremy ----- Original Message ----- From: "Aleksander Slominski" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, January 18, 2003 1:33 AM Subject: 2.0 release branch (WSIF_2_0_BRANCH) hi, to minimize impact of last minute changes i have created WSIF_2_0_BRANCH to host the first official 2.0 release of WSIF outside the main trunk. in this branch i have backed up last changes concerning caching of WSIFOperations as i think this is not good idea to make such big changes just a week before scheduled release (as agreed upon by everybody and recorded in release plan/schedule). please keep committing remaining changes related to this release into this branch. i have just modified this branch to compile j2c sample (J2EE 1.3.1 is required) and fixed problem with not copying WSDL extension documentation in distribution zip/tarballs. thanks, alek -- "Mr. Pauli, we in the audience are all agreed that your theory is crazy. What divides us is whether it is crazy enough to be true." Niels H. D. Bohr
