Am Mittwoch, den 13.09.2006, 10:13 +0200 schrieb Stefano Bagnara: > 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. Agree. We should define a list of features we want to include. Maybe with prio. Then after a period we must dedicide what todo if we want to release it soon we can remove tasks if not we can focus on a new date. I think a release date is "importend".
> > 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. agree. > > >>> 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. Same here. > > >>> 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 I hope we can get this work with new javamail when its released. > - JAMES-487 - Refactor Bundled handlers to use the "HandlerChain" pattern Thats a must. > - JAMES-577 - Switch default sendpartial to true for RemoteDelivery > - JAMES-607 - Rewrite MBoxMailRepository to use mstor Im not sure about this now. For this we must get sure mstor is really thread-safe! > - JAMES-611 - Remove finalizers and make sure we always call dispose > when unreferencing objects > - JAMES-461 - Javamail Store based MailRepository support (was: Maildir > support) Joachim did a great work on this. Yes thats a must. > - 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 Don't think that is importent for many people. I whould delay this.. > - JAMES-551 - Use MINA as framework Don't think that we will able to do this in 2.4 > - 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 See above > > 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 I hope i will have some time and hope other commiters too.. bye Norman
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
