Friday makes sense (and I guess you would let the vote run till Monday?), and I agree it could get risky to throw in too many fixes now.
You are probably right in that more exciting Fuseki2 issues will come once it is out :) Shall I have a go to simply comment/hide those "bits that don't work" in the UI? (e.g. [Delete] and [Active]). That's probably better than buttons that kind-of doesn't work - at least for a "first release", don't pretend to have features that aren't there. On 25 February 2015 at 14:44, Andy Seaborne <a...@apache.org> wrote: > On 25/02/15 14:18, Stian Soiland-Reyes wrote: >> >> When will you start the vote..? > > > Friday if all goes well. It's been too long as it is. > >> I had a quick look at some of the outstanding Fuseki 2 issues. >> >> Unfortunately the land of Javascript is still rather mysterious to me.. >> >> Given that this will be Fuseki 2.0.0, I will have another go tonight >> to at least try to fix JENA-869 (DELETE that doesn't), > > > That one looks tricky. Even if there is a small fix, it is a symptom of > something generally amiss so I think it'll manifest itself elsewhere even if > some test cases pass. > > I'd rather go for the "delete via UI not yet implemented" approach, get > changes after 2.13.0 so they can be then properly tested. "Delete" is to be > treated very carefully where data is concerned! > >> JENA-867 >> (Active button that doesn't deactivate), > > > Probably related to JENA-869. The lifecycle of datasets needs checking. > >> JENA-865 (Example query has broken prefixes) > > > That looks more likely to be a small localised issue. > > --------------------- > > From my POV, "release early, release often" applies. > > I'd like to think that Fuseki 2 is a useful step forwards in the current > state. It has some testing in development and seems as robust as Fuseki1 > when used in the same way (the java server part). > > Fuseki1 is in the release as well. That reduces risk. > > I'm fully expecting new requirements/expectations to come along as it gets > more used and that will set priorities and may overtake or significantly > modify the existing JIRA. The real world has a tendency of throwing up the > unexpected (the "unknown unknowns"). > > There comes a point when last minute fixes do indeed fix an observed problem > but can result in changes elsewhere in unexpected ways. > > Andy > > > >> >> On 24 February 2015 at 18:27, Andy Seaborne <a...@apache.org> wrote: >>>> >>>> == Jena 2.* >>>> >>>> Some first thoughts for the next release ... >>>> >>>> What number should it be? We may have have new components: >>>> >>>> * OSGi bundle >>>> * Adds Fuseki2 (as 2.0.0); Fuseki1 still there >>>> * jena-elephas? >>>> (If this works for you, Rob - no strong advocacy either way) >>>> * Anything else I've forgotten. >>> >>> >>> >>> Final call for Jena 2.13.0. >>> >>> Everyone - please test development master. >>> >>> >>> >>> Once the OSGi matter is resolved, everything has settled down, and any >>> feedback acted on, I'm ready to be RM for the release. >>> >>> I have a clean copy locally and have it building - the machine has maven >>> 3.2.3 and a direct internet connection to central. >>> >>> Thanks to Rob's updated process instructions for using git - the "Git >>> Configuration Issue" warning box was needed. >>> >>> Andy >>> >>> https://cwiki.apache.org/confluence/display/JENA/Release+Process >> >> >> >> > -- Stian Soiland-Reyes Apache Taverna (incubating) http://orcid.org/0000-0001-9842-9718
