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

[Fengguang Wu]

On Wed, Jun 20, 2012 at 04:01:56PM -0700, Joe Perches wrote:
> 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.

And possibly attach fixed-by/reverted-by tags to the bad commit using
git-notes.  This can be automated once we provide a machine readable
annotation you mentioned below.

> > 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).

Yeah it's not always feasible due to conflicts, but should work well
for trivial fixes.

> > And having 'fixes bug in XX' as a machine-readable annotation would
> > doubtlessly have other benefits.

Agreed.

> > 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.

I like your ideas! It could make bisect much less susceptible to
noises created by independent bugs.

Thanks,
Fengguang