Noel J. Bergman ha scritto:
Robert Burrell Donkin wrote:
trunk was forked from 2.3.0 several years ago now
Yes, I am keenly aware of the last time I had time to work on a release and
the communal disinterest or inability to do one since. One question I have
is, should the next release come from a v2.3.0 follow-on, or should we even
attempt to extricate something from trunk. And if the latter, then we are
going to have to compare that against the known, good, codebase. And, yes,
as the person who did this the last time, I'm well aware of the effort
involved. Hence my question and concerns.
Are you referring to the merge between trunk and 2.2.0 code between 2004
and 2005 ? I think it is a different story. That branch involved much
less code than current v2.3-trunk differences but included major changes
to mailet api.
I don't agree that the only way to produce quality is to compare with
previous work. The fact that you don't know what is in trunk because you
had no time to review most commits doesn't mean that this is the same
for everyone else here.
IMO there is no need at all to merge v2.3 and trunk this time. This time
we had no single fix in v2.3 that has not been done in trunk too. We
have been very diligent and we avoided diverging branches so to not
repeat the post-2.2.0 mistakes.
If you need time to check code quality in trunk, well, take your time
and let's discuss about specific code.
If you think it doesn't worth your time then start working on v2.3 and
make a proposal from there.
contains significant differences not only in organisation but also design.
i doubt whether anyone has the time required to perform a comprehensive
manual comparison now whether the mailets are in trunk or elsewhere.
Well, that's part of the issue. Due to the reorg, we will be hard pressed
to compare the changes in the current code from the released code.
If you exclude IMAP most code has changed BEFORE the code
reorganization. So it should be easier than you think. You will see that
since dicember 2006 we had very limited changes in the sources (if you
exclude IMAP and its dependencies).
It is a lot of code, because we implemented a lot of features and fixed
a lot of long standing issues in our services API.
i think that moving the mailets into a separate project should make
things move managable.
In the long run, I agree. Even in the mid-term, we can compare the Mailets
in the new project with those in the release, and validate the changes.
I will make a separate reply for mailet issues.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
