hama-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Edward J. Yoon" <edwardy...@apache.org>
Subject Re: [VOTE] Skip minor release, and prepare 1.0
Date Wed, 28 Aug 2013 03:39:53 GMT
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 <menonsuraj5@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 <edwardyoon@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 <edwardyoon@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 <edwardyoon@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message