Matches for patch, 1691 total results Sorted by newest | relevance
Fri Jan 29 20:29:53 UTC 2016 <kakobrekla> what is the 'special patch'?
Fri Jan 29 20:28:37 UTC 2016 <mircea_popescu> + # You need to have these keys in your gpg keyring to vertify V, trinque's special patch, buildroot, and other stuff.
Fri Jan 29 20:28:01 UTC 2016 <mod6> to verify V, trinque's special patch, buildroot, and other stuff.
Fri Jan 29 20:16:41 UTC 2016 <phf> i remember ascii suggesting that perhaps we should stick to one hunk per patch, but that's not the case right with existing patches. if z thematically needs to touch two different files (a and b), then both modifications are inside a single patch
Fri Jan 29 18:55:37 UTC 2016 <ascii_butugychag> mircea_popescu: note how i cut the shiva patch in 2
Fri Jan 29 18:48:07 UTC 2016 <mircea_popescu> the best way forward, imo, is to restructure it as 1) one large patch consisting of nothing but the return fixes and some smaller patches doing the rest of the stuff built on top of that.
Fri Jan 29 18:47:43 UTC 2016 <mircea_popescu> polarbeard don't get this wrong, you did a lot of very useful work in that patch.
Fri Jan 29 18:32:47 UTC 2016 <mircea_popescu> note that the only way i got my apparently very controversial /s /t patch to even be considered was showing how it could be machined.
Fri Jan 29 18:32:14 UTC 2016 <ascii_butugychag> so i can ask the same question, line after line, for a whole patch
Fri Jan 29 18:32:13 UTC 2016 <mircea_popescu> polarbeard yeah, you get the right idea, but seriously, making a single patch consisting of JUST -return error +return error is the right way
Fri Jan 29 18:31:43 UTC 2016 <mircea_popescu> but it's also immense and should all be one single patch so we can see it more readily.
Fri Jan 29 18:31:28 UTC 2016 <polarbeard> mircea_popescu: the patch ended up being a bit verbose, yep, but it made sense to me fixing the messages as I was adding metadata, that's why I didn't add filtering, to not add actual logic to an already pretty big patch
Fri Jan 29 18:31:27 UTC 2016 <mircea_popescu> there's a lot of stuff in there that will necessarily result in a huge patch (the guy is stuck, willy-nilly, doing a lot of
Fri Jan 29 18:29:56 UTC 2016 <punkman> mircea_popescu: so how would you split polarbeard's patch?
Fri Jan 29 18:26:13 UTC 2016 <ascii_butugychag> pete_dushenski: supposedly there is an x11 patch to make it go
Fri Jan 29 18:23:55 UTC 2016 <mircea_popescu> so in full terms, i would say that again, including both in the same patch is both premature optimization and a kludge.
Fri Jan 29 18:23:07 UTC 2016 <phf> a way to indicate (a->a' b->b') would normally be to include them both in a single patch. i think that's how it's done now
Fri Jan 29 18:18:26 UTC 2016 <phf> so in the above example x y z are distinct patches, their effect is to take files through states, a, a', a". so if a patch takes a->a', then it needs a in genesis. if a patch takes a'->a" then it needs genesis and a->a' patch. i was trying to indicate that y and z modify two separate files, i'm trying to see what is there that indicates that state (a' b') is desirable over (a' b)
Fri Jan 29 18:12:52 UTC 2016 <punkman> phf, my "shortest path" algo is to recursively find all antecedents of the patch I want to press. it's useful.
Fri Jan 29 17:33:28 UTC 2016 <ascii_butugychag> phf: i have a patch for adding actual tcp to ts