james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: 2.3.x vs trunk [WAS Re: [VOTE] Mailets -> Mailet subproject]
Date Thu, 06 Mar 2008 13:38:56 GMT
Noel J. Bergman ha scritto:
> Stefano Bagnara wrote:
>> 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.
> 
> Yes, much less code.  More code ==> more bugs.  And you certainly aren't
> going to claim that there aren't major changes in trunk from the known-good
> code.

Let's start collecting bugs in JIRA and start solving some of them. We 
keep talking about how unstable is trunk and how many bugs are in trunk, 
but we don't have bugs reported against that code.
We are discussing too much about what it "could be" and we should use 
our limited time to work on concrete things.
If we'll collect too many critical/problematic bugs against trunk we may 
agree more easily that v2.3 is the way to go and that trunk should be 
discarded, don't you think?
We need a proof that trunk is really unstable. I always remember that 
working on 2.3 most bugs where in the old code and not in the new code, 
so we cannot simply say that old code is stable/good and new code is not 
stable good. E.g: we wrote unit tests for a lot of the new code, old 
code is not unit tested.

>> 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.
> 
> Actually, (a) you have no idea what I review, and (b) I will bet you that
> almost no one is reviewing a fraction of the commits.  That's part of our
> dysfunction as a community.  Out of Serge, Danny, myself, Vincenzo, Soren,
> Steve, Norman, Robert, Bernd and anyone else whom I've missed, how many
> pairs of eyes do you believe are reviewing each commit?  My guess is 2-3,
> tops, on average, including the committer.

(a) VERY TRUE. Tell us.
(b) VERY TRUE: this is true since JAMES project has been created. Or at 
least is true since I'm here (2005).

We need to cut milestones and do releases if we want people to use that 
code and increase our confidence on the code quality.

>> IMO there is no need at all to merge v2.3 and trunk this time.
> 
> I agree with you, but who suggested such a thing?

Good then. Recorded. No need to merge. (it was probably a 
misunderstanding on my side.. )

>> This time we had no single fix in v2.3 that has not been done in trunk
> too.
> 
> It isn't a matter of what is fixed in trunk.  Hey, every appropriate fix
> that went into MS-Windows XP went into MS-Windows Vista, too, but that
> doesn't make MS-Windows Vista any less a diasterous load of digital garbage.
> For that matter, I am currently testing Ubuntu 7.10 and 8.04.  Guess what?
> The new kernel in 8.04 (still Alpha) has major functional regressions
> compared to 7.10.  New code, new designs, new bugs.

During v2.3 development also happened the opposite thing: new code, new 
design, old buggy code no more used ;-)
But again, this is theory: let's collect the bugs and let's see if we 
have men-power to fix them or not.

>> 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.
> 
> So you propose that we first vet v2.3.0 against a pre-reorg revision of
> trunk, and then compare the current trunk against the first post-reorg
> revision?
> 
> 	--- Noel

I just suggested you a simpler way to work around the problem you 
described (reorganization make it difficult to compare). I don't need 
this check for myself.

Let us know what are your conclusions/ideas once you'll have checked the 
code.

Thank you,
Stefano



---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message