Elias Torres wrote:
Dave wrote:
On 3/1/07, Allen Gilliland <[EMAIL PROTECTED]> wrote:
[snip]
Three reasons:
- A branch is additional work
I agree that a branch is a little bit of extra work, but I don't think
it's horrible.
- We're all working on the same thing, i.e. 4.0
- I'm dedicated to actively maintaining the JPA back-end and keeping
it in sync with anything Allen or Elias or anybody else does,
including new manager interfaces and methods.
Problem here is that this can't happen in parallel all the time. What
if I am developing a pretty sizable new feature which requires backend
mods and I'm not going to be ready to commit it for a couple of weeks?
I don't want the various backend impls to be conflicting with my
development space regardless of the fact that I know you are willing to
fix up the JPA side once I commit.
That said, I'm not totally opposed to a branch, but I think we need to
coordinate, sync-up and perhaps better define 4.0 and the time frame.
Maybe we need one, maybe we don't.
agreed, and I think that's basically what we are doing now. From what I
know right now I think that it would be a good idea to put the whole
persistence bake-off backend thing into it's own branch which is
separate from the official 4.0 dev branch. And since I have been doing
work on the JPA impl it means more work for me too and I am willing to
help with it.
I thought that consensus was that Roller 4.0 is these things:
- New backend
I think we voted +1 to that idea, but we still need to vote +1 to the
actual implementation. "new backend" is pretty generic and we need to
keep working to figure out exactly what that means. so far the ideas
have been Datamapper, JPA, and iBatis, and just for completeness sake I
would argue that we should consider the idea that Hibernate would remain
the backend if we can't find a suitable alternative.
I think I've said this before, but my one condition here is that the new
backend has to be better than what we have now or it won't get my vote.
So while I voted +1 to the idea of a new backend, I still plan to vote
again when we see the actual implementations.
- Start of Struts2 migration
- Introduce requirement for JDK 5
- Other features Allen wants?
And Allen and I both wanted to have some stability by late March.
I'm not sure about this consensus, but that's probably because I wasn't
around. I see a 4.0 proposal, but I didn't think that Roller 4.0 was
closed for new proposals.
I'm trying to sync up with 4.0 work we did for Lotus Connections and it
wasn't until now that I'm ready to write proposals and work on them
together with the community.
It's definitely not closed for proposals. I have a few more that I am
doing as well.
However, a month for all that? It seems crazy to me to think that we'll
replace the UI, back-end, new Java version in a month.
I think that time frame is based on our development cycle which has been
such that 3.2 development has basically been done for a while now, so
it's time for 4.0. However, 4.0 is a major release and I don't think we
should rush things. I am actually pretty flexible on the 4.0 timing,
but I think that end of March is a good time to be closing off 4.0 for
new proposals and starting to focus on wrapping up new features and
thinking about stabilization. I don't think that end of March is when
4.0 needs to be code complete though.
I'm guessing Elias could get his features in pretty quicky and late
I'd hope that anything I want to do will not slow you down. But I don't
want to wait til 4.1. Roller is really fast at moving versions, but
slower at releasing them, therefore I need to catch up with your
development schedule not your release schedule.
I don't think that's the case. I think your timing is perfect for 4.0
work and your proposals are right on schedule.
March could still work, but what about JPA stability and what about
iBatis vs. JPA. Do we pick JPA over iBatis just because iBatis isn't
ready by arbitrary date X?
I'd hope not.
My primary goal is having a stable JPA implementation by late March.
I'm willing to be flexible on pretty much everything else.
Whats the new consensus? What do you guys need and by when?
I'm not sure why the topic changed into time frames. What I think Allen
and I were asking was where to do the work? For example I don't know
what you are doing with JPA (e.g. I thought you were ripping everything
out to do a straight JPA, else we are just continuing with our multiple
back-end story). If so, I didn't want to be working with a branch that
had all of that going.
I agree and I think this is another good example of why a persistence
bake-off branch makes the most sense. Then we can add the iBatis
backend in there and use it as part of the comparison for new backends.
I have 2 proposals, plus 3 more coming (Reverse Proxy, Lucene Search
revamping and continue discussing language detection). Everything else
is little bug fixes here and there.
All of those proposals can be worked in w/o a need of a major branch
(the worse would be to break search for a few days or such).
If 4.0 branch is stable enough, then I got my answer: work on branch 4.0
. I don't want to force you to work on a branch unless it's counter
productive to the rest of us.
I think a special branch for the new backend / persistence bake-off
makes the most sense and provides the cleanest approach, so that's what
I vote for.
-- Allen
-Elias
- Dave
