<div dir="ltr">On Mon, May 26, 2014 at 9:58 PM, Guo Yixuan <<a href="mailto:culu.gyx@gmail.com">culu.gyx@gmail.com</a>> wrote:<br>><br>> Hello Steffen and Gianfranco,<br>><br>> I've noticed that, since long ago, our patches keeps growing<br>
> in a unsustainable way, and thus really difficult to understand<br>> and maintain. There're currently more than seventy of them in<br>> debian/patches, and some of them have their place in series,<br>> partly commented. Also, the naming method in README.patches<br>
> is largely ignored by us.<br>><br>> As a first step, I'm going to purge those dropped for a long<br>> time, eg. patches like AvoidingBlanksInMakefiles.patch, or<br>> 005_disable_client_res.patch, which I don't find helpful even<br>
> for backports. Meanwhile, some dropped patches might still<br>> be useful in some way, eg. 006_correct_catalog_path.patch.<br>><br>> (more work in progress)<br><br>@Steffen<div>Would you mind if I removed your const patch set?</div>
<div><br></div><div>I mean these ones:</div><div><br></div><div>debian/patches/series:</div><div><div>13:#AddSomeConstToMakeClearMemoryIsNotAllocated.patch</div><div>14:#AddingMoreConst.patch</div><div>15:#evenMoreConst03.patch</div>
<div><br></div><div>and also annoying_warning_const_image.patch (not in series)</div><div><br></div><div>They seem to be just for debugging purpose, and it's not quite</div><div>meanful to maintain them in Debian. (It would be nice if the</div>
<div>upstream takes them, but we should not add them to our</div><div>maintenance burden, or to upstream-Debian deviation,</div><div>should we?)</div><div><br></div><div>Cheers,</div><div><br></div>Yixuan</div></div>