Thanks Mike, those are great answers! They don't even have to be the final answers, but I'm really happy to see that the migration path has been thought about.
I disagree with you about the criticality of security issues and how we handle them, but we can run a "fire drill" during the trial to fully develop the process. If you're volunteering to write a migration script using rest APIs (or perhaps one already exists) then that addresses the last of my concerns to starting a trial. Obviously I'd consider completion and testing of the script a requirement to completing the switch, but that's still a ways off. Consider me officially onboard with running a trial. Mike On Fri, Feb 16, 2018 at 9:27 AM, Mike Walch <mwa...@apache.org> wrote: > 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. > > > > > > > > > >
