You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by "Alan D. Cabrera" <li...@toolazydogs.com> on 2006/01/05 19:22:30 UTC
Geronimo 2.0
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
It's my understading that we're going for JEE 5. I think that our
re-arch of security should go into that as well.
How do we want to stage this effort in terms of SVN organization? When
should we cut a 2.0 development branch?
Regards,
Alan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFDvWPm1xC6qnMLUpYRAmQWAJ0eCHtNjhMH/IO4+LtNR3sUaLTmNgCfZ0YU
aTEL53hKe+hA9qF54wt3yWI=
=UMhP
-----END PGP SIGNATURE-----
Re: Geronimo 2.0
Posted by Jacek Laskowski <el...@gmail.com>.
2006/1/11, Greg Wilkins <gr...@mortbay.com>:
> Alan D. Cabrera wrote:
> > It's my understading that we're going for JEE 5. I think that our
> > re-arch of security should go into that as well.
> >
> > How do we want to stage this effort in terms of SVN organization? When
> > should we cut a 2.0 development branch?
>
>
> Did we decide anything here?
Hi Greg,
I'd say 'yes'. I think Dave B. summed it up nicely:
"We need to follow through on Geronimo 1.x for a few release cycles,
get some user feedback, learn the lessons we need to learn for a
while, *then* start Geronimo 2.0."
with a comment by Jason:
"the trunk should be used for feature development for 1.1"
and then Dave B again:
"All that said, I do think it's a positive thing to explore JEE 5 and
experiment with ideas. I just think we need to be absolutely sure
that it doesn't overshadow 1.x."
So, branch the trunk and move on. When you're done, it will be merged
with the trunk. Does it sound good?
> Where/How can I start playing with Jetty 6 and servlet 2.5 in geronimo?
I can't answer the question, but wonder what you miss before moving
on? I think that the deployers would certainly have to be "enhanced"
to accept 2.5 deployment descriptors.
Jacek
Re: Geronimo 2.0
Posted by Greg Wilkins <gr...@mortbay.com>.
Alan D. Cabrera wrote:
> It's my understading that we're going for JEE 5. I think that our
> re-arch of security should go into that as well.
>
> How do we want to stage this effort in terms of SVN organization? When
> should we cut a 2.0 development branch?
Did we decide anything here?
Where/How can I start playing with Jetty 6 and servlet 2.5 in geronimo?
cheers
Re: Geronimo 2.0
Posted by "Kresten Krab Thorup (Trifork)" <kr...@trifork.com>.
I think that doing new development on the HEAD is the way to go, i.e.
2.0 development should happen here. Then what goes on the 1.x branch
(es) is maintenance and bug fixing. This will certainly serve to
stabilize (and perhaps even stall) development on 1.x; but that is
not a bad thing. Users will experience that 1.x releases are "more
compatible" in many ways because all the creative big changes happen
elsewhere.
Kresten Krab Thorup
krab@trifork.com
On Jan 6, 2006, at 1:28 AM, Alan D. Cabrera wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Bruce Snyder wrote, On 1/5/2006 4:26 PM:
>> On 1/5/06, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>>
>>
>>>>> How do we want to stage this effort in terms of SVN
>>>>> organization? When
>>>>> should we cut a 2.0 development branch?
>>>>
>>>>
>>>> I suppose that the JEE 5 work would be best suited to a 2.0 branch.
>>>> That means that there is a potential to have to do a lot of double
>>>> work. What I mean to say is that any new innovations being
>>>> committed
>>>> to the HEAD will need to be refactored and committed to the 2.0
>>>> branch. And this work will increase more with the addition of more
>>>> branches (e.g., 1.1, 1.2, etc.).
>>>
>>> You touched on the concern that I had. I'm thinking that once we
>>> cut
>>> this, there will be no further work on 1.x, because everyone will
>>> want
>>> to work on 2.x.
>>
>>
>> Then we should probably consider making a decision that the HEAD
>> should contain 2.x work only. If any fixes need to be done to the 1.x
>> code then proper branching and tagging should occur to facilitate
>> that
>> work.
>
> Good point. What do others think?
>
>
> Regards,
> Alan
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2 (MingW32)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
> iD8DBQFDvbmY1xC6qnMLUpYRAsEZAJ4hKUKXBCTxkTQfPMXGOr3w1LswAQCbBtpt
> 0ThTQUdCzTdCaaapV71OgZ8=
> =L4zh
> -----END PGP SIGNATURE-----
>
Re: Geronimo 2.0
Posted by Jacek Laskowski <el...@gmail.com>.
2006/1/6, Alan D. Cabrera <li...@toolazydogs.com>:
> Bruce Snyder wrote, On 1/5/2006 4:26 PM:
> > Then we should probably consider making a decision that the HEAD
> > should contain 2.x work only. If any fixes need to be done to the 1.x
> > code then proper branching and tagging should occur to facilitate that
> > work.
>
> Good point. What do others think?
Hi,
That's exactly what I had already proposed in my previous response.
There's no need to complicate things unless some need arises. I
remember when Alan stated that patches will be applied to a branch and
would eventually end up as 1.0.1 or 1.1 and on. I think HEAD should
always reflect the state of the main releases of Apache Geronimo, i.e.
Apache Geronimo 2.0, 3.0 and on. The numbers after the dots would be
in branches.
> Alan
Jacek
Re: Geronimo 2.0
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Bruce Snyder wrote, On 1/5/2006 4:26 PM:
> On 1/5/06, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>
>
>>>>How do we want to stage this effort in terms of SVN organization? When
>>>>should we cut a 2.0 development branch?
>>>
>>>
>>>I suppose that the JEE 5 work would be best suited to a 2.0 branch.
>>>That means that there is a potential to have to do a lot of double
>>>work. What I mean to say is that any new innovations being committed
>>>to the HEAD will need to be refactored and committed to the 2.0
>>>branch. And this work will increase more with the addition of more
>>>branches (e.g., 1.1, 1.2, etc.).
>>
>>You touched on the concern that I had. I'm thinking that once we cut
>>this, there will be no further work on 1.x, because everyone will want
>>to work on 2.x.
>
>
> Then we should probably consider making a decision that the HEAD
> should contain 2.x work only. If any fixes need to be done to the 1.x
> code then proper branching and tagging should occur to facilitate that
> work.
Good point. What do others think?
Regards,
Alan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFDvbmY1xC6qnMLUpYRAsEZAJ4hKUKXBCTxkTQfPMXGOr3w1LswAQCbBtpt
0ThTQUdCzTdCaaapV71OgZ8=
=L4zh
-----END PGP SIGNATURE-----
Re: Geronimo 2.0
Posted by Jacek Laskowski <el...@gmail.com>.
2006/1/6, David Jencks <da...@yahoo.com>:
> Either I don't understand what is being proposed or I think it is a
> recipe for disaster.
Hi Dave,
I think there might be the third option ;)
> My past experience with open source projects leads me to believe that
> having more than one main development area that is leading to a
> release is likely to cause only confusion, not progress towards
> functionality.
Well, the more branches we will have the more headaches it will cause
to us. I think that's totally unavoidable when moving towards JEE 5
where Java 5 plays a crucial role.
> In my opinion if we call head 2.0 and start adding JEE 5 features to
> it, there will never be any more j2ee 1.4 releases with added
> functionality. We will have a couple bug fix 1.0 releases, then a
> year or so while we try to finish JEE 5. I don't think this is
> acceptable.
Correct.
> I would like to propose a process by which disruptive new feature
> development occurs in separate subprojects or feature-specific
> branches that can be merged into trunk when feature complete and stable.
That's exactly what was said. Noone suggested to work on HEAD and
eventually breaks it for weeks. I think one of the reason we switched
to svn was the simplicity to create and merge a branch. We can
therefore easily experiment in our own branches, but that contradicts
what you said above with "more than one main development area". It's
unavoidable in such a large project to have only "one main development
area". There's going to be lots of branches, imho.
As far as EJB 3 is concerned it shouldn't be a big deal. It will be
implemented by OpenEJB which is a separate project so appropriate
interfaces should do the work nicely. The real pain will be with the
other modules that will require separate branches and be merged once
finished.
> I realize there are some significant problems with this as regards
> JEE 5, at least as far as jdk support level, in that JEE 5 requires
> use of jdk 1.4 incompatible code. Personally I don't have enough
> information about how hard it is to convert to generics to begin to
> guess what these problems might be. It would also be useful to know
> more about e.g. whether retrotranslator might actually work.
I don't understand. Why are you scared of using Java 5? Geronimo 1.0
is on its own branch, and anybody who wants to play with the source
code will download that branch. Others who want to be on the cutting
edge will work with HEAD. Problems will have to be sorted out for
sure, but Geronimo 1.0 is safe and so are their minor descendants
(i.e. 1.x.x versions).
> I think in order to consider this realistically we need a list of
> features we plan to add and to decide for each one of them whether it
> requires jdk 1.5 support and whether it can fit into "1.0". For
> instance I think the proposed security improvements could fit into
> 1.0 written in jdk 1.4.
But that wouldn't be 1.0 any more, but a branch called 1.0.x or 1.x.
Weren't you worried about having more than one main development area?
Aren't you proposing just that?
> At this point, I think we should label head 1.1-SNAPSHOT and work on
> any features that require 1.5 in one or more branches, labelled by
> feature.
That's acceptable, but how long do you envision HEAD will survive
before migrating to Java 5? Why don't you want to start using Java 5
right away? I don't remember who was it (possibly Dain) who expressed
so much enthusiasm about using Java Generics and I really think it
will save us a lot of time when developing with Java 5 instead of
writing code that will be a nightmare to support. Ok, maybe it won't
be a nightmare, but the additional code to support Java 1.4 will add
unnecessary burden.
> I also think we need to decide on and publish criteria for including
> bug fixes in 1.0.1, and indeed if we want to release a 1.0.1 or just
> go for 1.1.
That's an interesting matter. What changes make 1.x and what does
1.0.x? Anyone could comment on it. I think the security issue of Jetty
asks for 1.0.x.
> david jencks
Jacek
Re: Geronimo 2.0
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
Once I finish the suddenly-urgent mountain of book work, I have a lot
more console and management stuff to work on. There's no reason that
has to wait for a rewritten CORBA stack, EJB3 container, security
stack, etc., much less all the new specs and JSRs. So I certainly
plan to contribute to a 1.1 release. (I'm not sure whether new
Jetspeed/Pluto integration would fit into 1.1 or 2.0, though 1.1 would
be nice.)
I'd prefer to see us draw up as much of a feature list as we can for
1.1 and 2.0, and then based on those think about where we want to put
things and how we branch. That may also suggest a time frame for
each.
Aaron
On 1/6/06, David Jencks <da...@yahoo.com> wrote:
> Either I don't understand what is being proposed or I think it is a
> recipe for disaster.
>
> My past experience with open source projects leads me to believe that
> having more than one main development area that is leading to a
> release is likely to cause only confusion, not progress towards
> functionality.
>
> In my opinion if we call head 2.0 and start adding JEE 5 features to
> it, there will never be any more j2ee 1.4 releases with added
> functionality. We will have a couple bug fix 1.0 releases, then a
> year or so while we try to finish JEE 5. I don't think this is
> acceptable.
>
> I would like to propose a process by which disruptive new feature
> development occurs in separate subprojects or feature-specific
> branches that can be merged into trunk when feature complete and stable.
>
> I realize there are some significant problems with this as regards
> JEE 5, at least as far as jdk support level, in that JEE 5 requires
> use of jdk 1.4 incompatible code. Personally I don't have enough
> information about how hard it is to convert to generics to begin to
> guess what these problems might be. It would also be useful to know
> more about e.g. whether retrotranslator might actually work.
>
> I think in order to consider this realistically we need a list of
> features we plan to add and to decide for each one of them whether it
> requires jdk 1.5 support and whether it can fit into "1.0". For
> instance I think the proposed security improvements could fit into
> 1.0 written in jdk 1.4.
>
> At this point, I think we should label head 1.1-SNAPSHOT and work on
> any features that require 1.5 in one or more branches, labelled by
> feature.
>
> I also think we need to decide on and publish criteria for including
> bug fixes in 1.0.1, and indeed if we want to release a 1.0.1 or just
> go for 1.1.
>
> thanks
> david jencks
>
>
>
> On Jan 6, 2006, at 9:10 AM, Alan D. Cabrera wrote:
>
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Matt Hogstrom wrote, On 1/6/2006 7:07 AM:
> >> I'll summarize what I think I read.
> >>
> >> HEAD will be 2.0 which includes JEE 5 and other significant work
> >> (Maven
> >> 2 conversion, etc.)
> >>
> >> Branches/1.0 will be where the work for 1.0.x will take place. It
> >> would
> >> be from this code base we'd branch to a 1.1 when appropriate.
> >
> > So, we would eventually have 2 branches and 1 trunk:
> >
> > branches/1.0
> > branches/1_trunk
> > tags/*
> > trunk
> >
> >> I'm updating my local copy of the branches/1.0 with a version
> >> change for
> >> Geronimo to 1.0.1-SNAPSHOT as well as updating to Tomcay 5.1.15 and
> >> Jetty 5.1.10 to incoroporate the latent fixes.
> >>
> >> I'll build and test to make sure its still working (I'm not going
> >> to run
> >> TCK). and then commit these changes back when I've confirmed we're
> >> ready
> >> to go for 1.0.1. Does this sound workable?
> >
> > Can we have jira issues assigned to 1.0.1 so that we can see what's
> > coming down the pipeline?
> >
> >
> > Regards,
> > Alan
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.2 (MingW32)
> > Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
> >
> > iD8DBQFDvqSa1xC6qnMLUpYRArhpAJ91d5cSrHGEsY0pG6Jf+Nb+9gNuSgCfR8gH
> > m3qYJWEG9Zej/Sg+O5pMPQA=
> > =goh1
> > -----END PGP SIGNATURE-----
> >
>
>
Re: Geronimo 2.0
Posted by Dain Sundstrom <da...@iq80.com>.
David has a compelling argument...
I am concerned about delivering j2ee 1.4 features and release over
the next year while jee5 is written. I don't want to repeat the
lesson we all learned with the very very long gap between m3 and m4.
With out micro kernel design, don't you think we should be able to
develop most of the jee5 new features in plugin modules or subprojects?
Regaurdless, I have a few features I'd like to put into 1.x to make
transition to 2.x painless, so I will be working on whatever branch
is to become 1.1.
-dain
On Jan 6, 2006, at 11:10 AM, David Jencks wrote:
> Either I don't understand what is being proposed or I think it is a
> recipe for disaster.
>
> My past experience with open source projects leads me to believe
> that having more than one main development area that is leading to
> a release is likely to cause only confusion, not progress towards
> functionality.
>
> In my opinion if we call head 2.0 and start adding JEE 5 features
> to it, there will never be any more j2ee 1.4 releases with added
> functionality. We will have a couple bug fix 1.0 releases, then a
> year or so while we try to finish JEE 5. I don't think this is
> acceptable.
>
> I would like to propose a process by which disruptive new feature
> development occurs in separate subprojects or feature-specific
> branches that can be merged into trunk when feature complete and
> stable.
>
> I realize there are some significant problems with this as regards
> JEE 5, at least as far as jdk support level, in that JEE 5 requires
> use of jdk 1.4 incompatible code. Personally I don't have enough
> information about how hard it is to convert to generics to begin to
> guess what these problems might be. It would also be useful to
> know more about e.g. whether retrotranslator might actually work.
>
> I think in order to consider this realistically we need a list of
> features we plan to add and to decide for each one of them whether
> it requires jdk 1.5 support and whether it can fit into "1.0". For
> instance I think the proposed security improvements could fit into
> 1.0 written in jdk 1.4.
>
> At this point, I think we should label head 1.1-SNAPSHOT and work
> on any features that require 1.5 in one or more branches, labelled
> by feature.
>
> I also think we need to decide on and publish criteria for
> including bug fixes in 1.0.1, and indeed if we want to release a
> 1.0.1 or just go for 1.1.
>
> thanks
> david jencks
>
>
>
> On Jan 6, 2006, at 9:10 AM, Alan D. Cabrera wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Matt Hogstrom wrote, On 1/6/2006 7:07 AM:
>>> I'll summarize what I think I read.
>>>
>>> HEAD will be 2.0 which includes JEE 5 and other significant work
>>> (Maven
>>> 2 conversion, etc.)
>>>
>>> Branches/1.0 will be where the work for 1.0.x will take place.
>>> It would
>>> be from this code base we'd branch to a 1.1 when appropriate.
>>
>> So, we would eventually have 2 branches and 1 trunk:
>>
>> branches/1.0
>> branches/1_trunk
>> tags/*
>> trunk
>>
>>> I'm updating my local copy of the branches/1.0 with a version
>>> change for
>>> Geronimo to 1.0.1-SNAPSHOT as well as updating to Tomcay 5.1.15 and
>>> Jetty 5.1.10 to incoroporate the latent fixes.
>>>
>>> I'll build and test to make sure its still working (I'm not going
>>> to run
>>> TCK). and then commit these changes back when I've confirmed
>>> we're ready
>>> to go for 1.0.1. Does this sound workable?
>>
>> Can we have jira issues assigned to 1.0.1 so that we can see what's
>> coming down the pipeline?
>>
>>
>> Regards,
>> Alan
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.2 (MingW32)
>> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>>
>> iD8DBQFDvqSa1xC6qnMLUpYRArhpAJ91d5cSrHGEsY0pG6Jf+Nb+9gNuSgCfR8gH
>> m3qYJWEG9Zej/Sg+O5pMPQA=
>> =goh1
>> -----END PGP SIGNATURE-----
>>
Re: Geronimo 2.0
Posted by Bill Stoddard <bi...@wstoddard.com>.
David Jencks wrote:
> Either I don't understand what is being proposed or I think it is a
> recipe for disaster.
>
> My past experience with open source projects leads me to believe that
> having more than one main development area that is leading to a release
> is likely to cause only confusion, not progress towards functionality.
>
> In my opinion if we call head 2.0 and start adding JEE 5 features to
> it, there will never be any more j2ee 1.4 releases with added
> functionality. We will have a couple bug fix 1.0 releases, then a year
> or so while we try to finish JEE 5. I don't think this is acceptable.
From my experience working on the Apache HTTP Server, I agree with David.
Bill
Re: Geronimo 2.0
Posted by Greg Wilkins <gr...@mortbay.com>.
Even if we don't think about 2.0, there are two main ways in which we can handle a stable
branch in source control:
1) We can have a 1.0 branch and as new features and bug fixes are tried and tested
in the dev area(s), then these patches are moved to the 1.0 branch as patch sets via
some QA process. This will give us much better control and stability of our released
versions, but it needs effort to control the patches moving into the 1.0 branch.
If we look at the Linux kernel development style, they are very much in this style
with patches coming from multiple development areas and being QA's into the main
kernal branches.
2.0 development would fit nicely in this as it would just be another source of
patches to be QA'd into branches.
2) We can continue development on a trunk and then every time we want to make a release
we copy the trunk to a branch and have a few weeks stabalizing it and then release it.
This is simpler for the developers, but the stability of final releases may suffer as
stuff that your really didn't want will make it's way into releases.
This means that the trunk can never be more than a few weeks away from a release. It
also means that 2.0 cannot be developed in trunk as we can't just copy the whole
blob.
It also means that having multiple dev areas is difficult as there is no
single source to copy a branch from and no culture of merging.
We must decide which of these models we want to go with - regardless of 2.0
development. I think that geronimo is of a size and complexity that we should
consider the overheads of approach 1). Formal compliance issues also push
us towards good QA of all patches to stable releases.
But to do so, we need to develop a culture flowing patch sets through a
QA process. We will need multiple people responsible for controlling patches into
specific subsystems and giving assurances to the main build manager that they
have QA's the patches. These will be tough thankless jobs - maybe we should
see if Linus wants a change from all that C hacking?
cheers
Re: Geronimo 2.0
Posted by Gianny Damour <gi...@optusnet.com.au>.
David Blevins wrote:
>
> On Jan 6, 2006, at 11:10 AM, David Jencks wrote:
>
>> Either I don't understand what is being proposed or I think it is a
>> recipe for disaster.
>>
>> My past experience with open source projects leads me to believe
>> that having more than one main development area that is leading to a
>> release is likely to cause only confusion, not progress towards
>> functionality.
>>
>> In my opinion if we call head 2.0 and start adding JEE 5 features to
>> it, there will never be any more j2ee 1.4 releases with added
>> functionality. We will have a couple bug fix 1.0 releases, then a
>> year or so while we try to finish JEE 5. I don't think this is
>> acceptable.
>>
>
> Amen!
>
> We can't go from two years of development on 1.x with little to no
> user interaction then abandon it after the first release and go back
> into the development hole. We need to follow through on Geronimo 1.x
> for a few release cycles, get some user feedback, learn the lessons
> we need to learn for a while, *then* start Geronimo 2.0.
>
> Now is not the time to turn our focus to the next shinny ball, now is
> the time to focus on users of 1.x as they will need our dedication
> before they can bring it into production.
+1
Also, we need to think about when we need to turn to this next shinny
ball. At this stage, I think that JEE 5 is still a shiny technology and
the mass of the community has not yet started to transition to it.
Hence, we need to support what people want now. Having said that, we
need to be in an acceptable state, WRT JEE 5 features, when the
community will ask for it; this means that we will need to improve the
stack from a user perspective.
Thanks,
Gianny
>
> There is my $0.02.
>
> -David
>
>
>
Re: Geronimo 2.0
Posted by Jacek Laskowski <el...@gmail.com>.
2006/1/7, David Blevins <da...@visi.com>:
> We can't go from two years of development on 1.x with little to no
> user interaction then abandon it after the first release and go back
> into the development hole.
Hi Dave,
Who said we would abandon 1.x? I'm pretty sure noone did. The point I
see is that many of us (if not all) think that 1.1-SNAPSHOT is more
appropriate than 2.0-SNAPSHOT. I don't see any difference, to be
honest. The truth is that we all can live with any version as long as
we know what we need to achieve in the coming releases. I think JEE
1.5 deserves its own 2.0 release whereas smaller functionalities will
go to 1.x releases. AFAIUI, that's what we all agree with. So is mine.
But...if someone have implemented a feature of JEE 5 on a separate
branch, how (s)he should proceed with regard to the trunk? If it
merged with it, will it break our support for 1.0? I don't think so.
Would it lower our willingness to add more features to 1.0? I don't
think so. So, what are we talking about?
I keep wondering what makes me so excited about JEE 5 and arguing
about the versions. I think it's Java 5 that will surely make our
programming life easier. Generics and annotations seem to be so
helpful.
The more I think about 1.1 vs 2.0, though, the more I understand
Daves' point (Dave B and Dave J). The smaller steps we do the better.
That's exactly what DJ had said in his mail and now I got his point
(!) "More than one main development area" is about making smaller
steps in the trunk rather than doing all at once (and end up with
nothing).
Thanks everybody for your time and patience while explaining it to me! ;)
> We need to follow through on Geronimo 1.x
> for a few release cycles, get some user feedback, learn the lessons
> we need to learn for a while, *then* start Geronimo 2.0.
Ok, ok. We'll see how it goes. I'm not suggesting we call the trunk
2.0-SNAPSHOT and stop supporting our users. I can live with
1.1-SNAPSHOT, too.
> Now is not the time to turn our focus to the next shinny ball, now is
> the time to focus on users of 1.x as they will need our dedication
> before they can bring it into production.
Sure. Good point. Users are what make these shinny features
implemented in any product, and so does in Geronimo.
> There is my $0.02.
Add my 0,02 PLN to it ;)
> -David
Jacek
Re: Geronimo 2.0
Posted by David Blevins <da...@visi.com>.
On Jan 8, 2006, at 8:47 AM, Alan D. Cabrera wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> David Blevins wrote, On 1/6/2006 3:24 PM:
>>
>> On Jan 6, 2006, at 11:10 AM, David Jencks wrote:
>>
>>> Either I don't understand what is being proposed or I think it is a
>>> recipe for disaster.
>>>
>>> My past experience with open source projects leads me to believe
>>> that
>>> having more than one main development area that is leading to a
>>> release is likely to cause only confusion, not progress towards
>>> functionality.
>>>
>>> In my opinion if we call head 2.0 and start adding JEE 5
>>> features to
>>> it, there will never be any more j2ee 1.4 releases with added
>>> functionality. We will have a couple bug fix 1.0 releases, then a
>>> year or so while we try to finish JEE 5. I don't think this is
>>> acceptable.
>>>
>>
>> Amen!
>>
>> We can't go from two years of development on 1.x with little to
>> no user
>> interaction then abandon it after the first release and go back into
>> the development hole. We need to follow through on Geronimo 1.x
>> for a
>> few release cycles, get some user feedback, learn the lessons we
>> need
>> to learn for a while, *then* start Geronimo 2.0.
>>
>> Now is not the time to turn our focus to the next shinny ball, now is
>> the time to focus on users of 1.x as they will need our dedication
>> before they can bring it into production.
>
>
> Dave,
>
> I don't think that anyone is advocating the abandonment of 1.x. I
> think
> we are merely acknowledging the fact that a lot of people will want to
> work on, to use your choice of words, the next shinny ball. You can't
> control what people want to work on. We can control how it's done so
> that we can minimized the impact on 1.x branch.
>
> This was the reason for my initial email.
>
I get it, and yes I am shoving words in people's mouths when I say
"abandon." And, yes, it's a pretty fine line.
But there is no way that just some people can start 2.x, meaning:
everyone will feel pressure to get their ideas in before things are
so far along and it's too late; people will be land grabbing to get
their name on their favorite part of the server.
I am pretty hypocritical though from a certain perspective though as
I feel it's critical to get OpenEJB 3 into light asap. But in both
cases, Geronimo and OpenEJB, I am driven by some level of guilt.
In OpenEJB we burned people badly as development on 1.x dried up when
2.x was started. People waited patiently but 2.x never turned out to
be something 1.x users could use. The goal for OpenEJB 3 and the
promise that we've made to our users is that it will be something
they can use.
In Geronimo we've told people so many times for so many months "hold
on", "just wait", "we're almost there." I feel like there was an
unspoken agreement there that it would be "their turn" next to be the
focus of our community and it's our turn to be the patient ones; more
over that if we don't do this, it will be the ultimate of insults to
those that did wait with enduring anticipation at our first major
release.
The bottom line(s) for me is I feel we need to show people that 1.x
is our highest priority for a while if we expect them to make a
serious investment in it (and ultimately, Geronimo). And when I say
our highest priority I don't mean a high priority, I mean a hot-bed
of exciting development and new things.
All that said, I do think it's a positive thing to explore JEE 5 and
experiment with ideas. I just think we need to be absolutely sure
that it doesn't overshadow 1.x.
I don't want to make too big of a stink about this as everything is a
balancing act and somewhere in the middle is commonly the optimal
answer -- I'm sure we can find it if we keep talking -- but there are
warning bells going off in my head at the thought of anything that
might further retard the procurement of users from our fairly large
potential user-base -- by saying that I'm not implying that anyone
with a different perspective doesn't share the same concerns. Just
trying to explain what's rollin' round my head.
-David
Re: Geronimo 2.0
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
David Blevins wrote, On 1/6/2006 3:24 PM:
>
> On Jan 6, 2006, at 11:10 AM, David Jencks wrote:
>
>> Either I don't understand what is being proposed or I think it is a
>> recipe for disaster.
>>
>> My past experience with open source projects leads me to believe that
>> having more than one main development area that is leading to a
>> release is likely to cause only confusion, not progress towards
>> functionality.
>>
>> In my opinion if we call head 2.0 and start adding JEE 5 features to
>> it, there will never be any more j2ee 1.4 releases with added
>> functionality. We will have a couple bug fix 1.0 releases, then a
>> year or so while we try to finish JEE 5. I don't think this is
>> acceptable.
>>
>
> Amen!
>
> We can't go from two years of development on 1.x with little to no user
> interaction then abandon it after the first release and go back into
> the development hole. We need to follow through on Geronimo 1.x for a
> few release cycles, get some user feedback, learn the lessons we need
> to learn for a while, *then* start Geronimo 2.0.
>
> Now is not the time to turn our focus to the next shinny ball, now is
> the time to focus on users of 1.x as they will need our dedication
> before they can bring it into production.
Dave,
I don't think that anyone is advocating the abandonment of 1.x. I think
we are merely acknowledging the fact that a lot of people will want to
work on, to use your choice of words, the next shinny ball. You can't
control what people want to work on. We can control how it's done so
that we can minimized the impact on 1.x branch.
This was the reason for my initial email.
Regards,
Alan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFDwUIZ1xC6qnMLUpYRArSVAJ4wvd7ZbQhqdkuVnsF0lUaI7lByOACeN0Vu
VRh2v9fqbdQWwYlXiFHCHow=
=n376
-----END PGP SIGNATURE-----
Re: Geronimo 2.0
Posted by David Blevins <da...@visi.com>.
On Jan 6, 2006, at 11:10 AM, David Jencks wrote:
> Either I don't understand what is being proposed or I think it is a
> recipe for disaster.
>
> My past experience with open source projects leads me to believe
> that having more than one main development area that is leading to
> a release is likely to cause only confusion, not progress towards
> functionality.
>
> In my opinion if we call head 2.0 and start adding JEE 5 features
> to it, there will never be any more j2ee 1.4 releases with added
> functionality. We will have a couple bug fix 1.0 releases, then a
> year or so while we try to finish JEE 5. I don't think this is
> acceptable.
>
Amen!
We can't go from two years of development on 1.x with little to no
user interaction then abandon it after the first release and go back
into the development hole. We need to follow through on Geronimo 1.x
for a few release cycles, get some user feedback, learn the lessons
we need to learn for a while, *then* start Geronimo 2.0.
Now is not the time to turn our focus to the next shinny ball, now is
the time to focus on users of 1.x as they will need our dedication
before they can bring it into production.
There is my $0.02.
-David
Re: Geronimo 2.0
Posted by Jason Dillon <ja...@planet57.com>.
My $0.02 inline below...
> In my opinion if we call head 2.0 and start adding JEE 5 features
> to it, there will never be any more j2ee 1.4 releases with added
> functionality. We will have a couple bug fix 1.0 releases, then a
> year or so while we try to finish JEE 5. I don't think this is
> acceptable.
I strongly recommend against using 2.0 the trunk if 2.0 is to include
the JEE 5 features. The trunk should always remain as stable
development, as close to the latest supported release as possible.
Unstable features, features that take a long time, or prototypes
should always be implemented on a development/feature branch, never
on the trunk.
> his point, I think we should label head 1.1-SNAPSHOT and work on
> any features that require 1.5 in one or more branches, labelled by
> feature.
I agree completely... but would like to mention that the entire tree
does not need to be branched, you could have a branch for a single
module, or a sub-set of modules. However, this will be much easier
once we've moved to Maven 2.
* * *
I think at this point, the trunk should be used for feature
development for 1.1, perhaps even for staging for a switch to Maven
2... though ideally Maven 2 should be done on a dev branch, but
Subversion is still not the best at automatically merging, so it may
be easier to use the trunk.
Um... and I don't think there is any way to avoid managing several
active dev & release branches. Just keep the required branches
modules to a minimum and it should be manageable.
Anyways, just my opinion... not sure that matters :-P
--jason
Re: Geronimo 2.0
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
David Jencks wrote, On 1/6/2006 11:10 AM:
> Either I don't understand what is being proposed or I think it is a
> recipe for disaster.
>
> My past experience with open source projects leads me to believe that
> having more than one main development area that is leading to a release
> is likely to cause only confusion, not progress towards functionality.
>
> In my opinion if we call head 2.0 and start adding JEE 5 features to
> it, there will never be any more j2ee 1.4 releases with added
> functionality. We will have a couple bug fix 1.0 releases, then a year
> or so while we try to finish JEE 5. I don't think this is acceptable.
>
> I would like to propose a process by which disruptive new feature
> development occurs in separate subprojects or feature-specific branches
> that can be merged into trunk when feature complete and stable.
>
> I realize there are some significant problems with this as regards JEE
> 5, at least as far as jdk support level, in that JEE 5 requires use of
> jdk 1.4 incompatible code. Personally I don't have enough information
> about how hard it is to convert to generics to begin to guess what
> these problems might be. It would also be useful to know more about
> e.g. whether retrotranslator might actually work.
>
> I think in order to consider this realistically we need a list of
> features we plan to add and to decide for each one of them whether it
> requires jdk 1.5 support and whether it can fit into "1.0". For
> instance I think the proposed security improvements could fit into 1.0
> written in jdk 1.4.
>
> At this point, I think we should label head 1.1-SNAPSHOT and work on
> any features that require 1.5 in one or more branches, labelled by
> feature.
Your assumption is that 1.5 features are compact concise changes. The
changes that are required, though, are quite comprehensive. I think we
at least need a single 1.5 branch as well as a 1.4 branch.
> I also think we need to decide on and publish criteria for including
> bug fixes in 1.0.1, and indeed if we want to release a 1.0.1 or just go
> for 1.1.
We need to pump out 1.0.1 ASAP.
Regards,
Alan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFDvsmc1xC6qnMLUpYRAjisAJ4uYVFdWnt8ZR4Ib/a6hAJgMsDBDgCdGZIc
kpoS00XdIBMpN8z5Qsa3Ll4=
=6bQl
-----END PGP SIGNATURE-----
Re: Geronimo 2.0
Posted by David Jencks <da...@yahoo.com>.
Either I don't understand what is being proposed or I think it is a
recipe for disaster.
My past experience with open source projects leads me to believe that
having more than one main development area that is leading to a
release is likely to cause only confusion, not progress towards
functionality.
In my opinion if we call head 2.0 and start adding JEE 5 features to
it, there will never be any more j2ee 1.4 releases with added
functionality. We will have a couple bug fix 1.0 releases, then a
year or so while we try to finish JEE 5. I don't think this is
acceptable.
I would like to propose a process by which disruptive new feature
development occurs in separate subprojects or feature-specific
branches that can be merged into trunk when feature complete and stable.
I realize there are some significant problems with this as regards
JEE 5, at least as far as jdk support level, in that JEE 5 requires
use of jdk 1.4 incompatible code. Personally I don't have enough
information about how hard it is to convert to generics to begin to
guess what these problems might be. It would also be useful to know
more about e.g. whether retrotranslator might actually work.
I think in order to consider this realistically we need a list of
features we plan to add and to decide for each one of them whether it
requires jdk 1.5 support and whether it can fit into "1.0". For
instance I think the proposed security improvements could fit into
1.0 written in jdk 1.4.
At this point, I think we should label head 1.1-SNAPSHOT and work on
any features that require 1.5 in one or more branches, labelled by
feature.
I also think we need to decide on and publish criteria for including
bug fixes in 1.0.1, and indeed if we want to release a 1.0.1 or just
go for 1.1.
thanks
david jencks
On Jan 6, 2006, at 9:10 AM, Alan D. Cabrera wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Matt Hogstrom wrote, On 1/6/2006 7:07 AM:
>> I'll summarize what I think I read.
>>
>> HEAD will be 2.0 which includes JEE 5 and other significant work
>> (Maven
>> 2 conversion, etc.)
>>
>> Branches/1.0 will be where the work for 1.0.x will take place. It
>> would
>> be from this code base we'd branch to a 1.1 when appropriate.
>
> So, we would eventually have 2 branches and 1 trunk:
>
> branches/1.0
> branches/1_trunk
> tags/*
> trunk
>
>> I'm updating my local copy of the branches/1.0 with a version
>> change for
>> Geronimo to 1.0.1-SNAPSHOT as well as updating to Tomcay 5.1.15 and
>> Jetty 5.1.10 to incoroporate the latent fixes.
>>
>> I'll build and test to make sure its still working (I'm not going
>> to run
>> TCK). and then commit these changes back when I've confirmed we're
>> ready
>> to go for 1.0.1. Does this sound workable?
>
> Can we have jira issues assigned to 1.0.1 so that we can see what's
> coming down the pipeline?
>
>
> Regards,
> Alan
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2 (MingW32)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
> iD8DBQFDvqSa1xC6qnMLUpYRArhpAJ91d5cSrHGEsY0pG6Jf+Nb+9gNuSgCfR8gH
> m3qYJWEG9Zej/Sg+O5pMPQA=
> =goh1
> -----END PGP SIGNATURE-----
>
Re: Geronimo 2.0
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Matt Hogstrom wrote, On 1/6/2006 7:07 AM:
> I'll summarize what I think I read.
>
> HEAD will be 2.0 which includes JEE 5 and other significant work (Maven
> 2 conversion, etc.)
>
> Branches/1.0 will be where the work for 1.0.x will take place. It would
> be from this code base we'd branch to a 1.1 when appropriate.
So, we would eventually have 2 branches and 1 trunk:
branches/1.0
branches/1_trunk
tags/*
trunk
> I'm updating my local copy of the branches/1.0 with a version change for
> Geronimo to 1.0.1-SNAPSHOT as well as updating to Tomcay 5.1.15 and
> Jetty 5.1.10 to incoroporate the latent fixes.
>
> I'll build and test to make sure its still working (I'm not going to run
> TCK). and then commit these changes back when I've confirmed we're ready
> to go for 1.0.1. Does this sound workable?
Can we have jira issues assigned to 1.0.1 so that we can see what's
coming down the pipeline?
Regards,
Alan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFDvqSa1xC6qnMLUpYRArhpAJ91d5cSrHGEsY0pG6Jf+Nb+9gNuSgCfR8gH
m3qYJWEG9Zej/Sg+O5pMPQA=
=goh1
-----END PGP SIGNATURE-----
Re: Geronimo 2.0
Posted by Matt Hogstrom <ma...@hogstrom.org>.
Thanks Kevan...I was going to ask about TC as 5.1.15 was not found:)...leaving
at 5.1.9 for now. Other changes in and building now.
Kevan Miller wrote:
>
> On Jan 6, 2006, at 10:07 AM, Matt Hogstrom wrote:
>
>> I'll summarize what I think I read.
>>
>> HEAD will be 2.0 which includes JEE 5 and other significant work
>> (Maven 2 conversion, etc.)
>>
>> Branches/1.0 will be where the work for 1.0.x will take place. It
>> would be from this code base we'd branch to a 1.1 when appropriate.
>>
>> I'm updating my local copy of the branches/1.0 with a version change
>> for Geronimo to 1.0.1-SNAPSHOT as well as updating to Tomcay 5.1.15
>> and Jetty 5.1.10 to incoroporate the latent fixes.
>>
>> I'll build and test to make sure its still working (I'm not going to
>> run TCK). and then commit these changes back when I've confirmed
>> we're ready to go for 1.0.1. Does this sound workable?
>
>
> Matt,
> Tomcat 5.5.15 is stll in Beta. So, I'd hold off just a bit. Preliminary
> tests look good. I'm running a more complete test, now. How about you
> update version and Jetty. I'll cutover Tomcat when appropriate...
> --kevan
>
>
>
Re: Geronimo 2.0
Posted by Matt Hogstrom <ma...@hogstrom.org>.
I agree and do not advocate upgrading releases. However, Jetty I think is a
requirements as there is a security hole. As far as Tomcat is concerned I'll
defer that decision to you :)
Matt
Alan D. Cabrera wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Kevan Miller wrote, On 1/6/2006 8:47 AM:
>
>>On Jan 6, 2006, at 10:07 AM, Matt Hogstrom wrote:
>>
>>
>>>I'll summarize what I think I read.
>>>
>>>HEAD will be 2.0 which includes JEE 5 and other significant work
>>>(Maven 2 conversion, etc.)
>>>
>>>Branches/1.0 will be where the work for 1.0.x will take place. It
>>>would be from this code base we'd branch to a 1.1 when appropriate.
>>>
>>>I'm updating my local copy of the branches/1.0 with a version change
>>>for Geronimo to 1.0.1-SNAPSHOT as well as updating to Tomcay 5.1.15
>>>and Jetty 5.1.10 to incoroporate the latent fixes.
>>>
>>>I'll build and test to make sure its still working (I'm not going to
>>>run TCK). and then commit these changes back when I've confirmed
>>>we're ready to go for 1.0.1. Does this sound workable?
>>
>>
>>Matt,
>>Tomcat 5.5.15 is stll in Beta. So, I'd hold off just a bit. Preliminary
>>tests look good. I'm running a more complete test, now. How about you
>>update version and Jetty. I'll cutover Tomcat when appropriate...
>
>
> Good point Keven. Matt, I think that we should avoid version upgrades
> for a patch release if we can help it.
>
>
> Regards,
> Alan
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2 (MingW32)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
> iD8DBQFDvqTe1xC6qnMLUpYRAuwiAJ0fgGNJpSyxWKop798/EVtM3XLZCgCfQv8J
> QKSjMpmRG4SFbEg052RmpN0=
> =aRfh
> -----END PGP SIGNATURE-----
>
>
>
>
Re: Geronimo 2.0
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Kevan Miller wrote, On 1/6/2006 8:47 AM:
>
> On Jan 6, 2006, at 10:07 AM, Matt Hogstrom wrote:
>
>> I'll summarize what I think I read.
>>
>> HEAD will be 2.0 which includes JEE 5 and other significant work
>> (Maven 2 conversion, etc.)
>>
>> Branches/1.0 will be where the work for 1.0.x will take place. It
>> would be from this code base we'd branch to a 1.1 when appropriate.
>>
>> I'm updating my local copy of the branches/1.0 with a version change
>> for Geronimo to 1.0.1-SNAPSHOT as well as updating to Tomcay 5.1.15
>> and Jetty 5.1.10 to incoroporate the latent fixes.
>>
>> I'll build and test to make sure its still working (I'm not going to
>> run TCK). and then commit these changes back when I've confirmed
>> we're ready to go for 1.0.1. Does this sound workable?
>
>
> Matt,
> Tomcat 5.5.15 is stll in Beta. So, I'd hold off just a bit. Preliminary
> tests look good. I'm running a more complete test, now. How about you
> update version and Jetty. I'll cutover Tomcat when appropriate...
Good point Keven. Matt, I think that we should avoid version upgrades
for a patch release if we can help it.
Regards,
Alan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFDvqTe1xC6qnMLUpYRAuwiAJ0fgGNJpSyxWKop798/EVtM3XLZCgCfQv8J
QKSjMpmRG4SFbEg052RmpN0=
=aRfh
-----END PGP SIGNATURE-----
Re: Geronimo 2.0
Posted by Kevan Miller <ke...@gmail.com>.
On Jan 6, 2006, at 10:07 AM, Matt Hogstrom wrote:
> I'll summarize what I think I read.
>
> HEAD will be 2.0 which includes JEE 5 and other significant work
> (Maven 2 conversion, etc.)
>
> Branches/1.0 will be where the work for 1.0.x will take place. It
> would be from this code base we'd branch to a 1.1 when appropriate.
>
> I'm updating my local copy of the branches/1.0 with a version
> change for Geronimo to 1.0.1-SNAPSHOT as well as updating to Tomcay
> 5.1.15 and Jetty 5.1.10 to incoroporate the latent fixes.
>
> I'll build and test to make sure its still working (I'm not going
> to run TCK). and then commit these changes back when I've confirmed
> we're ready to go for 1.0.1. Does this sound workable?
Matt,
Tomcat 5.5.15 is stll in Beta. So, I'd hold off just a bit.
Preliminary tests look good. I'm running a more complete test, now.
How about you update version and Jetty. I'll cutover Tomcat when
appropriate...
--kevan
Re: Geronimo 2.0
Posted by Jacek Laskowski <el...@gmail.com>.
2006/1/6, Matt Hogstrom <ma...@hogstrom.org>:
> HEAD will be 2.0 which includes JEE 5 and other significant work (Maven 2
> conversion, etc.)
Hi Matt,
That's my understanding, too.
> Branches/1.0 will be where the work for 1.0.x will take place. It would be from
> this code base we'd branch to a 1.1 when appropriate.
+1
> I'm updating my local copy of the branches/1.0 with a version change for
> Geronimo to 1.0.1-SNAPSHOT as well as updating to Tomcay 5.1.15 and Jetty 5.1.10
> to incoroporate the latent fixes.
Excellent! Let us know when it's finished so we could give it a whirl,
esp. those who don't follow scm.
> I'll build and test to make sure its still working (I'm not going to run TCK).
> and then commit these changes back when I've confirmed we're ready to go for
> 1.0.1. Does this sound workable?
I wouldn't have said it better ;) I think we should write it down
somewhere. Any hints on where it ought to be?
On another note, what do others think about creating Grinder (or
another tool) scripts to validate a release? It would likely be
similar to TCK, but unlike TCK anybody could run it.
> Matt
Jacek
Re: Geronimo 2.0
Posted by Matt Hogstrom <ma...@hogstrom.org>.
I'll summarize what I think I read.
HEAD will be 2.0 which includes JEE 5 and other significant work (Maven 2
conversion, etc.)
Branches/1.0 will be where the work for 1.0.x will take place. It would be from
this code base we'd branch to a 1.1 when appropriate.
I'm updating my local copy of the branches/1.0 with a version change for
Geronimo to 1.0.1-SNAPSHOT as well as updating to Tomcay 5.1.15 and Jetty 5.1.10
to incoroporate the latent fixes.
I'll build and test to make sure its still working (I'm not going to run TCK).
and then commit these changes back when I've confirmed we're ready to go for
1.0.1. Does this sound workable?
Matt
Jacek Laskowski wrote:
> 2006/1/6, John Sisson <jr...@gmail.com>:
>
>
>>I agree we don't want too many branches.
>
>
> Hi John,
>
> Well, we should get used to them ;) Especially when Java EE 5 work
> takes off. I think there will be more refactorings than ever before.
> It's going to be lots of fun (sarcasm).
>
>
>>Will fixes for the 1.0.1 release (hopefully we can get out in a few
>>weeks) be committed to the 1.0 branch and then we create another tag for
>>the 1.0.1 release?
>
>
> I'm not too familiar with svn branching/tagging stuff, but AFAIK
> they're just copies of the HEAD. If so, only the disk space limits us
> (which is not the case yet). So, if a need to fix something shows up,
> we will likely have to apply it to HEAD and branch, be it 1.0.1 or 1.1
> depending on its value/importance.
>
>
>>Do we have any guesstimates on when we would have JEE 5 development
>>completed?
>
>
> I'm pretty sure we don't. Why would that be beneficial?
>
>
>>How long it will be before we can deliver a release with some
>>innovations in it, since we previously agreed we want to release
>>frequently?
>
>
> I think we should stick with the 3-months period for small releases
> (like 1.0.1) and 6-months period for larger ones (like 1.1) or even
> the most important (like 2.0, 3.0). That could be our goal, and the
> time will show how we go ;)
>
>
>>If this is going to be a while then we should discuss the work that is
>>planned for the near future and whether there are enhancements that can
>>be delivered in a releases before JEE 5, and if so, how that could be
>>managed.
>
>
> Well, we don't have to wait till JEE 5 development is announced.
> You/anybody can start his/their work on a branch and merge it with the
> HEAD when completed. Of course, the more talk about it the better.
> That's my understanding of how it could (ought to?) work.
>
>
>>Could some of the planned enhancements impact the stability of head
>>development and therefore should be done in a branch? E.G. would we have
>>stability problems doing JEE 5 development, re-arch of security, maven 1
>>to maven 2 migration, xbean support, corba impl etc. all in head?
>
>
> Yes, after having it completed and heavily tested on a branch.
>
> The views are indeed mine and I would appreciate any comments on it
>
>
>>John
>
>
> Jacek
>
>
>
Re: Geronimo 2.0
Posted by Jacek Laskowski <el...@gmail.com>.
2006/1/6, John Sisson <jr...@gmail.com>:
> I agree we don't want too many branches.
Hi John,
Well, we should get used to them ;) Especially when Java EE 5 work
takes off. I think there will be more refactorings than ever before.
It's going to be lots of fun (sarcasm).
> Will fixes for the 1.0.1 release (hopefully we can get out in a few
> weeks) be committed to the 1.0 branch and then we create another tag for
> the 1.0.1 release?
I'm not too familiar with svn branching/tagging stuff, but AFAIK
they're just copies of the HEAD. If so, only the disk space limits us
(which is not the case yet). So, if a need to fix something shows up,
we will likely have to apply it to HEAD and branch, be it 1.0.1 or 1.1
depending on its value/importance.
> Do we have any guesstimates on when we would have JEE 5 development
> completed?
I'm pretty sure we don't. Why would that be beneficial?
> How long it will be before we can deliver a release with some
> innovations in it, since we previously agreed we want to release
> frequently?
I think we should stick with the 3-months period for small releases
(like 1.0.1) and 6-months period for larger ones (like 1.1) or even
the most important (like 2.0, 3.0). That could be our goal, and the
time will show how we go ;)
> If this is going to be a while then we should discuss the work that is
> planned for the near future and whether there are enhancements that can
> be delivered in a releases before JEE 5, and if so, how that could be
> managed.
Well, we don't have to wait till JEE 5 development is announced.
You/anybody can start his/their work on a branch and merge it with the
HEAD when completed. Of course, the more talk about it the better.
That's my understanding of how it could (ought to?) work.
> Could some of the planned enhancements impact the stability of head
> development and therefore should be done in a branch? E.G. would we have
> stability problems doing JEE 5 development, re-arch of security, maven 1
> to maven 2 migration, xbean support, corba impl etc. all in head?
Yes, after having it completed and heavily tested on a branch.
The views are indeed mine and I would appreciate any comments on it
> John
Jacek
Re: Geronimo 2.0
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
John Sisson wrote, On 1/5/2006 7:25 PM:
> Will fixes for the 1.0.1 release (hopefully we can get out in a few
> weeks) be committed to the 1.0 branch and then we create another tag for
> the 1.0.1 release?
Yep.
Regards,
Alan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFDvqNG1xC6qnMLUpYRAqDfAJwLH1KV93WiTR21OX+IutEVTttwmQCeP3Kd
Tyda15+xRLXJIbwW6pXnNPQ=
=LQ8S
-----END PGP SIGNATURE-----
Re: Geronimo 2.0
Posted by John Sisson <jr...@gmail.com>.
Bruce Snyder wrote:
>On 1/5/06, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>
>
>
>>>>How do we want to stage this effort in terms of SVN organization? When
>>>>should we cut a 2.0 development branch?
>>>>
>>>>
>>>I suppose that the JEE 5 work would be best suited to a 2.0 branch.
>>>That means that there is a potential to have to do a lot of double
>>>work. What I mean to say is that any new innovations being committed
>>>to the HEAD will need to be refactored and committed to the 2.0
>>>branch. And this work will increase more with the addition of more
>>>branches (e.g., 1.1, 1.2, etc.).
>>>
>>>
>>You touched on the concern that I had. I'm thinking that once we cut
>>this, there will be no further work on 1.x, because everyone will want
>>to work on 2.x.
>>
>>
>
>Then we should probably consider making a decision that the HEAD
>should contain 2.x work only. If any fixes need to be done to the 1.x
>code then proper branching and tagging should occur to facilitate that
>work.
>
>
>
I agree we don't want too many branches.
Will fixes for the 1.0.1 release (hopefully we can get out in a few
weeks) be committed to the 1.0 branch and then we create another tag for
the 1.0.1 release?
My thoughts..
Do we have any guesstimates on when we would have JEE 5 development
completed?
How long it will be before we can deliver a release with some
innovations in it, since we previously agreed we want to release
frequently?
If this is going to be a while then we should discuss the work that is
planned for the near future and whether there are enhancements that can
be delivered in a releases before JEE 5, and if so, how that could be
managed.
Could some of the planned enhancements impact the stability of head
development and therefore should be done in a branch? E.G. would we have
stability problems doing JEE 5 development, re-arch of security, maven 1
to maven 2 migration, xbean support, corba impl etc. all in head?
John
>Bruce
>--
>perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
>);'
>
>Apache Geronimo (http://geronimo.apache.org/)
>
>
>
Re: Geronimo 2.0
Posted by Bruce Snyder <br...@gmail.com>.
On 1/5/06, Alan D. Cabrera <li...@toolazydogs.com> wrote:
> >>How do we want to stage this effort in terms of SVN organization? When
> >>should we cut a 2.0 development branch?
> >
> >
> > I suppose that the JEE 5 work would be best suited to a 2.0 branch.
> > That means that there is a potential to have to do a lot of double
> > work. What I mean to say is that any new innovations being committed
> > to the HEAD will need to be refactored and committed to the 2.0
> > branch. And this work will increase more with the addition of more
> > branches (e.g., 1.1, 1.2, etc.).
>
> You touched on the concern that I had. I'm thinking that once we cut
> this, there will be no further work on 1.x, because everyone will want
> to work on 2.x.
Then we should probably consider making a decision that the HEAD
should contain 2.x work only. If any fixes need to be done to the 1.x
code then proper branching and tagging should occur to facilitate that
work.
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
Apache Geronimo (http://geronimo.apache.org/)
Re: Geronimo 2.0
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Bruce Snyder wrote, On 1/5/2006 3:43 PM:
> On 1/5/06, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>
>
>>It's my understading that we're going for JEE 5. I think that our
>>re-arch of security should go into that as well.
>
>
> Agreed.
>
>
>>How do we want to stage this effort in terms of SVN organization? When
>>should we cut a 2.0 development branch?
>
>
> I suppose that the JEE 5 work would be best suited to a 2.0 branch.
> That means that there is a potential to have to do a lot of double
> work. What I mean to say is that any new innovations being committed
> to the HEAD will need to be refactored and committed to the 2.0
> branch. And this work will increase more with the addition of more
> branches (e.g., 1.1, 1.2, etc.).
You touched on the concern that I had. I'm thinking that once we cut
this, there will be no further work on 1.x, because everyone will want
to work on 2.x.
Regards,
Alan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFDvba11xC6qnMLUpYRAuAEAJ9c0uQDLeGgIzcqqR/iKv2l99QC5wCdGhVB
foYWLFogfXXWxoMY/OEXtI8=
=zGE8
-----END PGP SIGNATURE-----
Re: Geronimo 2.0
Posted by Bruce Snyder <br...@gmail.com>.
On 1/5/06, Alan D. Cabrera <li...@toolazydogs.com> wrote:
> It's my understading that we're going for JEE 5. I think that our
> re-arch of security should go into that as well.
Agreed.
> How do we want to stage this effort in terms of SVN organization? When
> should we cut a 2.0 development branch?
I suppose that the JEE 5 work would be best suited to a 2.0 branch.
That means that there is a potential to have to do a lot of double
work. What I mean to say is that any new innovations being committed
to the HEAD will need to be refactored and committed to the 2.0
branch. And this work will increase more with the addition of more
branches (e.g., 1.1, 1.2, etc.).
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
Apache Geronimo (http://geronimo.apache.org/)
Re: Geronimo 2.0
Posted by Jacek Laskowski <el...@gmail.com>.
2006/1/5, Alan D. Cabrera <li...@toolazydogs.com>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> It's my understading that we're going for JEE 5. I think that our
> re-arch of security should go into that as well.
>
> How do we want to stage this effort in terms of SVN organization? When
> should we cut a 2.0 development branch?
Hi Alan,
I think there's no point holding it any longer. Since the 1.0 release
is on its own branch, we can safely change all of the build artefacts
to 2.0-SNAPSHOT.
> Alan
Jacek
Re: Geronimo 2.0
Posted by Jeff Genender <jg...@apache.org>.
+1...I really like this idea.
Alan D. Cabrera wrote:
> It's my understading that we're going for JEE 5. I think that our
> re-arch of security should go into that as well.
>
> How do we want to stage this effort in terms of SVN organization? When
> should we cut a 2.0 development branch?
>
>
> Regards,
> Alan
>