| bjf | mpoirier, is this the patch set that tim suggested a separate tracking bug and pull request for each? | 00:00 |
|---|---|---|
| bjf | mpoirier, if they were all related i'd say you could do it as one, however "various fixes and improvements" isn't going to cut it | 00:01 |
| mpoirier | tim and i did indeed talk about it. | 00:02 |
| mpoirier | they are all loosely related *AND* depend on each other. | 00:02 |
| mpoirier | which is something tim and I haven't discussed. | 00:03 |
| mpoirier | if we start mixing and matching, the patches may not apply properly. | 00:03 |
| ogasawara | mpoirier: I'd just be clear in your emails/SRU's the dependencies | 00:07 |
| mpoirier | humm.... Should I say something like "this patch depends on commit XYZ" ? | 00:09 |
| mpoirier | in the commit message that is... | 00:10 |
| ogasawara | mpoirier: I'd refrain from doing that unless you know the sha1 is not going to change, ie it's in Linus' tree. otherwise it's meaningless. | 00:11 |
| bjf | mpoirier, how do the patches depend on each other, if one calls code that only exists in another, they should be the same commit, yes? | 00:11 |
| mpoirier | they should indeed, but the author did his work incrementally. | 00:12 |
| mpoirier | bjf: did I answered your question ? | 00:13 |
| bjf | mpoirier, yes, i'm thinking about it | 00:13 |
| mpoirier | ok | 00:14 |
| bjf | mpoirier, the last SRU i recently did was two commits and they went together and i did it as a single tracking bug and single pull/patch request | 00:14 |
| bjf | mpoirier, you can see however, that we can get into issues where the patch submission is "I fixed a bunch of stuff" and the commits were done incrementally | 00:15 |
| mpoirier | bjf: that's what the author did, hence the 1/6...6/6 scheme. He also posted as such to linux-omap. | 00:17 |
| ogasawara | mpoirier: you could still submit them as a patch set of 6 patches but each patch references a different bug#/SRU | 00:17 |
| mpoirier | ogasawara: would you have an example handy somewhere ? | 00:18 |
| ogasawara | mpoirier: basically your PATCH 0/0 email will have a summary stating something like "The following series of patches are dependent on one another but resolve SRU A, B, C ..." | 00:19 |
| ogasawara | make that your PATCH 0/6 email | 00:19 |
| ogasawara | mpoirier: then each patch you | 00:20 |
| ogasawara | mpoirier: that is submitted contains a reference to the BugLink | 00:20 |
| ogasawara | mpoirier: you can always insert additional text to the body of the email to then contain the SRU justification | 00:20 |
| ogasawara | mpoirier: and actual patch is inlined below | 00:21 |
| mpoirier | ogasawara: i like were you're going. let's clarify a few things. | 00:22 |
| mpoirier | each email I send contains a patch that is associated with a bug (as usual) and also has a SRU description in it. | 00:23 |
| ogasawara | correct | 00:23 |
| mpoirier | good. | 00:23 |
| mpoirier | the very first email, please clarify "resolve SRU A, B, C...". | 00:24 |
| ogasawara | mpoirier: it was my understanding the patch set resolves a series of multiple issues | 00:24 |
| mpoirier | indeed. | 00:24 |
| ogasawara | mpoirier: each issue should have it's own separate SRU | 00:24 |
| mpoirier | Indeed. | 00:25 |
| mpoirier | I have a problem with the definition of A, B, C... | 00:26 |
| ogasawara | you could switch A, B, C... for issue 1, issue 2, issue 3, .... | 00:26 |
| ogasawara | it's just the list of issues to be resolves | 00:26 |
| === ivoks is now known as ivoks-afk | ||
| mpoirier | can I think of those as list of summaries, and the real SRU justifications will come in the following emails ? | 00:27 |
| ogasawara | mpoirier: sure | 00:27 |
| === bjf is now known as bjf[afk] | ||
| === bjf[afk] is now known as bjf | ||
| mpoirier | ok. I'll send you a draft of that very first email on Monday before sending to the list. | 00:29 |
| ogasawara | mpoirier: eh, just send it to the list | 00:29 |
| ogasawara | mpoirier: I trust you'll get it right | 00:29 |
| ogasawara | mpoirier: plus it's good for others to learn from as well | 00:30 |
| mpoirier | ya... meanwhile i'm getting the beating. | 00:30 |
| bjf | ogasawara, don't we have a wiki page somwhere that says what qualifies as a SRU for the kernel? (something like stable_kernel_rules.txt in the kernel's Documentation directory) | 00:30 |
| ogasawara | mpoirier: we all had to learn somewhere :) | 00:30 |
| ogasawara | bjf: we do, lemme find the link | 00:30 |
| mpoirier | indeed we do but I find there are always a few hidden rules to follow... | 00:31 |
| ogasawara | mpoirier: that's the spirit of open source anyways...submit, fix-up, re-submit, fix up, ... | 00:31 |
| ogasawara | mpoirier: indeed and it's best for those to be publicly described for other's to pick up on in the future | 00:31 |
| bjf | mpoirier, but everything that ogasawara and i have covered are not hidden rules and should be clearly explained in the wiki | 00:31 |
| ogasawara | bjf: https://wiki.ubuntu.com/KernelTeam/KernelUpdates | 00:32 |
| ogasawara | bjf: we should import the StablePatchFormat doc into that, or somehow tie the two together | 00:33 |
| bjf | ogasawara, yes, i can see that | 00:33 |
| === jjohansen is now known as jj-afk | ||
| jj-afk | I'll be back on later | 00:35 |
| jj-afk | have a good weekend | 00:35 |
| ogasawara | you too jj-afk | 00:35 |
| * ogasawara thinks it might be a good time to start the weekend too | 00:35 | |
| * bjf is done | 00:36 | |
| === bjf is now known as bjf[afk] | ||
| === Daviey- is now known as Daviey | ||
| === fddfoo is now known as fdd | ||
| === yofel_ is now known as yofel | ||
| === amitk-afk is now known as amitk | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!