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

[Ethan Raynor]

Hi,

On Thu, Oct 27, 2016 at 12:30 AM, Dominik Vogt <dominik.v...@gmx.de> 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

Re: fvwm3 repo (WAS: Re: Separate or common project infrastructure fvwm v2/v3.)

[Ethan Raynor]

Hi,

Is it OK to request these sorts of conversations take place someplace
else? I did not know before that there's a lot of heated
conversations. I don't want to have to read these.

Please be considerate. Or agree on something and move on, may be?

Ethan


On Sun, Nov 13, 2016 at 1:43 AM, Dominik Vogt  wrote:
> On Sun, Nov 13, 2016 at 01:05:23AM +, Thomas Adam wrote:
>> On Thu, Oct 27, 2016 at 01:23:23AM +0100, Thomas Adam wrote:
>> > "Copying" was a bad choice of words.  With fvwm3, what I would suggest is
>> > taking the current fvwm2 repository (including all of its branches) and
>> > making that the basis for fvwm3.  That way, we can change it however we 
>> > like.
>> > We're then able to link fvwm2's repo in to easily backport changes using
>> > standard git commands, etc.  It's something I'd be happy to run through if
>> > that's required, or wanted.
>>
>> Controversially, I've gone ahead and created a fvwm3 repository [1].  It has
>> been set up as fvwm2 was; the only difference is there's no tags.  The master
>> branch is the same from fvwm2.
>>
>> I've aleady gone ahead and made fvwm3 rename key parts.  So for example, the
>> binary is currently called 'fvwm3' and the share prefix installs to
>> $PREFIX/share/fvwm3.
>
> Why on earth do we have to repeat the mistake of the past by
> putting the version number in the project name *again*?  Every
> other project manages backwards incompatible releases just fine,
> only fvwm changes its name with each major release.  This just
> complicates things, and helps nobody.  That's what configure's
> binary suffix is for.
>
>> I'm not necessarily expecting this to remain as-is for
>> too long, but it does mean that fvwm3 can be installed along side fvwm2.
>
>
>> 1.  How do I port fixes from fvwm3 -> fvwm2?
>>
>> You can do this with remotes.  From fvwm3's POV:
>>
>>   git remote add fvwm2 g...@github.com:fvwmorg/fvwm.git
>>   git fetch -n fvwm2
>>   git checkout -t origin/fvwm2 fvwm2-master
>>   git cherry-pick COMMIT1 COMMIT2
>>   git push
>>
>> This will also handle file rename cases.  So for example, fvwm/fvwm3.c would
>> map to fvwm/fvwm.c in fvwm2's repository, as git understands file renames.
>
> In the past couple of years I haven't been contributing that much,
> and I'm absolutely for having the sources in git.  But over the
> recent years, I've tested the initiol fvwm git repo, then switched
> to the mvwm repo, rewritten all the config files on various
> machines to switch to mvwm, in the mean time backported fixes from
> mvwm to fvwm (with some amount of merge conflicts), converted all
> the icons to a different format because mvwm required that,
> switched back to the fvwm repo, backported the parser branch to
> the fvwm repo (very annoying), rewritten the config from mvwm to
> fvwm yet again.  And I've got to rewrite it *again*, manage two
> different configs and fiddle with two repos in parallel, just to
> be able to install two versions in parallel, which is already
> possible (and if not, this needs to be fixed anyway).
>
> By the way, everybody else would call their versions fvwm-2 and
> fvwm-3, and that's what I'll do, starting now.
>
> Ciao
>
> Dominik ^_^  ^_^
>
> --
>
> Dominik Vogt
>

Re: fvwm3 repo (WAS: Re: Separate or common project infrastructure fvwm v2/v3.)

[Ethan Raynor]

Hi,

I can understand personal opinions - they're important and they happen
all the time with projects, I understand that. But I don't think it is
very fair to say I should not read it - when I won't know weather it's
there or not to start with. So I think just not having those
conversations is better.

Thanks again though.

Ethan

On Mon, Nov 14, 2016 at 1:03 AM, Dominik Vogt <dominik.v...@gmx.de> wrote:
> Please don't top post on the fvwm lists.
>
> On Mon, Nov 14, 2016 at 12:44:47AM +0000, Ethan Raynor wrote:
>> it's those points i would like to see put elsewhere
>
> I've completely understood that it bothers you.  If you don't want
> to read it, don't.  This is an unavoidable part of public software
> development.
>
>> as that doesnt have much - if anything- to do with fvwm.
>
> Discussing the fvwm infrastructure and the personal opinions about
> it is completely on topic.  This list is not a place where
> politeness or political correctness is exspecially important.
>
>> or am i wrong?
>
> Ciao
>
> Dominik ^_^  ^_^
>
> --
>
> Dominik Vogt
>

fvwm3 discussion continuing?

[Ethan Raynor]

Hey all,

I've had a few mail probs recently and wondered if the discusion about
fvwm3 is still happening?

If it is- what are the outcomes from any conversations?

Ethan