[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Removal of INCLUDES in favour of AM_CPPFLAGS

From: Stefano Lattarini
Subject: Re: Removal of INCLUDES in favour of AM_CPPFLAGS
Date: Fri, 01 Feb 2013 19:59:58 +0100

On 02/01/2013 07:18 PM, Bob Friesenhahn wrote:
> On Fri, 1 Feb 2013, Stefano Lattarini wrote:
>> This wrong approach is probably the result of me trying to keep a foot
>> in both camps -- that is, maintaining mainline Automake while trying
>> to encourage a switch to Automake-NG in the long term.  Probably not a
>> good move, for any of those projects.
>> I should at this point decide whether just devote my "Automake time"
>> to mainline Automake (which amounts at letting Automake-NG die,
>> basically) or to Automake-NG (after tying some loose ends in the
>> mainline Automake code base, of course).
>> So, is anyone using or playing with Automake-NG, or at least
>> contemplating the idea to do so in the short term?  Or should
>> we just let the project die?
> While I understand that your time is limited, the logic of this last
> paragraph escapes me.  Automake has benefited significantly from your
> work in the past couple of years.
Still, when I (mostly unwittingly) had let my interest in Automake-NG steer
decisions for mainline Automake, the results have not been good .  I now
realize that trying to advance the development of both mainline Automake
and Automake-NG puts me in a "conflict of interest" situation, which makes
me susceptible of making choices suboptimal for one of the projects while
I'm focusing on the other.  That is not good.  That's why I think I need
to choose only one of these projects to actively devote myself to, and do
only basic "maintenance work" on the other [1].

 [1] For Automake-NG, this maintenance work would mean keeping the master
     branch regularly merged in ng/master, and ensure the testsuite keeps

> Other than pain/complaints caused by the sudden removal of
> long-deprecated (but not verbosely warned) features,
> Automake has been working better than before.  I don't see why
> Automake-NG should suffer or be aborted because of some complaint
> about Automake.
Because I fear I won't be able to focus on both at the same time,
without risking to favor one at the detriment of the other.

> If Automake can be put back on a stable course,
I think it easily can, at this point.  IMHO, the new pending features and
deprecations are all worthwhile; it's just some overly-eager removal of
old features that should be reverted.

> then you should be able to re-focus on Automake-NG.
That would mean limiting myself to basic maintenance work on mainline
Automake.  Which can be a worthwhile trade-off, but only if I can have
some hope that someone is going to actually use or at least play with

> None of us will be encouraged to experiment with or depend on Automake-NG
> by such questions.
The fact that I've dissuaded you to possibly depend on it is a good thing :-)
I wouldn't trust it to such degree yet.  But starting to experiment with it
would give precious real-world feedback, and that is of paramount importance
if we want to reduce the risk of painting us in a corner (design-wise, or
compatibility-wise, or in other unanticipated ways).

> If Automake-NG is heading to the fate of the Quagmire, then all of us
> should fear to use it.
I fear that what killed Quagmire (developed by Tom Tromey, so not some
random unexperienced guy) was precisely the lack of early adopters and
experimenters.  Lacking users, you lack feedback, you lose motivation,
and the project dies.

> However, if it does not doom us to the fate of the Quagmire and is
> believed to have a future with official releases, then we can start
> to depend on it and take pride in using it.
A first step would certainly be making it a separate project on
Savannah, rather than just a glorified branch in the Automake Git
repository (plus a dedicated mailing list).  Anyone has experience
or suggestions on how to better proceed in this direction?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]