Grzegorz Kossakowski skrev:
Reinhard Poetz pisze:
Daniel Fagerstrom wrote:
If you feel that you can spend some time on the 2.2 release without
endangering your GSoC task, feel free to do that. If not, focus on
your GSoC task.
Although I think that a C22 release would be more than necessary, I
have to agree with Daniel. It's not only you who currently has a more
important goal (GSoC) but others have too - otherwise the release
would be out for months. So don't worry too much.
At the end of August Daniel will evaluate your GSoC work. If you push
forward the final release or the documentation it will be great for
the project in general but (as you certainly know) doesn't have any
relevance for your GSoC evaluation.
I can agree with you both, but you have missed the point, IMHO.
The point is that both I and Reinhard want you to succeed with your GSoC
project. I'm completely assured that you are capable of succeeding. But
as you have become aware of the task isn't trivial. So to succeed you
need focus on tasks that is necessary for your project and wait with all
the rest of the interesting tasks that pops up until later.
Priority and focus is everything for successful projects. The hard thing
is not to choose what to do, but to chose what not to do.
I wanted to work on C2.2 release because current state of things
effectively stops me from continuing my work.
It doesn't ;)
We have already released RC1
so I think that major changes (even internal) should not come into 2.2
final.
In principle yes, but it wouldn't work for Cocoon. Anyway, 99.9% of the
contracts in Cocoon will be unchanged by your work.
Moreover, I'm almost sure that my work will destabilize trunk
from time to time because I've already learned that it's impossible (or,
ineffective in a case if you wait for perfection before committing)
to keep everything stable and working.
It is no big deal if you destabilize or break something from time to
time. In all cases this far you or we have been able to fix it quickly.
And if somethings takes to long to fix, it can always be reverted.
This could lead to the situation
that we want to release 2.2 but my stuff is "half-baked" and since
it is in the core it stops the release.
We have to keep this in mind when we are approaching a code freeze. But
as long as we not even have a release date, you shouldn't worry about it
and just contimue your work.
On the other hand, I cannot (and wouldn't want to) release 2.2 only
myself so even there are folks willing to help whole process demands
some time and it cannot be speeded up by my full commitment. Thus I
think the quickest and most effective solution is:
1. Revert changes in r559394 that broke the trunk
We found a solution on that didn't we?
2. Branch whole trunk for my GSoC work and start work there
For me it took a long time before I felt that I had the right to touch
the core. So while refactoring the template stuff I did everything
within the template block and worked on own copies of the object models
rather than fixing the core ones. In retrorespect this was clearly
counterproductive and I'm sure you wish that I had acted more confident
back then. Now you have to clean up instead ;)
Anyway, *you have the right to work in the core*. And I'm pushing you
beyond your comfort zone to accelerate the process in making you
understand it. Actually, if you think about it, you are probably already
the greatest expert on some parts of the core.
Now, if you feel that it is absolutely necessary, you can of course
branch the trunk. But think about the consequences. If you break
something in your branch it is much less likely that you will notice as
you are the only tester. You will get less feedback. And when you merge
back to the trunk you will get feedback and error reports on things
where you don't remember the details anymore. So in the end I would
think that you don't win anything, quite the opposite.
I think limited branching for testing an idea as you did a couple of
weeks ago is fine as long as you merge back soon. But I think that
working in a branch for more than a few days is a mistake.
While considering second step I'm starting to think that it would more
make sense to branch modules that we are going to release so they can
stabilize and others could continue work in the trunk. What worries me
is that our modules are not self-contained (they need parent poms, for
example) so I don't have an idea how to branch a subset of our modules.
Branching whole trunk does not make sense because some modules are ready
for a release and some are not. Do you have an idea how to manage two
versioning (maintenance and developer's) lines of our Maven modules?
Don't know if the added complexity is worthwhile. What I would like to
see is that we have a time boxed release scheme where we ship more or
less automatically every sixth week. This would give a natural community
rhythm where we can do experimental stuff in the beginning of the period
and need to focus on making everything work in the end of the period.
Eclipse does something like that and it seem to work really well
http://www.artima.com/lejava/articles/eclipse_culture.html.
/Daniel
