kamino icon indicating copy to clipboard operation
kamino copied to clipboard

Support cloning milestones?

Open demianmnave opened this issue 7 years ago • 4 comments

The GitHub API apparently supports migrating milestones, so perhaps this functionality could be added to Kamino as a convenience. This would also avoid problems with migrating issues having milestones that don't exist in the target repository.

demianmnave avatar Aug 22 '17 15:08 demianmnave

Here's my argument against creating milestones:

Let's say I create the milestone associated with the issue that you wish to clone in the new repo. That's fine. But what if this milestone is just one of many milestones? For instance, some people create milestones for their agile/Scrum projects. If I clone a milestone that is for Sprint 3, it has no meaning in the new repo. Furthermore, what if there's already a Sprint 3 milestone in the new repo?

I feel like it would add confusion and I think what should happen is milestones should be ignored altogether.

But I'm open to a counter argument or suggestions to make this work :)

johnmurphy01 avatar Aug 22 '17 15:08 johnmurphy01

It would certainly have to be optional, and not the default behavior.

For my use case, I wanted to exactly clone the issues, labels, and milestones associated with the branch that I turned into a new repository. If this is not a common use case, or is not a situation Kamino is meant to address, then simply ignoring milestones when cloning is perfectly acceptable.

demianmnave avatar Aug 22 '17 15:08 demianmnave

I could do the following:

  • Add a new option to the Options screen that says something like: Migrate associated milestones when cloning an issue. By default, this option will be disabled
  • If enabled, it will create only the associated milestone. It will not create all milestones within a repo
  • If disabled, it will behave as version 2.7 does now and ignore the milestone.

Thoughts?

johnmurphy01 avatar Aug 22 '17 16:08 johnmurphy01

There is no reason to migrate all milestones given the way Kamino works now, so this is definitely a reasonable solution. It isn't hard to image Kamino growing into a tool that supports bulk cloning, in which case migrating all milestones (but still not by default) would make more sense.

It's just icing on the cake, but you might also consider putting the option on the "Confirm Clone" dialog if an issue has milestones associated with it. The initial value could be populated by the state of the options page checkbox so that a user can decide per-issue whether to migrate milestones or not.

demianmnave avatar Aug 22 '17 19:08 demianmnave