Re: [README] New development cycle
- From: Janek Kozicki <janek_listy wp pl>
- To: General discussion about sawfish wm <sawfish-list gnome org>
- Subject: Re: [README] New development cycle
- Date: Wed, 19 Nov 2008 15:56:50 +0100
Christopher Bratusek said: (by the date of Tue, 18 Nov 2008 22:10:31 +0100)
> Voting system stays as is, but what if there's only the authors vote, or
> just one additional vote, should
> I then decide about the patch or are there other ideas?
usually I made the decision. But I in general preferred to delay the
decision until there are more votes, unless I was sure that this
patch is good.
> About sawfish-experimental ... I would prefer doing sawfish development,
> like I do librep and rep-gtk.
> When something is finished, tested and approved it goes to trunk
> immediately. That means, if your patch
> is approved, you can commit on your own without having to ask once more.
> Of course we can keep
> sawfish-experimental, but how many people do really use it, in favor of
> stable or trunk? What do you think?
I made experimental, because some people (not only me ;) had
objections about adding stuff that might break sawfish in some way or
And also I wanted to encourage Scott Scriven to add his tabbing
support. He is still reluctant because it's heavily untested and
-experimental was the place for initial implementation. Last time I
checned he stopped this because he couldn't make a useful testing
environment (which allows easy restarting of sawfish and testing it,
without closing your entire session).
It's a bit sad that tab support is sitting on his HDD waiting without
hope ;-) Maybe you could contact him and retrieve what he has - and
continue his efforts?
> Does anyone know how to upload to the gnome-ftp and how to update the
> gnome-release-rss? What might
> give us more publicity. ( RSS-Location:
> http://ftp.gnome.org/pub/gnome/LATEST.xml )
I was uploading only to sf.net and I was sending an announcement to
gnome-announce-list gnome org upon release.
> I thought about the documentation situation ... perhaps it's really
> better to force the developer to add at least
> a small documentation entry for the new functions? As you can see on the
> wiki the current docu is outdated.
yes, good idea.
remember that it's better that each committed patch is on the wiki,
just for one reason: if there is a regression, then everyone can go
to wiki and try unapplying each patch to find the root cause of the
problem. Please try to be strict, and if you commit anything on your
own, just make a wiki patch page for it, and write that it was
accepted and committed by you. Or we might get a mess.
best reagrds :^)
Janek Kozicki |
] [Thread Prev