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
Re: [Bro-Dev] Bro 2.6-beta plans
> On Sep 13, 2018, at 5:57 PM, John Althouse wrote: > > Could anyone update Bro on docker to include 2.5.5, 2.6-beta and master? > https://hub.docker.com/r/broplatform/bro/tags/ > > We use this with our internal trybro instance which is fantastic for quickly > collaborating and testing scripts. :) Working on it now :-) There isn't an official 2.6 beta, but I will build and upload 2.5.5 and current master. — Justin Azoff ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev