You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Dan Smith <ds...@pivotal.io> on 2016/03/18 01:31:07 UTC
[DISCUSS] M2 issues - what's included and how we're tracking them
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
Re: [DISCUSS] M2 issues - what's included and how we're tracking them
Posted by Anthony Baker <ab...@pivotal.io>.
I don’t think we have a Target Version field. Let’s try using the Fix Version for now:
- When you fix a bug, mark the Fix Version based on the branch where the commit was made. Currently develop is M2.
- When we want to target an issue for a release, mark the Fix Version appropriately. Then we can see progress using the roadmap thingy.
I definitely agree about having a regular release cadence! Somewhere between 4-8 weeks feels right.
Anthony
> On Mar 18, 2016, at 9:45 AM, Nitin Lamba <nl...@apache.org> 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 <ag...@pivotal.io>
> 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 <ab...@pivotal.io> wrote:
>>
>>> +1 for fix version
>>>
>>> Anthony
>>>
>>>> On Mar 17, 2016, at 8:55 PM, William Markito <wm...@pivotal.io>
>>> 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 <ds...@pivotal.io> 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
>>>
>>
Re: [DISCUSS] M2 issues - what's included and how we're tracking them
Posted by Dan Smith <ds...@pivotal.io>.
Last week I mentioned hoping to kick off an M2 release today. However some
of these M2 issues are still pending, so it will wait until they are
addressed.
Thanks,
-Dan
On Mon, Mar 21, 2016 at 4:36 PM, Dan Smith <ds...@pivotal.io> wrote:
> I changed the wiki page queries to look at fix version, based on the
> replies on this thread.
>
> I also removed the M2 fix version from the issues suggested. Our new list
> of M2 issues is now down to these:
>
> GEODE-52 Remove @author tags from Java source
> GEODE-386 Change xsd namespace to apache
> GEODE-874 v1.0.0-incubating.M1.RC2: Text file errors in the source
> distribution
> GEODE-904 Update LICENSE for BSD/MIT dependencies
> GEODE-914 Review NOTICE (again)
> GEODE-1025 Remove compile dependency on spring data gemfire/geode
>
> -Dan
>
Re: [DISCUSS] M2 issues - what's included and how we're tracking them
Posted by Dan Smith <ds...@pivotal.io>.
I changed the wiki page queries to look at fix version, based on the
replies on this thread.
I also removed the M2 fix version from the issues suggested. Our new list
of M2 issues is now down to these:
GEODE-52 Remove @author tags from Java source
GEODE-386 Change xsd namespace to apache
GEODE-874 v1.0.0-incubating.M1.RC2: Text file errors in the source
distribution
GEODE-904 Update LICENSE for BSD/MIT dependencies
GEODE-914 Review NOTICE (again)
GEODE-1025 Remove compile dependency on spring data gemfire/geode
-Dan
On Fri, Mar 18, 2016 at 3:57 PM, William Markito <wm...@pivotal.io>
wrote:
> +1
>
> On Fri, Mar 18, 2016 at 3:12 PM, Anthony Baker <ab...@pivotal.io> wrote:
>
> > +1
> >
> > I would also consider:
> >
> > GEODE-818
> > GEODE-835
> >
> > Anthony
> >
> > > On Mar 18, 2016, at 3:00 PM, Dan Smith <ds...@pivotal.io> wrote:
> > >
> > > 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)
> >
> >
>
>
> --
>
> ~/William
>
Re: [DISCUSS] M2 issues - what's included and how we're tracking them
Posted by William Markito <wm...@pivotal.io>.
+1
On Fri, Mar 18, 2016 at 3:12 PM, Anthony Baker <ab...@pivotal.io> wrote:
> +1
>
> I would also consider:
>
> GEODE-818
> GEODE-835
>
> Anthony
>
> > On Mar 18, 2016, at 3:00 PM, Dan Smith <ds...@pivotal.io> wrote:
> >
> > 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)
>
>
--
~/William
Re: [DISCUSS] M2 issues - what's included and how we're tracking them
Posted by Anthony Baker <ab...@pivotal.io>.
+1
I would also consider:
GEODE-818
GEODE-835
Anthony
> On Mar 18, 2016, at 3:00 PM, Dan Smith <ds...@pivotal.io> wrote:
>
> 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)
Re: [DISCUSS] M2 issues - what's included and how we're tracking them
Posted by Dan Smith <ds...@pivotal.io>.
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 <ez...@pivotal.io> 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 <ds...@pivotal.io> 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 <nl...@apache.org> 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 <agingade@pivotal.io
> >
> >> 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 <ab...@pivotal.io>
> >> wrote:
> >>>
> >>>> +1 for fix version
> >>>>
> >>>> Anthony
> >>>>
> >>>>> On Mar 17, 2016, at 8:55 PM, William Markito <wm...@pivotal.io>
> >>>> 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 <ds...@pivotal.io>
> >> 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
> >>>>
> >>>
> >>
>
>
Re: [DISCUSS] M2 issues - what's included and how we're tracking them
Posted by Edin Zulich <ez...@pivotal.io>.
+ 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 <ds...@pivotal.io> 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 <nl...@apache.org> 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 <ag...@pivotal.io>
>> 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 <ab...@pivotal.io>
>> wrote:
>>>
>>>> +1 for fix version
>>>>
>>>> Anthony
>>>>
>>>>> On Mar 17, 2016, at 8:55 PM, William Markito <wm...@pivotal.io>
>>>> 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 <ds...@pivotal.io>
>> 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
>>>>
>>>
>>
Re: [DISCUSS] M2 issues - what's included and how we're tracking them
Posted by Dan Smith <ds...@pivotal.io>.
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 <nl...@apache.org> 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 <ag...@pivotal.io>
> 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 <ab...@pivotal.io>
> wrote:
> >
> > > +1 for fix version
> > >
> > > Anthony
> > >
> > > > On Mar 17, 2016, at 8:55 PM, William Markito <wm...@pivotal.io>
> > > 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 <ds...@pivotal.io>
> 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
> > >
> >
>
Re: [DISCUSS] M2 issues - what's included and how we're tracking them
Posted by Nitin Lamba <nl...@apache.org>.
+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 <ag...@pivotal.io>
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 <ab...@pivotal.io> wrote:
>
> > +1 for fix version
> >
> > Anthony
> >
> > > On Mar 17, 2016, at 8:55 PM, William Markito <wm...@pivotal.io>
> > 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 <ds...@pivotal.io> 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
> >
>
Re: [DISCUSS] M2 issues - what's included and how we're tracking them
Posted by Anilkumar Gingade <ag...@pivotal.io>.
+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 <ab...@pivotal.io> wrote:
> +1 for fix version
>
> Anthony
>
> > On Mar 17, 2016, at 8:55 PM, William Markito <wm...@pivotal.io>
> 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 <ds...@pivotal.io> 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
>
Re: [DISCUSS] M2 issues - what's included and how we're tracking them
Posted by Anthony Baker <ab...@pivotal.io>.
+1 for fix version
Anthony
> On Mar 17, 2016, at 8:55 PM, William Markito <wm...@pivotal.io> 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 <ds...@pivotal.io> 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
Re: [DISCUSS] M2 issues - what's included and how we're tracking them
Posted by William Markito <wm...@pivotal.io>.
+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 <ds...@pivotal.io> 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