On Mon, Jul 23, 2018 at 5:53 AM, Ernesto Puerta <epuertat@xxxxxxxxxx> wrote: > Being able to solely rely on git/GitHub is ok, but git is rather tough when > it comes to depict non-sequential relationships (epics, features, tasks, > bugs, etc.). > > From past experience I've found that a decent issue tracker supporting some > hierarchical break-down is an extremely valuable tool for backporting. It > allows everyone (and not only git masters) to follow all the pieces of code > that ensure a feature meets its expected behaviour (it provides a single > entry point for a backporting script). And it's easy to implement with a > server-side hook & a few REST API calls. I'll agree here with this. An "epic" (a feature with various different components and relations to other issues) would just not work by adding one or two lines to git commits. I do think the two can go hand in hand (is it a requirement to exclude tooling vs. git commit additions?), but certainly what we lack today is an issue tracker that can easily give an overview of something that spawns multiple issues/backports at once > > Unfortunately for the (2), as you mentioned, from a tooling perspective only > a 100% test-case coverage could catch those. > > Ernesto > (the guy with a 210-commit backporting ongoing) > > On Mon, Jul 23, 2018 at 9:13 AM Jan Fajerski <jfajerski@xxxxxxxx> wrote: >> >> On Sun, Jul 22, 2018 at 02:03:10PM +0000, Sage Weil wrote: >> >Backports are always hard, but I think there are two main categories of >> >reasons why they can break things: >> > >> > (1) is the pattern we saw with 12.2.6, where a feature is introduced >> > with >> >a bug, a bugfix follows a bit later when it is discovered and fixed, but >> >the feature backport doesn't realize there is a later fix. >> > (2) is when a feature is backported completely but there is some >> >functional second order interaction with the rest of the system that >> >prevents it from working correctly. >> > >> >The latter scenario will always require either a developer who is paying >> >close attention or a lot of testing to prevent, which is why we should >> >always be very mindful with backports, especially non-bugfix ones, and >> >especially ones in complicated code. The first case, though, is IMO a >> >failure in tooling and process. >> > >> >A few possible solutions come to mind: >> > >> >1- Always reference the commit that introduced the bug/regression in the >> >bugfix commit. Then, when backporting, always search git for the sha1 of >> >the patch being cherry-pick -x'd. This should turn up the follow-on fix. >> >(Perhaps some tooling could streamline this?) >> > >> >2- Always mention the follow-on fix as a comment on the pull request that >> >originally introduced the new code/feature. This requires checking the >> >original pull request when doing the backport. >> > >> >3- Always open a tracker ticket, even for recent, just-introduced >> > bugfixes >> >in master. Reference that... somewhere? >> > >> >I think the core problem is that when doing feature backports there is >> > not >> >always a (feature) ticket or other single reference to look at that >> >captures everything about that feature. Even #2 and using the PR doesn't >> >seem like a complete solution because often there are multiple pull >> >requests to introduce a feature. >> > >> >It seems like there are two main options: lean on the git history, or >> > lean >> >on external feature tickets. >> > >> >I'm worried about the latter because we frequently have a series of >> >incremental pieces for a single feature, or related features that build >> > on >> >one another, so there isn't always a 1:1 mapping between the PRs and a >> >(hypothetic) feature ticket. We also don't always maintain feature >> >tickets, so this would be a net increase of process overhead. >> > >> >This makes me lean toward leaning on git, and being more pedantic about >> >ensure any bug fix references the git commit where the issue was >> >reproduced. The kernel uses a simple >> >> I think it makes sense to lean on git as the primary tool to track this. >> Other >> tools could use this info to provide convenience (e.g. github will make >> those >> shas into links) or be used on top of this where is makes sense. >> > >> > Fixes: <sha1> >> > >> >tag in commits. With that, I think, the missing piece is some >> >tooling/help to make sure we pay attention to these tags. I see two >> >scenarios: >> > >> > - You are backport foo and need to notice commit bar that has a Fixes: >> >foo line. >> > - You already backported foo. Later you commit bar with Fixes: foo, and >> >need to noticed that foo was already backported and the backport branch >> >also needs bar. >> > >> >What do you think? >> >sage >> > >> >-- >> >To unsubscribe from this list: send the line "unsubscribe ceph-devel" in >> >the body of a message to majordomo@xxxxxxxxxxxxxxx >> >More majordomo info at http://vger.kernel.org/majordomo-info.html >> > >> >> -- >> Jan Fajerski >> Engineer Enterprise Storage >> SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, >> HRB 21284 (AG Nürnberg) >> -- >> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in >> the body of a message to majordomo@xxxxxxxxxxxxxxx >> More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
