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
