make unmaintained ??

Zbigniew Jędrzejewski-Szmek zbyszek at
Mon Oct 26 12:49:23 UTC 2015

On Mon, Oct 26, 2015 at 08:37:05AM -0400, Stephen Gallagher wrote:
> 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.
> > 
> >
> > 
> > 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
the upgrade.


More information about the devel mailing list