Quoth Rodolfo García Peñas (kix),
Carlos say what is included or not, he say who are commiters or not,
and he say the wmaker destination. But, there are no rules. There are
no method to know if a patch or a new idea will be included or not,
there are not wmaker destination (we are solving problems, not
improving wmaker). If I can't decide, I won't waste time writing code.
I do think that we lack a clear focus with regards to project
direction.
I don't have any objection to there being just one committer and I
don't have any objection to that one committer being Carlos. He's
shown himself to be motivated and capable and I get the impression
that he has a checklist that he considers before accepting patches -
correct formatting, no compiler warnings, update to the NEWS file -
which is exactly what you want from a committer. What I'm less sure
about, and what frustrates me as someone who's had patches
representing a substantial time investment rejected, is knowing what
that checklist actually is.
This whole debate has had somewhat of a polarising effect and with
emotions running high it's all too easy to start viewing the
development community in terms of two camps, the conservatives who are
only interested in bug fixes and code cleanup, and the progressives
who want to commit anything that compiles. The reality isn't like
that. We've added lots of features to wmaker-crm, drawers being only
the most recent, and even among the patches which have been rejected
there haven't been any outlandish ideas; no one is proposing that
wmaker needs a builtin flight simulator.
It's a small project. Too small to leave any of the (very few)
developers feeling like their contributions aren't welcome. Let's
decide what we want wmaker to be before we start talking about forks.
In terms of the direction that I'd like to see...
Bug fixes, code tidyup, optimisations etc of course. We're good at
this already.
Features which enable new users to discover wmaker. My --replace
patch was written with that in mind. If an XFCE user has heard of
wmaker and wants to try it out, it's a lot easier to say "type wmaker
--replace at the command line then xfwm4 --replace to go back" than
"so first you need to identify and kill your existing window manager
process..." or worse "just close down all your applications and log
out..." Yes I would consider theming or eye candy features to be in
this category. Users like good looking desktops.
Features from other desktops. If another window manager does
something well then surely there's no shame in "copying" that feature.
Things which aid configurability. We're already very good at this.
You can, for example, enable or disable dragging windows across
workspaces and separately enable or disable magically creating
workspaces when you do so. Perhaps there are other little things
which some people like and other don't.
New features should be configurable where appropriate. It doesn't
make a lot of sense for the --replace feature to be disabled but the
"start typing in the switchpanel to match window titles" patch I
submitted did have an option to completely disable its functionality.
We tend to be good at this already.
Where a new feature would change the behaviour of some existing
system it should be disabled by default so that a user who didn't
explicitly enable it would see no change. We're good at this already.
I'm quite happy to see some kind of peer review regarding patches
that don't obviously fit within whichever guidelines we agree on.
That could be a vote or a challenge to make a convincing arguement for
it or something else.
And probably some other stuff I forgot.
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
