decisions about applying patches (was: sawfish-1.3.1 and ShapeInput)

Michal Jaegermann said:     (by the date of Sat, 28 Jul 2007 23:14:14 -0600)

> src/events.c.   The following patch solves the issue:

thanks, it looks reasonable - in every other place in the code
(except this one) there are #ifdef ShapeInput before referring to it.

> BTW - in my source I also carry some patches which were posted
> on this list by other people.  Here are correspoding descriptions
> from my spec file for four of these:
> # Avoid saving poperties for the desktop window
> # Don't grab focus on KDE menus
> # make window to draw properly with transparent pieces
> # some mice have tons of buttons

I am thinking that we need some kind of "decision system" for
applying patches. So far I've applied only patches that I can
understand myself. But I foresee that more complicated patches will
come, which I won't be able to understand, while others will
understand. Bear in mind that I don't understand sawfish core. In
fact I'm sure that other people here are better qualified than me,

A central source to keep all submitted patches is not enough (like
bugtracker) - I guess that we need some kind of voting system. It
serves only one purpose: more than single person will say that the
patch is correct and should be applied. And someone will be able to
say that the patch doesn't work in some circumstances.

The simplest solution that comes to my mind is to use our wiki site
for that. We could do it in similar way that [[Scripts]] work there.
Each patch is a dedicated article (like each script is an article).
Information about all patches is collected together on a single page
(like And most importatntly -
people can write comments about each patch on the peage dedicated to
it, especially saying if he wants it, or is against it.

This is to give an opportunity to people who know sawfish better than
me, to decide about whether patch should be applied or not. If
"enough" number of votes is collected a patch is applied or rejected.
How much is "enough" ... well - we will see ;-) I guess it will
depend on how good reasoning is provided by people who vote. Like
this example:

"a good patch, I used it for years" 
   -> bad reasoning

"in every other place in the code (except this one) there are #ifdef
ShapeInput before referring to it." 
   -> good reasoning (heheh shamelessly used my own comment ;)

Any other ideas?

I hope that you understand what I'm trying to describe. I hope that
this method will work. And we could start making this [[Patches]]
wiki page, by using your four patches mentioned above.

Janek Kozicki                                                         |

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]