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: https://lists.gnu.org/archive/html/info-gnu/2014-10/msg00000.html 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. See https://savannah.gnu.org/bugs/?33034 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. Zbyszek -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
