It sounds like we have consensus on using the fix version to track what's in the release. I'll update the fix version on the tickets that don't have it and change the query for the wiki page. I think there is some consensus for pushing out the subtasks GEODE-818, so I'll update those to not be in M2.
I also like the idea of time based releases. I think that argues for not marking things as "in scope" for a release, but instead just prioritizing them. Or at least only marking a minimal set of things as "must fix" for M2. Since we're talking about time scope, what date do we want to target for starting a vote for M2? It's been about 7 weeks since M1, so maybe should we target about a week from now - Friday, March 25? If we do that, I think we should remove a few more things from the "Must Fix" list: GEODE-33 Create project examples GEODE-919 GEODE-823 Remove checksums from .asc files (asc.md5, asc.sha1) -Dan On Fri, Mar 18, 2016 at 1:28 PM, Edin Zulich <[email protected]> wrote: > + 1 for fix version > > +1 one for moving out the larger tasks and releasing sooner > > > On Mar 18, 2016, at 12:04 PM, Dan Smith <[email protected]> wrote: > > > > I'll take the blame for the sub-tasks of GEODE-818 - I created those as I > > was working on GEODE-27 and found parts of the code that need cleaning > up. > > But some of those tasks are rather large, so we should probably move them > > out. > > > > > > On Fri, Mar 18, 2016 at 9:45 AM, Nitin Lamba <[email protected]> wrote: > > > >> +1 for fixed version > >> > >> Typical JIRA workflow would expect the Assignee to put fixed version > AFTER > >> the issue is resolved. There's another field 'Target Version' which is > used > >> for planning, however, in the interest of simplicity, we can use Fixed > >> Version. > >> > >> As for M2, we already have a lot of new features going-in (wan, cq, > pulse, > >> etc) so we could fix only high-priority items (POM, artifacts, etc) and > >> remove any new items that haven't been started yet, and prepare for a > >> release. > >> > >> +1 for Anil's proposal > >> > >> He brings-up an important question about release cadence - time or > scope? > >> My view is for a time-based release that creates an execution rhythm > >> (release early/often). This would also utilize agile/ sprint mechanisms > >> available in JIRA. > >> > >> How about 6 weeks of dev (feature, bug squashing, etc) and 2 weeks of > >> release hardening (prep/review/vote)? May need a different thread than > M2. > >> > >> Nitin > >> > >> On Fri, Mar 18, 2016 at 9:03 AM, Anilkumar Gingade <[email protected] > > > >> wrote: > >> > >>> +1 fixed version... > >>> > >>> About what we need to include, depends on time-line (if any) and scope > of > >>> the release (based on requirement)... > >>> > >>> If there is no time-line and there is no specific requirement, we can > >> take > >>> balanced approach...Have a release time (approximate); identify tickets > >>> that can be fixed.... > >>> > >>> GEODE-1072 can be big chunk of work...Or most of sub-project in > >>> GEODE-818... > >>> > >>> -Anil. > >>> > >>> > >>> > >>> On Thu, Mar 17, 2016 at 9:12 PM, Anthony Baker <[email protected]> > >> wrote: > >>> > >>>> +1 for fix version > >>>> > >>>> Anthony > >>>> > >>>>> On Mar 17, 2016, at 8:55 PM, William Markito <[email protected]> > >>>> wrote: > >>>>> > >>>>> +1 to use "Fix Version". This also helps with release notes > >>>> auto-generated > >>>>> by JIRA. > >>>>> > >>>>> About the scope, I'd push for M3 at least GEODE-33 and rather release > >>>>> sooner... > >>>>> > >>>>> > >>>>>> On Thu, Mar 17, 2016 at 5:31 PM, Dan Smith <[email protected]> > >> wrote: > >>>>>> > >>>>>> Hi folks, > >>>>>> > >>>>>> We currently have 17 open M2 issues marked with "Sprint" M2, and 14 > >> of > >>>>>> those are also marked with "Fix Version" M2. Which of these issues > >> do > >>> we > >>>>>> actually want to try to get into M2 at this point, and what do we > >> want > >>>> to > >>>>>> push out? > >>>>>> > >>>>>> As far as tracking the issues go I think we should settle on a > >> single > >>>>>> convention: either the sprint field or the fix version field. What > >>>> field do > >>>>>> people want to use? > >>>>>> > >>>>>> M2 Wiki Page: > >>>>>> > >>>>>> > >>>> > >>> > >> > https://cwiki.apache.org/confluence/display/GEODE/1.0.0-incubating.M2+%28Second%29+Release > >>>>>> > >>>>>> Issues with M2 as the Sprint > >>>>>> https://issues.apache.org/jira/issues/?filter=12334915 > >>>>>> > >>>>>> GEODE-27 Apache Geode POM file(s) are incorrect! > >>>>>> GEODE-386 Change xsd namespace to apache > >>>>>> GEODE-33 Create project examples > >>>>>> GEODE-1075 GEODE-818 Move Admin REST API code into the geode-web > >>>>>> project > >>>>>> GEODE-1072 GEODE-818 Move HDFS code to it's own subproject and > >> get > >>>> rid > >>>>>> of HDFS dependencies in gemfire-core > >>>>>> GEODE-1080 GEODE-818 Move JettyHelper and related classes to a > >>>>>> subproject > >>>>>> GEODE-1074 GEODE-818 Move gfsh classes into their own sub > >> project > >>>>>> GEODE-1073 GEODE-818 Move redis to it's own sub-project, remove > >>>>>> dependencies from core > >>>>>> GEODE-818 RC Feedback: Fix Maven & pom dependencies > >>>>>> GEODE-823 RC Feedback: Fix build artifacts > >>>>>> GEODE-52 Remove @author tags from Java source > >>>>>> GEODE-1071 GEODE-818 Remove MailManager and javax.mail > >> dependency > >>>>>> GEODE-919 GEODE-823 Remove checksums from .asc files (asc.md5, > >>>>>> asc.sha1) > >>>>>> GEODE-1025 Remove compile dependency on spring data > >> gemfire/geode > >>>>>> GEODE-914 Review NOTICE (again) > >>>>>> GEODE-904 Update LICENSE for BSD/MIT dependencies > >>>>>> GEODE-874 v1.0.0-incubating.M1.RC2: Text file errors in the > >> source > >>>>>> distribution > >>>>>> > >>>>>> -Dan > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> > >>>>> ~/William > >>>> > >>> > >> > >
