Jeffrey Blattman wrote:
i had a rather large change recently where it would have made my
professional life much easier if i had committed it to 3.0 (vs. the
trunk and 3.1). that was about a month ago, and 3.0 was at RC 1. now i
(the professional "i") am up the creek if roller 3.1 doesn't release
sometime in the near future.
but that's my problem, and i only brought it up because i *think* it's
an example of the way things should work. a less aggressive approach to
feature addition make sense. developers shouldn't worry about the
release number. work on features, and whatever release they fall into
depends on when they are complete. we shouldn't be targeting features
for a particular release.
I agree with this for the most part, but the timing of feature additions
and releases has to be in sync to some degree. I definitely agree that
we want people focusing on the work itself and not what release it goes
into, but at the same time, if a body of work is reasonable in size or
has enough commitment to ensure that it will be finished before any new
software release then I think it's okay to assume that feature will be
part of the next release.
the problem is when features are worked on the trunk. then they are
forcefully committed to the next release. which is why it makes sense to
use the sandbox model for feature dev. in my professional life, we do
the same thing, except that we actually create CVS branches for feature
dev, and merge back into the trunk only when the feature is release
ready (well, that's how it works in theory).
This seems like a double edged sword though. If all features are worked
on in branches then we lose some ability to collaborate. Obviously, at
the same time, if someone is going to work on something that would make
the trunk unstable for a while then that's not good either.
So in my mind the answer is to just solve each situation as it happens.
I think that in general we want people working out of the trunk as
much as possible, and when it makes sense then we can have people move
into a branch on their own.
-- Allen
Elias Torres wrote:
I've been with Roller for sometime now but it is until recently that I
have been working closely with to the development lifecycle. At the end
of 3.0 we submitted proposals for working on 3.1 and those got approved
so we are making plans based on those proposals and dates estimates.
However, there have been a couple or more proposals that appear last
minute before code freeze and get submitted/implemented. I'm just trying
to figure out our process and what's good practice and what's not. I'm
not sure how would you feel if I submitted a few proposals this week on
behalf of IBM's needs as opposed to waiting for 3.2. I'm not saying that
we can't work like this, but I'm trying to understand what is acceptable
or not to this community. I definitely don't want to misbehave in the
friendly/cooperative environment we have today.
As I look into the future of IBM and Roller I'm not sure we'll have tons
of proposals closely tied to the schedule because we won't be able to
keep up with Roller's short lifecycle. Our direction is going to be more
like: get a feature implemented in whichever release it happens to fall
under and we backport it to our internal version until we make the jump
to let's say 4.0.
-Elias
