I agree, let's discuss that in a separate thread. Tommaso
2013/8/28 Edward J. Yoon <[email protected]> > 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 >
