Hi,
Sorry for the delay. I am too busy this week. I have a lot of work.
I am talking about different hats:
1. Developer hat
2. Commiter hat
*All* developers have the same weight, and they can disscuss about
what patches should be uploaded or not.
The commiter only do the commit. IMO the current behavior is that
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 don't want to continue with this discussion more time, but I don't
like the current method. Some tips IMO:
1. We should search a new place with integrated git+BTS+code review (I
don't know if github or other place could do it). I have a lot of
things here, in my paper-notepad, about wmaker. I would like to upload
them to an stable BTS as bugs/wishlist. Why I don't like repo.or.cz?
Because we don't have BTS, and because the current behavior doesn't
include code review (we don't discuss about the patches in the mail
list), so I (we) cannot decide about patches. If something is in the
repo then it exist, else, the thing (patch, idea) never happended.
2. Rules. Rules about what the commiter can do, what can do the
developers. Definitions about what is a developer, what is a
commiter,... I would like know what I am doing here. If the commiter
has more weight than developers and there are only one commiter, we
have a problem.
3. Flexibility to do things and branch definitions. I have
experimiental branches here about new ideas. I sent some patches
twice, but the code is only in the mail list, so nobody can help. I
would like to make commits in expermimental branches and the code
could be included in the #next branch. The current branching method is
a binany method. Or the patch is included, or the patch is not
included. Patches should be stable, solve bugs. The #next branch is
only a pre-master branch, so IMO there are no differences between
#master and #next (only, some time).
4. Future. Where we are going? Then, where can we write our ideas, our plan?
kix
"Carlos R. Mafra" <crma...@gmail.com> escribió:
On Mon, 11 Nov 2013 at 9:32:04 +0300, Yury Tarasievich wrote:
I think we have the gist of the problem right there, in the lines
quoted. I see a plain clash of perspectives there.
We *might* benefit from the new ideas, generated in the way of
hobbie or otherwise.
We *would* benefit from general production going forward.
I won't go so far as to declare the "production manager" some sort
of supreme authority. However, it is obvious that not every idea is
bound to make it into the (long-existing) software product, for
which PM is, after all, responsible.
So I'd say there's an *urgent* need for some kind of contribution
rejection procedure. Something like following: (a) Carlos (or
anybody) with his PM's hat on has the first (immediate) say on what
is *not* going in *right now*. (b) However, there also must be an
(almost immediate) request for comments going into the list,
formal-like. (c) If the request gathers no evidence supporting the
innovation, everything stays as it was. (d) Otherwise, steps are
taken etc.
I believe this is simple enough and sufficient to block (or
alleviate) the rise of bad feelings.
But this is what happens already, and this thread illustrates that.
My first reaction to the theming patch is that we don't need it.
The patch is good etc, but the idea behind the patch leads to bloat.
My opinion is that not everything that can be done should be done.
Bloat starts like this: "wouldn't it be cool if...?" and then you
make a small concession because many people appear on the mailing
list and say "yes, it is cool, please do it. It doesn't increase
the size too much."
So in this case, despite the patch being OK I felt
the need to stop the idea. Keep the WINGs widgets as simple as
possible, no choice of colors whatsoever etc. That is what it
has been for the past +15 years already and no one is suddenly
going to dislike WM because the widgets cannot be green or red.
But given the reaction, I am "forced" to accept the patch. There
has even been a suggestion to fork wmaker! And perhaps I'm being
too conservative, so it will be OK in the end. But in any case,
if the repository was only mine the patch would not go in.
So the above situation corresponds to your steps a) - d) above.
What I guess it's happening here is that Rodolfo is complaining
not because of other people's patches, but because his own patches
have a history of a rough ride into the repository. Not everything
he codes I like 100% (I have the impression that he was learning how to
code along the way last year or so), so sometimes there are clashes
and he is fed up. He has a 40-patch series that is not applied yet,
and I'm not sure what to do.
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Rodolfo García Peñas (kix)
http://www.kix.es/
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
