[00:00] <bjf> mpoirier, is this the patch set that tim suggested a separate tracking bug and pull request for each?
[00:01] <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:02] <mpoirier> tim and i did indeed talk about it.
[00:02] <mpoirier> they are all loosely related *AND* depend on each other.
[00:03] <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:07] <ogasawara> mpoirier: I'd just be clear in your emails/SRU's the dependencies
[00:09] <mpoirier> humm.... Should I say something like "this patch depends on commit XYZ" ?
[00:10] <mpoirier> in the commit message that is...
[00:11] <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:12] <mpoirier> they should indeed, but the author did his work incrementally.
[00:13] <mpoirier> bjf: did I answered your question ?
[00:13] <bjf> mpoirier, yes, i'm thinking about it
[00:14] <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:15] <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:17] <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:18] <mpoirier> ogasawara: would you have an example handy somewhere ?
[00:19] <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:20] <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:21] <ogasawara> mpoirier: and actual patch is inlined below
[00:22] <mpoirier> ogasawara: i like were you're going.  let's clarify a few things.
[00:23] <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:24] <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:25] <mpoirier> Indeed.
[00:26] <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:27] <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:29] <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:30] <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:31] <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:32] <ogasawara> bjf: https://wiki.ubuntu.com/KernelTeam/KernelUpdates
[00:33] <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:35] <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:36]  * bjf is done