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 <[email protected]>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 <[email protected]> > 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 <[email protected] > >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 <[email protected]> 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 <[email protected] > > > >> 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 <[email protected]> > 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 < > [email protected]> > >> 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 <[email protected]> > >> 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
