[Ksummit-2012-discuss] [ATTEND] Process issues, device model, stable

Joe Perches joe at perches.com
Wed Jun 20 23:01:56 UTC 2012

On Thu, 2012-06-21 at 08:52 +1000, NeilBrown wrote:
> It sounds to me like people are finding ways to work around process issues
> with a platform that "we" own and control.
> Is this an instance of "The platform problem"?
> Can we suggest enhancements to 'git' that would make these problems disappear?
> e.g. A common problem is that a bug is found in a patch that is already
> sufficiently 'frozen' that we would rather not fix it in-situ, but we want
> the patch which fixes the bug to be tightly bound to the patch which
> introduces the bug - sufficiently tightly that 'git bisect' will prefer not
> to separate them.
> If the 'fix' commit is created so that it's parent is the 'break' commit, we
> would just need some tag in the 'fix' commit to say "Always include me with
> my parent if possible".  Then we would need some smarts in git-bisect to
> honour this tag.
> I suspect those smarts would be very non-trivial, but then the issue that is
> being addressed is very prevalent so it is probably worth it (easy for me to
> say as I'm not doing the coding).
> And having 'fixes bug in XX' as a machine-readable annotation would
> doubtlessly have other benefits.
> i.e. should we be looking at how to enhance the tool instead of (or as well
> as) how to enhance the process?

Another option may be to standardize on reverting
brokenness where possible and use a new patch instead
of fixing the brokenness.

Of course that's not always possible so your suggestion
is still good and useful.

I think it'd be useful for git bisect to be able to
avoid/ignore reverted commits.

More information about the Ksummit-2012-discuss mailing list