I am thinking bi-annual, and agree that we should shoot for 6.1 as soon as possible, actually. Let's make master stable and then start tackling the few remaining issues, which seem reasonable to me:
https://issues.apache.org/jira/browse/JOSHUA/fixforversion/12335049/?selectedTab=com.atlassian.jira.jira-projects-plugin:version-summary-panel One issue not listed here was to switch the junit test cases to testng (I think that's what we decided). The main thing I need to do is setup the language packs so that they can be used with Joshua 6.1. matt > On Jul 11, 2016, at 4:46 AM, kellen sunderland <kellen.sunderl...@gmail.com> > wrote: > > Thanks for organizing Lewis, sorry for the late replies. Looking at the > frequency of our updates I'd suggest quarterly, or bi-annual releases. If > we can keep the master branch stable (which should really be a goal of > ours) then hopefully it's not too much work to create the releases. I do > appreciate that there's probably some effort required to create release > notes + documentation. Hopefully JIRA will be able to help us create some > of this documentation. > > I'd agree that we should shoot for a 6.1 release fairly soon. I'll review > the PRs that came from our side early after the Apache switch. They should > probably have JIRA tickets tracking the changes with fix version assigned > as 6.1. > > -Kellen > > > > On Thu, Jun 23, 2016 at 11:01 PM, Tom Barber <t...@analytical-labs.com> > wrote: > >> Hey Matt >> >> Over on OODT our releases are few and far between, although that said, >> I've been trying to increase the frequency even if they are very minor. The >> main reason being, if someone commits some code, they don't want to wait 12 >> months for it to hit a stable release! So you might say yearly major >> releases and patch releases at sporadic points inbetween to include patches >> people have submitted, this also keeps drive by committers interested >> because if they get some stuff into the codebase they then may commit more, >> rather than say "well I submitted a fix for issue x ages ago and its got >> notwhere". Releases don't need to be set in stone, but I would try and >> keep them ticking over. >> >> Just my own 2 cents. >> >> Tom >> >> -------------- >> >> Director Meteorite.bi - Saiku Analytics Founder >> Tel: +44(0)5603641316 >> >> (Thanks to the Saiku community we reached our Kickstart >> < >> http://kickstarter.com/projects/2117053714/saiku-reporting-interactive-report-designer/ >>> >> goal, but you can always help by sponsoring the project >> <http://www.meteorite.bi/products/saiku/sponsorship>) >> >> On 23 June 2016 at 21:56, Matt Post <p...@cs.jhu.edu> wrote: >> >>> Hi Lewis, >>> >>> Sorry for taking some time to get back to you. I think the roadmap looks >>> great. One thing, though, is that the Amazon folks and I have discussed >>> making a number of backwards-incompatible changes in an effort to >> modernize >>> some pieces of the code. This would have to do with things like the >> config >>> file format, a totally new pipeline based on duct tape, and some other >>> ideas. We think those changes would be suitable for a 7.0 release (major >>> version number change signals backwards incompatibility). >>> >>> I think we've been doing some good work on improving Joshua, but at the >>> same time, I think the release cycle is still little too accelerated for >>> me. I would like to push back to semi- yearly or even yearly releases, >> with >>> bug fixes in between. However, I'm also curious how this might affect our >>> ability to move out of incubation. Do you have any thoughts on this? >>> >>> The major downsides to releases are documentation. It's just hard to find >>> the time to do. >>> >>> My own thoughts for what I'd like to do: >>> >>> - Maybe a 6.1 release (soon, to get it out of the way? or otherwise this >>> fall?), where we formalize the Apache move and maybe formalize the >> release >>> of a handful of language packs, without a lot of other changes >>> >>> - Write a linux.com article advertising this, hopefully attracting some >>> attention >>> >>> - Shoot for a 7.0 release with many of the changes we've discussed (some >>> offline). If we get a good showing at MT Marathon in Prague this year, >> that >>> could be a good time to get all of that in order. >>> >>> - Start getting to work on a version of Joshua that swaps out the core >>> decoder for a neural approach >>> >>> matt >>> >>> >>> >>> >>>> On Jun 23, 2016, at 4:13 PM, Tom Barber <t...@analytical-labs.com> >> wrote: >>>> >>>> I would volunteer some cycles for multi model support in the server and >>> an >>>> improved rest interface and basic UI for end user interaction if you >>> fancy >>>> it. >>>> >>>> -------------- >>>> >>>> Director Meteorite.bi - Saiku Analytics Founder >>>> Tel: +44(0)5603641316 >>>> >>>> (Thanks to the Saiku community we reached our Kickstart >>>> < >>> >> http://kickstarter.com/projects/2117053714/saiku-reporting-interactive-report-designer/ >>>> >>>> goal, but you can always help by sponsoring the project >>>> <http://www.meteorite.bi/products/saiku/sponsorship>) >>>> >>>> On 23 June 2016 at 21:10, Lewis John Mcgibbney < >>> lewis.mcgibb...@gmail.com> >>>> wrote: >>>> >>>>> Hi Folks, >>>>> Anyone have any comments on this? >>>>> Seeing that the Maven multimodule project seems to be taking flight, >> it >>>>> would be nice to see where the roadmap is going? >>>>> Any comments would be great. Also, I'm kinda lost as to what is >>> happening >>>>> with Jira but it looks like it is not really being used for much. >>>>> Thanks >>>>> >>>>> On Mon, Jun 20, 2016 at 11:34 AM, Lewis John Mcgibbney < >>>>> lewis.mcgibb...@gmail.com> wrote: >>>>> >>>>>> Hi Folks, >>>>>> I've just smartened up Jira a bit with our Roadmap being defined as >>>>> follows >>>>>> >>>>>> >>>>>> >>>>> >>> >> https://issues.apache.org/jira/browse/joshua/?selectedTab=com.atlassian.jira.jira-projects-plugin:roadmap-panel >>>>>> >>>>>> Right now there are only 14/14 issues as RESOLVED for 6.1. This is >>> false >>>>>> as I know that many more issues have been addressed however I don't >>> think >>>>>> that Jira tickets have been created for all changes to the source >> code. >>>>>> Maybe moving forward we could open Jira issues and link them to the >>>>> Github >>>>>> tickets via commit messages? >>>>>> >>>>>> Additionally, everything that was currently UNRESOLVED has merely >> been >>>>>> pushed to 6.2. If this is not what is required then please reassign >> the >>>>> fix >>>>>> version for any ticket(s) to 6.1 and we can fix. >>>>>> >>>>>> Finally, are there any mitigating factor which would prevent a 6.1 >>>>> release >>>>>> candidate being prepared right now? >>>>>> Thanks >>>>>> Lewis >>>>>> >>>>>> -- >>>>>> *Lewis* >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> *Lewis* >>>>> >>> >>> >>
