We don't actually have permission to change the JIRA instance ourselves, but we can open an apache infra ticket for it. Here is a blog post about some integration they added fairly recently. It says here that they need to enable several features as requested by particular projects. Is there anything listed here we don't want turned on?
I'm going to do a little more digging, because it is not clear to me if the actual content of the patches makes it back to the JIRA with this automatic integration. It would be nice to remove the extra step of generating and uploading patch files, but we want to make sure we have the code changes stored on apache infra somehow. https://blogs.apache.org/infra/entry/improved_integration_between_apache_and On Tue, Jul 7, 2015 at 5:41 PM, Jim Scott <[email protected]> wrote: > 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? > > >
