Re: [Groff] Git branching workflow

[Steffen Nurpmeso]

Bonjour Bertrand,

Bertrand Garrigues <address@hidden> wrote:
 |On Wed, Sep 17 2014 at 01:32:23 PM, Steffen Nurpmeso <address@hidden> \
 |wrote:
 |> Hello Bertrand,
 |[...]
 |>
 |> First i'm sorry that i didn't really test your work on the
 |> migration to autoxy.  I personally declined completely to use
 |> these back around 2001 and rather spend about half a year writing
 |> a perl(1) based configuration, build and installation facility.
 |
 |Little disgression on autotools ... Personnally, at first I avoided the
 |use the autotools, mainly because I was frightened by the anti-autotools
 |propaganda (I have more experience in CMake for example), until I found
 |a few years ago that it wasn't bad ... Also I think that you will always
 |have difficult problems to solve on a large projects, no matter what
 |build system you use, autotools, CMake, SCons, plain Makefiles. The
 |difficulties come from the project complexities, and not (necessarily)
 |from the tools you are using for the build system.

Of course.  That is true.

 |> And today i'm really in favour of POSIX and what it ships: sh(1),
 |> awk(1), etc.  It must be said that most of the entries that need
 |> to be configured for groff were already present in Issue 1 of
 |> POSIX (!!), and i don't think that groff would at all compile on
 |> systems that are this old, even if there would be modern compilers
 |> available.
 |
 |Configuration or portability issues are not the only problems the
 |autotools solve, I think they give you good practical tools for the
 |various targets you need (build, installation, distribution, tests ....)
 |and spare you the need to reinvent the wheel.

Ok ok ok.  For example my perl system produced an uninstallation
script that got installed along with the library (actually it was
something like apr-1-config, that echoed compiler / linker flags
etc. on request, but it had an uninstallation target).

 |> Granted that it may be easier to deal with the one or other
 |> system-specific or C-library specific bug.
 |> But imho: what this codebase really needs is a complete overhaul,
 |> move of bug-specific hacks to shared code -- just grep NEED_DECL
 |> in src/ and see how often such missing _declarations_ are checked
 |> in _sources_ --, not a different configuration system.
 |> For S-roff all this has to and _will_ vanish.
 |> I don't see a point in complicating user's life with the remains.
 |> My point of view.
 |
 |Other persons on the list have already expressed their fear that
 |automake will bring extra complications. I hope that it will, on the
 |contrary, bring some ease of use: automatic checks with the 'distcheck'
 |or 'check' targets, no need to manually call autoreconf, just type
 |'make' (currently you need to be careful, passing '-I m4' otherwise you
 |will overwrite the aclocal.m4, like it happens recently on master), in
 |most of the cases no need to manually write install/uninstall/clean
 |rules.

Uninstall?
Not the autotools that i don't like.

And, please: even on [automake2] i see a ~90+ KB m4/ directory!
90 KB project-specific M4!  Where there is any salvation from
unrolling your own?

  ?0[]$ ls -o configure sysdeps/generic/cnf* sysdeps/generic/x86/cnf*
  -rwxrwxr-x  1 steffen  47231 19 Sep 11:49 configure
  -rw-rw-r--  1 steffen   8735 19 Sep 11:49 sysdeps/generic/cnf.bld_errno_tbl.c
  -rw-rw-r--  1 steffen  12415 19 Sep 11:49 sysdeps/generic/cnf.bld_signal_tbl.c
  -rw-rw-r--  1 steffen   8519 19 Sep 11:49 sysdeps/generic/cnf.builddep.pl
  -rw-rw-r--  1 steffen   1685 19 Sep 11:49 sysdeps/generic/cnf.chk_rtsignal.c
  -rw-rw-r--  1 steffen   1089 19 Sep 11:49 sysdeps/generic/cnf.fdsetsize.pl
  -rw-rw-r--  1 steffen    919 19 Sep 11:49 sysdeps/generic/cnf.pageshift.pl
  -rw-rw-r--  1 steffen   2090 19 Sep 11:49 sysdeps/generic/cnf.tz_h.pl
  -rw-rw-r--  1 steffen   5515 19 Sep 11:49 sysdeps/generic/x86/cnf.cpuclass.pl
  -rw-rw-r--  1 steffen   5908 19 Sep 11:49 sysdeps/generic/x86/cnf.cpuid.c
  -rw-rw-r--  1 steffen   1431 19 Sep 11:49 sysdeps/generic/x86/cnf.dotofrom.pl

And see how it ends:

  <> Configuration finished.
    < You can now type 'make'.  ('make help' shows options.)
    < To reverse config (full cleanup), type 'make distclean'.
      (Forget the POINT OF NO RETURN statement immediately :)).

Ah!  The dramatic composition!!

  @ Have fun!

Have you _ever_ seen a autotool script with such a friendly
finale??

 |[...]
 |> Diversifying the active set of branches naturally decreases the
 |> number of people which actively use changes that rot in some topic
 |> branch, which is in effect all that i wanted to say.  
 |
 |I agree, most of the topic branches should not live too long. I consider
 |the long-living automake branch as an exception, due to the particulary
 |large number of files impacted.
 |
 |> E.g., if you're done with the automake integration topic branch, then
 |> i as a maintainer would merge it onto [next], first with a merge
 |> commit, so that the branch remains intact.  Shall then defects show
 |> up, because of the broader audience and their testing, you could fix
 |> the bug in the topic branch, which then can be re-merged for broad
 |> testing (after being rebased by you so that a --ff-only merge would be
 |> possible?).
 |
 |In this use-case I would favour deleting the automake branch after the
 |initial merge into 'next', and then creating a new branch to fix the
 |issues found on 'next'.

 |[...]
 |> So, finally, it turns out that i think that it is essential that
 |> there is a main development branch which carries as many changes
 |> as possible.
 |
 |Well I agree, particularly if more heavy developments arrive in the
 |future.

Well, i managed to forget removing an empty line from a released
mdoc manual page which resulted in error messages and messed up
display.

 |> And another good news -- just call "$ git gc --aggressive" when
 |> you're done, and the repository will be cleaned from all that
 |> development garbage.
 |
 |Interesting, I didn't know this one, thanks!

Hm.
Ciao,

--steffen