I am going to try to answer your questions. Keep in mind that my answers are how I would handle the transition. The point of the trial is to iterate and find the best solution for everyone.
> Some of the concerns brought up would be answerable with a trial. How do we > do a release? What does aggregating issues fixed in a particular version > look like? > You can tag GH issues with a version but I think it's best to just go through commit history to compile the release notes. This should already be done as there is no guarantee even with Jira that all issues were labeled correctly. If you are using GitHub issues, all issue numbers in commits link back to the issue or pull request which we don't have with Jira right now. > A trial would also answer how we handle security issues - JIRA can make > certain issues only visible to PMC. Is there a GH issues equivalent? > I don't think there is GH issues equivalent but I don't think this is a critical feature. The PMC has record on the private email list of any security issues. If it's a true security issue, shouldn't it be fixed immediately anyways? Some issues are not answerable with a trial, however. What happens to our > old issues? Do we close them as Won't Fix? Do we migrate them? Do we lock > JIRA and leave the archives up as a historical reference? If there is some > aspect of a trial that would answer this, then I'm all ears. > As for the migration, both GitHub & Jira have REST APIs. I could create a script that reads all open Jira issues and creates a corresponding GitHub issue. Each issue on GitHub could link back the old Jira issues and vice versa. It wouldn't be a perfect transition as I am sure not all fields will be moved over but we could at least get title, descriptions, reporter, and affected versions moved. If there is a link back to the original Jira issue, you could always go back to view original issue. This migration could be tested on a fork before being done on the main repo. After the migration is done, I would lock Jira but leave it up for historical purposes. > On Thu, Feb 15, 2018 at 7:26 PM, Mike Walch <mwa...@apache.org> wrote: > > > I want step back a little. I don't view this as just changing our issue > > tracker. I want to move to GitHub issues as I see a lot of benefit in > using > > one tool to manage issues, view/browse code, and review pull requests. > One > > tool makes contributing to open source so much easier. I think it will > > become the norm over time. This doesn't mean projects need to be locked > > into GitHub. Gitlab provides the same thing. I understand there are > > switching costs so I am on board with a trial. However, I think the > > benefits are worth the switch. You can fight this trend but I think it's > > like fighting the move from Subversion to Git. > > > > On Thu, Feb 15, 2018 at 7:04 PM, Josh Elser <els...@apache.org> wrote: > > > > > On 2/15/18 6:18 PM, Christopher wrote: > > > > > >> On Thu, Feb 15, 2018 at 5:08 PM Josh Elser <els...@apache.org> wrote: > > >> > > >> On 2/15/18 4:56 PM, Christopher wrote: > > >>> > > >>>> On Thu, Feb 15, 2018 at 4:55 PM Josh Elser <els...@apache.org> > wrote: > > >>>> > > >>>> On 2/15/18 4:17 PM, Mike Drob wrote: > > >>>>> > > >>>>>> What do we do if the trial is wildly successful? Is there a > > migration > > >>>>>>>> > > >>>>>>> plan > > >>>>>>> > > >>>>>>>> for our currently open issues? We have almost 1000 of them. > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> As Keith said in the other thread, we don't need to have all the > > >>>>>>> > > >>>>>> answers up > > >>>>> > > >>>>>> front. > > >>>>>>> > > >>>>>>> You're right, we don't need to have all of the answers up front. > > >>>>>> This is one that I'd like to have some thought put into though. > > >>>>>> > > >>>>>> There's lots of things that are fine to handle as we approach it, > > but > > >>>>>> > > >>>>> this > > >>>>> > > >>>>>> one seems like it will lead to us having split issue trackers > > >>>>>> > > >>>>> for_years_ > > >>> > > >>>> down the road. > > >>>>>> > > >>>>>> > > >>>>> This is a good point I hadn't yet considered. > > >>>>> > > >>>>> There's not only the migration question that eventually needs to be > > >>>>> answered, but an immediate question of how will we determine when > we > > >>>>> can > > >>>>> release a version of Accumulo? Are there conventions/features on > the > > GH > > >>>>> issues side that will provide some logical analog to the fixVersion > > of > > >>>>> JIRA? > > >>>>> > > >>>>> > > >>>> These are all great questions... that could be answered with a > > trial... > > >>>> > > >>>> > > >>> Shall I assume then that you are volunteering to handle all issue > > >>> management across the disparate systems for all releases? > > >>> > > >>> A trial is a good idea to determine _if we like the system_ and want > to > > >>> migrate to it. It's not a substitute for determining if the system is > > >>> _viable_. > > >>> > > >>> > > >> I'm of a different opinion: I already know I like GitHub issues and > want > > >> to > > >> migrate to it. What I don't know is if it is viable for Accumulo's > > needs. > > >> > > > > > > > > > Glad you like GH issues, but that isn't not what is being discussed > here. > > > The matter at hand is figuring out the logistics of *how* do we move > to a > > > different issue tracker in a manner that doesn't derail the project > > > management of a fully-distributed team. > > > > > > I'm worried because I feel like there are valid concerns being brought > up > > > here without acknowledgement of the impact of those who only > participate > > > with Accumulo digitally. > > > > > >
