The main requirement is that it requires a person with a high enough permission level in JIRA to setup the connector to github. They also need to be able to configure the github side as well.
On Tue, Jul 7, 2015 at 7:38 PM, Matt Burgess <[email protected]> wrote: > Is it difficult to get the DVCS connector installed/enabled for Drill's > Jira? I know for my company it's been sitting on the to-do list for a > while, but we haven't actually installed it. > > Sent from my iPhone > > > On Jul 7, 2015, at 8:25 PM, Jim Scott <[email protected]> wrote: > > > > The instructions for setting up JIRA to integrate with github is here: > > http://blogs.atlassian.com/2014/04/connecting-jira-6-2-github/ > > > > As Ted points out, in this case any comment on a commit that says > DRILL-NNN > > would get found by JIRA and would automatically be added to the Jira > ticket > > for the history to be reviewed. > > > >> On Tue, Jul 7, 2015 at 4:32 PM, Ted Dunning <[email protected]> > wrote: > >> > >> The only Apache requirement is that the mailing list + JIRA makes sense > and > >> is readable as a history of the project. Keeping the issues on github > >> won't fly. > >> > >> It is pretty easy to get github to hook into JIRA pretty well if the PR > >> messages have a reference to the JIRA. I don't know the details. > >> > >> The suggestion to require the person who merges to include a code-word > in > >> the message is a very good one. > >> > >> > >> > >>> On Tue, Jul 7, 2015 at 1:35 PM, Jacques Nadeau <[email protected]> > wrote: > >>> > >>> I don't think we need anything formal. Do you want to propose a few > >> simple > >>> guidelines? > >>> > >>> E.g. Should we link to PRs on JIRA, do we really need a JIRA, the > merger > >> is > >>> responsible for including the "close #123" syntax in the commit, etc. > >>> > >>> On Tue, Jul 7, 2015 at 1:33 PM, Jason Altekruse < > >> [email protected]> > >>> wrote: > >>> > >>>> Seems to be enough consensus that this is beneficial. I took a look at > >>> the > >>>> bylaws and it doesn't say anything specific there about an official > >>> review > >>>> process. Is there a need to start a separate vote thread before making > >> a > >>>> change like this? > >>>> > >>>> I would be in favor of allowing both for a little bit, if it is a > >>>> significant improvement we can move to completely deprecate > >> reviewboard. > >>>> > >>>>> On Tue, Jul 7, 2015 at 1:14 PM, Jacques Nadeau <[email protected]> > >>>> wrote: > >>>> > >>>>> What did we decide here? > >>>>> > >>>>> Are we going to move forward with trying out pull requests? If so, > >> do > >>> we > >>>>> want to start having everyone do it or suggest only one or two do it > >> to > >>>>> start? > >>>>> > >>>>> thoughts? > >>>>> Jacques > >>>>> > >>>>> On Wed, Jun 24, 2015 at 8:46 AM, Jacques Nadeau <[email protected]> > >>>>> wrote: > >>>>> > >>>>>> I can't remember the rule. I think it was 3gb and 15 minutes. In > >>>> order > >>>>>> to get under 3 gb, I think we need to run single threaded. Last I > >>>>> checked, > >>>>>> running with 4 threads on dedicated hardware completes in ~12 > >>> minutes. > >>>>>> However, the Travis instances used to be really slow virtual > >>> machines. > >>>>> I'm > >>>>>> sure a solution can be found but I think we'd need some concerted > >>>> effort > >>>>> on > >>>>>> reducing the test footprint. > >>>>>> > >>>>>> We talked before (Daniel's suggestion) about treating more of the > >>> tests > >>>>> as > >>>>>> integration tests. This would help as much of the test time is > >> spent > >>>>>> starting and stopping Drillbits for each test class. If we only > >> did > >>>> this > >>>>>> once for all those tests, the footprint would be much smaller. > >>>>>> > >>>>>> > >>>>>> > >>>>>> On Wed, Jun 24, 2015 at 8:37 AM, Ted Dunning < > >> [email protected]> > >>>>>> wrote: > >>>>>> > >>>>>>> On Wed, Jun 24, 2015 at 11:35 AM, Jacques Nadeau < > >>> [email protected]> > >>>>>>> wrote: > >>>>>>> > >>>>>>>> We tried Travis before. The problem is that travis's nodes > >> aren't > >>>>>>>> substantial enough to complete our test suite within their > >>> timeout. > >>>>>>> > >>>>>>> Haven't the tests been substantially improved since then? > >>>>>>> > >>>>>>> Can the tests be segregated into pieces so Travis can still do > >> some > >>>>> useful > >>>>>>> work? >
