[Qgis-developer] backported fixes

[Sandro Santilli]

On Wed, Jun 03, 2015 at 06:29:36PM +0200, Paolo Cavallini wrote:
> Il 03/06/2015 10:17, Sandro Santilli ha scritto:
> 
> > The problem I see is by requiring [BACKPORTED] tag in the commit
> > to master you're basically preventing to test fixes in master branch
> > before deciding if it's safe or not to backport.
> > 
> > I saw Jurgen referencing the commit identifier of the master branch
> > in the backporting commit, and I followed that habit as in that way
> > you can tell if a commit was backported by 'git log --grep'ing for
> > the commit of interest. For example (try these in 2.8 branch):
> 
> Hi Sandro,
> I see your point. My aim was to give "normal" users an easy way of
> discovering whether they can expect a fix in the next LTR release, or if
> they have to head for next release.

I think "normal" users should refer to the ticket for the bug they
are interested about. That one should be the source of all information.
It'd be surely the easiest one to get to (and users should be encouraged
to look for tickets and file them if not present, about their bugs).

Then we'd be back to finding a good way to encode which branches
got the fix. So far I think the agreement was to have "Target Version"
set to the oldest version containing the fix, so if you read "2.10"
as "Target Version", that means "2.8" will not have the fix, unless
some other step is taken. Now it'd be nice if the code that automatically
closes tickets reading commit logs (is it a standard redmine plugin ? or
is it code some qgis developer wrote?) could also derive from the
branch name whether or not the "Traget Version" should be updated.

--strk;