[Qgis-developer] backported fixes

[Matthias Kuhn]

On 06/04/2015 10:43 AM, Sandro Santilli wrote:
> On Wed, Jun 03, 2015 at 11:09:45PM +0200, Matthias Kuhn wrote:
>> On 06/03/2015 10:11 PM, Sandro Santilli wrote:
>>> On Wed, Jun 03, 2015 at 09:43:31PM +0200, Matthias Kuhn wrote:
>>>
>>>> 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?
>>> The log of the backporting commit, you mean ?
>>>
>>> Isn't the information possibly derivable from the branch name ?
>>> Not specifying anything would be the minimum possible effort for
>>> developer :)
>> `git branch --contains {sha}` should return release-2_8 for a backported
>> commit.
> Only if the commit was "merged". Does not work with cherry-picked or otherwise
> rebased commits (very frequent, and personally I prefer those).

The master's commit hash not. But at the time that one is pushed to the
repository and hence evaluated by the plugin hook we don't know if it's
backported.
However, if you leave the "Fixes #XXXX" message in place it will
generate a new hash when backported (cherry-picked), which will be
linked in the ticket as well and return release-2_8 when evaluated by
the tracker.
The downside of this approach is that we do know that it's fixed in
release-2_8 but not in which point release. So if I fix something today
it says "fixed in 2.8" but to be precise it should say "fixed in 2.8.3".

>
>> But I have no idea how this plugin works and who maintains it :)
> Whatever the plugin does, it necessarely fetch commits of all branches
> (or it would not be able to find out about cherry-picked commits in the
> stable branch). 
>
> Right now the user should have all the info, as long as the commit log
> references the ticket. And the redmine plugin would also have them all,
> so there's no need to ask developers to do anything more than referencing
> the ticket (thus the importance, IMHO, to _require_ tickets exist for any
> commits into the stable branch).
>
> --strk;
We could also go the other way and take the release-2_8 branch history
as canonical source for fixes/Changelog.

That would be
 * 100% accurate
 * Contain information about the fix
 * Have a link to the ticket if one exists.

For me the two things are different:

 * The changelog (with fixes that *may* have a ticket attached)
 * The ticket that should contain information about on which branches it
has been resolved

Matthias

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20150604/debc9b3b/attachment-0001.pgp>