Subject: 2.0.47 almost ready. Need thoughs on CVS

From: Brady Montz <[email-masked]>
Date: 17 Jun 1998 19:59:55 -0700

OK, finally. 2.0.47 is almost ready. I've been using it for a few days and it
seems to work for me :-)

I've decided that I'll just release it to fvwm-workers for final testing
before announcing it to the fvwm list. 

I'd like to have a public CVS repository set up ASAP. If possible, I'd like it
set up when I release 2.0.47 (I won't hold up fvwm 2.0.47 unless I have a
solid date on when CVS will be setup). I've only used CVS in a local setting,
so it's probably best if somebody with more experience sets that up (Jason
Tibbitts volunteered I recall).

Here's my proposal:

After 2.0.47, fvwm 2.0 goes into a feature freeze. So, I'd like two source
directories, one for 2.0.*, and one for fvwm 2.3 (when 2.0.* has stabilised
I'd like to release it as 2.2 so we're matching the linux and xemacs
convention of odd minor numbers denoting stable releases. So, 2.1 will have
to be skipped). 

I'd like to able to control read/write access to each source tree. Bonus
points for a page on the website which is automatically updated to list who
has access. 

I think a good initial policy might be that only I have write access to the
"stable" code, and everybody on the fvwm-workers list having full access to
the "unstable" code. I see no reason why everything shouldn't be
world-readable. 

It would be nice if all checkins resulted in mail being sent to fvwm-workers. 

Suggestions? Comments?

-- 
 Brady Montz
 [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: Makoto MATSUSHITA (まつしたまこと) <[email-masked]>
Date: Thu, 18 Jun 1998 12:54:53 +0900

bradym> OK, finally. 2.0.47 is almost ready. I've been using it for a
bradym> few days and it seems to work for me :-)

Wonderful :-)

bradym> I've decided that I'll just release it to fvwm-workers for
bradym> final testing before announcing it to the fvwm list.

Yes, that's why this list is on the earth.

bradym> Here's my proposal:
bradym> After 2.0.47, fvwm 2.0 goes into a feature freeze. So, I'd
bradym> like two source directories, one for 2.0.*, and one for fvwm
bradym> 2.3 (when 2.0.* has stabilised I'd like to release it as 2.2
bradym> so we're matching the linux and xemacs convention of odd minor
bradym> numbers denoting stable releases. So, 2.1 will have to be
bradym> skipped).

Hmm, This means that current 2.0.x series (you want to name as 2.1.x,
I suppose) is still in beta phase, then named "2.2.0" when released,
and further effort for stabilization for the code will be named as "2.2.x" ?

bradym> I think a good initial policy might be that only I have write
bradym> access to the "stable" code, and everybody on the fvwm-workers
bradym> list having full access to the "unstable" code. I see no
bradym> reason why everything shouldn't be world-readable.

Can we do such r/w control within the SAME module (sorry I'm novice
user of CVS/CVSup, I do NOT know it can or not)? I think it may be bad
idea that "stable" code and "unstable" code are not the same module.

BTW, Is there any plan to provide CVSup/sup service ?

-- -
Makoto `MAR' MATSUSHITA

---

From: Jason L Tibbitts III <[email-masked]>
Date: 17 Jun 1998 22:43:00 -0500

>>>>> "BM" == Brady Montz <[email-masked]> writes:

BM> I'd like to have a public CVS repository set up ASAP. If possible, I'd like it
BM> set up when I release 2.0.47 (I won't hold up fvwm 2.0.47 unless I have a
BM> solid date on when CVS will be setup). I've only used CVS in a local setting,
BM> so it's probably best if somebody with more experience sets that up (Jason
BM> Tibbitts volunteered I recall).

You're cutting it really close.  I leave the country tomorrow and am away
for just over three weeks.  I can check in sources if I get them within the
next two hours but if problems develop...

BM> After 2.0.47, fvwm 2.0 goes into a feature freeze. So, I'd like two source
BM> directories, one for 2.0.*, and one for fvwm 2.3 (when 2.0.* has stabilised
BM> I'd like to release it as 2.2 so we're matching the linux and xemacs
BM> convention of odd minor numbers denoting stable releases. So, 2.1 will have
BM> to be skipped). 

Why would you want two separate repositories?  Why not use branching?
That's the reason branches exist.  (Note that I'm not a CVS expert and
haven't tried to do serious cross-branch merges, but that's how other much
larger projects like, say, Mozilla, egcs, Gnome, etc. work.)

BM> I'd like to able to control read/write access to each source tree. Bonus
BM> points for a page on the website which is automatically updated to list who
BM> has access. 

I haven't the time to do anything more than the basics now; I made it clear
when I was leaving, and this doesn't give me enough time to do any custom
hacking.  A CVS repository, an account, CVSweb and anonymous rsync I can
do.  If you want anything over that then it's either going to have to wait
until I get back or it's going to have to come from someone other than me.

 - J<

---

From: Makoto MATSUSHITA (まつしたまこと) <[email-masked]>
Date: Thu, 18 Jun 1998 13:49:15 +0900

tibbs> Why would you want two separate repositories?  Why not use
tibbs> branching?  That's the reason branches exist.

I'm also wondered if 2.0 and 2.3 is NOT THE SAME MODULES.

I think both are the same 'fvwm' source, so there are only ONE MODULE
is needed (maybe in src/fvwm module, and aliased to fvwm), and then
make a branch and tagged it (we can use HEAD branch for stable or
unstable branch, so we maybe do not want to make two more
branches). It is very simple, and well-known way to do :-)

tibbs> (Note that I'm not a CVS expert and haven't tried to do serious
tibbs> cross-branch merges, but that's how other much larger projects
tibbs> like, say, Mozilla, egcs, Gnome, etc. work.)

I'm also not an expert of CVS/CVSup but... merge the branch(es) is
(partly in some cases) automated. However, I think there is no support
in cvs to merge the two modules, for example, src/fvwm-2.0 and
src/fvwm-2.3. If so, it seems very natual for me; why we want to merge
an apple and a banana into one fruit :-)

-- -
Makoto `MAR' MATSUSHITA

---

From: Jason L Tibbitts III <[email-masked]>
Date: 18 Jun 1998 00:12:40 -0500

>>>>> "MM" == Makoto MATSUSHITA (=?ISO-2022-JP?B?GyRCJF4kRCQ3JD8kXiQzJEgbKEI=?=) <Makoto> writes:

MM> BTW, Is there any plan to provide CVSup/sup service ?

Dunno, nobody's ever asked for it before.  I think anonymous rsync is much
better suited for the task of letting people just copy out the source than
something layered over CVS, but if it's easy to set up then I don't mind
running it.

Of course, it still remains to be seen whether I can get the sources and
get them incorporated before I go on vacation.  Otherwise, it will have to
fall on someone else's shoulders.

 - J<

---

From: Brady Montz <[email-masked]>
Date: 18 Jun 1998 10:29:26 -0700

Jason L Tibbitts III <[email-masked]> writes:

> BM> I'd like to have a public CVS repository set up ASAP. If possible, I'd
> BM> like it set up when I release 2.0.47 (I won't hold up fvwm 2.0.47 unless
> BM> I have a solid date on when CVS will be setup). I've only used CVS in a
> BM> local setting, so it's probably best if somebody with more experience
> BM> sets that up (Jason Tibbitts volunteered I recall).
> 

OK. No CVS for over three weeks.

---

From: Brady Montz <[email-masked]>
Date: 18 Jun 1998 10:48:39 -0700

> an apple and a banana into one fruit :-)

You're probably right. My only experience with branching was with RCS, which
made me (perhaps irrationally) predjudiced against the whole concept. 

If we have a way of sending all commit logs to the mailing list, it shouldn't
be too hard to keep order. 

As far as modules go, if we have two "global" cvs branches, then the modules
automatically will have two branches as well, and if someone wants to compile
the 2.3 FvwmButtons with 2.2 fvwm, then they can just do two checkouts. Don't
immediately see any way to make it much easier than that. 

Should be have a CVS module for each fvwm module?