Subject: Re[4]: Further development

From: Bob Woodside <[email-masked]>
Date: Sun, 1 Nov 1998 22:27:48 -0500 (EST)

Steve Robbins <[email-masked]> wrote:
>  Dominik said he'd merged the patches sometime Friday afternoon...
>  several files were missing
>  I retrieved the missing files from the "animicons_menupos"  branch....

	Ok, I started over, and checked out the main trunk Saturday evening
between atacks from pint-sized ghouls. Configures, builds, runs; I like that,
I really do.

	But now I suspect that I'm more confused than ever. I have the
following unanswered questions.

	1) Is this the version I should be working from? If not, which? 
	2) Do we have a consensus on Dan's request that I merge in my
	   StartsOnPage patch?
	3) If yes to #2, and I get commit permission, what then? Do I branch,
	   or what? 
	4) The, er, official release plan has undergone so many transmogrifi-
	   cations in the last few days, it's hard to know just what is
	   what. Could we get something like a "Release Roadmap for Dummies"? --
	   i.e., something like
	       current main trunk     ==>> beta x.y.z
	       branch blah_blah_blah  ==>> release a.b.c
	       branch more_blah       ==>> Dominik's playpen, will get merged
	                                   with x.y.z when he's ready. Don't
	                                   mess with this one.

	   etc.

--
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: Sun, 01 Nov 1998 23:20:58 -0500

> between atacks from pint-sized ghouls. Configures, builds, runs; I like that,

I too was attacked by ghouls.  Co-incidence?

> 	1) Is this the version I should be working from? If not, which? 

It would seem logical to work from version 2.1.0.  From  what I see of
CVS so  far,  it doesn't matter   too much if a  2.2.0  and 2.3.0  are
created before you are  done.  You can pretty  much merge  your branch
into any release.

> 	2) Do we have a consensus on Dan's request that I merge in my

I think you do.  There have been no objections so  far.  Since we have
StartsOnDesk, how could there be an objection to StartsOnPage?

> 	3) If yes to #2, and I get commit permission, what then? Do I branch,

I think a   good rule is, always  create  a branch.   The merges  come
later.  Use a branch name  that is just words.   I think its too early
to target a release.

> 	                                   with x.y.z when he's ready. Don't

As I remember, one  of the reasons Starts on  page was held out  is it
co-opted one of the style flags and we were waiting for GSFR.

I never saw GSFR as much work.  Nor did I see it as a necessity.

Unless you are  feeling extra ambitious, I would  just add another int
to hold the flags you need, if that is still a consideration.  I think
you will  find  that pretty easy in   the current code.  (And I  don't
think it will complicate any GSFR in the future.)

--
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: Steve Robbins <[email-masked]>
Date: Mon, 2 Nov 1998 00:14:16 -0500 (EST)

> 	1) Is this the version I should be working from? If not, which? 

No, I'd suggest basing any development on the main trunk.  Do an update to
pick up the stuff I did today.  (Use "cvs update -A" if you have any
sticky tags)

> 	2) Do we have a consensus on Dan's request that I merge in my

I don't even know what it is, but if Dan's in favour, I suspect that it's
a good idea. 

> 	3) If yes to #2, and I get commit permission, what then? Do I branch,

Basically, Dominik's in charge of the tree, so it's up to him.  If the
changes are likely to be large and disruptive, then you'd likely want to
work on a branch.

> 	   what. Could we get something like a "Release Roadmap for Dummies"? --

Roughly speaking, there are only two parts of the tree worth worrying
about: the trunk, and the last beta version.  If you're going to start
work on some large change, I'd check out the last beta, create a branch,
and work from there.  If it's a small change, then I think the thing to do
is to submit a patch against the trunk to the maintainer.  Or just commit
it yourself, depending on the maintainer.

--
Steve Robbins                              <[email-masked]>

First, we take Manhattan, then we take Berlin.

---

From: [email-masked] (Paul D. Smith)
Date: 02 Nov 1998 01:02:15 -0500

%% Dan Espen <[email-masked]> writes:

  >> between atacks from pint-sized ghouls. Configures, builds, runs; I
  >> like that, I really do.

  de> I too was attacked by ghouls.  Co-incidence?

I led around a pint-sized ghoul... er... girl... dressed as a
butterfly... hmm...

  >> 3) If yes to #2, and I get commit permission, what then? Do I branch,

  de> I think a   good rule is, always  create  a branch.   The merges  come
  de> later.  Use a branch name  that is just words.   I think its too early
  de> to target a release.

I think for the very, very near future just keep the changes in your
workspace.  The nice thing about CVS is that it's very easy to keep your
local changes up-to-date with the latest stuff in the tree, even if you
don't check it in.

We have been spending a lot of time talking about various ways this can
be done but I think there are two facts everyone agrees to at this
point:

 1) Dominik is in charge of the 2.2 release, and

 2) Whomever is in charge of the release gets to decide how it's
    handled.

As I see it, Dominik has 3 choices:

 a) Have everyone check in potential changes to an "alpha" branch, from
    which he'll merge changes he wants to keep into the mainline branch
    for beta dists and the release.

 b) Have everyone send him patches, which he'll apply (or not) to the
    mainline branch.

 c) Have everyone just check in their code, perhaps first mentioning the
    change being made to him for approval.

Of course, some combination depending on the size, etc. of the change is
also possible.  In short, you should ask Dominik how he wants to handle
it; perhaps after you've got it working in your workspace and can give
him an idea of the extent of the changes.

PS. I agree with Dan E. about the GSFR--'way overdue and I don't think
    it's that big a deal.  Several quite workable solutions have already
    been provided in detail on this list--I'm quite partial to the
    bitfields solution since I really like being able to see the flags
    set via a symbolic debugger, but YMMV.

    The reason I think people shy away from just making another int is
    they want to get the real solution done, and when you introduce a
    short-term solution like that it lets the pressure off :)

PPS. I don't think the GSFR is appropriate for 2.2--let's get a stable
     release out, dammit!  But it seems like a fine goal for 2.3/2.4.

-- 
-------------------------------------------------------------------------------
 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].