I agree as well, the vote was releasing Yoko in total. I think that
in the future, we should cut the release and vote on that so that
there is no confusion as to what we're voting on.
Regards,
Alan
On Feb 20, 2007, at 8:45 AM, Vescovi, Matteo wrote:
Hi,
That was my understanding too.
My vote was in favour of creating a milestone release of all modules.
Creating a release with all modules should also require less time
than cutting a new trimmed down release (i.e. once we sort out the
tagging of our CXF dependency, we're pretty much done and we can
call for a vote).
- Matteo
Nolan, Edell wrote:
Hi,
I was under the impression when I voted for the M2 release it was
for a
full release of all modules of Yoko. Was I correct in my assumption ?
Balaji the option of tagging CXF and making a yoko release on top of
this tagged version seems like a good solution to me.
Cheers, Edell.
-----Original Message-----
From: Mosur Ravi, Balaji [mailto:[EMAIL PROTECTED] Sent: 20 February
2007 16:15
To: yoko-dev@incubator.apache.org
Subject: RE: Rules for a release vote.
I think in another discussion, there was a talk about not
releasing yoko
with just the ORB. (I don't think we reached any consensus!!!)
So can we work on the option of tagging a version of CXF for out next
release?
This might be some work but I think it would solve both the issues.
- Putting out a release for Geronimo
- Not splitting up yoko just for the sake of a release.
- Balaji
-----Original Message-----
From: David Jencks [mailto:[EMAIL PROTECTED]
Sent: Monday, February 19, 2007 1:54 PM
To: yoko-dev@incubator.apache.org
Subject: Re: Rules for a release vote.
On Feb 19, 2007, at 10:17 AM, Daniel Kulp wrote:
On Monday 19 February 2007 12:02, David Jencks wrote:
A couple quick comments
-- I recall some incubating project (activemq?) being told that
they
could start release votes for themselves and the incubator
simultaneously, thus having both 72 hr waits run concurrently.
Yea. However, IMO, that didn't work very well. There was some
confusion as
to where the votes went. There were IPMC members that didn't vote
specifically because they didn't want their vote influencing the
PPMC votes.
(they want the PPMC to function by themselves as much as
possible) Etc...
I wouldn't recommend going that route unless it's somewhat of an
emergency
(security patch or similar). The "cleanest" route is the Yoko
PPMC gets it
ready to their satisfaction and the IPMC then validates it.
That makes a lot of sense :-)
-- I'm really worried about the cxf snapshot dependency. IMO we
absolutely need to avoid releasing yoko bits that depend on cxf or
get something stable from cxf that we can release against. If the
bits of cxf yoko needs are actually quite stable and basically done
then perhaps cxf could make a milestone release of those bits.
Otherwise I don't think we should be releasing something that
depends
on code we know is unstable.
Well, from the CXF teams standpoint, there isn't a way we would
release a
milestone based on the latest code. There are things that are
in major flux
right now. Actually, I think some stuff that was committed on
Friday/Saturday may have broken Yoko. Not sure yet, but I'm
not going to
deploy another CXF snapshot until I double check.
Thus, the options are really:
1) CXF team tags, builds, and deploys a snapshot based on a
specific SVN
version number. 2.0-incubator-509280-SNAPSHOT for example.
2) Yoko team pretty much does that instead of CXF.
3) Create a "coreorb" or "embedded" assembly. I was talking to
Balaji about
this on Friday. Basically, in distribution, have
an "yoko-incubating-M2-embedded.tar.gz" thing along with the
current full
source/bin builds. This may make sense long term anyway. For
this
release, ONLY release the embedded stuff. (basically, deploy to
a staging
area, then delete all the stuff you aren't planning on releasing
before the
votes) In the future (1.0 or M3), when things stabilize,
everything would be
released together, both the embedded versions and the full versions.
How about "embedded" and "full" profiles and we run the mvn
release plugin on the "embedded" profile?
btw is yoko using mvn 2.0.5 yet?
thanks
david jencks
Dan
thanks
david jencks
On Feb 19, 2007, at 7:32 AM, Daniel Kulp wrote:
On Monday 19 February 2007 06:35, Rick McGuire wrote:
I'm not sure I've got the terminology correct here, but what
are the
voting rules for an incubating project to cut a release. What
are
the
binding votes required for the vote to pass (i.e, do we need
to nudge
the project mentors to vote on this)?
From my understanding, this is what will need to be done:
1) Get some sort of tagged/reproducable snapshot of CXF. This
can
be done
one of two ways:
a) you can tag (svn cp) the cxf version into your own tags dir,
modify the
version numbers, and build/deploy a snapshot from there.
b) convince a cxf developer to do it from their tree. I could
possibly do
this late tomorrow if need be.
The important thing is to get a version that is known and
reproducable. I'd
suggest a version with the SVN number in the version number.
2) Tag your own codebase, update version numbers, etc... (since
you
depend on
snapshots, you cannot use the mvn release plugin) Build and
deploy to a
staging area. (/home/user/public_html/yoko_m2 on people or
similar) One
note: don't deploy javadocs jars. (or rm them before the vote)
With your
setup, those jars don't have the required NOTICE/LICENSE/
DISCLAIMER
in them
so they aren't releasable. If you wait another 3 or 4 days,
that
will be
fixable.
3) Call a vote on that here. Wait 72 hours.
4) Call a vote on [EMAIL PROTECTED] Wait at least 72 hours. This was a
major
holdup last time. Once you call a vote, I'd start asking the
Harmony and
Geronimo folks that are on the IPMC to get a in vote asap. You
need the 3
+1's.
Anyway, if you start right now, at a minimum, that's 6 days before
a release.
More likely: 8-10 days.
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
[EMAIL PROTECTED]
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
[EMAIL PROTECTED]
