Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support cloning milestones? #100

Open
demianmnave opened this issue Aug 22, 2017 · 4 comments
Open

Support cloning milestones? #100

demianmnave opened this issue Aug 22, 2017 · 4 comments

Comments

@demianmnave
Copy link

demianmnave commented Aug 22, 2017

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 demianmnave changed the title Support cloning milestones and labels? Support cloning milestones? Aug 22, 2017
@johnmurphy01
Copy link
Contributor

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 :)

@demianmnave
Copy link
Author

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.

@johnmurphy01
Copy link
Contributor

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?

@demianmnave
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants