mental@...3... wrote:
Quoting bulia byak <buliabyak@...400...>:
Third, strive to fix ASAP any bugs or regressions found in the code you checked in. If you know the code you're about to check in has some unfixable (in the short term, or even at all) regressions, please warn people on the list and try to find a consensus.
One thing in particular that I'd like to underscore for the benefit of the list: breakage is, fundamentally, a debt.
The longer code remains broken or disabled, the more difficult it becomes to fix or re-integrate later. This difficulty increases super-linearly with time.
In other words, he longer you remain in debt, the more interest you have to pay.
This is why small, incremental changes are best. It's also why I'm so aggressive about ripping out unused or commented-out code.
Maybe then to change Bryce's rule: don't check in broken code. Code for the core application must compile. I think the 24 hour rule should be stricken. This is not to say that merging the gtkmm code into HEAD will not be problematic. As, maybe that code might break the inkscape_gtkmm code, but it should not break the core Inkscape application.
SIMPLY: Inkscape CVS should also be compilable.
SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id%14396&op=click _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel