I just noticed that we have two "input devices" commands in File menu. Please whoever did this, decide which one we will use and delete the other!
In general, I would propose a "bus tomorrow" rule as a general guideline for committing stuff to our SVN:
Before committing, imagine you are hit by bus tomorrow and cannot continue your work. Is your work so far still better off committed?
That is, please do not willfully introduce duplication in the code and especially in the UI unless this solves some problems for the user (not you). What you commit must not be perfect and complete (nothing is ever perfect or complete), but it must be immediately useful for something and must not introduce confusion for the user. An exception can be made when your commit does not change the UI; committing unused code is still bad but can be tolerated so long as it's hidden. But two same-purpose commands in the menu or two indistinguishable LPEs are not acceptable in any case. Either we do the switch or we do not. If you expect users to give you feedback after comparing the two commands, forget it. People are too busy to bother. If not ready, do not commit; if ready, just make the switch, as early in the release cycle as possible, and be ready to answer angry emails :)
Thanks.
I had put that in to be able to ask for feedback. At the time people wanted it on by default so they could see it. It's well overdue to turn of the duplication.
Functionally, though, it's not duplication. The new one will replace the old one when complete (so normally that would be when to turn it on by default). However at the moment it provides read-only diagnostics that aren't shown by any other tool. A few outside people use it for that.
So it does at least pass the "immediately useful for something" test.
On Jan 19, 2009, at 11:05 AM, bulia byak wrote:
I just noticed that we have two "input devices" commands in File menu. Please whoever did this, decide which one we will use and delete the other!
In general, I would propose a "bus tomorrow" rule as a general guideline for committing stuff to our SVN:
Before committing, imagine you are hit by bus tomorrow and cannot continue your work. Is your work so far still better off committed?
That is, please do not willfully introduce duplication in the code and especially in the UI unless this solves some problems for the user (not you). What you commit must not be perfect and complete (nothing is ever perfect or complete), but it must be immediately useful for something and must not introduce confusion for the user. An exception can be made when your commit does not change the UI; committing unused code is still bad but can be tolerated so long as it's hidden. But two same-purpose commands in the menu or two indistinguishable LPEs are not acceptable in any case. Either we do the switch or we do not. If you expect users to give you feedback after comparing the two commands, forget it. People are too busy to bother. If not ready, do not commit; if ready, just make the switch, as early in the release cycle as possible, and be ready to answer angry emails :)
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Sun, Jan 18, 2009 at 8:16 PM, Jon A. Cruz <jon@...18...> wrote:
However at the moment it provides read-only diagnostics that aren't shown by any other tool. A few outside people use it for that.
So, can we rename it e.g. to "Input Device Test" in the menu, and remove at least the second empty tab?
On Jan 19, 2009, at 6:22 PM, bulia byak wrote:
So, can we rename it e.g. to "Input Device Test" in the menu, and remove at least the second empty tab?
Could be... but I think since it's unlikely to generate any new feedback at the moment, I can probably just #ifdef it so it won't show up for anyone who doesn't explicitly turn it on.
Would a pref with no ui be a better option, so if you need someone to use it for debug info they wouldn't need to do a new build?
Sent from my iPhone
On 19 Jan 2009, at 10:58, "Jon A. Cruz" <jon@...18...> wrote:
On Jan 19, 2009, at 6:22 PM, bulia byak wrote:
So, can we rename it e.g. to "Input Device Test" in the menu, and remove at least the second empty tab?
Could be... but I think since it's unlikely to generate any new feedback at the moment, I can probably just #ifdef it so it won't show up for anyone who doesn't explicitly turn it on.
This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Jan 19, 2009, at 11:15 PM, John Cliff wrote:
Would a pref with no ui be a better option, so if you need someone to use it for debug info they wouldn't need to do a new build?
That probably would be a bit of a better balance.
Once I can fit the time in, I'll get that all set. Of course, I'll be sure to add a big TODO comment next to it so that removal won't slip my mind.
Hmmm... might be handy to do something to scan the code for TODO's and keep them in mind.
On 2009-January-19 , at 21:40 , Jon A. Cruz wrote:
Hmmm... might be handy to do something to scan the code for TODO's and keep them in mind.
Since you are on OS X, the TODO bundle for TextMate does just that. E.g. http://warpspire.com/tipsresources/web-production/using-textmates-todo-bundl...
JiHO --- http://jo.irisson.free.fr/
I just noticed that we have two "input devices" commands in File menu. Please whoever did this, decide which one we will use and delete the other!
In general, I would propose a "bus tomorrow" rule as a general guideline for committing stuff to our SVN:
Before committing, imagine you are hit by bus tomorrow and cannot
It seems like this project is really suffering from not having decent source control software, because this is exactly what branches were designed for - something which is a major PITA in SVN.
It really worries me that the inkscape SVN is such a free-for-all, leading to the situation that between releases, the quality of the code drops so low that it takes months to tidy it up again; and still there are many bugs released. If you had GIT or Bazaar or whatever, combined with a decent organization structure (allowing only a few people to apply patches to trunk), you'd see the quality of inkscape radically improve because people would be able to experiment and mess around without hosing the trunk.
Wine is a good example of this working well - they are able to release every 2 weeks. Their code is beautifully tidy, they have very few bugs and regressions, and there's very little redundancy because a few people are keeping an eye on what's being put in.
Git is really helping us on the Lumiera project for exactly these reasons.
Joel
On Tue, Jan 20, 2009 at 6:11 AM, Joel Holdsworth <joel@...1709...> wrote:
It seems like this project is really suffering from not having decent source control software, because this is exactly what branches were designed for - something which is a major PITA in SVN.
I don't think any technical tools will magically solve a problem that stems from psychology. For example, for me personally this lack of branches has never been a problem: I just keep my current project in my local tree until I decide it's ready to commit, or until I abandon it. I think we just need to teach ourselves to behave more responsibly, that is all :)
I'm not against a better patch/branch management as such, and the idea of someone signing a patch for committing is generally solid. But I just don't see why the respected, competent developers that we already have in the project cannot _themselves_ be a little more mindful of the "always compilable, always usable" ideal that we strive to maintain.
On Jan 20, 2009, at 10:11 PM, Joel Holdsworth wrote:
I just noticed that we have two "input devices" commands in File menu. Please whoever did this, decide which one we will use and delete the other!
In general, I would propose a "bus tomorrow" rule as a general guideline for committing stuff to our SVN:
Before committing, imagine you are hit by bus tomorrow and cannot
It seems like this project is really suffering from not having decent source control software, because this is exactly what branches were designed for - something which is a major PITA in SVN.
Actually branches are often a bigger PITA that not. Other than the low-level tech differences (where SVN vs. GIT really differ), the general workflow of many people adding new things to an existing codebase gets unruly. It's not as much an aspect of the tool, but is an aspect of the higher-level problem. I've see things come up over an over again (even with people who use SVN or Bzr or such) and some comes down to the longer something diverges, the more issues are encountered.
It really worries me that the inkscape SVN is such a free-for-all, leading to the situation that between releases, the quality of the code drops so low that it takes months to tidy it up again; and still there are many bugs released. If you had GIT or Bazaar or whatever, combined with a decent organization structure (allowing only a few people to apply patches to trunk), you'd see the quality of inkscape radically improve because people would be able to experiment and mess around without hosing the trunk.
That is what happens in general. And we have things in place to address that.
However, I think the higher level issue is the approach to development. We really could be considered an agile project, with all that goes along with that. Experiments *do* go off trunk for the most part, but actual work in progress does go in. That's perhaps a subtle difference, but one thing we work with.
Ken Schwaber's article "Get Ready for Scrum!" really sets things out well http://www.informit.com/articles/article.aspx?p=24027 (there are actually 8 pages there, not 7, so don't let it fool you into stopping early)
Wine is a good example of this working well - they are able to release every 2 weeks. Their code is beautifully tidy, they have very few bugs and regressions, and there's very little redundancy because a few people are keeping an eye on what's being put in.
Actually I would say that Wine is a good example of a completely different project with completely different needs and development management. Among other things it is merely implementing a fully specified system (perhaps not as well documented, but fully specified) with very precise constraints. That does lend it self more to a waterfall approach. Adding completely new features to a freeform tool is a different design flow.
Git is really helping us on the Lumiera project for exactly these reasons.
We've had people researching Git, Bzr and many other for some time now. Some are even using it now. However the issue is not so much on of the tool.
Also, different developers work different ways. Bulia, for example, is *very* good at thinking of something, going off and tuning it in his day-to-day-work, and then committing a magic all-in-one appearance. For myself, I work much better in a collaborative, iterative approach. Some also is that I am not an artist in my day work, so I don't get as much time to view things that way myself. The other is that I do talk things out with artists in our project, but more often they can't visualize the new approaches until they can get their hands on a first iteration.
In this case we did have new functionality, no breakage of old functionality, and something some people found useful. Bulia pointed out the main issue with possible confusion, and since that came to attention, it was something I tuned up and got going.
Far more than any source control change or change to contributors effective workflow, I believe we would gain from beefing up and having more people running our automated testing. *That* is a tool use that can bring major improvements. With Agile, XP and TDD, having good and expanding tests in place really pay off far more than source tool tweaks.
participants (5)
-
bulia byak -
jiho -
Joel Holdsworth -
John Cliff -
Jon A. Cruz