On 21/05/2015 14:41, Nathan Cutler wrote: >> * a backport issue is created in the "Backport" tracker and is >> "Related" to the original issue > > Hi Loic: > > I like the idea of having backport tickets in a separate Redmine > subproject/issue tracker. It would just be in a separate tracker, in the same project. > In fact, I would go even a step further and > have separate subprojects for each target version (hammer backports, > firefly backports). Separating them in a different project / subproject would create problems because redmine has ways to partition the subprojects that make some things difficult. For instance not all issues can be "Related" to issues in other projects which is kind of annoying. My general impression with redmine subprojects is that they tend to complexify and obscure the process rather than help. Or maybe it's just that my redmine skills are not what they should be. Do you have a different experience ? > Having all, e.g. hammer, backports in one place is advantageous in > pretty much every way I can think of: easier to see what has been > done, what needs to be done, easier to search, easier to automate, > less risk of munging something not related to backports... Yes. And I think we can have that by grouping them in a tracker instead of a subproject. Unless there are things we can only do if that's a subproject ? > It also has the effect of removing all the backport-related tickets > from the bug tracker(s). With the risk that developers who currently see and care for pending backport tickets would no longer see them. We would then have to seduce them into adding one more place to the list of places they have to watch. Maybe I'm being too conservative ? Too eager to not disrupt anything that could cause a problem to the developers ? Cheers > > Nathan > -- Loïc Dachary, Artisan Logiciel Libre
Attachment:
signature.asc
Description: OpenPGP digital signature
