On Thu, 14 Nov 2013 at 11:31:39 +0000, Iain Patterson wrote: > 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.
My point of view is to try to keep wmaker as it is now as hard as possible. I use wmaker because I like it as it is _now_, because of its simplicity. Since Rodolfo is complaining about me I guess I should not say this, but I need to in order to avoid misunderstandings: I don't care too much if we loose a possible user because he does not like how wmaker looks or because wmaker can't do this or that fancy thing. I don't care about software "democracy" either. I care about _current_ users, people who are here in the mailing list writing bug reports or just complaining about some issues. These are the people who decided to use wmaker because they thought it is worth it now, not because they are expecting some new feature some day. One nice thing about wmaker-crm is that by me being the sole committer I could have a way to cut off bloat and things which I don't personally feel are necessary. Regarding the --replace patch I agree that there might be a few users out there who could try wmaker for the first time using the --replace scenario, but I don't think that is an argument why the log off & log in procedure is not the simplest way to go. So there is a pretty straightforward way to use wmaker, just log in to it. That's what we've always done, it's really simple. I understand that Iain spent a lot of time with the patch, and that he is one of the most valuable contributors, but I couldn't change my mind about it. And don't forget that the prospecting users might try wmaker for the first time using --replace and go back to KDE or something. So we actually are wasting resources to a probability scenario. My point of view is that I want to please the current users, because they are _already_ using it due to its _current_ virtues. > > 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. Apart from bug fixes and code cleanups (which are accepted by default), the checklist is subjective. There is no way to guarrantee that a non-bug-fix patch will be accepted or not. The patch must be relevant to everyday usage in a clear way. The --replace and the WINGs theming patches are not that relevant. They will please a few users once or twice in a lifetime, perhaps a bit more, but the point is: who keeps changing the widget colors or trying new window managers from the terminal anyway?. Now compare that with the new maximization state patches. I (for example) use the left/right maximization _every_ single day, that's something that really matters. It affects productivity a lot in a meaningful way. People argue that "new users" will like to change widget colors in the _future_. I argue that old users don't care _now_. So the checklist is subjective but it has a point. Patches that can be used to increase productivity are probably accepted, patches that have no clear impact on productivity (or usage) and increase the number of lines of code are probably not going to be accepted. That's how I try to decide things but it's not always black & white. -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
