cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: woah there - "vetoed" changes committed to Engine
Date Sun, 17 Sep 2000 00:56:30 GMT
Please, allow me to chime in...

Robin Green wrote:
> Donald Ball <> wrote:
> >robin, i'm psyched to see another committer dedicated to keeping the
> >cocoon1 branch up and running until cocoon2 comes around, but i got a
> >little issue here. i voted -1 on the engine synch. patch since i thought
> >that we shouldn't put in a patch that messes around with cocoon that
> >deeply shortly before a new major release. according to the terms of the
> >asf project constitution:
> >
> >
> >
> >my veto is binding unless you convince me otherwise.
> Right. Sorry, I forgot about that. It's been a while since I read the
> constitution.

No problem, I'm sure you won't do the same mistake again.
> >i'm really not trying
> >to be a tight-ass, i'm perfectly happy to switch my vote, but we oughta
> >follow the rules - especially now that there are now, what, six, seven
> >whole committers on the cocoon project? :)
> Absolutely. I'm not the type of person who tends to break rules on a
> personal whim (by mistake, maybe; for a good reason, maybe; but not on a
> whim...).

I share this vision, otherwise I wouldn't have proposed you for this
> >(note i'm speaking from experience here, having introduced a fairly
> >serious synchronization bug shortly before a major release of cocoon. was
> >it 1.3?)
> Okay, here's my attempt at swaying you (and anyone else who has similar
> concerns). There are basically three changes here.
> 1. Fixing a bug that only allowed one request through the engine at a time
> (that's right - one thread per engine!), which was not what was intended at
> all, according to the submitter (i.e. I removed the synchronized (this) {}
> ). I can't see how this change can be dangerous. It's just changing it back
> to how it was in 1.7.4. I think the original synrchronized block was just
> left in mistakenly.

> 2. Fixing a possible missed notify() by synchronizing fully on the Block
> object, rather than only part of the time. I can't see how this change could
> be dangerous either - indeed it prevents a bug that could have been very
> hard to find and could have caused mysterious timeouts on many sites on
> heavy load - when one thread unblocks before another thread is ready to
> receive the notification. That's a synchronization ABC thing, anyway - at my
> college it was exactly this concept of missed notify that was used to
> explain why synchronization is necessary.

Place it under half an hour of JMeter shower and if it remains live
you're safe.

Anything else will be fixed in 1.8.1

> 3. A very primitive profiler that just takes the current time at various
> points and puts the results in a hashtable, that is disabled by default in
> - so it can't do any damage. (Touch wood!)
> (Why #3? Well, I had a pile up of things I wanted to make into patches when
> I submitted it as a patch, so I hurriedly put two of them together for
> convenience. With hindsight this was a bad idea.)

Oh, c'mon, things like these don't hurt and if they do, who cares, we
fix them.

> It looks to me like there are three options:
> A. Undo these set of changes (or at least the synchronization changes), and
> end up with a release that is very likely more buggy. In my opinion
> certainly more buggy.
> B. Keep them, and release on schedule, with only a few days testing period.
> We have Apache JMeter - that's good for testing multi-threading. (note that
> JMeter can also expose JVM bugs, not just Cocoon bugs.)
> C. Keep them, but defer the release (but keep the feature-freeze) to allow a
> longer testing period. I'm not sure what length of testing period would be
> most suitable for this type of change.
> In my opinion, C is most preferable, because it is most likely to work best
> at the end of it, followed by B, followed by A (least preferable).

I vote B, release "early" means exactly this.
> Ultimately I feel that leaving these bugs in (with admittedly
> hard-to-quantify risks), out of a belief that the risks are higher if they
> are fixed, is a misjudgement. If you're going to leave bugs in software,
> there'd better be a good reason for it, which _outweighs_ the reason for
> fixing it - and I don't think it does in this case. (Obvious point, I know,
> but how else could I say it?)

The only reason for a bug to remain in the code is when either:

 - you don't know it's there
 - you don't know how to fix it
 - you can't fix it without braking something more important
 - you have to patch parts of the JDK itself to fix it (in C2 we are
reaching this point, unfortunately)
> These are really _simple_ fixes, measured against the standards of the
> software industry (multiple megabyte MS patches anyone? Okay maybe there's a
> little redundancy there, but still). Sure, any fix can introduce new bugs -
> but you could say that about anything, even correcting a comment (hey, you
> could delete the */ by accident :).

NOTHING is a simple bug fix. Do not underestimate the non-linearity of
open software systems used by thousands of individuals: it's the
"butterfly effect", a small change can trigger a tornado a few months

This said, if we release early and often, the systems are still
non-linear, but the correction steps faster... so we can stop the
tornado from happening as soon as we forecast it.
> "Why do I think this is an issue worth arguing about?" you may be wondering.
> Well, it's simple - I'm embarassed with these particular bugs, and even more
> embarassed with a few other things like how-it-works.xml (which didn't even
> build, which hadn't been finished and which contained numerous mistakes
> which would be rather unhelpful to a newbie; so I've rewritten it. It was
> not written by any of the Cocoon committers, I hasten to add, just an
> enthusiastic outsider who thought he/she understood things better than
> he/she really did - it can happen to anyone!)

It was my mistake not to check it deeper (but you know, my interest in
Cocoon1 dropped suddently as soon as the C2 sitemap was implemented.
> So, for the sake of the "dignity" of the Cocoon project overall, including
> myself, I'd like to get it in a more shipshape condition. Now you may say
> that's about image and PR and marketing etc. which we are things we should
> stop getting hung up about - but it's not just image, it's about code
> quality (and quality of the docs). And yes I admit it, I am being fussy, but
> we're all allowed our little weaknesses aren't we? :)

eh, eh, and you guys thought I was the picky one :)
> While I can see the sense in being cautious just before a release, as a
> general principle - if I were a complete outsider I expect I'd _still_ think
> that leaving these known simple bugs in was... odd, for an open source
> project.

No, it's not ODD, it's what happens when there is a bottleneck and I was
the bottleneck.

This is why I wanted somebody to take my job but willing to take this
position until you proposed yourself.

So, everything should be in shape now... just remember that you are just
a coordinator: as a developer your votes count as one like anybody else
(sometimes when you coordinate a project it's easy to forget this, I
know this from personal experience :)

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<>                             Friedrich Nietzsche
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------

View raw message