bug#13578: [IMPORTANT] Savannah issues

Stefano Lattarini writes: > So we should maybe go (after the next major release) with this naming > scheme for the branches? > > * maint -> for next micro version > * stable -> for next minor version > * master -> for next major version That seems to match common practice, insofar as I unde

bug#13578: [IMPORTANT] Savannah issues

Stefano Lattarini writes: > And while you *might* have changed my mind before (because you have > valid points, and maybe it would have better to err on the side of > safety), I have now already rewritten maint, so rather than messing > up by rewriting it again (to its old value, granted, but a re

bug#13578: [IMPORTANT] Savannah issues

Just that by far the most common branch setup in git repos seems to be using master as the "dev trunk", with releases, release candidates (etc) on special branches. There are often additional feature branches for even more speculative changes, but master is generally not really "safe," even if it'

bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository

2013/2/12 Stefano Lattarini : > Mostly fair points; but the biggest issue with this proposal (not > sure why I didn't think of it before, sorry) is that it is not at > all clear that a version like "1.13.0.1" is supposed to be a beta > release. People will easily mistake it for a stable release.

bug#13524: Improving user experience for non-recursive builds

>> Hmm, if that's the case, then I think "canon" is the wrong term to >> use, as it typically implies that the result is still in the same >> domain as the input. >> > Suggestions for a better name then? Dunno... something like "RELDIR_SYM" would make sense ... it's a symbol corresponding to RELD

bug#13524: Improving user experience for non-recursive builds

>> ... and "canon_reldir" means the same thing, except canonicalized? >> > Yes, "canonicalized" in a sense quite specific to Automake: > > > > So, for example, if %reldir% expands to 'foo/bar-baz.d', '%canon-reldir%' > w

bug#13524: Improving user experience for non-recursive builds

%...% seems nice to me. I don't think "typability" should be a prime factor in deciding, especially such trivial issues such as shifted-characters (like 75% of punctuation in Makefiles is shifted on most keyboards); readability is _much_ more important (and readability in many cases means not too

bug#13524: Improving user experience for non-recursive builds

Stefano Lattarini writes: >> E.g., if I have a directory "foo" that has sources etc, and builds >> some specific targets, then I can isolate the automake stuff for foo >> by using an include file "foo/Makefile.am.inc" or something, and then >> putting an appropriate include in the top-level Makefi

bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option

Pedro Alves writes: >> OK, you've all made clear you have your sensible reasons to have the '.info' > > ... >> it available only though the new, undocumented option named (literally) >> "hack!info-in-builddir". I hope this is acceptable to you. > ... >> *undocumented* option '!hack!info-in-buildd