Date: Sun, 27 Jul 2014 15:17:24 -0400 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Preparing 1.0.4 maintenance release Looking at the commit log, I see a pretty huge list of commits that should probably be applied to 1.0.4: 246e752d9e7c472735444815163f0a22e5bc4161 -- backport 4e5c7a2176773c9a1564c6603240337b3ad6b496 94cf991bf4b18bb87a15a96e7b5e7d92fab787ba -- really needed? cef0f289f666b6c963bfd11537a6d80916ff889e fe82bb9b921be34370e6b71a1c6f062c20999ae0 70d9c303b3115ab0fe6060ba0f7b0e4c0a2320b7 1cc69faa5c2f0a189c35cf980ff4fa526ce866f4 -- INSTALL note on gcc 4.9 e89cfe51d2001af08fc2a13e5133ba8157f90beb ebd8142a6ae19db1a5440d11c01afc7529eae0cd 984c25b74da085c6ae6b44a87bbd5f8afc9be331 ea496d6c63ecbb5ea475111808e5c0f799354450 729673689c3e78803ddfdac2ca6be5a5b80e124a 349381aa8c0fc385e54e1068dd5f2b27af55cd12 da27118157c2942d7652138b8d8b0056fc8f872f c463e11eda8326aacee2ac1d516954a9574a2dcd -- without this, next item needs backport a6adb2bcd8145353943377d6119c1d7a4242bae1 -- workaround constant folding bug? 72ed3d47e567b1635a35d3c1d174c8a8b2787e30 d69ab5b3686acf75fdf5db6fad19c2c6a510bb4f dc9c40a609de6a79ec30013b0963a57393daa22e 7fdae458bd421046a300a69dcb32953ac9450136 bb3a3befeaa01531c273ef9130f3fbcaaf8a25e2 a294f539c78c6ba0a2786ef3c5b2a1210a33864e -- with this, backport of next is not needed bcad48439494820989f5867c3f8ccfa6aae2909f -- maybe backport 1456b7ae6b72a4f2c446243acdde7c951268d4ab 884cc0c7e253601b96902120ed689f34d12f8aa0 522a0de2101abd12b19a4d2ba5c09abbb7c5fc79 f61be1f875a2758509d6e9e2cf6f1d9603b28b65 1312930f9bdea47006a8a8c8509c0bed5cf69e85 a19cd2b64aabee4ae3c80bcf4ba8da26fba560e4 0206f596d5156af560e8af10e950d3cb2f29b73d For a couple (see the notes) I think a direct cherry-pick would suffice if I also cherry-pick one or more previous commits that make minor related changes that aren't strictly necessary for the bugfix. Otherwise there would be non-trivial backporting work to apply the change to the old branch. My question is this: from a standpoint of providing a stable/regression-free 1.0.4 release, which approach would be preferable: A. Simply cherry-pick enough to minimize or eliminate the need to custom-backport important bug fixes. This risks breakage from bringing in unnecessary changes, but avoids making new changes in a backport by hand that wouldn't be heavily tested. B. Backport by hand the commits that don't apply cleanly. This avoids bringing in unnecessary changes that might introduce breakage, but risks creating new bugs in a branch that's not going to get good testing. C. Skip fixes that would require non-trivial backporting unless they're security-critical. As a lot of the fixes are for archs that obviously weren't really working right back when 1.0.0 was released, there's some argument to be made that these archs should just be deprecated in the 1.0.x series. On the other hand, most of the breakage was limited to multi-threaded usage and certain particular usage cases (like the mips dev_t issue which only affects programs that actually parse the device numbers) so it's plausible that people have working simple systems with 1.0.x on these archs and would like the continued support. One other item: the above list has the workarounds for gcc 4.9.x in it. I think I should just backport then to rs-1.0 and leave them in place permanently for maximum stability/safety rather than worrying about later going back and deprecating support for these broken compilers in a stable series. Does that sound reasonable? Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.