hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Foley <mfo...@hortonworks.com>
Subject [PROPOSAL] Two Jira infrastructure additions to support sustaining bug fixes
Date Thu, 15 Sep 2011 18:58:59 GMT
Hi all,
for better or worse, the Hadoop community works in multiple branches.  We
have to do sustaining work on 0.20, even while we hope that 0.23 will
finally replace it.  Even after that happens, we will then need to do
sustaining releases on 0.23 while future development goes into 0.24 or 0.25,
and so on.

This is the price we pay for having this stuff actually in use in
production.  That's a good thing!
And it's been that way in every software company I've worked in.

My current efforts as release manager for 0.20.205 have made a couple
deficiencies in our Jira infrastructure painfully obvious.  So I would like
to propose two changes that will make it way easier and more reliable to
handle patches for sustaining bug fixes.  But I wanted to bounce them off
you and make sure they have community support before asking the
Infrastructure team to look at them.

1. Add a custom field "Target Version/s" [list].

Motivation: When making a release, one wants to query all Jiras marked fixed
in this release.  This can't be done reliably with current usage.
Also, one wants to be able to query all open issues targeted for a given
branch.  This can't be done reliably either.

Why current usage is deficient:  Currently we have "Affects Version/s" and
"Fix Version/s".  But the Fix Versions is being overloaded.  It is used to
mean "should be fixed in" (target versions) while the bug is open, and "is
fixed in" (fix versions) after the bug is resolved.  That's fine if there's
only one branch in use.  But if a fix is targeted for both A and B, and it's
actually committed to A but not yet to B, there's no way to query the state
of the fix.  The bug appears open for both (or sometimes it's incorrectly
closed for both!).  You have to manually visit the individual bug report and
review the SubversionCommits.  This might be automatable, but it sure isn't
easily expressed.

If we add a Target Versions field, then intent and completion can be
separately marked (in the Target Versions and Fix Versions, respectively),
and simple queries can clearly differentiate the cases.

2. Add "target branch/s" field to Attachments metadata (or if that's not
feasible, establish naming convention for Attachments to include this info)

Motivation: Enable CI test-patch on patches targeted for non-trunk, as well
as make the target clear to human viewers.

If this field can be added (I'm not sure Jira supports it), I suggest adding
it to the "Attach Files" dialogue box, and displaying it in the Attachments
and Manage Attachments views. If the Infra team says Jira can't support it,
then we (Hadoop dev) should talk about an unambiguous naming convention.

If this meta-datum were available, it should be fairly easy to modify the
automated test-patch process to test each patch against its intended target
branch. (This process is managed internally by members of the Hadoop dev
team, and I can help with it.)  This would give the usual benefits of CI to
our sustaining processes as well as mainstream development.

If you like either or both of these ideas, kindly +1 them.  If it's a bad
idea, by all means say why.
Absent negative feedback, I'm planning to open Infrastructure requests in a
few days.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message