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 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.

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.

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 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.