[00:00] mpoirier, is this the patch set that tim suggested a separate tracking bug and pull request for each? [00:01] 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:02] tim and i did indeed talk about it. [00:02] they are all loosely related *AND* depend on each other. [00:03] which is something tim and I haven't discussed. [00:03] if we start mixing and matching, the patches may not apply properly. [00:07] mpoirier: I'd just be clear in your emails/SRU's the dependencies [00:09] humm.... Should I say something like "this patch depends on commit XYZ" ? [00:10] in the commit message that is... [00:11] 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] 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:12] they should indeed, but the author did his work incrementally. [00:13] bjf: did I answered your question ? [00:13] mpoirier, yes, i'm thinking about it [00:14] ok [00:14] 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:15] 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:17] bjf: that's what the author did, hence the 1/6...6/6 scheme. He also posted as such to linux-omap. [00:17] mpoirier: you could still submit them as a patch set of 6 patches but each patch references a different bug#/SRU [00:18] ogasawara: would you have an example handy somewhere ? [00:19] 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] make that your PATCH 0/6 email [00:20] mpoirier: then each patch you [00:20] mpoirier: that is submitted contains a reference to the BugLink [00:20] mpoirier: you can always insert additional text to the body of the email to then contain the SRU justification [00:21] mpoirier: and actual patch is inlined below [00:22] ogasawara: i like were you're going. let's clarify a few things. [00:23] 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] correct [00:23] good. [00:24] the very first email, please clarify "resolve SRU A, B, C...". [00:24] mpoirier: it was my understanding the patch set resolves a series of multiple issues [00:24] indeed. [00:24] mpoirier: each issue should have it's own separate SRU [00:25] Indeed. [00:26] I have a problem with the definition of A, B, C... [00:26] you could switch A, B, C... for issue 1, issue 2, issue 3, .... [00:26] it's just the list of issues to be resolves === ivoks is now known as ivoks-afk [00:27] can I think of those as list of summaries, and the real SRU justifications will come in the following emails ? [00:27] mpoirier: sure === bjf is now known as bjf[afk] === bjf[afk] is now known as bjf [00:29] ok. I'll send you a draft of that very first email on Monday before sending to the list. [00:29] mpoirier: eh, just send it to the list [00:29] mpoirier: I trust you'll get it right [00:30] mpoirier: plus it's good for others to learn from as well [00:30] ya... meanwhile i'm getting the beating. [00:30] 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] mpoirier: we all had to learn somewhere :) [00:30] bjf: we do, lemme find the link [00:31] indeed we do but I find there are always a few hidden rules to follow... [00:31] mpoirier: that's the spirit of open source anyways...submit, fix-up, re-submit, fix up, ... [00:31] mpoirier: indeed and it's best for those to be publicly described for other's to pick up on in the future [00:31] mpoirier, but everything that ogasawara and i have covered are not hidden rules and should be clearly explained in the wiki [00:32] bjf: https://wiki.ubuntu.com/KernelTeam/KernelUpdates [00:33] bjf: we should import the StablePatchFormat doc into that, or somehow tie the two together [00:33] ogasawara, yes, i can see that === jjohansen is now known as jj-afk [00:35] I'll be back on later [00:35] have a good weekend [00:35] you too jj-afk [00:35] * ogasawara thinks it might be a good time to start the weekend too [00:36] * bjf is done === 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