Hi all,
for previous releases, we had a two-stage freeze: first, feature freeze (no new features, only bugfixes), followed by full freeze for a short time and then a release. This time, I propose that we start even earlier with an even milder freeze: a _refactoring freeze_ which blocks any wide-ranging, deep-going refactorings that are not focused on adding a specific feature or fixing a specific bug.
In particular, this means no lib migrations, no rewriting and rearranging code "for general correctness", and no 2geom syncs "just in case" until the release. I realize this is all done for good reasons, but experience shows that each such wave of changes brings bugs that keep popping up long after the wave has passed.
So, if there are no objections, let's finish and commit any refactorings that are pending, and set a date after which we will only be allowed to commit focused, easily testable features and bugfixes.
I agree.
Adib. ---
On Thu, Mar 12, 2009 at 9:06 PM, bulia byak <buliabyak@...400...> wrote:
Hi all,
for previous releases, we had a two-stage freeze: first, feature freeze (no new features, only bugfixes), followed by full freeze for a short time and then a release. This time, I propose that we start even earlier with an even milder freeze: a _refactoring freeze_ which blocks any wide-ranging, deep-going refactorings that are not focused on adding a specific feature or fixing a specific bug.
In particular, this means no lib migrations, no rewriting and rearranging code "for general correctness", and no 2geom syncs "just in case" until the release. I realize this is all done for good reasons, but experience shows that each such wave of changes brings bugs that keep popping up long after the wave has passed.
So, if there are no objections, let's finish and commit any refactorings that are pending, and set a date after which we will only be allowed to commit focused, easily testable features and bugfixes.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Hi,
Most lpe are hidden atm. Not all of them necessarily need to be in this release cycle, but some might.
Should a lpe be released in this cycle, the earlier it is un-hidden, the better. So if there are lpes we definitly want to be added in this release, I think it's a good time to say so, so that we can concentrate on stabilizing the underlying maths, the parameter list, etc...
Cheers, jfb.
On Wed, Mar 18, 2009 at 8:51 AM, jf barraud <jf.barraud@...400...> wrote:
Hi,
Most lpe are hidden atm. Not all of them necessarily need to be in this release cycle, but some might.
That is correct, and I would like to eventually see all of them restored except the too badly broken or superfluous ones. But this has no bearing on the subject of this thread - restoring a LPE is not refactoring and can be done quite late in the cycle (though, of course, it is preferable to do it earlier). Releasing with a new LPE which is broken is not nearly as bad as breaking some old, highly visible stuff (like the ruler!) by refactoring and not noticing it.
participants (3)
-
bulia byak -
jf barraud -
the Adib