On 5/15/18 7:19 PM, Robin Sommer wrote: > What do people think? Any support, or concerns?
Yeah, generally in favor with some comments: * For porting over JIRA tickets to GitHub, "most recent" doesn't seem like a good metric to use. e.g. BIT-1829 (pcap triggering assertion in binpac) seems kind of important and not something I'd want to have lost in the move, although it had no activity in almost a year. So, I think it's worth it to be more comprehensive here, and as long as someone is going through to review all the tickets, they may as well just port all the older ones that are still valid over to GitHub. (Yeah, I guess I'm volunteering). * One thing I did like about using JIRA for merge requests is that I could make a single ticket and just say I have a given branch name in a bunch of repos that are ready for review/merge. I find myself in that situation quite often, actually, so transitioning to GitHub PRs, I wonder if we'd want a PR to be created against each individual repo? Seems a bit much in terms of overhead. Alternatively, could still create a GH issue and just say "please review branch foo in repos X, Y, Z and merge them". Or else create a single PR in the "root" repo and mention in the PR that the same branch in child submodules also exists and needs merging. That may play better with Travis CI integration even, although maybe not in the case where you need to change things in the "external testing" repos, which are not connected to bro via a submodule. - Jon _______________________________________________ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev