cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: HttpServletRequest vs o.a.c.e.Request saga continues
Date Mon, 30 Jul 2007 22:34:12 GMT
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

Mime
View raw message