Re: [Bro-Dev] Moving to GitHub?
Big thumbs up. On May 15, 2018, at 5:34 PM, Johanna Amann wrote: >> What do people think? Any support, or concerns? > > I am in favor. The only thing I would miss are the immediate change > notifications by email - I really like those... > > Johanna > ___ > bro-dev mailing list > bro-dev@bro.org > http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] Moving to GitHub?
I am in favor. I would like to still maintain the the Jira and wiki for a couple months until we finish up some work. Really just the BPM tickets. > On May 15, 2018, at 7:19 PM, Robin Sommer wrote: > > This has been coming up in various contexts & subgroups of people, and > I wanted to send it out as a proposal to gather some broader feedback: > Do we want to move Bro's git repositories and tickets to GitHub? > > Currently we're hosting our Git repositories on our own server at > git.bro.org; from there, we mirror them to GitHub. For issue tracking, > we use JIRA at tracker.bro.org. Much of all this is a legacy setup in > some sense. I believe it would simplify life for both users & > developers if we moved to GitHub as the authoratative place for both > code and tickets. > > More specifically, I propose that we: > > 1. Turn the current git repository mirrors on github.com/bro into >authoritative source for all Bro code. Then we discontinue >git.bro.org. We can set up up some notification system there >instead that points people still using the old URLs to GitHub. > > 2. Switch to using GitHub as our primary issue tracker. Giving >the large amount of old tickets in JIRA, I think we should >just start from scratch there, porting over just the most >recent pending tickets. We'd keep the JIRA running in >read-only mode so that we don't loose the history and can >always refer back to old tickets. > > 3. Switch to a mostly PR-based development model (i.e., no more >merge requests tracked separately through tickets), and also >use GitHub for code review & feedback. > > 4. Make sure it all integrates nicely with Travis CI (which has >already been set up recently). > > About the only downside I see is that emailing out our standard commit > notifications won't be quite as smooth anymore: we'd still get them, > but with a bit of delay as some system would need to be polling for > changes, rather than being triggered immediately. Not much of a > problem I think (and with some additional work, we could make them > push-triggered, too; but probably not worth it). > > What do people think? Any support, or concerns? > > Robin > > -- > Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin > ___ > bro-dev mailing list > bro-dev@bro.org > http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] Moving to GitHub?
> What do people think? Any support, or concerns? I am in favor. The only thing I would miss are the immediate change notifications by email - I really like those... Johanna ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
[Bro-Dev] Moving to GitHub?
This has been coming up in various contexts & subgroups of people, and I wanted to send it out as a proposal to gather some broader feedback: Do we want to move Bro's git repositories and tickets to GitHub? Currently we're hosting our Git repositories on our own server at git.bro.org; from there, we mirror them to GitHub. For issue tracking, we use JIRA at tracker.bro.org. Much of all this is a legacy setup in some sense. I believe it would simplify life for both users & developers if we moved to GitHub as the authoratative place for both code and tickets. More specifically, I propose that we: 1. Turn the current git repository mirrors on github.com/bro into authoritative source for all Bro code. Then we discontinue git.bro.org. We can set up up some notification system there instead that points people still using the old URLs to GitHub. 2. Switch to using GitHub as our primary issue tracker. Giving the large amount of old tickets in JIRA, I think we should just start from scratch there, porting over just the most recent pending tickets. We'd keep the JIRA running in read-only mode so that we don't loose the history and can always refer back to old tickets. 3. Switch to a mostly PR-based development model (i.e., no more merge requests tracked separately through tickets), and also use GitHub for code review & feedback. 4. Make sure it all integrates nicely with Travis CI (which has already been set up recently). About the only downside I see is that emailing out our standard commit notifications won't be quite as smooth anymore: we'd still get them, but with a bit of delay as some system would need to be polling for changes, rather than being triggered immediately. Not much of a problem I think (and with some additional work, we could make them push-triggered, too; but probably not worth it). What do people think? Any support, or concerns? Robin -- Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
