[fvwmorg/fvwm] 9e1b6b: fvwm-menu-desktop improvements

[somiaj]

  Branch: refs/heads/js/fvwm-menu-desktop
  Home:   https://github.com/fvwmorg/fvwm
  Commit: 9e1b6b9f760f00633acdbfb30a9e36200a976116
  
https://github.com/fvwmorg/fvwm/commit/9e1b6b9f760f00633acdbfb30a9e36200a976116
  Author: somiaj 
  Date:   2016-10-27 (Thu, 27 Oct 2016)

  Changed paths:
M bin/fvwm-menu-desktop-config.fpl
M bin/fvwm-menu-desktop.in
M modules/FvwmForm/FvwmForm-MultiMenuHelp

  Log Message:
  ---
  fvwm-menu-desktop improvements
 Updated fvwm-menu-desktop to load defaults from the FvwmForms
 config file. Simplifed the FvwmForms UI for configuring fvwm-menu-desktop.

[fvwmorg/fvwm] 65aa4d: fvwm-menu-desktop improvements

[somiaj]

  Branch: refs/heads/js/fvwm-menu-desktop
  Home:   https://github.com/fvwmorg/fvwm
  Commit: 65aa4d4ccb8797bf680d9341a5ec2cd8db55eb34
  
https://github.com/fvwmorg/fvwm/commit/65aa4d4ccb8797bf680d9341a5ec2cd8db55eb34
  Author: somiaj 
  Date:   2016-10-27 (Thu, 27 Oct 2016)

  Changed paths:
M bin/fvwm-menu-desktop-config.fpl
M bin/fvwm-menu-desktop.in
M modules/FvwmForm/FvwmForm-MultiMenuHelp

  Log Message:
  ---
  fvwm-menu-desktop improvements
 Changes to be committed:
modified:   bin/fvwm-menu-desktop-config.fpl
modified:   bin/fvwm-menu-desktop.in
modified:   modules/FvwmForm/FvwmForm-MultiMenuHelp

 Updated fvwm-menu-desktop to load defaults from the FvwmForms
 config file along with better integrate it with with Fvwm
 and the default config.

Re: Separate or common project infrastructure fvwm v2/v3.

[Ethan Raynor]

Hi,

On Thu, Oct 27, 2016 at 12:30 AM, Dominik Vogt  wrote:

I'm just a recent user of fvwm full time and haven't been around long
enough to appreciate many of the issues raised in this email. I can
see though that fvwm's history goes back a long way and that might
have a few reasons why these issues are being discused.

I want to address one point below on why I think a seperte git repo
for fvwm-3 is a good idea - as i do know about how project
organisations work.

>  * Switching git repository:  Given that the current amount of
>work going into version 2.x is very low, having both versions
>in the same repository is certainly manageable.  It's just more
>work for anybody who is interested in both repos (and getting
>access to github *is* very cumbersome compared to cvs access in
>the past).

Having that 'mental separation' of what "was" (if you'll permit me to
say that), and whar "is" makes clear to me. I can understand Thomas'
point - it does help - when you also consider that the code will
change and diverge. When you have a repository with code in it, if
it's going to be based off an existing code base, but change, then it
really does make sense to have a completely separate area for this.

If you don't - how will you manage branch names, and knowing where to
merge one thing to another? If fvwm-3 lives in the same repository,
switching between a fvwm2 branch and fvwm3 branch is hassle because
you'll have different .o files which will need to be cleared before
doing another build. What will you do about releases? If you do have
fvwm-3 and fvwm-2 in the same repo, the tagging will be a nightmare -
in fact, you'll struggle to do this in the same repo as tagging is
global in git, and is not done per branch.

So that to me suggests you'll have to have a separate repo for fvwm-3
if you want to do releases - since Github does these per tag, not
branch.

HTH,

Ethan Raynor