[<prev] [next>] [day] [month] [year] [list]
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.
