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

[Dominik Vogt]

On Mon, Nov 14, 2016 at 01:11:57AM +, Ethan Raynor wrote:
> 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.

I don't.  Software development is difficult enough without
worrying about the feelings of the readers.  This just eats up
time that could be used to do some useful work.

--

Please don't top post on this list, i.e. put your answers below
the text you're refering to, not above it.
https://en.wikipedia.org/wiki/Posting_style

BAD
 ^
 |
 |
> On Mon, Nov 14, 2016 at 1:03 AM, Dominik Vogt  wrote:
> > Please don't top post on the fvwm lists.
> >
> > On Mon, Nov 14, 2016 at 12:44:47AM +, Ethan Raynor wrote:
> >> it's those points i would like to see put elsewhere
 |
 |
 v
GOOD

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt

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

[Dominik Vogt]

On Mon, Nov 14, 2016 at 12:58:42AM +, Thomas Adam wrote:
> On Mon, Nov 14, 2016 at 01:52:51AM +0100, Dominik Vogt wrote:
> > By the way, any idea why "make distcheck" has never caught the
> > faulty uninstallation of the symlinks?
> 
> Nope, no idea.
> 
> I find dist/distcheck to be some seriously weird automake black magic which
> I've never fully understood.

As far as I understand it:

1. Make everything.
2. Build a tarball from the build result, using the files
   mentioned in the Makefile.am.
3. Create three subdirs (SOURCE, BUILD, INSTALL or whatever the
   exact names are).
4. Extract the tarball into SOURCE.
5. Unprotect BUILD, write protect SOURCE and protect INSTALL from
   any access.
6. cd into the builddir, build everything with --srcdir=SOURCE and
   --prefix=INSTALL.
   => This makes sure that all files built are placed in BUILD,
  all source files are taken from SOURCE, and nothing is
  installed or built in INSTALL during the build step.
7. Protect SOURCE from any access, write protect BUILD and
   unprotect INSTALL.
8. make install
   => This makes sure that installing actually places the files
  in INSTALL and not elsewhere.
9. make uninstall and check that nothing is left in INSTALL
   except empty directories.
   => Check that everything put into INSTALL ist removed, and that
  files are actually removed from the INSTALL and not from
   SOURCE or BUILD.

If "make distcheck" fails, it's normally either because some file
is missing from the tarball or not properly uninstalled.

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  wrote:
> Please don't top post on the fvwm lists.
>
> On Mon, Nov 14, 2016 at 12:44:47AM +, 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
>

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

[Dominik Vogt]

Please don't top post on the fvwm lists.

On Mon, Nov 14, 2016 at 12:44:47AM +, 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

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

[Thomas Adam]

On Mon, Nov 14, 2016 at 01:52:51AM +0100, Dominik Vogt wrote:
> It's still not good.  Isn't there a standard Automake way to
> install shell scripts?

IIRC, there's bin_SCRIPTS -- ah, poking around reveals this:

https://www.gnu.org/software/automake/manual/html_node/Scripts.html

Although we're already using that in places across fvwm.

> uninstalled.  (I certainly can do this, but I'd like to give the
> author of the Makefile.am the chance to fix it - I know it's
> tedious, but it's neccessary.)

Heh.  Very well.  I will take a look.

> By the way, any idea why "make distcheck" has never caught the
> faulty uninstallation of the symlinks?

Nope, no idea.

I find dist/distcheck to be some seriously weird automake black magic which
I've never fully understood.

-- Thomas Adam

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

[Dominik Vogt]

On Sun, Nov 13, 2016 at 05:13:22PM +, Thomas Adam wrote:
> On Sun, Nov 13, 2016 at 04:09:14PM +0100, Dominik Vogt wrote:
> > Bofore you start working on that, please take a look at the
> > dv/fix-transform-name branch.
> 
> OK, this looks good.  I'm surprised that FvwmCommand.sh is installed to
> /.../libexec/fvwm/$(VERSION) without execute permissions.   But this isn't a
> bug, it seems to always have been the case.

It's still not good.  Isn't there a standard Automake way to
install shell scripts?

> I suppose the next step is to remove the compatability symlinks, both in terms
> for fvwm2 -> fvwm and xpmroot, and the symlinks for the documentation.  You
> can do that on top of what you have, if you like.

I think it's more important to first fix the Makefile.am in
default-config and its subdirs as written in the other thread.
Furthermore, the symlinks are not properly installed when
--program-transform-name is used, and they are not properly
uninstalled.  (I certainly can do this, but I'd like to give the
author of the Makefile.am the chance to fix it - I know it's
tedious, but it's neccessary.)

By the way, any idea why "make distcheck" has never caught the
faulty uninstallation of the symlinks?

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt

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

[Dominik Vogt]

On Mon, Nov 14, 2016 at 12:07:42AM +, Ethan Raynor wrote:
> Is it OK to request these sorts of conversations take place someplace
> else?

No.

If there's one place for discussing fvwm development, it's this
mailing list.

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt

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

[Dominik Vogt]

On Sun, Nov 13, 2016 at 02:03:52PM +, Thomas Adam wrote:
> On Sun, Nov 13, 2016 at 04:30:23AM +0100, Dominik Vogt wrote:
> > On Sun, Nov 13, 2016 at 02:06:19AM +, Thomas Adam wrote:
> > > On Sun, Nov 13, 2016 at 02:43:13AM +0100, Dominik Vogt wrote:
> > > > 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.
> > > 
> > > So what would you rather, and to what extent should this happen?
> > 
> > See attached patch.  The Makefile.am need some tuning because some
> > names are hard coded in install...local rules (FvwmCommand.sh,
> > FvwmCommand.pm, xpmroot*, fvwm2*, message catalogs).  It's easy to
> > firgure out; just configure with --prefix=some-private-dir, ass
> > program-suffix and program-prefix, then install and see which
> > files end up in the wrong place.
> 
> Right.  I'd forgotten that automake allowed for --program-{prefix,suffix} --
> that makes things much easier.  So I'll rejig some things and use this.
> 
> I can see there's a few things which will need adjusting.  We won't need the
> fvwm2 symlink at all since that would be misleading, surely?  The other parts
> you've identified shouldn't be too difficult to fix.

>  I'm unsure what should
> happen with the gettext files, and if they need namespacing at all.

As with my path modules don't get a suffix (unless installed in
bin/), the same concern applies to the module manpages.  It would
be confusing to have a module "FvwmButtons" with a manpage
"FvwmButtons-3.1".  But if the module name is not suffixed, there
cannot be multiple versions of the manpage installed.

> One observation I've got is:
> 
> > +transform=`echo "${program_transform_name}" | "$SED" -e 's/\\$\\$/\\$/'`
> > +PPACKAGE=`echo "${PACKAGE}" | "$SED" -e "${transform}"`
> 
> Is this not what the option '--program-transform-name=program' is doing?  See:
> 
> https://www.gnu.org/software/automake/manual/html_node/Renaming.html

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt

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

[Dominik Vogt]

On Sun, Nov 13, 2016 at 02:03:52PM +, Thomas Adam wrote:
> On Sun, Nov 13, 2016 at 04:30:23AM +0100, Dominik Vogt wrote:
> > On Sun, Nov 13, 2016 at 02:06:19AM +, Thomas Adam wrote:
> > > On Sun, Nov 13, 2016 at 02:43:13AM +0100, Dominik Vogt wrote:
> > > > 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.
> > > 
> > > So what would you rather, and to what extent should this happen?
> > 
> > See attached patch.  The Makefile.am need some tuning because some
> > names are hard coded in install...local rules (FvwmCommand.sh,
> > FvwmCommand.pm, xpmroot*, fvwm2*, message catalogs).  It's easy to
> > firgure out; just configure with --prefix=some-private-dir, ass
> > program-suffix and program-prefix, then install and see which
> > files end up in the wrong place.
> 
> Right.  I'd forgotten that automake allowed for --program-{prefix,suffix} --
> that makes things much easier.  So I'll rejig some things and use this.
> 
> I can see there's a few things which will need adjusting.  We won't need the
> fvwm2 symlink at all since that would be misleading, surely?  The other parts
> you've identified shouldn't be too difficult to fix.  I'm unsure what should
> happen with the gettext files, and if they need namespacing at all.  I don't
> make use of such things.

Bofore you start working on that, please take a look at the 
dv/fix-transform-name branch.

> One observation I've got is:
> 
> > +transform=`echo "${program_transform_name}" | "$SED" -e 's/\\$\\$/\\$/'`
> > +PPACKAGE=`echo "${PACKAGE}" | "$SED" -e "${transform}"`
> 
> Is this not what the option '--program-transform-name=program' is doing?  See:

Roughly, but it only modifies program names while we also want to
change some subdir names.  And it does not work in Makefile.am
hooks.  :-/

> https://www.gnu.org/software/automake/manual/html_node/Renaming.html

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt

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

[Dominik Vogt]

On Sun, Nov 13, 2016 at 02:06:19AM +, Thomas Adam wrote:
> On Sun, Nov 13, 2016 at 02:43:13AM +0100, Dominik Vogt wrote:
> > 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.
> 
> So what would you rather, and to what extent should this happen?

See attached patch.  The Makefile.am need some tuning because some
names are hard coded in install...local rules (FvwmCommand.sh,
FvwmCommand.pm, xpmroot*, fvwm2*, message catalogs).  It's easy to
firgure out; just configure with --prefix=some-private-dir, ass
program-suffix and program-prefix, then install and see which
files end up in the wrong place.

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt
>From 08f22e1a9aa492cf084020ea9d3c7dbf286659ea Mon Sep 17 00:00:00 2001
From: Dominik Vogt 
Date: Sun, 13 Nov 2016 04:16:14 +0100
Subject: [PATCH] !

---
 configure.ac |8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/configure.ac b/configure.ac
index e3a5424..665e77b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -93,9 +93,11 @@ AC_MSG_RESULT([assuming $PERL as perl location])
 AC_SUBST(PERL)
 
 # installation paths
-FVWM_MODULESUBDIR=/${PACKAGE}/${VERSION}
-FVWM_DATASUBDIR=/${PACKAGE}
-FVWM_DOCSUBDIR=/doc/${PACKAGE}
+transform=`echo "${program_transform_name}" | "$SED" -e 's/\\$\\$/\\$/'`
+PPACKAGE=`echo "${PACKAGE}" | "$SED" -e "${transform}"`
+FVWM_MODULESUBDIR=/${PPACKAGE}/${VERSION}
+FVWM_DATASUBDIR=/${PPACKAGE}
+FVWM_DOCSUBDIR=/doc/${PPACKAGE}
 
 AC_ARG_ENABLE(package-subdirs,
   AS_HELP_STRING([--disable-package-subdirs],
-- 
1.7.10.4

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

[Thomas Adam]

On Sun, Nov 13, 2016 at 02:43:13AM +0100, Dominik Vogt wrote:
> 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.

So what would you rather, and to what extent should this happen?  If you don't
have the time to do the work, at least have the courtesy to say so and provide
a list of things you want, and it'll get done.  But to keep going silent for a
while, coming back, and then bemoaning the state of things because you weren't
around, and/or didn't get asked, and/or things werent done how you would have
wanted, isn't how projects are run, or indeed, *will not* be run for as long
as I am involved with them.

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

It's all a little bit "moan, moan, moan" coming from you, with there being
little evidence of anything actually wrong, other than you don't like
something.  So far, I've been kind.  So far, I've been courteous and polite in
helping you and explaining all that I can.  But I cannot work with just that
alone, Dominik.  I can't help *you* or give assistance when the rhetoric
you're throwing out is intangible.  I've just _told_ you how you can
accomplish certain tasks.  If you actually have something sensible which you
need help with, then by all means ask me for help if you need it.  But please
stop whinging.

> By the way, everybody else would call their versions fvwm-2 and
> fvwm-3, and that's what I'll do, starting now.

So what I want from you is a list of things which aren't correct.  You say you
want "fvwm-2" and "fvwm-3".  Fine, I don't mind what it's called, provided
some choice is made.

-- Thomas Adam

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

Separate or common project infrastructure fvwm v2/v3.

[Dominik Vogt]

This is important enough to warrant a separate discussion thread.

On Wed, Oct 26, 2016 at 01:45:46PM +0100, Thomas Adam wrote:
> Oh, and the point of a separate repo still stands, in my eyes.  You might
> think it moot, or even an unnecessary point, but I feel it's a very important
> one.  It reinforces (psychologically) that it's separate from fvwm2.  It
> reinforces that fvwm3 is discrete, and it reinforces the idea that it will
> become divergent from fvwm2 quite quickly.

First of all, for me personally there is no psychological issue.
I can think of the continued work to be all new regardless of
which mailing list its discussed on and where the repository is
located.  It may be different for others.

>From the point of view of the users and the people reading
fvwm-workers I am very sceptical.  We have already abandoned cvs
in favour of git, and as you can see, this has even further
reduced the number of old timers who have set up a development
environment.  I'd be very careful about sending yet another "we
don't want to have anything to do with the old stuff" message to
the world.

Switching to new infrastructure, we'll automatically lose some of
the people that are interested in fvwm development, be it that
they miss that the mailing lists have moved or that they won't
understand why there are two projects with the same name and which
to look at.  On the other hand:

 * Staying on the same mailing list:  Readers will notice over time
   that we're working on something new, that version 3 will be a
   more modern and radically different thing than version 2.  They
   may become interested in it or not, only time will tell.  There
   is no information hurdle they have to take to find out that
   something new is being done.

   Bugs reported for fvwm-2.x will still be relevant to fvwm-3.x
   for a long time (depends on the bugs).  We don't want to keep
   people from reporting bugs on the list because they might think
   the project is dead when it has just moved.

 * 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).

 * Switching to a new web space:  This would make us the target of
   ridicule for years and cause musch confusion.  How would we
   explain that there are two distict web pages for the same project
   that differ only in version number?  It would just be
   inconvenient for everybody.  All right, we would have to place
   a big announcement on the web page with a link that points to the
   version 2 related sub pages, but I think with two different web
   pages we'd have to do it on both anyway.

 * With new infrastructure we'd run the risk that fvwm is kicked
   out of even more distributions.

So, is there maybe *another* way to foster enthusiasm about a new,
incompatible version?  Maybe we just need to do some "public
relations" work here.  A while ago you started a discussion about
a new logo contest.  Great idea, why not make it an event around
the official "fork" date.  I'd be happy to donate another prize.
We'd have something "new" practically from day one.  Maybe an Irc
"fvwm version 3" kickoff party where we explain our plans for the
future?

> It's not as if we're backporting features or fixes between the two.

Of course I'll continue backporting fixes like the recent ones in
event handling in the window management core.  This code is
changes at a very low pace, and backports are easily done.

> Copy---if it makes you feel any easier--- the entirety of the
> files from fvwm's master branch to new fvwm3 repository.  Do your
> work there, the set up is

Not at all, that would just greatly complicate things and confuse
people.  What use would two copies of the same code in deifferent
repositories be?

> Do your work there, the set up is
> easy.  Having a separate fvwm3 repository also allows to integrate anything we
> wish to the main fvwm website as well (when that becomes appropriate).

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt