> > It is. As I explained earlier, the idea is that anything fixed in STABLE
>
> You are being misleading with this generalization. State dependancy is
> state dependancy no matter which direction you cut it. If the subject
> of such a dependancy for a fix is changed in head, then whether you port
> the fix from head to stable or stable to head, you have porting to do.
> If there is no such dependancy, there is no gain other than some
> administrivia.
No. A fix in STABLE has more chances to be portable to HEAD than the
other way, because in HEAD we just tend to had stuff. And there have
been lot of *seriouos* bug never fixed in STABLE because they were
obscured or fixed in HEAD by something else.
> > will end up in HEAD. But HEAD has more. So fixing bugs in STABLE means
> > that we can merge all the changes back to HEAD in one shot (say weekly),
> > instead of one by one like we did previously.
> > And you are not tempted to use new features for "easiness".
>
> It's also somewhat dangerous to generalize all bug fixes together this
> way. Many bug fixes cause regressions or turn out otherwise undesirable
> well after they're committed to HEAD. If careful discretion is not
> used, this would be no different in stable, creating an undesirable
> dependancy contention and stall in the stable release cycle, unless you
> chose to ignore that and just have stable releases that weren't quite so
> stable.
We said merging should not be performed carefully ? Not me. Who talked
about regression testing and unit testing ? Marc, a few other and I.
> It is correct that many relatively benign fixes being done directly in
> stable (as some developers chose well to do during the last cycle)
> reduces by a little bit some of the administrivia involved in
> maintaining such a branch, but there are a lot of fixes that really do
> need to be worked out first in HEAD.
No. If the bug is in STABLE it should be worked out in STABLE. Working
on in HEAD may result to a fix that is either hard to port and end up
not being theren, or a fix that in incomplete and lead to other bugs.
> There are also no fewer bilateral fixes that you would NOT want to
> merge from stable to head than that you would not want to merge from
> head to stable. These fixes happen for good reason - it's called
> Progressive Code Divergence and it means that as AbiWord progresses, its
> code diverges from its past code. Simple concept, but it must be dealt
> with thoughtfully, not with a sweeping chrono-only approach where
> conflicts inhibit progress in HEAD or cause undue wasted time or effort.
> As for easiness, one must be careful not to combine feasibility under
> the umbrella of easiness. We are not exactly drowning in time,
> resources, and manpower here. When (presumably following guidelines
> previously laid forth) the milestone interval is kept short by
> discipline, it is not such a tragedy for a fix which is infeasible in
> stable to be done only in head where it is, erm, 'easier'. So while it
> is important for the sake of the users to give credence to the needs of
> a production line, do not let overzealousness cause a shortfall in the
> long run which hurts the users just as much (and can really dishearten
> an innocent volunteer coder).
Again this code divergence makes it harder to backport fix to STABLE
rather than the other way.
> Yes, most of us are involved in a number of projects aside from abiword,
> and if anything that should teach us that as important as learning from
> our experiences elsewhere is realizing that each project has different
> needs which need to be met with different approaches.
Sure they all have different needs, but in that case, it applies because
I'm talking about maintenance of one code base base while the other one
is evolving. I adapted the "case study" to AbiWord.
If I insist on doing that way, this is because I think we didn't do it
the right way last time. I'm trying to provide a solution. I seriously
believe that we owe quality and fixes to our user base, for 2.2.x
release.
Hub
-- Crazy French - http://www.figuiere.net/hub/Received on Thu Dec 23 17:44:08 2004
This archive was generated by hypermail 2.1.8 : Thu Dec 23 2004 - 17:44:08 CET