[Development] Closing issues automatically with new keyword

[Oswald Buddenhagen]

On Fri, Aug 10, 2018 at 08:38:46AM +0000, Alexander Blasche wrote:
> Thiago Macieira <thiago.macieira at intel.com> wrote:
> > On Wednesday, 8 August 2018 23:39:16 PDT Alex Blasche wrote:
> > > That is the current approach and it does not work or scale.
> > > Between branching time and release time is a fairly long time. By
> > > then the x.y branch contains already x.y.(z+1) fixes (assuming the
> > > latest release branch is x.y.z). It is a big pita going through
> > > the issues figuring out which is where. I tried this for some time
> > > and found it a waste of time.
> > >
this is rather obviously something that should be automated. the system
can easily query the sha1 from the ticket, see what the lowest branch it
appears on in git is, and update the ticket's fix-version if it's wrong.

> > > A better approach might be to have some flag in the gerrit/git
> > > system that announces that the last merge for x.y.z was done. The
> > > script could then automatically mark fixes targeting the x.y
> > > branch as x.y.(z+1)
> > >
i previously thought that this is a good idea, too, but a) there is
inherently a race condition here due to the downmerge, and b) it's an
additional meta data store that needs to be 1) created and 2)
maintained.

so now i think the hook/intergration should just set the fix version to
the target branch name. yes, that implies that we should have the
version "dev" in jira.

a note on the "changes" field: it's kind of redundant with the automated
gerrit link derived from the task-number footer, and consequently many
people _refuse_ to set it "out of principle". however, it has the big
advantage that it allows fixing things up retroactively, both when a bug
link turned out to be bogus and when it was not done to start with. so
the hook should definitely populate it.

> > Why can't the renaming in JIRA be done at that exact time? That way,
> > we wouldn't get a mass update of tasks with the version changed.
> >
that's not a problem. notifications can be suppressed.

> It can and it should probably be done by the release manager. We have
> never consistently done it so far though.
> 
yes, because the effort was ridiculous as you noticed yourself.

> I find an automated version much cleaner and scalable. Hence my hope
> fregl can pick this up.
> 
yes, as a separate script that is operated "off-line" by the release
manager (or the guy doing the downmerge, which was me so far).