I'm not making a complaint, I'd like to take this job in fact. :-) What I mean here is maybe we can commit patch to both trunk and Java 6 branch at the same time. (It may bring more workload to every committer.)
Merging by bunch is convenient but error-prone. 2009/4/22 Nathan Beyer <[email protected]>: > I would like to help with the merging, but I don't feel like I understand > our current conventions for doing it. Would some one mind documenting the > why, what and how? This would help me get in the flow and make it a habit. > > I feel like this is the problem as the integrity builds - it isn't > documented, so it requires research and reverse-engineering to repeat by > another person. > > Sent from my iPhone > > On Apr 21, 2009, at 11:04 AM, Sean Qiu <[email protected]> wrote: > >> 2009/4/17 Tim Ellison <[email protected]>: >>> >>> Immediately after a release is usually the time that I'm thinking about >>> lessons learned, the project road map, and future deliveries from >>> Harmony. >>> >>> Most noticeable for me was the long stabilization period we undertook >>> for M9 compared to earlier releases. This was required, I believe, >>> because of the longer open development period [1]. The lesson to take >>> away from that is to ensure we keep an eye on our regular release >>> schedule and keep the time boxes short enough that stable fixes get out >>> to our users, and we minimize the frozen codebase period. >>> >>> Looking ahead I'd therefore expect 5.0 M10 to be released at the end of >>> May (6 weeks after April 8th = May 20). >>> >>> >>> The other thing that bothers me is the lack of expose we give our Java 6 >>> branch. While the majority of fixes we commit are applied to both >>> branches, we have some good work completed in the Java 6 API branch's >>> core classes that is not getting the uptake it deserves. >> >> What about each committer takes charge of this? >> When we apply certain patches to trunk, >> we'd make the decision whether merge it to branch 6 meanwhile. >> >> I've tried to do some merging work, it is not easy to tell "proper" >> and "improper" against a great number of patches. >> It do introduce potential risks while merging. >> >>> >>> The non-core Java 6 classes get very little attention at the moment. >>> With Harmony's strong modular architecture we can easily construct a >>> headless runtime that delivers those core classes without the missing >>> functionality. >>> >>> I'd like to suggest that we experiment with the flexible components in >>> Harmony to deliver a headless runtime based on the Java 6 APIs. >>> >> >> +1 >> >>> Thoughts? >>> >>> [1] Depending on exactly how you count it, we were open from 17 Nov - 27 >>> Feb, which is a massive 14.5 weeks! >>> >>> Regards, >>> Tim >>> >> >> >> >> -- >> Best Regards >> Sean, Xiao Xia Qiu > -- Best Regards Sean, Xiao Xia Qiu
