You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hama.apache.org by "Edward J. Yoon" <ed...@apache.org> on 2013/08/17 10:33:56 UTC
[VOTE] Skip minor release, and prepare 1.0
Hi all,
I was planning to cut a 0.6.3 release candidate (Hadoop 2.0 compatible
version), however it seems the age of compete for the preoccupancy is
past. So we don't need to hurry up now. Moreover, we are currently
adding a lot of changes, and still need to be improved a lot. We knows
what we should do exactly.
Do you think we can skip minor release and prepare 1.0 now?
--
Best Regards, Edward J. Yoon
@eddieyoon
Re: [VOTE] Skip minor release, and prepare 1.0
Posted by Tommaso Teofili <to...@gmail.com>.
I agree, let's discuss that in a separate thread.
Tommaso
2013/8/28 Edward J. Yoon <ed...@apache.org>
> Let's close this vote thread, and open new DISCUSS thread for our roadmap.
>
>
> On Thu, Aug 22, 2013 at 11:14 AM, Edward J. Yoon <edwardyoon@apache.org
> >wrote:
>
> > > And we do have some dependencies between few features. Please take a
> look
> > > into the image I uploaded in the roadmap wiki page.
> >
> > Looks very nice. Actually, listed issues in your diagram should be
> > solved now before thinking about further improvements in detail.
> >
> > On Wed, Aug 21, 2013 at 11:21 PM, Suraj Menon <me...@gmail.com>
> > wrote:
> > > I am +1 for frequent releases. However, I believe that it should go
> with
> > > more test automation and some feedback on the attempts for the same. I
> > > think it is high time we started using cobertura or tools similar to
> > > cobertura(Clover is not free) and findbugs.
> > >
> > > And we do have some dependencies between few features. Please take a
> look
> > > into the image I uploaded in the roadmap wiki page.
> > >
> > > -Suraj
> > >
> > >
> > > On Mon, Aug 19, 2013 at 12:19 PM, Chia-Hung Lin <clin4j@googlemail.com
> > >wrote:
> > >
> > >> I agree that would be good for us to have feedback with releases,
> > >> instead of silently working until accomplishing version 1.0.
> > >>
> > >> Considering frequent releases[1][2], we may break e.g. version 0.7
> > >> into smaller parts and release them frequently by prioritizing tasks.
> > >> For example, if the task `Add Hama to BigTop distribution' is
> > >> considered that can be done earlier compared to the rest of tasks in
> > >> the roadmap. Then we can release it first (after that feature is
> > >> accomplished); thus users who want that feature can take that release
> > >> for evaluation, etc., and feedback if any issue. So do other tasks. By
> > >> prioritization, software is released based on each feature and in a
> > >> smaller cycle. The benefit is we can release as many/ earlier as
> > >> possible without tasks being blocked by features that require longer
> > >> time to finish.
> > >>
> > >> Therefore, I suppose we can:
> > >> - discuss the tasks prioritization for the roadmap version 0.7 (or
> > >> move tasks to the next version release, etc.)
> > >> - work on the tasks in parallel.
> > >> - release a version (iteratively) if a feature is accomplished.
> > >>
> > >>
> > >> [1].
> > >>
> >
> http://en.wikipedia.org/wiki/Extreme_programming_practices#Small_releases
> > >> [2]. http://xprogramming.com/what-is-extreme-programming/#small
> > >>
> > >>
> > >> On 19 August 2013 17:20, Edward J. Yoon <ed...@apache.org>
> wrote:
> > >> >> Sorry just want to double check what's the plan. Doesn't get point
> > >> >> about skip release until reaching version 1.0. Are we going to just
> > >> >> release some minor fixes and other (significant) patches will be
> > >> >> released after version 1.0? Or ...
> > >> >
> > >> > No release until reaching version 1.0. If I remember correctly, some
> > >> > people wanted.
> > >> >
> > >> > But I still dislike, because this can cause no-feedback and make
> > >> > participation difficult.
> > >> >
> > >> >> For release procedure, probably we can borrow ideas from continuous
> > >> >> integration where IIRC software is released as earlier as possible,
> > >> >> and release cycle is reduced so that problems can be discovered and
> > >> >> fixed earlier. That seems to be suitable for our scenario.
> > >> >
> > >> > If we follow your idea, what should we do?
> > >> >
> > >> > See http://wiki.apache.org/hama/RoadMap - Do you think we can
> finish
> > >> > 0.7 within a year? If not, should we separate them into 0.8, 0.9
> ...,
> > >> > etc? Is there a way to work in parallel?
> > >> >
> > >> > On Sun, Aug 18, 2013 at 9:02 PM, Chia-Hung Lin <
> clin4j@googlemail.com
> > >
> > >> wrote:
> > >> >> Sorry just want to double check what's the plan. Doesn't get point
> > >> >> about skip release until reaching version 1.0. Are we going to just
> > >> >> release some minor fixes and other (significant) patches will be
> > >> >> released after version 1.0? Or ...
> > >> >>
> > >> >> For release procedure, probably we can borrow ideas from continuous
> > >> >> integration where IIRC software is released as earlier as possible,
> > >> >> and release cycle is reduced so that problems can be discovered and
> > >> >> fixed earlier. That seems to be suitable for our scenario.
> > >> >>
> > >> >>
> > >> >> On 18 August 2013 16:11, Edward J. Yoon <ed...@apache.org>
> > wrote:
> > >> >>> I mean, "put all TODO things into 1.0 roadmap, and just skip
> release
> > >> >>> until reach version 1.0".
> > >> >>>
> > >> >>>> people would compare MRv2, Giraph to Hama; and would think that
> > MRv2,
> > >> >>>> and Giraph would be more better/ stable than Hama because of FT,
> > etc.
> > >> >>>
> > >> >>> Spark also supports full fault-tolerance, and comparison has been
> > >> >>> already started.. Spark shows good performance, giraph shows good
> > >> >>> scalability. Hama has good performance and very flexible
> interface,
> > >> >>> but we are in gray zone.
> > >> >>>
> > >> >>>> +0
> > >> >>>
> > >> >>> I'm -0. I think we have to cut periodically.
> > >> >>>
> > >> >>> On Sun, Aug 18, 2013 at 4:26 PM, Chia-Hung Lin <
> > clin4j@googlemail.com>
> > >> wrote:
> > >> >>>> +0
> > >> >>>>
> > >> >>>> Personally I would not go for 1.0 now though the release for 1.0
> > is
> > >> >>>> ok for me. My reason is people may expect functions such as FT to
> > be
> > >> >>>> ready when it's in the version 1.0. Also it might be inevitably
> > that
> > >> >>>> people would compare MRv2, Giraph to Hama; and would think that
> > MRv2,
> > >> >>>> and Giraph would be more better/ stable than Hama because of FT,
> > etc.
> > >> >>>> regardless of differences between projects.
> > >> >>>>
> > >> >>>>
> > >> >>>>
> > >> >>>>
> > >> >>>>
> > >> >>>>
> > >> >>>>
> > >> >>>> On 17 August 2013 16:33, Edward J. Yoon <ed...@apache.org>
> > >> wrote:
> > >> >>>>> Hi all,
> > >> >>>>>
> > >> >>>>> I was planning to cut a 0.6.3 release candidate (Hadoop 2.0
> > >> compatible
> > >> >>>>> version), however it seems the age of compete for the
> > preoccupancy is
> > >> >>>>> past. So we don't need to hurry up now. Moreover, we are
> currently
> > >> >>>>> adding a lot of changes, and still need to be improved a lot. We
> > >> knows
> > >> >>>>> what we should do exactly.
> > >> >>>>>
> > >> >>>>> Do you think we can skip minor release and prepare 1.0 now?
> > >> >>>>>
> > >> >>>>> --
> > >> >>>>> Best Regards, Edward J. Yoon
> > >> >>>>> @eddieyoon
> > >> >>>
> > >> >>>
> > >> >>>
> > >> >>> --
> > >> >>> Best Regards, Edward J. Yoon
> > >> >>> @eddieyoon
> > >> >
> > >> >
> > >> >
> > >> > --
> > >> > Best Regards, Edward J. Yoon
> > >> > @eddieyoon
> > >>
> >
> >
> >
> > --
> > Best Regards, Edward J. Yoon
> > @eddieyoon
> >
>
>
>
> --
> Best Regards, Edward J. Yoon
> @eddieyoon
>
Re: [VOTE] Skip minor release, and prepare 1.0
Posted by "Edward J. Yoon" <ed...@apache.org>.
Let's close this vote thread, and open new DISCUSS thread for our roadmap.
On Thu, Aug 22, 2013 at 11:14 AM, Edward J. Yoon <ed...@apache.org>wrote:
> > And we do have some dependencies between few features. Please take a look
> > into the image I uploaded in the roadmap wiki page.
>
> Looks very nice. Actually, listed issues in your diagram should be
> solved now before thinking about further improvements in detail.
>
> On Wed, Aug 21, 2013 at 11:21 PM, Suraj Menon <me...@gmail.com>
> wrote:
> > I am +1 for frequent releases. However, I believe that it should go with
> > more test automation and some feedback on the attempts for the same. I
> > think it is high time we started using cobertura or tools similar to
> > cobertura(Clover is not free) and findbugs.
> >
> > And we do have some dependencies between few features. Please take a look
> > into the image I uploaded in the roadmap wiki page.
> >
> > -Suraj
> >
> >
> > On Mon, Aug 19, 2013 at 12:19 PM, Chia-Hung Lin <clin4j@googlemail.com
> >wrote:
> >
> >> I agree that would be good for us to have feedback with releases,
> >> instead of silently working until accomplishing version 1.0.
> >>
> >> Considering frequent releases[1][2], we may break e.g. version 0.7
> >> into smaller parts and release them frequently by prioritizing tasks.
> >> For example, if the task `Add Hama to BigTop distribution' is
> >> considered that can be done earlier compared to the rest of tasks in
> >> the roadmap. Then we can release it first (after that feature is
> >> accomplished); thus users who want that feature can take that release
> >> for evaluation, etc., and feedback if any issue. So do other tasks. By
> >> prioritization, software is released based on each feature and in a
> >> smaller cycle. The benefit is we can release as many/ earlier as
> >> possible without tasks being blocked by features that require longer
> >> time to finish.
> >>
> >> Therefore, I suppose we can:
> >> - discuss the tasks prioritization for the roadmap version 0.7 (or
> >> move tasks to the next version release, etc.)
> >> - work on the tasks in parallel.
> >> - release a version (iteratively) if a feature is accomplished.
> >>
> >>
> >> [1].
> >>
> http://en.wikipedia.org/wiki/Extreme_programming_practices#Small_releases
> >> [2]. http://xprogramming.com/what-is-extreme-programming/#small
> >>
> >>
> >> On 19 August 2013 17:20, Edward J. Yoon <ed...@apache.org> wrote:
> >> >> Sorry just want to double check what's the plan. Doesn't get point
> >> >> about skip release until reaching version 1.0. Are we going to just
> >> >> release some minor fixes and other (significant) patches will be
> >> >> released after version 1.0? Or ...
> >> >
> >> > No release until reaching version 1.0. If I remember correctly, some
> >> > people wanted.
> >> >
> >> > But I still dislike, because this can cause no-feedback and make
> >> > participation difficult.
> >> >
> >> >> For release procedure, probably we can borrow ideas from continuous
> >> >> integration where IIRC software is released as earlier as possible,
> >> >> and release cycle is reduced so that problems can be discovered and
> >> >> fixed earlier. That seems to be suitable for our scenario.
> >> >
> >> > If we follow your idea, what should we do?
> >> >
> >> > See http://wiki.apache.org/hama/RoadMap - Do you think we can finish
> >> > 0.7 within a year? If not, should we separate them into 0.8, 0.9 ...,
> >> > etc? Is there a way to work in parallel?
> >> >
> >> > On Sun, Aug 18, 2013 at 9:02 PM, Chia-Hung Lin <clin4j@googlemail.com
> >
> >> wrote:
> >> >> Sorry just want to double check what's the plan. Doesn't get point
> >> >> about skip release until reaching version 1.0. Are we going to just
> >> >> release some minor fixes and other (significant) patches will be
> >> >> released after version 1.0? Or ...
> >> >>
> >> >> For release procedure, probably we can borrow ideas from continuous
> >> >> integration where IIRC software is released as earlier as possible,
> >> >> and release cycle is reduced so that problems can be discovered and
> >> >> fixed earlier. That seems to be suitable for our scenario.
> >> >>
> >> >>
> >> >> On 18 August 2013 16:11, Edward J. Yoon <ed...@apache.org>
> wrote:
> >> >>> I mean, "put all TODO things into 1.0 roadmap, and just skip release
> >> >>> until reach version 1.0".
> >> >>>
> >> >>>> people would compare MRv2, Giraph to Hama; and would think that
> MRv2,
> >> >>>> and Giraph would be more better/ stable than Hama because of FT,
> etc.
> >> >>>
> >> >>> Spark also supports full fault-tolerance, and comparison has been
> >> >>> already started.. Spark shows good performance, giraph shows good
> >> >>> scalability. Hama has good performance and very flexible interface,
> >> >>> but we are in gray zone.
> >> >>>
> >> >>>> +0
> >> >>>
> >> >>> I'm -0. I think we have to cut periodically.
> >> >>>
> >> >>> On Sun, Aug 18, 2013 at 4:26 PM, Chia-Hung Lin <
> clin4j@googlemail.com>
> >> wrote:
> >> >>>> +0
> >> >>>>
> >> >>>> Personally I would not go for 1.0 now though the release for 1.0
> is
> >> >>>> ok for me. My reason is people may expect functions such as FT to
> be
> >> >>>> ready when it's in the version 1.0. Also it might be inevitably
> that
> >> >>>> people would compare MRv2, Giraph to Hama; and would think that
> MRv2,
> >> >>>> and Giraph would be more better/ stable than Hama because of FT,
> etc.
> >> >>>> regardless of differences between projects.
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>> On 17 August 2013 16:33, Edward J. Yoon <ed...@apache.org>
> >> wrote:
> >> >>>>> Hi all,
> >> >>>>>
> >> >>>>> I was planning to cut a 0.6.3 release candidate (Hadoop 2.0
> >> compatible
> >> >>>>> version), however it seems the age of compete for the
> preoccupancy is
> >> >>>>> past. So we don't need to hurry up now. Moreover, we are currently
> >> >>>>> adding a lot of changes, and still need to be improved a lot. We
> >> knows
> >> >>>>> what we should do exactly.
> >> >>>>>
> >> >>>>> Do you think we can skip minor release and prepare 1.0 now?
> >> >>>>>
> >> >>>>> --
> >> >>>>> Best Regards, Edward J. Yoon
> >> >>>>> @eddieyoon
> >> >>>
> >> >>>
> >> >>>
> >> >>> --
> >> >>> Best Regards, Edward J. Yoon
> >> >>> @eddieyoon
> >> >
> >> >
> >> >
> >> > --
> >> > Best Regards, Edward J. Yoon
> >> > @eddieyoon
> >>
>
>
>
> --
> Best Regards, Edward J. Yoon
> @eddieyoon
>
--
Best Regards, Edward J. Yoon
@eddieyoon
Re: [VOTE] Skip minor release, and prepare 1.0
Posted by "Edward J. Yoon" <ed...@apache.org>.
> And we do have some dependencies between few features. Please take a look
> into the image I uploaded in the roadmap wiki page.
Looks very nice. Actually, listed issues in your diagram should be
solved now before thinking about further improvements in detail.
On Wed, Aug 21, 2013 at 11:21 PM, Suraj Menon <me...@gmail.com> wrote:
> I am +1 for frequent releases. However, I believe that it should go with
> more test automation and some feedback on the attempts for the same. I
> think it is high time we started using cobertura or tools similar to
> cobertura(Clover is not free) and findbugs.
>
> And we do have some dependencies between few features. Please take a look
> into the image I uploaded in the roadmap wiki page.
>
> -Suraj
>
>
> On Mon, Aug 19, 2013 at 12:19 PM, Chia-Hung Lin <cl...@googlemail.com>wrote:
>
>> I agree that would be good for us to have feedback with releases,
>> instead of silently working until accomplishing version 1.0.
>>
>> Considering frequent releases[1][2], we may break e.g. version 0.7
>> into smaller parts and release them frequently by prioritizing tasks.
>> For example, if the task `Add Hama to BigTop distribution' is
>> considered that can be done earlier compared to the rest of tasks in
>> the roadmap. Then we can release it first (after that feature is
>> accomplished); thus users who want that feature can take that release
>> for evaluation, etc., and feedback if any issue. So do other tasks. By
>> prioritization, software is released based on each feature and in a
>> smaller cycle. The benefit is we can release as many/ earlier as
>> possible without tasks being blocked by features that require longer
>> time to finish.
>>
>> Therefore, I suppose we can:
>> - discuss the tasks prioritization for the roadmap version 0.7 (or
>> move tasks to the next version release, etc.)
>> - work on the tasks in parallel.
>> - release a version (iteratively) if a feature is accomplished.
>>
>>
>> [1].
>> http://en.wikipedia.org/wiki/Extreme_programming_practices#Small_releases
>> [2]. http://xprogramming.com/what-is-extreme-programming/#small
>>
>>
>> On 19 August 2013 17:20, Edward J. Yoon <ed...@apache.org> wrote:
>> >> Sorry just want to double check what's the plan. Doesn't get point
>> >> about skip release until reaching version 1.0. Are we going to just
>> >> release some minor fixes and other (significant) patches will be
>> >> released after version 1.0? Or ...
>> >
>> > No release until reaching version 1.0. If I remember correctly, some
>> > people wanted.
>> >
>> > But I still dislike, because this can cause no-feedback and make
>> > participation difficult.
>> >
>> >> For release procedure, probably we can borrow ideas from continuous
>> >> integration where IIRC software is released as earlier as possible,
>> >> and release cycle is reduced so that problems can be discovered and
>> >> fixed earlier. That seems to be suitable for our scenario.
>> >
>> > If we follow your idea, what should we do?
>> >
>> > See http://wiki.apache.org/hama/RoadMap - Do you think we can finish
>> > 0.7 within a year? If not, should we separate them into 0.8, 0.9 ...,
>> > etc? Is there a way to work in parallel?
>> >
>> > On Sun, Aug 18, 2013 at 9:02 PM, Chia-Hung Lin <cl...@googlemail.com>
>> wrote:
>> >> Sorry just want to double check what's the plan. Doesn't get point
>> >> about skip release until reaching version 1.0. Are we going to just
>> >> release some minor fixes and other (significant) patches will be
>> >> released after version 1.0? Or ...
>> >>
>> >> For release procedure, probably we can borrow ideas from continuous
>> >> integration where IIRC software is released as earlier as possible,
>> >> and release cycle is reduced so that problems can be discovered and
>> >> fixed earlier. That seems to be suitable for our scenario.
>> >>
>> >>
>> >> On 18 August 2013 16:11, Edward J. Yoon <ed...@apache.org> wrote:
>> >>> I mean, "put all TODO things into 1.0 roadmap, and just skip release
>> >>> until reach version 1.0".
>> >>>
>> >>>> people would compare MRv2, Giraph to Hama; and would think that MRv2,
>> >>>> and Giraph would be more better/ stable than Hama because of FT, etc.
>> >>>
>> >>> Spark also supports full fault-tolerance, and comparison has been
>> >>> already started.. Spark shows good performance, giraph shows good
>> >>> scalability. Hama has good performance and very flexible interface,
>> >>> but we are in gray zone.
>> >>>
>> >>>> +0
>> >>>
>> >>> I'm -0. I think we have to cut periodically.
>> >>>
>> >>> On Sun, Aug 18, 2013 at 4:26 PM, Chia-Hung Lin <cl...@googlemail.com>
>> wrote:
>> >>>> +0
>> >>>>
>> >>>> Personally I would not go for 1.0 now though the release for 1.0 is
>> >>>> ok for me. My reason is people may expect functions such as FT to be
>> >>>> ready when it's in the version 1.0. Also it might be inevitably that
>> >>>> people would compare MRv2, Giraph to Hama; and would think that MRv2,
>> >>>> and Giraph would be more better/ stable than Hama because of FT, etc.
>> >>>> regardless of differences between projects.
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> On 17 August 2013 16:33, Edward J. Yoon <ed...@apache.org>
>> wrote:
>> >>>>> Hi all,
>> >>>>>
>> >>>>> I was planning to cut a 0.6.3 release candidate (Hadoop 2.0
>> compatible
>> >>>>> version), however it seems the age of compete for the preoccupancy is
>> >>>>> past. So we don't need to hurry up now. Moreover, we are currently
>> >>>>> adding a lot of changes, and still need to be improved a lot. We
>> knows
>> >>>>> what we should do exactly.
>> >>>>>
>> >>>>> Do you think we can skip minor release and prepare 1.0 now?
>> >>>>>
>> >>>>> --
>> >>>>> Best Regards, Edward J. Yoon
>> >>>>> @eddieyoon
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> Best Regards, Edward J. Yoon
>> >>> @eddieyoon
>> >
>> >
>> >
>> > --
>> > Best Regards, Edward J. Yoon
>> > @eddieyoon
>>
--
Best Regards, Edward J. Yoon
@eddieyoon
Re: [VOTE] Skip minor release, and prepare 1.0
Posted by Suraj Menon <me...@gmail.com>.
I am +1 for frequent releases. However, I believe that it should go with
more test automation and some feedback on the attempts for the same. I
think it is high time we started using cobertura or tools similar to
cobertura(Clover is not free) and findbugs.
And we do have some dependencies between few features. Please take a look
into the image I uploaded in the roadmap wiki page.
-Suraj
On Mon, Aug 19, 2013 at 12:19 PM, Chia-Hung Lin <cl...@googlemail.com>wrote:
> I agree that would be good for us to have feedback with releases,
> instead of silently working until accomplishing version 1.0.
>
> Considering frequent releases[1][2], we may break e.g. version 0.7
> into smaller parts and release them frequently by prioritizing tasks.
> For example, if the task `Add Hama to BigTop distribution' is
> considered that can be done earlier compared to the rest of tasks in
> the roadmap. Then we can release it first (after that feature is
> accomplished); thus users who want that feature can take that release
> for evaluation, etc., and feedback if any issue. So do other tasks. By
> prioritization, software is released based on each feature and in a
> smaller cycle. The benefit is we can release as many/ earlier as
> possible without tasks being blocked by features that require longer
> time to finish.
>
> Therefore, I suppose we can:
> - discuss the tasks prioritization for the roadmap version 0.7 (or
> move tasks to the next version release, etc.)
> - work on the tasks in parallel.
> - release a version (iteratively) if a feature is accomplished.
>
>
> [1].
> http://en.wikipedia.org/wiki/Extreme_programming_practices#Small_releases
> [2]. http://xprogramming.com/what-is-extreme-programming/#small
>
>
> On 19 August 2013 17:20, Edward J. Yoon <ed...@apache.org> wrote:
> >> Sorry just want to double check what's the plan. Doesn't get point
> >> about skip release until reaching version 1.0. Are we going to just
> >> release some minor fixes and other (significant) patches will be
> >> released after version 1.0? Or ...
> >
> > No release until reaching version 1.0. If I remember correctly, some
> > people wanted.
> >
> > But I still dislike, because this can cause no-feedback and make
> > participation difficult.
> >
> >> For release procedure, probably we can borrow ideas from continuous
> >> integration where IIRC software is released as earlier as possible,
> >> and release cycle is reduced so that problems can be discovered and
> >> fixed earlier. That seems to be suitable for our scenario.
> >
> > If we follow your idea, what should we do?
> >
> > See http://wiki.apache.org/hama/RoadMap - Do you think we can finish
> > 0.7 within a year? If not, should we separate them into 0.8, 0.9 ...,
> > etc? Is there a way to work in parallel?
> >
> > On Sun, Aug 18, 2013 at 9:02 PM, Chia-Hung Lin <cl...@googlemail.com>
> wrote:
> >> Sorry just want to double check what's the plan. Doesn't get point
> >> about skip release until reaching version 1.0. Are we going to just
> >> release some minor fixes and other (significant) patches will be
> >> released after version 1.0? Or ...
> >>
> >> For release procedure, probably we can borrow ideas from continuous
> >> integration where IIRC software is released as earlier as possible,
> >> and release cycle is reduced so that problems can be discovered and
> >> fixed earlier. That seems to be suitable for our scenario.
> >>
> >>
> >> On 18 August 2013 16:11, Edward J. Yoon <ed...@apache.org> wrote:
> >>> I mean, "put all TODO things into 1.0 roadmap, and just skip release
> >>> until reach version 1.0".
> >>>
> >>>> people would compare MRv2, Giraph to Hama; and would think that MRv2,
> >>>> and Giraph would be more better/ stable than Hama because of FT, etc.
> >>>
> >>> Spark also supports full fault-tolerance, and comparison has been
> >>> already started.. Spark shows good performance, giraph shows good
> >>> scalability. Hama has good performance and very flexible interface,
> >>> but we are in gray zone.
> >>>
> >>>> +0
> >>>
> >>> I'm -0. I think we have to cut periodically.
> >>>
> >>> On Sun, Aug 18, 2013 at 4:26 PM, Chia-Hung Lin <cl...@googlemail.com>
> wrote:
> >>>> +0
> >>>>
> >>>> Personally I would not go for 1.0 now though the release for 1.0 is
> >>>> ok for me. My reason is people may expect functions such as FT to be
> >>>> ready when it's in the version 1.0. Also it might be inevitably that
> >>>> people would compare MRv2, Giraph to Hama; and would think that MRv2,
> >>>> and Giraph would be more better/ stable than Hama because of FT, etc.
> >>>> regardless of differences between projects.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On 17 August 2013 16:33, Edward J. Yoon <ed...@apache.org>
> wrote:
> >>>>> Hi all,
> >>>>>
> >>>>> I was planning to cut a 0.6.3 release candidate (Hadoop 2.0
> compatible
> >>>>> version), however it seems the age of compete for the preoccupancy is
> >>>>> past. So we don't need to hurry up now. Moreover, we are currently
> >>>>> adding a lot of changes, and still need to be improved a lot. We
> knows
> >>>>> what we should do exactly.
> >>>>>
> >>>>> Do you think we can skip minor release and prepare 1.0 now?
> >>>>>
> >>>>> --
> >>>>> Best Regards, Edward J. Yoon
> >>>>> @eddieyoon
> >>>
> >>>
> >>>
> >>> --
> >>> Best Regards, Edward J. Yoon
> >>> @eddieyoon
> >
> >
> >
> > --
> > Best Regards, Edward J. Yoon
> > @eddieyoon
>
Re: [VOTE] Skip minor release, and prepare 1.0
Posted by Chia-Hung Lin <cl...@googlemail.com>.
I agree that would be good for us to have feedback with releases,
instead of silently working until accomplishing version 1.0.
Considering frequent releases[1][2], we may break e.g. version 0.7
into smaller parts and release them frequently by prioritizing tasks.
For example, if the task `Add Hama to BigTop distribution' is
considered that can be done earlier compared to the rest of tasks in
the roadmap. Then we can release it first (after that feature is
accomplished); thus users who want that feature can take that release
for evaluation, etc., and feedback if any issue. So do other tasks. By
prioritization, software is released based on each feature and in a
smaller cycle. The benefit is we can release as many/ earlier as
possible without tasks being blocked by features that require longer
time to finish.
Therefore, I suppose we can:
- discuss the tasks prioritization for the roadmap version 0.7 (or
move tasks to the next version release, etc.)
- work on the tasks in parallel.
- release a version (iteratively) if a feature is accomplished.
[1]. http://en.wikipedia.org/wiki/Extreme_programming_practices#Small_releases
[2]. http://xprogramming.com/what-is-extreme-programming/#small
On 19 August 2013 17:20, Edward J. Yoon <ed...@apache.org> wrote:
>> Sorry just want to double check what's the plan. Doesn't get point
>> about skip release until reaching version 1.0. Are we going to just
>> release some minor fixes and other (significant) patches will be
>> released after version 1.0? Or ...
>
> No release until reaching version 1.0. If I remember correctly, some
> people wanted.
>
> But I still dislike, because this can cause no-feedback and make
> participation difficult.
>
>> For release procedure, probably we can borrow ideas from continuous
>> integration where IIRC software is released as earlier as possible,
>> and release cycle is reduced so that problems can be discovered and
>> fixed earlier. That seems to be suitable for our scenario.
>
> If we follow your idea, what should we do?
>
> See http://wiki.apache.org/hama/RoadMap - Do you think we can finish
> 0.7 within a year? If not, should we separate them into 0.8, 0.9 ...,
> etc? Is there a way to work in parallel?
>
> On Sun, Aug 18, 2013 at 9:02 PM, Chia-Hung Lin <cl...@googlemail.com> wrote:
>> Sorry just want to double check what's the plan. Doesn't get point
>> about skip release until reaching version 1.0. Are we going to just
>> release some minor fixes and other (significant) patches will be
>> released after version 1.0? Or ...
>>
>> For release procedure, probably we can borrow ideas from continuous
>> integration where IIRC software is released as earlier as possible,
>> and release cycle is reduced so that problems can be discovered and
>> fixed earlier. That seems to be suitable for our scenario.
>>
>>
>> On 18 August 2013 16:11, Edward J. Yoon <ed...@apache.org> wrote:
>>> I mean, "put all TODO things into 1.0 roadmap, and just skip release
>>> until reach version 1.0".
>>>
>>>> people would compare MRv2, Giraph to Hama; and would think that MRv2,
>>>> and Giraph would be more better/ stable than Hama because of FT, etc.
>>>
>>> Spark also supports full fault-tolerance, and comparison has been
>>> already started.. Spark shows good performance, giraph shows good
>>> scalability. Hama has good performance and very flexible interface,
>>> but we are in gray zone.
>>>
>>>> +0
>>>
>>> I'm -0. I think we have to cut periodically.
>>>
>>> On Sun, Aug 18, 2013 at 4:26 PM, Chia-Hung Lin <cl...@googlemail.com> wrote:
>>>> +0
>>>>
>>>> Personally I would not go for 1.0 now though the release for 1.0 is
>>>> ok for me. My reason is people may expect functions such as FT to be
>>>> ready when it's in the version 1.0. Also it might be inevitably that
>>>> people would compare MRv2, Giraph to Hama; and would think that MRv2,
>>>> and Giraph would be more better/ stable than Hama because of FT, etc.
>>>> regardless of differences between projects.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 17 August 2013 16:33, Edward J. Yoon <ed...@apache.org> wrote:
>>>>> Hi all,
>>>>>
>>>>> I was planning to cut a 0.6.3 release candidate (Hadoop 2.0 compatible
>>>>> version), however it seems the age of compete for the preoccupancy is
>>>>> past. So we don't need to hurry up now. Moreover, we are currently
>>>>> adding a lot of changes, and still need to be improved a lot. We knows
>>>>> what we should do exactly.
>>>>>
>>>>> Do you think we can skip minor release and prepare 1.0 now?
>>>>>
>>>>> --
>>>>> Best Regards, Edward J. Yoon
>>>>> @eddieyoon
>>>
>>>
>>>
>>> --
>>> Best Regards, Edward J. Yoon
>>> @eddieyoon
>
>
>
> --
> Best Regards, Edward J. Yoon
> @eddieyoon
Re: [VOTE] Skip minor release, and prepare 1.0
Posted by "Edward J. Yoon" <ed...@apache.org>.
> Sorry just want to double check what's the plan. Doesn't get point
> about skip release until reaching version 1.0. Are we going to just
> release some minor fixes and other (significant) patches will be
> released after version 1.0? Or ...
No release until reaching version 1.0. If I remember correctly, some
people wanted.
But I still dislike, because this can cause no-feedback and make
participation difficult.
> For release procedure, probably we can borrow ideas from continuous
> integration where IIRC software is released as earlier as possible,
> and release cycle is reduced so that problems can be discovered and
> fixed earlier. That seems to be suitable for our scenario.
If we follow your idea, what should we do?
See http://wiki.apache.org/hama/RoadMap - Do you think we can finish
0.7 within a year? If not, should we separate them into 0.8, 0.9 ...,
etc? Is there a way to work in parallel?
On Sun, Aug 18, 2013 at 9:02 PM, Chia-Hung Lin <cl...@googlemail.com> wrote:
> Sorry just want to double check what's the plan. Doesn't get point
> about skip release until reaching version 1.0. Are we going to just
> release some minor fixes and other (significant) patches will be
> released after version 1.0? Or ...
>
> For release procedure, probably we can borrow ideas from continuous
> integration where IIRC software is released as earlier as possible,
> and release cycle is reduced so that problems can be discovered and
> fixed earlier. That seems to be suitable for our scenario.
>
>
> On 18 August 2013 16:11, Edward J. Yoon <ed...@apache.org> wrote:
>> I mean, "put all TODO things into 1.0 roadmap, and just skip release
>> until reach version 1.0".
>>
>>> people would compare MRv2, Giraph to Hama; and would think that MRv2,
>>> and Giraph would be more better/ stable than Hama because of FT, etc.
>>
>> Spark also supports full fault-tolerance, and comparison has been
>> already started.. Spark shows good performance, giraph shows good
>> scalability. Hama has good performance and very flexible interface,
>> but we are in gray zone.
>>
>>> +0
>>
>> I'm -0. I think we have to cut periodically.
>>
>> On Sun, Aug 18, 2013 at 4:26 PM, Chia-Hung Lin <cl...@googlemail.com> wrote:
>>> +0
>>>
>>> Personally I would not go for 1.0 now though the release for 1.0 is
>>> ok for me. My reason is people may expect functions such as FT to be
>>> ready when it's in the version 1.0. Also it might be inevitably that
>>> people would compare MRv2, Giraph to Hama; and would think that MRv2,
>>> and Giraph would be more better/ stable than Hama because of FT, etc.
>>> regardless of differences between projects.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On 17 August 2013 16:33, Edward J. Yoon <ed...@apache.org> wrote:
>>>> Hi all,
>>>>
>>>> I was planning to cut a 0.6.3 release candidate (Hadoop 2.0 compatible
>>>> version), however it seems the age of compete for the preoccupancy is
>>>> past. So we don't need to hurry up now. Moreover, we are currently
>>>> adding a lot of changes, and still need to be improved a lot. We knows
>>>> what we should do exactly.
>>>>
>>>> Do you think we can skip minor release and prepare 1.0 now?
>>>>
>>>> --
>>>> Best Regards, Edward J. Yoon
>>>> @eddieyoon
>>
>>
>>
>> --
>> Best Regards, Edward J. Yoon
>> @eddieyoon
--
Best Regards, Edward J. Yoon
@eddieyoon
Re: [VOTE] Skip minor release, and prepare 1.0
Posted by Chia-Hung Lin <cl...@googlemail.com>.
Sorry just want to double check what's the plan. Doesn't get point
about skip release until reaching version 1.0. Are we going to just
release some minor fixes and other (significant) patches will be
released after version 1.0? Or ...
For release procedure, probably we can borrow ideas from continuous
integration where IIRC software is released as earlier as possible,
and release cycle is reduced so that problems can be discovered and
fixed earlier. That seems to be suitable for our scenario.
On 18 August 2013 16:11, Edward J. Yoon <ed...@apache.org> wrote:
> I mean, "put all TODO things into 1.0 roadmap, and just skip release
> until reach version 1.0".
>
>> people would compare MRv2, Giraph to Hama; and would think that MRv2,
>> and Giraph would be more better/ stable than Hama because of FT, etc.
>
> Spark also supports full fault-tolerance, and comparison has been
> already started.. Spark shows good performance, giraph shows good
> scalability. Hama has good performance and very flexible interface,
> but we are in gray zone.
>
>> +0
>
> I'm -0. I think we have to cut periodically.
>
> On Sun, Aug 18, 2013 at 4:26 PM, Chia-Hung Lin <cl...@googlemail.com> wrote:
>> +0
>>
>> Personally I would not go for 1.0 now though the release for 1.0 is
>> ok for me. My reason is people may expect functions such as FT to be
>> ready when it's in the version 1.0. Also it might be inevitably that
>> people would compare MRv2, Giraph to Hama; and would think that MRv2,
>> and Giraph would be more better/ stable than Hama because of FT, etc.
>> regardless of differences between projects.
>>
>>
>>
>>
>>
>>
>>
>> On 17 August 2013 16:33, Edward J. Yoon <ed...@apache.org> wrote:
>>> Hi all,
>>>
>>> I was planning to cut a 0.6.3 release candidate (Hadoop 2.0 compatible
>>> version), however it seems the age of compete for the preoccupancy is
>>> past. So we don't need to hurry up now. Moreover, we are currently
>>> adding a lot of changes, and still need to be improved a lot. We knows
>>> what we should do exactly.
>>>
>>> Do you think we can skip minor release and prepare 1.0 now?
>>>
>>> --
>>> Best Regards, Edward J. Yoon
>>> @eddieyoon
>
>
>
> --
> Best Regards, Edward J. Yoon
> @eddieyoon
Re: [VOTE] Skip minor release, and prepare 1.0
Posted by "Edward J. Yoon" <ed...@apache.org>.
I mean, "put all TODO things into 1.0 roadmap, and just skip release
until reach version 1.0".
> people would compare MRv2, Giraph to Hama; and would think that MRv2,
> and Giraph would be more better/ stable than Hama because of FT, etc.
Spark also supports full fault-tolerance, and comparison has been
already started.. Spark shows good performance, giraph shows good
scalability. Hama has good performance and very flexible interface,
but we are in gray zone.
> +0
I'm -0. I think we have to cut periodically.
On Sun, Aug 18, 2013 at 4:26 PM, Chia-Hung Lin <cl...@googlemail.com> wrote:
> +0
>
> Personally I would not go for 1.0 now though the release for 1.0 is
> ok for me. My reason is people may expect functions such as FT to be
> ready when it's in the version 1.0. Also it might be inevitably that
> people would compare MRv2, Giraph to Hama; and would think that MRv2,
> and Giraph would be more better/ stable than Hama because of FT, etc.
> regardless of differences between projects.
>
>
>
>
>
>
>
> On 17 August 2013 16:33, Edward J. Yoon <ed...@apache.org> wrote:
>> Hi all,
>>
>> I was planning to cut a 0.6.3 release candidate (Hadoop 2.0 compatible
>> version), however it seems the age of compete for the preoccupancy is
>> past. So we don't need to hurry up now. Moreover, we are currently
>> adding a lot of changes, and still need to be improved a lot. We knows
>> what we should do exactly.
>>
>> Do you think we can skip minor release and prepare 1.0 now?
>>
>> --
>> Best Regards, Edward J. Yoon
>> @eddieyoon
--
Best Regards, Edward J. Yoon
@eddieyoon
Re: [VOTE] Skip minor release, and prepare 1.0
Posted by Chia-Hung Lin <cl...@googlemail.com>.
+0
Personally I would not go for 1.0 now though the release for 1.0 is
ok for me. My reason is people may expect functions such as FT to be
ready when it's in the version 1.0. Also it might be inevitably that
people would compare MRv2, Giraph to Hama; and would think that MRv2,
and Giraph would be more better/ stable than Hama because of FT, etc.
regardless of differences between projects.
On 17 August 2013 16:33, Edward J. Yoon <ed...@apache.org> wrote:
> Hi all,
>
> I was planning to cut a 0.6.3 release candidate (Hadoop 2.0 compatible
> version), however it seems the age of compete for the preoccupancy is
> past. So we don't need to hurry up now. Moreover, we are currently
> adding a lot of changes, and still need to be improved a lot. We knows
> what we should do exactly.
>
> Do you think we can skip minor release and prepare 1.0 now?
>
> --
> Best Regards, Edward J. Yoon
> @eddieyoon