Re: [Bro-Dev] JIRA to GitHub ticket migration plan
On Tue, Sep 18, 2018 at 7:35 AM Vlad Grigorescu wrote: > > On Sat, Sep 15, 2018 at 1:28 AM Robin Sommer wrote: >> >> Are Jenkins and Coverity already pulling from GitHub? > > No, I thought Jenkins was pushing to Coverity. Travis is triggered by commits on GitHub and looks like it has a monthly cron to upload to Coverity. However, some submodule + testing repos that Travis clones are actually using the bro.org repo instead of github.com URL, but that's maybe not something to try to change now, but rather wait until performing the actual move. > Is the plan to have GitHub issues within each repo? That is, bro, binpac, > etc. I think we'd lose the easy way to see all issues, Yeah, issues are better kept within the associated GH repo. We rarely saw JIRA tickets made for non-bro subcomponents and a good portion of people were already using GitHub issues for those anyway. > but if I recall, there was a way in GitHub to see issues across a few repos. > Maybe by organization? Probably thinking of "project boards". You can create an organization-wide board that contains issues from separate repos. I haven't looked extensively at project boards, but I don't think it's something we'll generally use because you have to manually add issues to boards rather than treat them like an automated filter based on issue labels/status/etc. That could make it more useful when organizing specific long-term projects, but still likely decide to use it on a case-by-case basis rather than generally. - Jon ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] JIRA to GitHub ticket migration plan
On Sat, Sep 15, 2018 at 1:28 AM Robin Sommer wrote: > Are Jenkins and Coverity already pulling from GitHub? > No, I thought Jenkins was pushing to Coverity. Is the plan to have GitHub issues within each repo? That is, bro, binpac, etc. I think we'd lose the easy way to see all issues, but if I recall, there was a way in GitHub to see issues across a few repos. Maybe by organization? --Vlad ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] JIRA to GitHub ticket migration plan
On Fri, Sep 14, 2018 at 13:45 -0500, Jonathan Siwek wrote: > Anything else to worry about? Are Jenkins and Coverity already pulling from GitHub? I don't know if there's anything we can do on the old server to make existing clones deal with the relocation more gracefully. I don't wthink there's a way just redirect a git client, but maybe we could get some error message into the output or something? Not sure. Robin -- Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] JIRA to GitHub ticket migration plan
On Fri, Sep 14, 2018 at 11:36 -0500, Jonathan Siwek wrote: > I did some label tweaking and reduced some prefix names: "Component" > -> "Area" and "Difficulty" -> "Pain". Ok, thanks, makes sense. Robin -- Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] JIRA to GitHub ticket migration plan
On Fri, Sep 14, 2018 at 9:54 AM Robin Sommer wrote: > > real question here is if we want to switch repositories before or > after 2.6? Forgot to say that my sentiment is conditional -- if I find that it's not disruptive/risky to the release process (e.g. whether I need to make commits within bro itself), then changing whenever seems fine, else wait until after 2.6. It's maybe a week or two away before I have more complete investigation/answer, but it's possibly that risky. Here's the general things I'll be looking into and fleshing out: * GitHub "protected branches" for permissions and access control * Which private repos can actually be moved to GitHub (we'll need to update to Team Account) * Where all in the docs uses the old bro.org git URL. * How to handle commit email notifications. * How decouple-able is the script-reference building process. I'm guessing I can just point to the github url and it will work, but maybe there's some more we can offload from bro.org to Travis or AWS at this point as well. Anything else to worry about? - Jon ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] JIRA to GitHub ticket migration plan
On Fri, Sep 14, 2018 at 9:54 AM Robin Sommer wrote: > > On Thu, Sep 13, 2018 at 19:39 -0500, Jon Siwek wrote: > > > A preview of what migrated issues will look like along with new labeling > > scheme: > > The only thing I noticed is that the labels are > quite long, making the list of tickets appear somewhat crowded. Could > we skip the prefixes ("Type:", "Component:") and instead use colors to > encode them? I did some label tweaking and reduced some prefix names: "Component" -> "Area" and "Difficulty" -> "Pain". It's possible the color design could be done more carefully, but the basic idea is the colors are mostly encoding importance/difficulty. Green = go, yellow = caution, red = stop. That may help people scan the list to find potential things to work on related to their abilities or available time. A problem with removing the prefixes totally is that labels are sorted by name. So when one is viewing issues, they can get inconsistent label orders between issues: the priority label could be at the start, end, or middle of the label set. A more annoying thing is that when someone is trying to add labels to a new issue, they have to jump around a list to find which labels to add and there's not a clear end point. With prefixes, I can scan the list from top to bottom: pick an area, pick a pain, pick a priority, pick a type, done. Without prefixes, it's also less intuitive whether one should be mixing various labels together and accidentally pick two types that aren't meant to go together. Especially for those that are color blind, having a secondary way (the prefix) to distinguish label categories is a simple solution without having to do more color design and verification effort. I don't know enough to say how much a problem the current colors actually would be for what number of people, but trying to be thoughtful just in case. > We are leaving switching to github as authoritative source for the > repositories to later, right? Doing it all at the same time could > avoid confusion ("everything is on github now" is an easier > statement), but would also make the process more complex. Maybe the > real question here is if we want to switch repositories before or > after 2.6? I'd like to do the steps separately. Moving tickets shouldn't make the location of the git repo any more confusing than it is already. Some users are already using github instead of bro.org and devs are likely less-confusable anyway (or if not, it's still not a big deal if someone accidentally pushes commits to a non-master branch of github instead of bro.org). - Jon ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] JIRA to GitHub ticket migration plan
On Thu, Sep 13, 2018 at 19:39 -0500, Jon Siwek wrote: > A preview of what migrated issues will look like along with new labeling > scheme: Looks great, nice job. The only thing I noticed is that the labels are quite long, making the list of tickets appear somewhat crowded. Could we skip the prefixes ("Type:", "Component:") and instead use colors to encode them? So, say, all types would be green, all components yellow (which they already are), etc. > Remaining tasks: We are leaving switching to github as authoritative source for the repositories to later, right? Doing it all at the same time could avoid confusion ("everything is on github now" is an easier statement), but would also make the process more complex. Maybe the real question here is if we want to switch repositories before or after 2.6? Robin -- Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
[Bro-Dev] JIRA to GitHub ticket migration plan
A preview of what migrated issues will look like along with new labeling scheme: https://github.com/jsiwek/test/issues The selection strategy of which tickets to migrate is something like "anything that is a reproducible bug or a simple/uncontroversial enhancement". Any tickets not in that preview list will be left open in JIRA, but frozen as read-only. Going forward, JIRA will serve as a historical archive or Good Idea Backlog that we can occasionally pull from, but that can be done manually whenever the situation comes up (just create a GH issue and link to old JIRA ticket). Remaining tasks: * Perform the actual migration * Update website/docs with new directions/process for issues * Email bro + bro-dev mailing lists once tickets are migration * Adapt workflow permissions for JIRA "BIT" project so it's read-only I expect I'll do those next Monday unless there's objections or feedback to address. - Jon ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev