[Qgis-developer] backported fixes

[Matthias Kuhn]

On 06/03/2015 09:26 PM, Sandro Santilli wrote:
> 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;
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
The ticket system sounds like a good place to manage this information.
In comparison to the commit in master the ticket can be altered later
on. And is referenced from the commit in master if that's the starting
point of the search.
Further it has a nice box showing commits including messages which
relate to that ticket. So if the commit message says "backported to
2.8.3" all the information is there. And it's a minimal effort for the
developer.

What do you think?

Matthias