make unmaintained ??
zbyszek at in.waw.pl
Mon Oct 26 12:49:23 UTC 2015
On Mon, Oct 26, 2015 at 08:37:05AM -0400, Stephen Gallagher wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> On 10/25/2015 06:10 PM, Adam Williamson wrote:
> > On Sun, 2015-10-25 at 19:53 +0100, Jan Kratochvil wrote:
> >> On Sun, 25 Oct 2015 01:07:47 +0200, Zbigniew Jędrzejewski-Szmek
> >> wrote:
> >>> I built 4.1 for rawhide. If that checks out to be OK, I can
> >>> push an update for F23 also.
> >> I do not understand why a major rebase could be permitted after
> >> all the F-23 freezing stages? It may cause FTBFSes or even
> >> broken builds. What is then all the release engineering good
> >> for? Why not to just run Rawhide then?
> >> This situation may be a FAQ, sorry I do not read every mail here.
> >> I did not want to be negative/discouraging, just I have seen such
> >> FTBFS regression(s) in Fedora in the past.
> > https://fedoraproject.org/wiki/Updates_Policy
> > Since we're frozen for Final at this point, non-blocker/FE updates
> > effectively have to respect the 'stable releases' policy, since
> > they will only go out as updates for F23 Final. That states:
> > "As a result, we should avoid major updates of packages within a
> > stable release. Updates should aim to fix bugs, and not introduce
> > features, particularly when those features would materially affect
> > the user or developer experience."
> > "Package maintainers MUST:
> > Avoid Major version updates, ABI breakage or API changes if at all
> > possible. Avoid changing the user experience if at all possible.
> > Avoid updates that are trivial or don't affect any Fedora users."
> > There isn't any body tasked with policing this, exactly - no-one
> > whose job it is to look at every package update and see if it meets
> > the rules - but if you think an update is inappropriate you can
> > post a comment and/or contact the package maintainer directly. If
> > you try this and the maintainer does not agree there's a problem,
> > and you're really concerned about it, you can escalate to the FPC,
> > I believe.
> I'm of the opinion that a new minor release of GNU make is likely not
> going to fit with the stable updates policy. I would be much happier
> if that went to Rawhide only at this point. We wouldn't change
> libtool, autoconf or gcc at this point, so I don't think it makes
> sense to change make either.
In this case it is worth looking at the actual changelog for 4.1:
The list of new features is:
* New variables: $(MAKE_TERMOUT) and $(MAKE_TERMERR) are set to non-empty
values if stdout or stderr, respectively, are believed to be writing to a
terminal. These variables are exported by default.
* Allow a no-text-argument form of the $(file ...) function. Without a text
argument nothing is written to the file: it is simply opened in the
requested mode, then closed again.
* Change the fatal error for mixed explicit and implicit rules, that was
introduced in GNU make 3.82, to a non-fatal error. However, this syntax is
still deprecated and may return to being illegal in a future version of GNU
make. Makefiles that rely on this syntax should be fixed.
So this is basically a minor release, almost entirely bugfixes.
If there are *any* issues caused by the upgrade in rawhide, then
it'll be reason not to upgrade F23. Otherwise, I'd just go with
More information about the devel