Norman Maurer wrote: >>> Now I think that not only we should include everything we have now in >>> trunk, but we should also define a period of feature development where >>> we try to put in every cool feature we are able to develop in this time >>> with one single restriction: keep storage compatibility. >> When do you expect to put that out?! I'm talking about a plan that allows >> us to put out a stable release very few months with carefully made changes, >> and you just want to core dump! I do not agree to that approach. > I don't agree with you both :-P > I think we need a roadmap and only workin on the code which include > features which listed in the roadmap. Bugs should be fixed too.. > When someone feel to work on a other task then one listed in the roadmap > he should raise his voice in the mailinglist and if we agree we put it > on the roadmap and include it. If not he should wait with the work and > wait for next release. > Like i said before i see no problems starting to workin on 2.4 and use > trunk as it is. I whould be happy if we could put out 2.4 in about 6 > Month later then 2.3 is released.
Well, I think that we have not enough man-power and paid-work to define a roadmap with dates and be sure we'll reach our goals. So we should either define a feature set OR a date for the branch. Imo if we want to be sure we'll release in about 6 month we should start the consolidation branch in 2-3 months from now. So I think we should define a list of things that could be included and things that must be postponed and then we'll have to accept what we have in trunk when we branch. >>> Furthermore I would consider a big mistake to try to release 2.4 as a >>> 2.3 + new fastfail things, because new fastfail things are still in >>> progress and not mature enough >> And yet you want to use TRUNK as 2.4?! Be consistent. Trunk has many such >> "still in progress and not mature enough" things, not just fast-fail. Maybe >> we decide that fast-fail isn't mature enough yet. As you say: > > I agree that we have stuff which is not 100% finish. So we need to focus > on that first! The handler api is one of the stuff we need to finish > first soon. Cause as longer we wait as harder it get to merge the > stuff. Right: if we define a date for the consolidation-branch then we can take care than no unfinished stuff is in trunk by that day so that we won't need to finish stuff in the branch but only to consolidate it. Now it is simply unfeasible to branch 2.4 from trunk and finish the fastfail work there. Imo if we wanted to branch today we should exclude fastfail because it is still work in progress and we still have a further proposal branch opened on that issue. So we only could include very few things: JMX stuff, few mailets, few management commands, and common daemon. I won't loose a "release cycle" for so few features. >>> A last reason to not start a 2.4 branch now and to not start a selective >>> merge job is that we are not sure that 2.3.0 would not need a 2.3.1 >>> release in a month >> If we start v2.4 from v2.3, we don't need 2.3.1. 2.4 would be suffice. I >> want to start using this stuff ASAP, not after another year of development >> and testing. >> --- Noel >> >> > I agree with Stefano.. And i think we can push a 2.4 release in 6 Month > ( At least i hope so). > > So i think the next step must a roadmap! First we should dedicide which > jira issues should be moved to 2.4 before do anything else. Without a > roadmap we only make it more complicated. My proposal is: - everything we have in trunk now: now I can't see anything critical enough to be removed. - JAMES-426 - Make james use virtual user table domains for servernames - JAMES-52 - 8bitmime capabilities missing - JAMES-487 - Refactor Bundled handlers to use the "HandlerChain" pattern - JAMES-577 - Switch default sendpartial to true for RemoteDelivery - JAMES-607 - Rewrite MBoxMailRepository to use mstor - JAMES-611 - Remove finalizers and make sure we always call dispose when unreferencing objects - JAMES-461 - Javamail Store based MailRepository support (was: Maildir support) - JAMES-614 - Add more actions to FastFailHandlers - JAMES-549 - Refactoring SMTPHandler to allow better integration of more the one class per command - JAMES-599 - BeanShell Scripting in James - JAMES-562 - Aliasmanagment should not depend on a user (see as VUT-UsersAliasingForwarding common interface and remove tightly dependencies between James and JamesUser) - JAMES-595 - Change names of release artifacts to use james-server instead of james. As I said if some of them will not be ready it won't be included: time based roadmap is good if we have a good amount of "new-feature-development" time in the release cycles. Other things that I would like to see there if we find the time: - JAMES-491 - SpoolManager refactorings - JAMES-126 - Add support for APOP authentication protocol - JAMES-551 - Use MINA as framework - JAMES-493 - Refactor James components/services to simplify their usage in other IoC containers (SDI) - JAMES-521 - Mail/Spool/Message repositories refactoring : there is a message 1 year old and another few months old about how to work on this while keeping storage compatibility. - JAMES-288 - memory efficient retrieval - JAMES-241 - fail gracefully upon large messages/attachments - JAMES-134 - Large emails in the spool cause SpoolManager to throw OutOfMemoryError - JAMES-334 - SHA hash incompatable with common generation methods - JAMES-332 - Support other digest algorithm (was: SHA hard coded in adduser) - JAMES-126 - Add support for APOP authentication protocol So there is no real distinction between the first list and the second one: as I said I think that everything I listed deserve inclusion in 2.4 and does not break storage compatibility and neither needs major refactorings, the main constraint is the time. I expect to actually be able to work on many of the issues on the first list but I hope to find the time for the second list. Stefano --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
