Subject: Merged branch for further development

From: Dominik Vogt <[email-masked]>
Date: Thu, 29 Oct 1998 08:23:08 +0100

Hi all,

I have merged the animate_icons and menu_position branches
into a new branch called 'animicons_menupos'. Further
testing and development should go against this branch
and not it's two parent branches anymore (this does not
affect creationb of new branches however).

The reasons for this step are

1) Common code base for further development. New branches
   can be created from this branch.

2) More important: common base for testing. In the end
   it's the merged code of all branches that must work,
   not just any single branch.

3) Not so important: easier to access than it is to
   create merges every time there has been a change in
   any branch (I think we will soon have branches for
   autoconf and German's patches).

Bye

Dominik
-- 
Dominik Vogt, Hewlett-Packard GmbH, Dept. BVS
Herrenberger Str.130, 71034 Boeblingen, Germany
phone: 07031/14-4596, fax: 07031/14-3883, [email-masked]
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
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: Thu, 29 Oct 1998 08:16:29 -0500

>    autoconf and German's patches).

I still think you're  using the CVS  tool the wrong way.  Please think
about it.  I don't see how  combining the branches into another branch
simplifies the process significantly.

I'm willing to give it a try though.

--
Dan Espen                                Phone: (732) 699-5570
444 Hoes Lane  Room RRC 1C-214           E-mail: [email-masked]
Piscataway, NJ 08854
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
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: Dominik Vogt <[email-masked]>
Date: Thu, 29 Oct 1998 15:14:34 +0100

> simplifies the process significantly.

Oh, there is not much of a practical reason behind it.
The code had to be merge somewhere and I did not want
to make a decision as final as putting it all in the
main branch.

In the future we could do the following:

- Basing on a labeled beta revision (like 2.0.47d,e,...)
  be create branches containing the new features (like
  menu_position and animate_icons).

- When we want a new beta we decide which branches go
  in there and merge them together in a new branch for
  the merge (perhaps called 'merge_2.0.47e').

- After testing that this branch works and possibly
  fixing bugs we merge the merge-branch into the
  main branch and give it the next label
  (2.0.47e in this example).

This way we end up with lots of dead branches, but that
is what is to be expected if every developer make his
own branches, isn't it?

What do you say, can we work this way or is it complete
rubbish?

Bye

Dominik

---

From: Steve Robbins <[email-masked]>
Date: Thu, 29 Oct 1998 10:29:50 -0500 (EST)

>   (2.0.47e in this example).

Aye, there's the rub: how rigorous will said testing be?  With a zillion
branches, how many people will be willing to download and test each of
them?  Or any of them?

My hunch is that more people are willing to download and test a beta or
even the mainline CVS code.  Probably "a lot" more people.  If we build a
long skinny tree, rather than a bushy one, there is more focus on the
experimental code.  

It is true that trying to do 2 or 3 things at once on the main trunk is
more likely to lead to unstable code.  But that's what "alpha code" 
means, right?  As long as we move fast enough to stabilize the code, it
should be doable.  Other groups (say the linux kernel) pull off this trick
regularly.
 
--
Steve Robbins                              <[email-masked]>

A man came up to me and said, "I'd like to change your mind,
by hitting it with a rock," he said, "though I am not unkind."

---

From: Dan Espen <[email-masked]>
Date: Thu, 29 Oct 1998 11:22:20 -0500

Dominik Vogt <[email-masked]> writes:
> ...

At least one other person seemed to support the branching plan
you implemented.  Therefore I take back everything I said.

Lets go with it.

---

From: Jason L Tibbitts III <[email-masked]>
Date: 29 Oct 1998 14:16:41 -0600

>>>>> "SR" == Steve Robbins <[email-masked]> writes:

SR> Aye, there's the rub: how rigorous will said testing be?  With a
SR> zillion branches, how many people will be willing to download and test
SR> each of them?  Or any of them?

I think the idea is to branch only rarely, when you want to make and share
relatively disruptive modifications.  Branches should not last long: a
month at most, and should be rebranched from the trunk (that is, have all
changes made on the trunk after the original branch point merged in) once
per week.  Unless, of course, development slows down quite a bit.

We don't want zillions of branches.  Folks just working on modules
shouldn't need to branch unless they are changing the module interface, and
that needs to be discussed anyway.  Things like a rewrite of the menu code
or modularization of the window decorations or the GSFR need a branch,
unless you want to just halt other streams of development for a bit while
the changes go in.  This may be worthwhile for autoconf since the work is
pretty much done.

Modifications made to a branch need to be related _only_ to the purpose of
the branch.  If you need to fix a bug on the main branch, check out a copy
of it, make and commit your change, then merge the trunk back into your
private branch.  (Sorry, I'm not enough of a CVS expert to give command
lines.)

SR> It is true that trying to do 2 or 3 things at once on the main trunk is
SR> more likely to lead to unstable code.  But that's what "alpha code"
SR> means, right?

The problem with doing this is that the developers step all over each
other.

SR> Other groups (say the linux kernel) pull off this trick regularly.
 
But that is a different environment.  Plus a whole bunch of it does go on
in the VGER tree, with the final results being sent to Linus.

 - J<

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 30 Oct 1998 15:11:46 +0100

After thinking much about the versioning issue discussed in 
several threads I have the following proposal how we could
do this:

(In this example I use some future revisions: 2.2.x for
the next stable and 2.3.x for the beta releases; [X]
denotes a reference to the picture below).

Versioning/development takes place in three different
branches in CVS:

- The main branch holds *always* the latest stable
  release and *nothing* else. The second component of
  a stable release is an even number.
  Example: 2.2.0 [A]

- The beta branch *always* holds the current beta version
  and *nothing* else. It is split off from the main
  branch when a new official release with the third
  component being 0 is made (e.g. 2.2.0, 2.2.4).
  Example: 2.3.0 [B]

- The alpha branch is the one in which the development
  actually takes place. It is split off from the beta
  branch immediately after a new beta branch has been
  created and gets the labels <x.y>_alpha_start, the
  sticky label <x.y>_alpha and similar start label with
  an additional '.0'
  Example: 2.3_alpha, 2.3_alpha_start and
           2.3.0_alpha_start [C].

The main and beta branch are always tared an published
on the web. They advance in the third component during
a development cycle.

The main (stable) branch gets bugfixes only, new features
usually go into the beta branch [D].

The beta branch is synchronized with the alpha branch for
new beta versions regularly, but the alpha branch is not
closed now [E].

When the next major stable release is pending, the alpha
branch is closed and finally merged into the beta branch
[F]. At this moment the beta branch is labeled <x.y>_beta
(sticky). During a beta tesing phase no development is
done at all [G]. Only bugfixes are integrated into the
beta.

When the beta is stable, the beta branch is closed and
merged into the main branch [H]. The main branch gets
a new second component number, the third number is reset
to zero and the cycle starts again.

Separate development branches:
------------------------------
Development for larger changes takes place in separate
branches split off from the current beta branch [I].
They may take some time and will finally be closed and
merged into the current beta branch and a new version
number is given to the beta branch [J]. Wehn this has
happened the alpha branch must be synchronized with
the new version in the beta branch [K].

You might object that not merging the feature branch
with the alpha branch may cause confusion. This is
true, but the win is that the developer of the
feature branch has less work when trying to merge it.
Merging small changes is usually easier than merging
a large patch, and this simplifies it somewhat.

Now the figure:
---------------

+ in the tree denotes a new label
* before a name denotes a sticky label

   main branch
        |      development branch
        |              
  2.2   +--------------+ 2.3.0
  2.2.0 |              | [B]
  [A]   |              |
        |              |              2.3_alpha_start
        |              |             *2.3_alpha             feature_A_start
        |              |              2.3.0_alpha_start    *feature_A
        |              |--------------------+---------------------+
  2.2.1 +              |                 [C]|                  [I]|
        |              |                    |                     |
  2.2.2 +              |                    |                     |
  [D]   |              |                    |                     |
        |        2.3.1 +<-------------------| 2.3.1_alpha_start   |
        |              |[E]                 |                     |
        |              |                    |                     |
        |              |                    |                     |
        |              |                    |                     |
  2.2.3 +              |                    |                     |
        |              |                    |                     |
        |              |                    |                     |
        |              |[J]                                       |
        |        2.3.2 +<------------------------------------------
        |              | 
        |              |                    |
        |              |------------------->+ 2.3.2_alpha_start
        |              |                 [K]|
        |              |                    |
        |              |                    |
        |              |                    |
       ...            ...                  ...
        |              |                    |
        |              |                    |
        |              |                    |
  2.3.x +              |[F]                 |
        |        2.3.y +<--------------------
        |    *2.3_beta |
        |              |
        |              |[G]
        |     Beta tests and bugfixes
        |              |
        |              |
  2.4.0 +<--------------
  [H]   |
        |
        |
   (and again from the start)

-----------------------------------------------------------------

What will we do to switch to this scheme:
-----------------------------------------

- There will be no 2.0.47.

- The current animicons_menupos branch is closed and
  merged into the main branch.

- The main branch is labeled '2.0_new'.

- The beta branch is opened according to above plan
  and labeled 2.1.0.

- Steve merges the changes for autoconf into the 2.1.0
  beta branch and we relabel it as 2.1.1.

- We tar the 2.1.1 beta branch, put it on the web and
  announce it very soon.

- The alpha branch is opened and labeled.

- Other changes go into the alpha branch (like the myriad
  of smaller patches or Germans patches). New beta versions
  are packaged, announced and put on the web.

- When we have implemented the changes we want, the
  alpha branch is closed and official beta testing
  commences.

- When the beta is stable enough, the beta branch is
  closed and 2.2 is 'shipped'.

If there are no serious objections to this plan I will
begin the restructuring on saturday afternoon (GMT).
OK, I know this is not much time, but I am conviced
at least Steve, Dan and Jason will have time to
react. Please reply as fast as possible so we can get
this smooth soon.

Bye

Dominik

---

From: Steve Robbins <[email-masked]>
Date: Fri, 30 Oct 1998 09:10:28 -0500 (EST)

On 29 Oct 1998, Jason L Tibbitts III wrote:

> per week. [ ... ]

Yes, possibly.  

I actually had in mind that there would be ONE person checking stuff into
the main trunk, incorporating changes for 2 or 3 different goals, perhaps
taking patches from others.

Your suggestion of several parallel branches with frequent merges is
another method of obtaining the same effect: the focus is still on the
main line of development.  I was questioning Dominik's implication that
that you could have several parallel lines of development going, and only
merge when a branch was "well tested".

There's a little bit of Elvis in everybody.
Except Michael J. Fox -- he's the anti-Elvis.

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 30 Oct 1998 15:30:27 +0100

One small additional comment:

This plan does not conflict with Steve's pumpking idea.
The pumpking would maintain the beta branch for a while
and possibly own the process of closing the alpha or
beta branch. The main branch does not need much attention
because it just gets bugfixes (that hopefully go into the
beta branch too).

Come to think of it: Since the main branch would be
thrown away when the beta is merged in it does not
make much sense to put the stable stuff into the main
branch.

This modification of my scheme would do it:

the main branch is always the beta branch. Upon
creatin of the new major stable code a 'stable'
branch is split off from the beta and not the
other way round:

                   main branch = beta branch
                        |
  stable branch         |
       2.2 +------------+2.3.0
           |            |
           |            |
          ...          ...
           |            |
          end           |
                        |
                        |
       2.4 +------------+2.5.0
           |            |
           |            |
          ...          ...

Bye

Dominik

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 30 Oct 1998 15:46:13 +0100

And an even smaller addendum:

One (in my eyes) big advantage of the revisioning plan
is the start of a new numbering. People will know
immediately that there has been a substantial change.

Bye

Dominik

---

From: Steve Robbins <[email-masked]>
Date: Fri, 30 Oct 1998 10:03:51 -0500 (EST)

>   Example: 2.3_alpha, 2.3_alpha_start and

OK, you have listed three branches and no main trunk.  There is little
reason to do this with CVS.  What you probably mean to do is use TAGS
rather than BRANCHES.  Tags are your friends!

As I understand it, "standard" way to use a CVS repository is to do all
development (save, perhaps some wildly disruptive changes) on the main
trunk.  When the sources are in a state that you want to release (either
as "beta" or "stable", you just TAG the repository.  There is no need to
branch.  Work continues on the main trunk.

Now, suppose that two months after the release of "version 1.2", a serious
bug is discovered.  You'd like to fix it, but the current trunk is nowhere
near releasable.  

   Consider this revision tree:

     +-----+    +-----+    +-----+    +-------+
     ! 1.0 !----! 1.2 !----! 1.3 !----! 1.3.1 !      <- The main trunk
     +-----+    +-----+    +-----+    +-------+

What do you do?  NOW you make a branch.  Suppose version x.y of the
sources are tagged as "version-x-y" (periods are not allowed in symbolic
tags).  You issue the command

	cvs rtag -b -r release-1-2 release-1-2-fixes fvwm

to create the branch rooted at version 1.2.  Now you can check out the
"fixes" branch with

	cvs checkout -r release-1-2-fixes fvwm

This gives you the sources as they existed in version 1.2.  It also makes
the tag "release-1-2-fixes" sticky.  

>From what you wrote, it's not clear you understand stickiness.  (Not
surprising, since it's a weird concept)  Stickiness is not a property of
tags in the repository, it is a property of tags IN YOUR CHECKED OUT
SOURCES.  Checking out a branch by tag name makes that tag sticky.  In the
example above, that's what we did, using the "-r release-1-2-fixes"
option. 

So now you fix the bug, and commit the sources.  Since our version has a
sticky 'release-1-2-fixes', the commit goes to that branch, creating the
following revision tree:

     +-----+    +-----+    +-----+    +-------+
     ! 1.0 !----! 1.2 !----! 1.3 !----! 1.3.1 !      <- The main trunk
     +-----+    +-----+    +-----+    +-------+
                     !
                     !
                     !   +-------+
     Branch       -> +---| 1.2.1 |
   release-1-2-fixes     +-------+

Now we tag the sources as 'release-1-2-1', and publish that new version
in a tar file.  If another bug needs to be fixed in 1.2.1, you simply do:

	cvs checkout -r release-1-2-1
[hack on sources]
	cvs commit

Now suppose you want to merge the changes into the main trunk.  You first
need a copy of the main trunk sources.  Do this using '-A' to get rid of
all sticky tags in your copy of the sources:

	cvs update -A

If you want *all* the changes on the "fixes" branch merged into the code,
you do

	cvs update -j release-1-2-fixes 
or even
	cvs update -j release-1-2-fixes file1 file2 ...

to selective apply the patches.

More likely, you will be merging back after every release of 1.2.x.  In
this case, you do

	cvs update -j release-1-2-x -j release-1-2-(x+1)

to merge the changes made between 1.2.x and 1.2.(x+1).

> on the web. They advance in the third component during

OK
 
> usually go into the beta branch [D].

Agreed.
 
> new beta versions regularly, but the alpha branch is not

Here I disagree.  There is no need for "alpha" and "beta" branches.  The
current head is the "alpha" branch.  What you are calling a beta branch is
really nothing more than a particular version of the sources TAGGED as
"release-2.3.x", say.  The alpha versions will not be tagged.  If you
really want to roll back to a previous alpha version, you can do so by
checking out with a particular date & time.  (example: "cvs checkout -D
yesterday") 
 
> done at all [G]. Only bugfixes are integrated into the

Too complicated.  Just freeze code development on the head until
satisfied, TAG it as "release-2-4-0", publish the tar file, and continue
on the head branch.  As I explained above, this is sufficient to be able
to go back and fix a bug to create version 2.4.1.
 
> Separate development branches:  ------------------------------
> Development for larger changes takes place in separate branches split
> off from the current beta branch [I].  They may take some time and will
> finally be closed and merged into the current beta branch and a new
> version number is given to the beta branch [J]. Wehn this has happened
> the alpha branch must be synchronized with the new version in the beta
> branch [K]. 

For large changes, a separate branch could be used, I grant you.  This is
the conversation I was just having with Jason Tibbits.
 
> You might object that not merging the feature branch with the alpha
> branch may cause confusion. This is true, but the win is that the
> developer of the feature branch has less work when trying to merge it. 
> Merging small changes is usually easier than merging a large patch, and
> this simplifies it somewhat. 

It isn't confusion that I foresee.  It is the false hope that the feature
branch developer has, in assuming that many people have checkout his
branch and tested it.

Nor do I see that there is less work in merging it back.  As you say,
merging small changes is easier.  The longer the feature branch is left
separate the larger the code drift.  So I suspect there may be MORE work.

But I am not at all opposed to people using feature branches!  I just
think it creates false hope.  I will be opposed when someone says "I have
been hacking on the branch for feature X for N months now.  There have
been no problems reported, so I believe the code is reliable enough to
include in the stable release next week."

Speeding motorcycle ... won't you take me ...

---

From: Steve Robbins <[email-masked]>
Date: Fri, 30 Oct 1998 10:08:42 -0500 (EST)

> What will we do to switch to this scheme:

I really think we ought to release something called "stable" right now.
It is not clear to me that the "animate icons" and "menu positioning" is
well enough tested to be called stable.

I do think the autoconf *is* reasonably tested: it has been out for about
10 months now, in the 2.0.46 form.  There should be some more discussion
about installation decisions, but I believe it is usable.  Or at least
more usable than the Imakefiles, IMO.

Is there something wrong with this?
I don't see how there possibly could be:
The waterbed's on fire, 
but everything else is as it should be.

---

From: Maciej Stachowiak <[email-masked]>
Date: Fri, 30 Oct 1998 10:18:49 EST

>   component being 0 is made (e.g. 2.2.0, 2.2.4).

Most people do this the other way around, i.e. latest development is
on the head, and incremental improvements or bugfixes to a stable
release or on a branch. There are many reasons why this makes sense.

 - Maciej

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 30 Oct 1998 16:30:33 +0100

> release or on a branch. There are many reasons why this makes sense.

Yup. If you read my own comments on my suggestion you will see
that I already recognised my error.

Bye

Dominik

---

From: Dan Espen <[email-masked]>
Date: Fri, 30 Oct 1998 10:43:41 -0500

> react. Please reply as fast as possible so we can get

What to do? What to do?  Jeez, the pressure is killing me.  :-)

I'm pretty sure I don't ever want to be Pumpkin.   (Also humor.  After
Dominik works   this out, I  think  this can  be a  pretty streamlined
process.)

We seem to be  in a race  between getting configure  in and  a release
out.  If so, I vote for waiting for configure.

Why?   I'm tired   of fvwm95 having   configure  and fvwm2 not  having
configure.

Am I wrong, or  has the activity  on  the fvwm  list (not  the workers
list) dropped to zero?

---

From: Tim Phipps <[email-masked]>
Date: Fri, 30 Oct 1998 15:56:39 +0000

> out.  If so, I vote for waiting for configure.
Me too.  It's a lot easier for most people and a release will hopefully
attract more people than just the worker list members.

> Am I wrong, or  has the activity  on  the fvwm  list (not  the workers
There is stuff going on.  Lots of problems/bugs with 2.0.46, some
patches and notably the SnapAttraction patch/command which is well
funky.

Cheers,
Tim.

---

From: Brad Giaccio <[email-masked]>
Date: Fri, 30 Oct 1998 11:00:44 -0500 (EST)

> patches and notably the SnapAttraction patch/command which is well
The FocusDir patch is nice too, and it fit almost perfecttly into 2.0.47

Brad

-- 
--- There are two kinds of knowledge, you either know the answer or
			you know where to find it
		      -Kane, Johnson, and anonymous

---

From: Dan Espen <[email-masked]>
Date: Fri, 30 Oct 1998 11:00:25 -0500

> patches and notably the SnapAttraction patch/command which is well

Hmm.  I wonder when I got unsubscribed to that list?
Perhaps someone over there got tired of listening to me, and
decided to unsubscribe me...

Guess I better re-subscribe.

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 30 Oct 1998 17:02:48 +0100

On Fri, Oct 30, 1998 at 10:03:51AM -0500, [email-masked] wrote:
> OK, you have listed three branches and no main trunk.

When I say 'main branch' I mean the same thing you call
'main trunk'.

> There is little reason to do this with CVS.  What you
> probably mean to do is use TAGS rather than BRANCHES.

No, I mean branches. I see no reason to mix up alpha,
beta and stable code all in one branch. No one will
have an overview of who is developing where and what
the stable/beta releases are.

> trunk.

Agreed (see my followups on my own posting).

> When the sources are in a state that you want to release (either

> What do you do?  NOW you make a branch.

And how would you find that branch in the repository? Nobody will
know that there is a 'stable' branch somewhere in the tree (or do
not take the effort to ckeck if there is one). And the next person
would create another 'stable' branch?

> example above, that's what we did, using the "-r release-1-2-fixes"

OK, I misunderstood this. But this has little impact on my proposal.

> sticky 'release-1-2-fixes', the commit goes to that branch, creating the

As I said, in a tree as busy as the fvwm tree you will lose overview
fast if we do this.

> to selective apply the patches.

I would *never* want to merge fixes from the 'stable'
version into the beta code!

> > usually go into the beta branch [D].

If you agree here you disagree with your own branching idea
above.

> "release-2.3.x", say.  The alpha versions will not be tagged.

The branches cost us nothing. The advantage of separate branches
is that you know immediately where the current stable/beta
versions are. The alpha branch would be the 'playground' for all
the new features. If we put everything into the main branch
immediately we have no control over what goes into the code and
what doesn't.

> If you really want to roll back to a previous alpha version, you can do so by

That does not work. You would have to know the exact time
you wanted because you can never be sure if someone checked
something in in the meantime. I think Dan's idea with a
'_start' tag was a good one.

> on the head branch.

And how would you do this? Just write a mail and hope everybody
reads it in time? This won't work because we cannot communicate
this well enough.

> branch developer has, in assuming that many people have checkout his

Nope, in my eyes branches for feature development are not
tested at all (except perhaps by volunteers). What you need
is a place where the developer can store his code and update
it with new betas. I wouldn't want anybody to waste time
testing my development branch until I ask for that or I
say it is ready.

> Nor do I see that there is less work in merging it back.

OK, probably. It is better to merge the feature branch into
the alpha branch.

> The longer the feature branch is left

Yes, but what can I do if I need two months to write my changes?
I can not influence how much work it is anyway.

> include in the stable release next week."

See above.

---------------------------------------------------------------

I know, usually you work with a version control system on
the main branch and label revisions there. The reason behind
my proposal is: 

I do not believe we can guarantee betas that even compile
at any time if everyone is working on the same files in
parallel (and there are not many files in the main code
for example). You couldn't even be sure that what you check
out compiles. At work we use strict locking policy for
our vcs and still this happens often.

Bye

Dominik

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 30 Oct 1998 17:07:58 +0100

> more usable than the Imakefiles, IMO.

The problem is not that autoconf may not be tested properly.
It's 2.0.47 that has not been tested enough. Just have a
look at the file 'fvwm/README.position' within you will find
more than 20 bugs I fixed in the old menu_position branch
and at least four or five of them were really serious
(and I'm only counting cordumps, not memory leaks or
anything). I cannot agree that we say this code is stable
before there has been proper testing. The presence of a new
beta alone with a completely new version number will give
a signal to the world that something is happening here.

Bye

Dominik

---

From: Dan Espen <[email-masked]>
Date: Fri, 30 Oct 1998 11:11:16 -0500

> '_start' tag was a good one.

Just  to  keep the record  staight,  the "_start" tag  was  based on a
recommendation from Andy Mortimer.

By the way,  I didn't seem to see a start tag on animicons_menupos.

When I get time, I would like to  create some documentation on our CVS
procedures.  (Anyone  else  is welcome to   do  it instead  of  me.  I
haven't started yet.)

What    commands  did you  use   when you   combined animate_icons and
menu_position into animicons_menupos?

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 30 Oct 1998 17:17:21 +0100

> Dominik works   this out, I  think  this can  be a  pretty streamlined

It seems we will have a little delay until Steve and I reach
an agreement.

> out.  If so, I vote for waiting for configure.

I don't see this as a race. It has been ages since a release and I see
no reason why we should put pressure on ourselves to get the new
release. The code is probably not stable enough and needs a beta test.
Period. So there is enought time to encompass autoconf.

----------------------------------------------------------------------

Can I take your answer as an agreement that we could implement
my plan?

Bye

Dominik

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 30 Oct 1998 17:29:35 +0100

> menu_position into animicons_menupos?

Err, thought I created this tag. I used the commands from
one of your early posings where you described how to branch
under CVS, first creating the _start tag and then the
real tag based on this. I have no clue why this failed.

Bya

Dominik

---

From: Dan Espen <[email-masked]>
Date: Fri, 30 Oct 1998 11:58:35 -0500

> Period. So there is enought time to encompass autoconf.

Frankly,  my  eyes glaze  over  whenever I   see a  project plan.  (It
happens at work too.)

I  think releasing one beta  without  configure, followed closely by a
release with  configure will be too  confusing.  I think, by including
configure, we  also send a clear message,  that this is  a new dynamic
fvwm2 team that doesn't get patches and then sit on them for ages.

I only wish Bob  Woodside would get  update  access and  re-provide us
with "Starts on Page".

I'm not too   concerned  about the  stability  issues that  have  been
brought up:

1) Greg's menu code has been around a long time without anyone finding
a "showstopper"   type   bug.  (DestroyMenu    didn't work,  but   the
workaround is pretty simple.)

2) Animate menus is a module, if it  doesn't work, don't  use it.  The
changes I made to the  core of fvwm2  to support it are fairly simple,
and have been a part of Afterstep for quite a while.

3) Configure is pretty well tested as a patch.

4) Menu positioning hasn't broken anything in my environment.

5) I think we can respond to bug reports in a  matter of hours, if not
minutes.

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 30 Oct 1998 18:20:07 +0100

> fvwm2 team that doesn't get patches and then sit on them for ages.

No, the 2.1.0 shall be created only to start the new numbering scheme.
The first real release will be 2.1.1 with 'anim_menu' AND autoconf.

> I only wish Bob  Woodside would get  update  access and  re-provide us

I have no objections.

> workaround is pretty simple.)

Then you should really have a look at fvwm/README.positions. You
said yourself that you didn't like the beta tests on the workers
list because they didn't find many problems. From just looking at
the code I know how to produce at least half a dozen coredumps
in the main code plus two modules (Pager and Buttons) (before my
fixes).

> 4) Menu positioning hasn't broken anything in my environment.

Nice to hear that, but I would not rely on that. You probably
haven't tested it thoroughly.

Bye

Dominik

---

From: Dan Espen <[email-masked]>
Date: Fri, 30 Oct 1998 13:40:24 -0500

> The first real release will be 2.1.1 with 'anim_menu' AND autoconf.

I'm concerned  about the releases that are  announced to the fvwm list
vs.   the fvwm-workers list.   In effect we have  had  about one dozen
releases announced to the fvwm-workers release in the last week or so.
If 2.1.0 is a dry run for  the workers list only,  I see no problem at
all.

If we  are going to   have a large group  of  non-developers build one
release with Imake followed closely by another release with configure,
I think that  could cause some  confusion.  (I still wouldn't have any
strong   objection,  if that   is the  plan.    We don't need absolute
concensus to proceed.  That would make our team effort unmanageable.)

> in the main code plus two modules (Pager and Buttons) (before my

I read it before, but I thought some of you might like a summary:

  Core dumps: 4
  Stange behavior: 11
  Bad message: 1
  Potential Problems: 3
  Memory Leak: 1

All and all, a pretty good job of bug repair...

But my point  was, providing the users  config files are correct,  and
they  avoid strange mouse/keyboard  operation,  fvwm2 menus  work much
better than they did before, and none of  these problems should really
scare a beta tester off.

Always remember, based on the fvwm2 man  page, there are either 39.342
or 3.4028e+38 unidentified bugs in fvwm2.

> haven't tested it thoroughly.

You're right, I haven't tested it at all except  to make sure my menus
still work as before.

---

From: [email-masked] (Paul D. Smith)
Date: 30 Oct 1998 13:48:34 -0500

%% Dominik Vogt <[email-masked]> writes:

  dv> the main branch is always the beta branch. Upon
  dv> creatin of the new major stable code a 'stable'
  dv> branch is split off from the beta and not the
  dv> other way round:

  dv>                    main branch = beta branch
  dv>                         |
  dv>   stable branch         |
  dv>        2.2 +------------+2.3.0
  dv>            |            |
  dv>            |            |
  dv>           ...          ...
  dv>            |            |
  dv>           end           |
  dv>                         |
  dv>                         |
  dv>        2.4 +------------+2.5.0
  dv>            |            |
  dv>            |            |
  dv>           ...          ...

Yes, I think this is the right way.  This is the way almost all other
net-centered open development projects I'm familiar with work.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <[email-masked]>         Network Management Development
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
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: Steve Robbins <[email-masked]>
Date: Fri, 30 Oct 1998 23:49:23 -0500 (EST)

> When I say 'main branch' I mean the same thing you call

OK.

I am just following the CVS docs, by the way, which use "branch" to really
mean a branch off the main line of code development. 
 
> And how would you find that branch in the repository?

It will be tagged in a standard way that makes it trivial.  

I like to be verbose and use "release-x-y-z".  Paul S, on the other hand,
has suggested R_x_y_z.  It is of little importance as long as it is used
CONSISTENTLY, is reasonably MNEUMONIC, and is well DOCUMENTED. 

> Nobody will

There is potentially a branch for each family of stable releases.  By
"family", I mean versions 2.2.0, 2.2.1, etc.  Development on the beta
2.3.x series continues on the main trunk.  When the 2.3 series is frozen
and becomes 2.4.0, a new branch may start from there.  A branch is only
required if some fixes to the release are to be made. 

> version into the beta code!

Right, and that's what I said.  The cvs commands apply the changes from
the "fixes" branch onto the main trunk.
 
> If you agree here you disagree with your own branching idea

Ugh.  I wrote too quickly.  The sentiment I agreed with is: 

	The stable branch gets bugfixes only, 
	new features on the beta line of code.

Upon reflection, though, I don't see a problem with incorporating some
"minor" features from the main trunk between stable releases.  

> versions are.

You know where each stable & beta version is by virtue of TAGGING the
code.  Whether you then create a branch rooted at that version or not is
irrelevant.  You can always do it at a later time, if need be. 

What I and Paul S and Maciej S are pointing out is simply that you don't
NEED to create a branch UNLESS you are going to further develop that line
of code.  A branch for bugfixes of a "stable" release is an example.

> '_start' tag was a good one.

1) I am going to assume that people know how to update ChangeLog before
a checkin.

2) If (1) is too optimistic, you can always do a "cvs diff" to find out
just what changed.  See also "cvs log" and "cvs annotate".  It's not
impossible to figure out what's going on. 

> reads it in time? This won't work because we cannot communicate

Well, Paul S indicates that other groups do development this way.  I
assume it is by email.  I don't have any direct experience in this,
however. 
 
> testing my development branch until I ask for that or I

As I say, I'm not opposed to this.  I think, however, it is only useful
for really LARGE changes in the code base.  Most small stuff should just
go on one single development line on the main trunk. 

If I had a rocket launcher, some son of a bitch would die.

---

From: Steve Robbins <[email-masked]>
Date: Sat, 31 Oct 1998 00:03:21 -0500 (EST)

On Fri, 30 Oct 1998, Dominik Vogt wrote:

> It's 2.0.47 that has not been tested enough. 

OK.  It doesn't have to be based on 2.0.47, then.  I have a autoconf'd
2.0.46; do you think that's stable enough to call 2.2.0?  

If need be, I'll back-port the autoconf to 2.0.45, or whatever version
seems solid.  

To repeat: 

(1) It seems vital to me to have a "stable" version out now, to stop
people from thinking "beta = stable". 

(2) I would rather not have code added in the last few weeks be included
as "stable".

Perhaps we can decide on which of the last few beta versions is the most
solid, (maybe the debian guy lurking on this list can speak to this?)  and
just re-label it as 2.2.0.  

I would also argue for patching in autoconf for 2.2.0, but that's not
vital to me. 

Too cool to live -- too smart to die.

---

From: Austin Donnelly <[email-masked]>
Date: Sat, 31 Oct 1998 20:12:02 +0000

> (2) I would rather not have code added in the last few weeks be included

I agree!  Code should be given time to "mature" before putting it out
as stable.

> just re-label it as 2.2.0.  

Debian has been using 2.0.46 for quite a while now, both on i386 and
Alpha.  The m68k people might also have it going.

The majority of outstanding 'bugs' against 2.0.46 are cosmetic, and
don't lead to segfaults:

These bugs are ones I've reported to this list before, so I'll just
summarise:

#8774: glitch in windowlist menu
  emacs "*scratch*" buffer with icon named "scratch" on path causes
  windowlist menu to have unwanted icon.

#9769: fvwm2: SkipMapping loses current focus
  bad interaction with ClickToFocus, StartsOnDesk, and SkipMapping

#21547: fvwm2: submenu positioning wrong when parent menu called from a button

#23759: fvwm2: MWMButtons doesn't look at MWMDecorMax
  MWM hints aren't being honoured correctly in ButtonStyle commands

Here are a small selection of other bugs:

#22102: parts of fvwm(2) are not configurable in hamm
  The FvwmWinList options for setting colours don't quite work.  I
  submitted a patch to this list that fixed the problem a while ago.

#18576: fvwm2: Fvwmbuttons are eating processor time
  This is caused by FvwmButtons signal handers doing too much work.
  Apparently, this bug can be replicated by ctrl-alt-backspace killing
  the X server rather than logging out correctly.

#16143: fvwm2: FvwmWinList drifts off screen...
  FvwmWinList drifts on restart if you have BorderWidth 0.  The code
  that handles this tried to compensate for window manager
  decorations, and is quite complex.

#14163: fvwm2 edgescroll behaves badly
  Setting an EdgeScroll of anything other than 100 100 doesn't do the
  right thing.

#10862: fvwm2: restarting fvwm2 reverses the z-order of windows
  We've discussed this one here before, and I've submitted a patch
  that fixes it.

To get the complete list of bugs we have open on fvwm2, look at:
  http://www.debian.org/Bugs/db/pa/lfvwm2.html

To get a the full details on a particular bug number (eg #16143): 
  http://www.debian.org/Bugs/db/16/16143.html

Austin

---

From: Dan Espen <[email-masked]>
Date: Sat, 31 Oct 1998 15:57:30 -0500

> Alpha.  The m68k people might also have it going.

I  don't   know exactly  what Debian   releases,  but I   am under the
impression the 2.0.46   that they release includes  the  colorlimiting
patch.  Perhaps other useful 2.0.47 patches are included also?

I see so many release plans being discussed, by head is spinning.

I don't care how  buggy the new menu  code is, the  old menu code with
the "mwm" option pops  up one menu on top  of another when you  are on
the right  edge  of the screen, to   the point where you  really can't
operate  the menus.  This  is bad enough  that I call the 2.0.46 menus
fatally  flawed.  The  undocumented "Left   Menus"  patch was a  crude
attempt to repair the damage.

I know I have no use at all for a 2.0.46 based release, stable or not.

---

From: Austin Donnelly <[email-masked]>
Date: Sat, 31 Oct 1998 21:23:26 +0000

On Sat, 31 Oct 1998, Dan Espen wrote:

> patch.

No, it doesn't.   My previous email was unclear, sorry.

My policy is that Debian's fvwm2 should be as close to the official
code as possible, so there are no random patches to it.

The only diffs are:

 - manpage fixes
      I keep forwarding manpage typo fixes to this list, but no-one
      ever seems to accept them.
 - fix to FvwmPager to parse multiple Geometry lines correctly

I've put them on the end of this email.

There has never been a Debian release of any of the 2.0.47 series - I
built a 2.0.47d package, but that's for my own testing use only.

Austin
------------------------------------------------------------
--- fvwm2-2.0.46-BETA.orig/Fvwm.tmpl
+++ fvwm2-2.0.46-BETA/Fvwm.tmpl
@@ -392,7 +399,7 @@
 
 /* take care of libs not correctly added by Imake on some systems */
 /* #ifdef AlphaArchitecture */
-#if defined(AlphaArchitecture) && !defined(linux)
+#if defined(AlphaArchitecture) && !defined(__linux__)
 KLUDGE_LIBS = -ldnet_stub
 #else
 #ifdef HPArchitecture
--- fvwm2-2.0.46-BETA.orig/modules/FvwmIdent/FvwmIdent.man
+++ fvwm2-2.0.46-BETA/modules/FvwmIdent/FvwmIdent.man
@@ -55,7 +55,7 @@
 Tells the module to use \fIcolor\fP instead of black for text.
 
 .IP "*FvwmIdentBack \fIcolor\fP"
-Tells the module to use \fIcolor\fP instead of black for the window
+Tells the module to use \fIcolor\fP instead of white for the window
 background.
 
 .IP "*FvwmIdentFont \fIfontname\fP"
--- fvwm2-2.0.46-BETA.orig/modules/FvwmPager/FvwmPager.c
+++ fvwm2-2.0.46-BETA/modules/FvwmPager/FvwmPager.c
@@ -886,7 +886,16 @@
            }
          tmp[strlen(tmp)-1] = 0;
          
+         /* reset back to defaults in case we get multiple Geometry
+           * lines. <[email-masked]>, 1997/09/17 */
+         usposition = 0;
+         xneg = 0;
+         yneg = 0;
+         window_w = 0;
+         window_h = 0;
+
          flags = XParseGeometry(tmp,&g_x,&g_y,&width,&height);
+
          if (flags & WidthValue) 
            {
              window_w = width;
@@ -911,7 +920,6 @@
            }
          if (flags & YNegative) 
            {
-             window_y = g_y;
              yneg = 1;
            }
        }
@@ -960,8 +968,10 @@
          CopyString(&font_string,&tline[Clength+5]);
          if(mystrncasecmp(font_string,"none",4) == 0)
            uselabel = 0;
-         
+         else
+           uselabel = 1;         
        }
+
       else if((strlen(&tline[0])>1)&&
              (mystrncasecmp(tline, CatString3("*", MyName, "Fore"),Clength+5)==
0))
        {
@@ -1030,6 +1040,12 @@
                             Clength+12)==0))
        {
          StartIconic = 1;
+       }       
+      else if((strlen(&tline[0])>1)&&
+             (mystrncasecmp(tline,CatString3("*",MyName,"NoStartIconic"),
+                            Clength+14)==0))
+       {
+         StartIconic = 0;
        }       
       else if((strlen(&tline[0])>1)&&
              (mystrncasecmp(tline,CatString3("*",MyName,"Rows"),
--- fvwm2-2.0.46-BETA.orig/modules/FvwmPager/FvwmPager.man
+++ fvwm2-2.0.46-BETA/modules/FvwmPager/FvwmPager.man
@@ -68,7 +68,7 @@

 .SH COPYRIGHTS
-The FvwmClean program, and the concept for
+The FvwmPager program, and the concept for
 interfacing this module to the Window Manager, are all original work
 by Robert Nation.
 
@@ -125,6 +125,10 @@
 
 .IP "*FvwmPagerStartIconic"
 Causes the pager to start iconified. 
+
+.IP "*FvwmPagerNoStartIconic"
+Causes the pager to start normally.  Useful for cancelling the effect
+of the \fIStartIconic\fP option.
 
 .IP "*FvwmPagerFont \fIfont-name\fP"
 Specified a font to use to label the desktops.  If \fIfont_name\fP is
--- fvwm2-2.0.46-BETA.orig/modules/FvwmWinList/FvwmWinList.man
+++ fvwm2-2.0.46-BETA/modules/FvwmWinList/FvwmWinList.man
@@ -8,7 +8,7 @@
 FvwmWinList is spawned by fvwm, so no command line invocation will work.
 
 .SH DESCRIPTION
-The FvwmWinList module provides a widow list made up of buttons, each
+The FvwmWinList module provides a window list made up of buttons, each
 corresponding to a window that FVWM is managing.  Clicking on the buttons
 with any of the three mouse buttons will either do a default action or
 can be user configured.  Like the other modules, FvwmWinList only works
--- fvwm2-2.0.46-BETA.orig/fvwm/builtins.c
+++ fvwm2-2.0.46-BETA/fvwm/builtins.c
@@ -617,6 +617,11 @@
   int val1, val2, val1_unit,val2_unit,n;
 
   n = GetTwoArguments(action, &val1, &val2, &val1_unit, &val2_unit);
+  if (n != 2)
+  {
+    fvwm_msg(ERR, "movecursor", "CursorMove needs 2 arguments");
+    return;
+  }
 
   XQueryPointer( dpy, Scr.Root, &JunkRoot, &JunkChild,
                  &x,&y,&JunkX, &JunkY, &JunkMask);
--- fvwm2-2.0.46-BETA.orig/fvwm/misc.c
+++ fvwm2-2.0.46-BETA/fvwm/misc.c
@@ -392,21 +392,18 @@
   *val1_unit = Scr.MyDisplayWidth;
   *val2_unit = Scr.MyDisplayHeight;
 
-  n = sscanf(action,"%d %d", val1, val2);
-  if(n == 2)
-    return 2;
-
   c1 = 's';
   c2 = 's';
   n = sscanf(action,"%d%c %d%c", val1, &c1, val2, &c2);
 
-  if(n != 4)
-    return 0;
-  
+  if(n<3)
+    return 0;  /* didn't get the second number */
+
   if((c1 == 'p')||(c1 == 'P'))
     *val1_unit = 100;
 
-  if((c2 == 'p')||(c2 == 'P'))
+  /* if n==4 then c2 is valid, so take account of it */
+  if((n==4) && ((c2 == 'p')||(c2 == 'P')))
     *val2_unit = 100;
 
   return 2;
--- fvwm2-2.0.46-BETA.orig/fvwm/fvwm2.man
+++ fvwm2-2.0.46-BETA/fvwm/fvwm2.man
@@ -864,9 +864,12 @@
 Moves the mouse pointer by \fIhorizontal\fP pages in the X direction
 and \fIvertical\fP pages in the Y direction.  Either or both entries
 may be negative.  Both horizontal and vertical values are expressed in
-percent of pages, so "CursorMove 100 100" means to move down and left
-by one full page.  "CursorMove 50 25" means to move left half a page
-and down a quarter of a page.  The CursorMove function should not be
+percent of pages, so "CursorMove 100 100" means to move down and right
+by one full page.  "CursorMove 50 25" means to move right half a page
+and down a quarter of a page.  Alternatively, the distance can be
+specified in pixels by appending a 'p' to the horizontal and/or vertical
+specification.  For example "CursorMove -10p -10p" means move ten
+pixels up and ten pixels left.  The CursorMove function should not be
 called from pop-up menus.
 
 .IP "CursorStyle \fIcontext cursornum\fP"
@@ -1299,9 +1302,9 @@
 .IP "OpaqueMoveSize \fIpercentage\fP"
 Tells \fIfvwm\fP the maximum size window with which opaque window
 movement should be used.  The percentage is percent of the total
-screen area.  With "OpaqueMove 0" all windows will be moved using the
-traditional rubber-band outline.  With "OpaqueMove 100" all windows
-will be move as solid windows.  The default is "OpaqueMove 5", which
+screen area.  With "OpaqueMoveSize 0" all windows will be moved using the
+traditional rubber-band outline.  With "OpaqueMoveSize 100" all windows
+will be move as solid windows.  The default is "OpaqueMoveSize 5", which
 allows small windows to be moved in an opaque manner but large windows
 are moved as rubber-bands.
 
@@ -1775,7 +1778,7 @@
 
 If \fIarg1\fP is zero then the new desktop number will be \fIarg2\fP.
 
-If only one argument is given, moves the selected window the the
+If only one argument is given, moves the selected window to the
 desktop specified as \farg1\fP.

------------------------------------------------------------

---

From: Dan Espen <[email-masked]>
Date: Sat, 31 Oct 1998 16:51:33 -0500

> code as possible, so there are no random patches to it.

Probably a good policy.

Well, maybe its one of the other free UNIXes.  I do remember a request
to keep one of them current  on colorlimit fixes.   On the other hand,
maybe I misunderstood what they were doing with the patch.

I think my  point was, most  people will want  a stable fvwm2 with all
the patches they've already applied.  If you have lots of requests for
the colorlimit  patch, these  people  won't be interested   in 2.0.46,
stable or not.

>       ever seems to accept them.

I feel your pain. :-)

You go thru all the work to create a patch, and it seems to disappear
into a black hole.

Precisely why I'm so much in favor of a public CVS tree.

Assuming Austin doesn't  want  to    apply  for update  access,    any
suggestions from  the list members on what   we can do  for the random
patch problem?

I'm not saying Austin can't apply, just  saying we do get patches from
other people once and a while.  Often they are just ignored.

In this case, unless someone else volunteers,  I volunteer to at least
look at the man page updates.