I would like to finish HARMONY-5617. Now the problem is just workarounded. Although it's a bugfix, actually it includes changes in VM signal handling to make it platform-independent, and moving stack and guard page operations and OS-level threading to porting layer - so I think it should be considered as a feature.
The patch is almost ready - I'm now investigating the last intermittent problem with SIGUSR2 handling. Also I want to check performance impact of the patch - this can take few days. Thanks, Ilya. 2008/4/25, Pavel Pervov <[EMAIL PROTECTED]>: > Well, I would like to unify types used in external interfaces with > those used in class library (hycomp.h). > > These changes are pretty simple, but widespread. There are series to > patches: one type unification per patch. If the code freeze is now - > then I have to wait for two weeks to commit the changes. I'd like to > do it before the freeze. > > Thanks, > Pavel. > > > On 4/25/08, Alexei Fedotov <[EMAIL PROTECTED]> wrote: > > All, > > Please pay attention to the suggestion of making a feature freeze > > today for incoming M6. Does anyone has features in progress we may > > want to include into M6 release? Please, speak up. > > > > It is important to understand if the suggestion is timely for harmony > > developers. > > Thank you. > > > > On Fri, Apr 25, 2008 at 1:58 PM, Tim Ellison <[EMAIL PROTECTED]> wrote: > > > > > > Stepan Mishura wrote: > > > > > > > On 4/24/08, Tim Ellison <[EMAIL PROTECTED]> wrote: > > > > > > > > > Mark Hindess wrote: > > > > > > > > > > > I agree with Tim on this issue. I think making a release, with the > > > > > > testing, evaluation and voting involved, should not be something > that > > > > > > downstream projects dictate. Doing this release would seem to set > a > > > > > > precedent that I would not be happy with. > > > > > > > > > > > > I would be inclined to vote -1 for any formal release that isn't > > > simply > > > > > > the next milestone release. Of course, this is not necessarily my > > > final > > > > > > decision. > > > > > > > > > > > > The downstream project should use our current release or if they > have > > > > > > a desperate need for something more recent then they should be more > > > > > > flexible. > > > > > > > > > > > > > > > > > Just to be clear about my views -- I have no objection if we choose > to > > > > > effectively freeze new feature work in the verifier so that Eclipse > can > > > take > > > > > a copy of the source code at a well-defined revision number with some > > > > > assurance from us that it is not in a great state of flux. > > > > > > > > > > However, if we are going to produce a formal milestone, that has > > > undergone > > > > > the testing, checking, signing, and distribution via ASF mirrors > then we > > > owe > > > > > it to all our users for that to be the best quality we can produce. > And > > > > > that means the feature freeze, code freeze, test and voting cycle > that > > > we > > > > > have established for the project. > > > > > > > > > > > > > > > > > > I don't know what particularly stands behind the 'officially released' > > > > requirement. We started our discussion with the requirement of 'binary > > > > release' and it transformed further to the 'source release'. > > > > > > > > > > Our emphasis is on the source code. The artifact that we vote upon as > the > > > release is the source bundle for our Milestone -- we are on open source > > > project after all. The binary builds are an important and sanctioned > > > convenience to our users, but our mandate is to produce source not > binaries. > > > > > > > > > > > > > So say if we'll complete testing verifier and declare 'officially' > > > > that we tested it in particular svn revision that we freeze (i.e. > > > > verifier code) till M6 (and optionally provide a source bundle). Then > > > > IIUC it is OK for you but I don't know if it is acceptable for Eclipse > > > > project. > > > > > > > > > > I meant we agree not to make any feature changes etc. in the verifier > area > > > knowing that Eclipse plan to pick up the code for TPTP, not that it > remains > > > frozen all the way to M6. > > > > > > > > > > > > > And if the 'officially released' requirement implies our current > > > > formal process (i.e. testing, checking, voting, signing, distribution > > > > and so on) then I don't see any way how to resolve it in the current > > > > situation. > > > > > > > > > > Let me make a concrete suggestion. > > > > > > We feature freeze today, and start a code freeze on Mon 28th April. > > > We can expect testing and bug fixing to continue for at least one week, > > > until Mon 5th May, then we have final vote and distribution probably > taking > > > until Fri 9th May. > > > > > > The dates need to be flexible so if we find problems we will, as always, > > > slip dates to get better quality. > > > > > > What do you think? A real M6, no arguments :-) > > > > > > Regards, > > > Tim > > > > > > > > > > > -- > > With best regards, > > Alexei > > > > > > -- > Pavel Pervov, > Intel Enterprise Solutions Software Division >
