Re: sawfish development tools

[Scott Scriven <sawfish-list toykeeper net>]

Janek, you're doing a great job.  I don't want to make things any 
harder for you, and I don't want to take over, but if I can make 
things easier I'd like to try.  :)

As for the rest of this message, sorry it's so long.  It's just 
ideas for how to possibly make things easier.


As for git vs bzr, it's not a simple comparison but I'll try to 
summarize.  Git is faster, and probably has more users.  However, 
it's pretty complex (130+ different programs, written in a 
variety of languages), it uses checksums instead of revision 
numbers, and has pretty limited project hosting services.

Bzr is easier, has better merging, has a more complete GUI, and 
ties in with launchpad.  But it runs relatively slowly, and it's 
changing so fast lately that it requires a pretty recent OS.

The SCM tool is only one part of the puzzle, though.  Some of the 
pieces I've found useful are:

  - A distributed SCM tool would make trunk write access less 
    important, since everyone can work on their own branches.  
    (examples: git, hg, bzr)

  - A branch hosting service lets everyone publish their branches 
    in one place.  It may also allow a team to own the trunk 
    repository, to eliminate bottleneck effects.  (examples: 
    github, launchpad)

  - A merge tracker can facilitate merge requests, code reviews, 
    voting, and merging.  The actual merge can even be done by a 
    merge bot, after being approved by votes and unit tests.  
    (examples: launchpad, patch queue manager, bundle buggy)

I'm actually pretty new to launchpad, but I like it so far.  It's 
kind of like sourceforge, except better.  I've found it useful 
for project management.  Some other misc things launchpad adds are:

  - Users can create a local branch with "bzr branch lp:sawfish", 
    make changes, then publish it with
    "bzr push lp:~myuser/sawfish/mybranch"

  - Bugs can be associated with code branches.  If you commit a 
    change with "--fixes lp:123456", that will automatically link 
    your branch to bug 123456, and mark the bug as "fix 
    available".  It's kind of like attaching a patch, but with 
    complete history.

  - User questions can be answered in a public support database.  
    This works both for FAQs and for specific, detailed issues.

  - Bugs can be converted to questions (and vice-versa).  So, if 
    someone files a bug which is really just a FAQ, or if someone 
    asks for help and it turns out their problem is a bug, it's 
    easy to handle.

  - Projects can define milestones, such as "release 1.3.5", and 
    associate bugs and blueprints with those milestones.  This 
    helps with remembering what needs to be done before the next 
    release.

  - All maintainer duties can be done by a team, if desired.

* Janek Kozicki <janek_listy wp pl> wrote:
> just a note: currently the only place where sawfish patches are 
> listed is the wiki patch page. There are no other places which 
> I'm going to consider to make a release. That is because a 
> single place is convenient, and because it allows voting.

Yes, this is a good thing.  It allows changes to be submitted, 
reviewed by more than one person, and accepted.  The discussion 
doesn't really work very well in wiki form, but that sort of 
thing could happen on the mailing list.

> ... having all patches listed in a single place.

It seems to me like a good idea to extend this idea further.  
There seem to be sawfish add-ons all over...  could we merge 
these into a "contrib" area in the sawfish repository, or 
something similar?

This would help keep things in one place, but it also would 
probably make the write-access bottleneck worse.  Very few people 
can commit changes to the repository.

* Timo Korvola <Timo Korvola iki fi> wrote:
> Wiki is not particularly good at storing the patches

Even in raw form, the patches aren't very good at storing 
changes.  If someone spends a month adding a feature or fixing a 
bug, they will probably have at least a few revisions before 
their work is ready to be merged, and converting the changes to a 
patch at the end of the process causes the loss of that project's 
commit messages and other history.

> And it uses the Gnome svn repository, where most of the current 
> Sawfish developers don't have write access.

This is one of the reasons I'd like to convert it to something 
else.

> A problem with the wiki is that there is sort of a reasonable 
> patch size.  ...  very big things don't get fixed because the 
> changes would be too big for a single patch.

This can be solved by using branch merges instead of patches.

As for tiny changes...  those will still have more overhead than 
code.

* Janek Kozicki <janek_listy wp pl> wrote:
> Wow, I'm very happy to see that sawfish development is gaining 
> even more momentum.

Definitely.  I'm very happy to see it alive and growing.  :)

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

The basic commands in git/hg/bzr are almost identical to svn.  
All of them copied their core command set from CVS.  However, all 
three have features and concepts not present in subversion.

Single-user workflow is the same...  commands for commit, diff, 
stat, add, rm, mv, ls, resolve, revert, and so on.  The biggest 
differences are when you want to collaborate -- then commands 
involve push, pull, merge, send, and sometimes cherry picking or 
rebasing.  There are also handy extras like bisecting, to isolate 
bugs.

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

Being the maintainer is not easy, and you've been doing a great 
job.  I certainly don't have time to do all that...

What about splitting maintainer duties among several people?  I'd 
like to help, but have limited time and a pretty unpredictable 
schedule.  I could help with bug management, code reviews, maybe 
a few fixes or features, and some overall project janitoring.

One of the reasons I suggest launchpad is so we could assign 
maintainership to a team, instead of an individual.  Does that 
sound useful?

> the current model works well - 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.

It's not necessary to change the model in order to change some of 
the tools.  :)

What you described should be just as easy with git/hg/bzr as it 
is with svn.  Things could continue to work as they are now, 
except for doing a "pull" command at the beginning and a "push" 
at the end.  Any process changes beyond that are optional.

> Currently people who want to contribute to sawfish only need to 
> know how to create a patch, and how to edit a wiki webpage.

That can remain the same, if desired.  However, we could give 
people more advanced options if they prefer.  I'd rather post a 
merge bundle than a simple patch, and it'd be nice to get 
notifications of new changes instead of having to check.

Anyway, just some ideas.


BTW...  I found out that there is some discussion elsewhere about 
moving all of GNOME to bzr or git.  Some of the launchpad team 
are going to GUADEC (July 7-12) to discuss it, along with people 
from Red Hat and Novell.

I get the impression that the GNOME discussion isn't "if" but 
"when" and "how".  I know sawfish isn't really part of GNOME any 
more, but as long as it's still hosted by GNOME's servers, it 
would be good to pay attention.  :)


-- Scott