Guys,
Inkscape's openness and the ease of contributing to it are wonderful. However, I would like to remind you that if you commit a change, by this very act you suggest that at least one of the following is true:
1 You are a heavy user of the changed/added feature, and you are sure you yourself can discover and fix most related bugs soon, if not already.
2 You intend to be around for a reasonable amount of time after your commit, _watch_ for bug reports related to your change, and fix them _promptly_.
If none of these are true, please REFRAIN FROM COMMITTING until you can make them true.
Why rant about it now? Two of the recent regressions are so nasty that they forced me downgrade to 0.43 for my daily work, painful as it is. Not being able to use the latest CVS - oops, sorry, SVN - is so annoying that I just can't help speaking out. The people who caused these regressions are known with a reasonable level of certainty, and I asked them to fix the bugs (or at least look into them) numerous times. The bugs are:
- export selection is broken (likely caused by Carl's changes in libnr)
- F6 and F8 keys don't work (most certainly caused by Jon Cruz' swatches panel)
I don't want to blame anyone, because these people may have some genuine reasons to be unable to fix these bugs. Or, it may be that the bugs are not caused by them at all. After all, I myself am too busy with work right now, so I can't even investigate these bugs in more detail, let alone fix them.
However, I feel that this is still a good occasion to state what I have stated: DO NOT COMMIT if you will be unable to support your change at least for the length of one full release cycle, and especially if you can't be on guard for the first few weeks when most of the bugs are found.
Thanks,
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
bulia byak wrote:
However, I feel that this is still a good occasion to state what I have stated: DO NOT COMMIT if you will be unable to support your change at least for the length of one full release cycle, and especially if you can't be on guard for the first few weeks when most of the bugs are found.
Subversion has a reputation for much improved for branching and merging, so long- and short-lived branches may be more usable for inkscape development than they were under CVS.
Perhaps the rule of thumb should be to use a branch for anything that has potential for non-trivial regression, whether the original committer is around to fix it or not. Keep merging the trunk to the branch while developing; when the feature is known regression-free, merge it to the trunk. The single/few feature commits will be easier to revert if needed.
FWIW, having a naming convention and retirement policy for branches becomes important if they are heavily used.
On 1/20/06, Jeff Kowalczyk <jtk@...36...> wrote:
Subversion has a reputation for much improved for branching and merging, so long- and short-lived branches may be more usable for inkscape development than they were under CVS.
Experience shows that it's very difficult to convince enough people to _use_ a branch. This makes the whole idea meaningless: if only the original author uses his branch in real design work (which is the ONLY way to find bugs), he could just as well not commit it at all, using his local tree to test the new patch until he feels it's stable enough for the trunk.
I'm not sure if svn makes it sufficiently easier for people to _run_ a branch for this situation to change.
Besides, often it's hard to say which changes are more dangerous. For example Carl's change, AFAIK, was supposed to be mere refactoring.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
bulia byak wrote:
I'm not sure if svn makes it sufficiently easier for people to _run_ a branch for this situation to change.
'svn switch' makes it easy. If the tester is running a checkout of trunk, with the svn switch command they can be running the branch in moments, and change back just as easily.
On Fri, 2006-01-20 at 08:44 -0500, Jeff Kowalczyk wrote:
bulia byak wrote:
I'm not sure if svn makes it sufficiently easier for people to _run_ a branch for this situation to change.
'svn switch' makes it easy. If the tester is running a checkout of trunk, with the svn switch command they can be running the branch in moments, and change back just as easily.
What about merging with branches, though?
As far as I can tell, with stock svn, it forces you to manually grovel the history looking for revision numbers to give to svn merge...
svk gives you smerge, at least, but I can't find anything like that in stock svn.
-mental
Update:
On 1/19/06, bulia byak <buliabyak@...400...> wrote:
- export selection is broken (likely caused by Carl's changes in libnr)
Fixed, thanks Carl
- F6 and F8 keys don't work (most certainly caused by Jon Cruz' swatches panel)
Being discussed - Jon, what is needed for a fix?
Anyway, since the worst of the problems is fixed, I'm back to latest svn. Hurray! :)
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
On Jan 25, 2006, at 9:32 PM, bulia byak wrote:
- F6 and F8 keys don't work (most certainly caused by Jon Cruz'
swatches panel)
Being discussed - Jon, what is needed for a fix?
I'll need to revert some of the container change, but still keep the other cleanup I did...
But I was also getting up a UI mockup to go a bit more into why a pane might still be needed.
participants (4)
-
bulia byak -
Jeff Kowalczyk -
Jon A. Cruz -
MenTaLguY