On Jan 20, 2009, at 10:11 PM, Joel Holdsworth wrote:
>> I just noticed that we have two "input devices" commands in File
>> Please whoever did this, decide which one we will use and delete the
>> 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
> 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
> 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
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
(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
> 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
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