Subject: Re: StyleById patch voting thread

From: Olivier Chapuis <[email-masked]>
Date: Tue, 1 Jul 2003 22:28:44 +0200

On Fri, Jun 27, 2003 at 10:07:37PM -0400, Dan Espen wrote:
> Olivier Chapuis <[email-masked]> writes:
> > On Tue, Jun 24, 2003 at 09:39:47AM +0200, Dominik Vogt wrote:
> > > On Tue, Jun 24, 2003 at 06:40:50AM +0200, Olivier Chapuis wrote:
> > > > On Thu, Jun 19, 2003 at 03:51:50PM +0200, [email-masked] wrote:
> > > > > On Sat, Jun 07, 2003 at 07:20:12PM +0200, Olivier Chapuis wrote:
> > > > > > On Mon, May 19, 2003 at 01:44:27PM +0200, Dominik Vogt wrote:
> > > > > > > Should the StyleById patch be applied before 2.6?  Please cast
> > > > > > > your votes here.
> > > > > > 
> > > > > > Seems that there is no conclusion here. It seems that there is two
> > > > > > votes for it (me and Mikhael) one vote against (Dominik) and one
> > > > > > unclear vote (Dan). So I ask for more votes and clarification
> > > > > > (Dan?). For that I send an other version of the patch (attached).
> > > > > > I've followed all the advice (I can follow) that I get in this
> > > > > > thread.  In particular, I've followed all the remarks (as I can) of
> > > > > > Dominik regarding the code.
> > > > > 
> > > > > > So, Dominik I even hope you revert your vote (very little hope
> > > > > > ...).
> > > > > 
> > > > > I don't know about your hope, but the chance that I do is zero. It
> > > > > is not the right time.
> > > > 
> > > > The reason of my hope is that the new version of the patch take in
> > > > account the reasons why you reject it.
> > > 
> > > Nothing on earth can make me agree to adding huge features in
> > > feature freeze.
> > 
> > It is not a huge feature, it is one of the few features that fvwm miss
> > to become a perfect window manager. So let us have it!!
> 
> Looking at the patch, I agree, its not huge.
> Its not minor either.
> 
> > > > You give 7 arguments.  The new patch handle arguments 3, 4 and 6.
> > > > Moreover, I've worked on argument 5 and style list
> > > > simplification has been improved.
> > > 
> > > As I said before, I reject making facts now that can never be
> > > changed again.  The way the style list works has always been a
> > > mistake.  No matter how much time you spend on optimising the
> > > style list code, it will always be a memory leak.  This logic is
> > > due for replacement, not for expansion.
> > 
> > I will say that this has almost nothing to do with the WindowStyle
> > cmd. This is a general problem regarding styles. Any way, I will
> > be interested to see a natural situation where the style list
> > go to infinity (with a fixed number of names). 
> 
> I don't agree that the Style code is fundamentally broken.
> But I know from past experience that Dominik's standards are
> higher than mine.  To me, the style code does the job
> so I don't see a problem with it.  The way matches work
> may seem odd, but I don't think there's a better way.
> 
> I don't understand the comment about the memory leaks.
> I remember Dominik doing some work to combine styles as they
> were issued.  There shouldn't be any leaking going on.
> 
> > > > About 1 and 2 I can just say that I do not _think_ that the
> > > > patch can cause instability.
> > > 
> > > It has already consumed much time in pointless arguments that
> > > could have been spent stabilising the code.  There is a direct
> > > relationship between my motivation to work on the remaining
> > > problems and the amount of distractions on this list that have
> > > nothing to do with it.
> 
> > > > Finally, I do not understand argument 7.
> > > 
> > > It's an ad-hoc syntax that *will* be thrown away right when we
> > > start thinking.  I have many enhancements in mind that have no
> > > chance of being implemented with this kind of just-throw-in-a-new-
> > > command-whenever-it-seems-to-work-for-the-moment approach.
> > 
> > I do not see the problem. If I follow your logic the Style command
> > will drastically change. Moreover, I cannot imagine that we
> > rework the style stuff and that at the end it will be not possible
> > to set "window attributes" on a given window.
> > > > But, maybe the most important is that there is 4 votes for the
> > > > patch (Dan, Mikhael, Olivier and Tim) and one vote against (Dominik).
> > > 
> > > Of course Dan can speak for himself, but according to the mail
> > > archive he did neither vote for nor against the patch.  Not that I
> > > think it matters.
> > 
> > In general Dan does not vote. He gives arguments. At the end there is
> > no arguments against. But yes it is possible that Dan use abstention.
> 
> I agree with Dominik, my vote hardly matters.
> As I said before, I think votes should be in proportion to contribution.
> 
> In this case, I've been agreeing with both sides.
> Dominik has some very good points.
> I don't agree about the Style code being a problem and therefore
> shouldn't be extended, but I do agree that we need to freeze
> features to create a stable release.
>

I am not agree with this. I think the code is safe. I do not
"understand" Dominik arguments against the patch (second version).
We have always added feature during feature freeze. Note also that
you can add bugs when you fix a bug... Currently, the existence of
the patch allowed to fix a few bugs! 

> I think Oliviers point about this nicely rounding out
> the feature set, and not being a big change is
> very good.  Also, he supplied test cases, so
> it shouldn't hold back 2.6 on that account.
> 
> > > > So, I think we should apply the patch.
> > > 
> > > Then take the consequences and abandon the idea of a stable 2.6
> > > release.
> > 
> > Why?
> 
> I don't want to put words in Dominiks' mouth, but I think
> he's been pretty clear, he doesn't want this patch applied.
> See his sentence above about motivation.
>

Should I use similar arguments? At the present time I will not.
 
> Considering Dominik's strong opinion, it might be a good idea
> to hold that patch for a while.
> Use your judgement.
> 
> Did I vote?
> 
> I guess I should, even if it doesn't count for much.
> 
> Damn, I can't make up my mind.
> I give up, I was hoping I could come up with some argument
> or line of reasoning that would settle this, but I admit,
> its beyond me.  I'm not going to vote.
> 
> Try to see the other persons viewpoint and then ask yourself,
> can I give in on this a little for the sake of the team.
> 

This is the only argument I see to do not apply the patch.
So now if the patch is not applied what I've to do with it?

Regards, Olivier
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Dan Espen <[email-masked]>
Date: Tue, 01 Jul 2003 18:16:03 -0400

> > to hold that patch for a while.
...
> So now if the patch is not applied what I've to do with it?

Anyone object to a CVS branch?

-- 
Dan Espen                           E-mail: [email-masked]

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 4 Jul 2003 11:10:24 +0200

> the patch allowed to fix a few bugs! 

I do not remember adding any new feature in feature freeze without
a very good reason why it has to be in the release.  I see none
here.  Fvwm existed ten years without window specific styles.
What is the reason why we can not live without the patch for some
more months?
 
> So now if the patch is not applied what I've to do with it?

I have held back dozens of patches for the sake of the feature
freeze and it's no fun for me either.  I refuse to abondon my
notion of software quality for the sake of making the developers
happy.  But of course I can't stop you from doing what I think is
wrong.  Take fvwm and have fun with it.  I give up.

Bye

Dominik ^_^  ^_^