Re: Maintenance question

[Leonard den Ottolander <leonard den ottolander nl>]

Hello Bulia,

On Wed, 2004-08-25 at 02:37, bulia byak wrote:
> Personally, I hope that these policies can be relaxed somewhat. People
> who want to help must have an easy way to do so. For example, patches
> should be reviewed, but it's really frustrating to wait for this
> review forever. Besides, I think it's only core or security-related
> patches that really need pre-commit review; for UI tweaks, much better
> feedback can be received from users of the CVS version than from a
> single reviewer, and it's also much faster for other developers to do
> cvs update and test than to apply a patch.

I already figured that trying to regulate things too much is probably
counter productive at this stage of revitalizing the project. Otoh I
would prefer to see a little reluctance towards committing
(incomplete/untested) patches too quickly. Give yourself a week to check
your own work before committing. This is why I propose to put up patches
for review, also by people with commit access. It's still possible to
commit them after a while if no-one responded.

Waiting with committing until a piece of work is complete also makes the
Changelogs more useful to work with. Instead of having to read through
dozens of Changelog entries to get an impression of what changed it's
easier to have a single (large) Changelog entry describing a whole
patch. This is especially important if people need to touch the same
part of the tree.

> I also think that the
> project must be more liberal in granting developer access, because
> working via patches and not having up-to-the-minute CVS access is very
> frustrating.

Personally I do not have a big problem with working with patches,
assuming they will be reviewed and hopefully committed in a reasonable
time. Frustration only creeps in if they are not reviewed within a
reasonable time, or not at all. Roland and Pavel Shirshov have been very
responsive in this respect, although I wonder if they can keep up the
pace if they remain with only the two of them ;) .

If there are enough people with commit access (say 10) people submitting
patches can be sure theirs will be reviewed in a reasonable time. Or
they can let them be peer reviewed and present them as such, thus taking
away some of the burden of the reviewers/committers.

> My own area of interest is the UI, and there's a lot of room for
> improvement here. My 2-years-old patch in the tracker ("hotkeys in
> hotlist") was never committed and has probably bitrotten by now. I
> also had a number of other UI improvements in my tree, but I never
> even submitted them as patches because that first patch was ignored. I
> really hope the situation will change and I will be able to contribute
> again.

It is my intention to do some work on Savannah Bugzilla. Maybe I should
ask Pavel Roskin directly, but actually I am waiting for a reply to my
mail that started this thread.

> By the way, I am a developer for Inkscape (www.inkscape.org), and I
> can't help noticing the similarities. Inkscape was forked half a year
> ago from Sodipodi, because the developers were frustrated by not
> having CVS access, long periods of stagnation, ignored patches, and
> other unpleasant signs of a "too centralized" project. I don't want to
> sound like boasting, but Inkscape has been a success. It now has a
> MUCH more usable UI, lots of new features, important architectural
> changes, and surprisingly, it's also more stable (rarely crashes,
> unlike Sodipodi) despite having several times more developers with CVS
> access. The openness of Inkscape has played out really well. Of course
> mc is a different kind of project, but it would still benefit by
> borrowing something from Inkscape's approach IMHO.
> 
> At the very least, we found that additional channels of communication
> and collaboration, such as Wiki and Jabber/IRC channel, are very
> useful in attracting new developers and helping them get familiar with
> the codebase.

I reserved #mc-devel at Freenode for this just yesterday. Please come
and join me there. It's rather boring only chatting to ChanServ ;-) .

> Looks like a small thing, but it's very important to for the project to look
> alive and well.

Very true.

> And of course, it's important to make releases more
> often, so that a wider audience can test the new stuff.

Sure.

Leonard.

-- 
mount -t life -o ro /dev/dna /genetic/research