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 >
