Re: Future Plans .....

[Daniel Fetchinson <fetchinson googlemail com>]

>> > here's a small subset of my future plans for Sawfish:
>> >
>> > in [] the name of the people I would like to ask for
>> > help/contribution on that topic
>> >
>> > Librep/Rep-GTK: R-Wrap
>> >
>> > Port g-wrap to librep and recreated rep-gtk from scratch with the
>> > new mechanism.
>> >
>> > [Alexey, Jürgen]
>> >
>> > Sawfish:
>> >
>> > Compositor
>> > Improve system for handling keys/keyboards
>> >
>> > [Timo, Janek, Teika, Jeremy]
>> >
>> > Recreate default themes with nicer, more visually appealing
>> > graphics, say same theme, but more modern style.
>> > Update Translations.
>>
>> I'm not sure if mxflat is a default theme or not, but since this is
>> the theme I use and like it as is, I'd like to ask for keeping it
>> intact. In my opinion no change to it is necessary, and especially no
>> change for the sake of changing.
>
> I've never said of all themes have to be changed, but for example I
> have a new, more modern Crux theme in mind, but I've never found the
> time to gimp it actually. Not that the current one is ugly, but it
> looks dusty.
>
>> > [Community]
>> >
>> > See also what is proposed in `Proposed Goals'
>> >
>> > Next Release: 3.0.0
>> >
>> > Skipping 1.7.0 and releasing 3.0.0 in Dec '10, so we have 12 months
>> > time for the changes we need/want to do. And I guess we'll need
>> > them. 1.6x will be supported 6 months with bugfixes and & co, just
>> > like 1.3.5x and 1.5x have been.
>>
>> I'd be more happy with more incremental changes and correspondingly
>> more frequent releases. This allows for more testing and more robust
>> major releases.
>
> Well, for 3.0 one alpha, beta and rc is planned, each after 3 months, a
> second rc then feature freeze begins. In addition, there will be a
> backported 1.7.0, with GTK+2 support, as 3.0 will be based on GTK+3 if
> everything goes fine. Atleast that's what got in my mind lately.

That sounds good, I didn't realize sawfish 3 will be based on gtk+3.

>> > Any thoughts?
>>
>> I think a mechanism should be found for testing releases before they
>> are actually released. Very simple compilation related problems
>> frequently have been arising lately and having buildbots or something
>> similar would improve the situation quite a bit. I'm not sure if
>> sf.net has facilities for this but I seem to remember they had a
>> server farm or some such. Having the buildbots to configure, compile
>> and install on multiple linux distros would be a major improvement.
>
> compilation itself is not the problem, except the 4th hyphen in
> --without-nine-mouse-buttons all issues were related to the packaging
> scripts, so perhaps the build-service from OpenSUSE would be
> interresting.

Yes, a build-service or bulidbots, or whatever helping automated
testing would be great I think.

Cheers,
Daniel



-- 
Psss, psss, put it down! - http://www.cafepress.com/putitdown