Daniel Fagerstrom pisze:
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 agree wholeheartedly - the temptation to fix everything what demands fixing
is really high.
Daniel and the rest, I really want to say that I enjoy and appreciate your personal and social comments. All in all, Apache is about
building community first and code as a second goal; you really understand this principle, IMHO.
I wanted to work on C2.2 release because current state of things
effectively stops me from continuing my work.
It doesn't ;)
;)
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?
Yes, but this mail was sent before you explained what you meant. :-)
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 ;)
YES :)
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.
Thanks! It's really encouraging.
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.
OK.
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.
I feel more comfortable in branch because I can commit often (and that is what I prefer) so code can even not compile (it was a case in my
latest branch). I was really disappointed by the fact that svn log is lost during merging back to the trunk so I was trying to find other
solution. It was a weird attempt, I must admit.
Since, I have green light for more braver actions in the trunk so I'm going to
stay there.
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.
Already read this article. I agree with it.
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
