Hi all,
I agree we need a code freeze before the release but I think we (the active
committers) need to agree if the time is now. Whilst Thursday has been
mentioned as release day, I don't see the harm in delaying for a short
period to sort out outstanding issues that people have. Obviously we don't
want to continually put back the release but at the same time, I believe we
can and should be flexible. We want a successful product, and I'm sure we'd
all agree that quality plays a part in that. As such I vote +1 to a and b
from Jeremy's note.
Owen.
|---------+---------------------------->
| | Nirmal |
| | Mukhi/Watson/IBM@|
| | IBMUS |
| | |
| | 20/01/2003 16:57 |
| | Please respond to|
| | axis-dev |
| | |
|---------+---------------------------->
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|
|
| To: [EMAIL PROTECTED]
|
| cc:
|
| 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]> To:
[EMAIL PROTECTED]
cc:
01/20/2003 11:16 AM Subject: Re: [WSIF] 2.0
Please respond to axis-dev 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
