axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeremy Hughes" <>
Subject Re: [VOTE/WSIF] 2.0 release branch (WSIF_2_0_BRANCH)
Date Mon, 20 Jan 2003 20:13:56 GMT
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

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 ... see release
 ... 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

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.

----- Original Message -----
From: "Nirmal Mukhi" <>
To: <>
Sent: Monday, January 20, 2003 4:57 PM
Subject: Re: [WSIF] 2.0 release branch (WSIF_2_0_BRANCH)


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.


"Anthony Elder" <>
01/20/2003 11:16 AM
Please respond to axis-dev

        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
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
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.


Anthony Elder
Web Services Development
IBM UK Laboratories,  Hursley Park
(+44) 01962 818320, x248320, MP208.

"Jeremy Hughes" <> on 20/01/2003 15:57:51

Please respond to

To:    "axis-dev list" <>
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
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
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
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
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
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
+1 to b)

Thanks and regards,

----- Original Message -----
From: "Aleksander Slominski" <>
To: <>
Sent: Saturday, January 18, 2003 1:33 AM
Subject: 2.0 release branch (WSIF_2_0_BRANCH)


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.



"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.

View raw message