Re: sawfish development tools

[Janek Kozicki <janek_listy wp pl>]

Timo Korvola said:     (by the date of Wed, 25 Jun 2008 14:10:03 +0300)

> Scott Scriven <sawfish-list toykeeper net> writes:

> > It would probably help with all the patch 
> > management, and make it easier for people to contribute.
> 
> A problem with the wiki is that there is sort of a reasonable patch
> size.  Very small things like typos don't get fixed, because they are
> not worth the hassle to set up a wiki page, and very big things don't
> get fixed because the changes would be too big for a single patch.


Wow, I'm very happy to see that sawfish development is gaining even
more momentum. There are currently 17 patches waiting on the wiki.
And I cannot do anything right now about this, because I need to
prepare for incoming conferences (29.06-5.07 Venice and 13.07-20.07
Montreal) which is quite a hard work in fact.

I'm skilled at working with SVN and 'patch -lp1 < ...', but I have no
time to learn bzr or git.

But FOR SURE I'm not going to hold you back. Maybe, just maybe, my
role here to "revive" sawfish is done, and now when the development
gets more momentum, someone else should take the "maintainer" stick
from me? 

Just volunteer, and I will do everything needed to provide you with
all access rights that currently I have. Then you will be free to set
up a bzr or git repository for sawfish, and mark it as an official
repository.

Personally, to avoid potential problems with 'organizing and
managing' of development, I just want to say, that in my view the
current model works well - for me (perhaps *only* for me).

- formatting problems on patch pages, are solved by applying patch
  using -l flag (--ignore-whitespace)

- adding a new patch (be it a single liner, or 2000-liner) is still
  as simple as clicking the button "Create patch page". Even if
  sometimes is feels a bit awkward to do so, due to not-normal patch length.

For me it's simple, because when I have time to make release I just
browse all submitted patches, consult with the mailing list, and
finally apply a patch. A process quite simple and transparent. The
bonus side for me, is that it does not require bzr or git skills.

Currently people who want to contribute to sawfish only need to know
how to create a patch, and how to edit a wiki webpage. If we are
going to switch to bzr or git, such person would need to know how to
work with them. That's an extra step, which may deter potential
contributors.


Therefore if I am to stay as the guy who makes releases by applying
patches, I would prefer to stay with the current method, because it
just works for me, and doesn't require extra learning of other tools.
But I really don't want to hold the sawfish development. It's just my
personal time constraints, that make it difficult to cope, if it gets
bigger or complicated. A single place (currently a wiki) to view
all patches waiting in queue is very convenient.


There is another solution also, someone of you will set up a git or
bzr repository, we will mark it as the official one (and deprecate
that one on gnome server). Then patches could be committed there into
branches, and the wiki patch page would not include a diff for it,
only the explanation and voting. Instead of a diff, there would be an
instruction on how to pull from repository a version of sawfish with
that patch included. And finally, there would be and instruction (for
me) on some other wiki page, how to merge those patches, so that I
would not need spend time learning that. But then... are you sure
that you still need me? :)


perhaps we should do some voting here about the sawfish future?

- vote no 1. remain status quo
- vote no 2. someone (Scott ? ;) volunteers to maintain using bzr
- vote no 3. someone (Timo ? ;) volunteers to maintain using git

any other options? :)

-- 
Janek Kozicki                                                         |