I really think that you, while well intentioned, are taking too
simplistic and overarching a view on this.
On Fri, 2004-12-17 at 18:00 -0500, Hubert Figuiere wrote:
> 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.
> 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.
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.
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).
> We are doing this here at the office for quite sometime and I must say
> that our release cycle is so that we have a few concurrent branches, the
> last released version, the currently being released version (ie all the
> test QA cycle), the about start release and the HEAD. We fix the bugs
> always in the older release they are supposed to be rolled in, and we
> merge periodically.
>
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.
> It is easy to have 2 trees for 2 different branches. I have been doing
> that since 1.0 release.
Yes, if there's anyone out there that does not understand how to
checkout using a branch tag or change sticky tags in a wd, do feel free
to ask. It is quite simple.
Regards
-MG
Received on Sat Dec 18 04:31:00 2004
This archive was generated by hypermail 2.1.8 : Sat Dec 18 2004 - 04:31:01 CET