Re: JAMES v2.4 Road Map (Status Update)
Hi Bernd, this is *the best* Mail I read on this thread !!! Kind regards Juergen Bernd Fondermann schrieb: Hi guys, so much words again for so few information, and not always fun to read. anyway, a few very short takes from me to let you know what my preferences are: Working on trunk towards 3.0: +1 Supporting old configuration in future versions: +1 Working on 2.4 by backporting stuff: +0 Using misleading mail subjects: -1 Using CAPS-LOCK when writing mail: -1 Bernd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] !EXCUBATOR:1,454051c953079300313603! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JAMES v2.4 Road Map (Status Update)
Hi guys, so much words again for so few information, and not always fun to read. anyway, a few very short takes from me to let you know what my preferences are: Working on trunk towards 3.0: +1 Supporting old configuration in future versions: +1 Working on 2.4 by backporting stuff: +0 Using misleading mail subjects: -1 Using CAPS-LOCK when writing mail: -1 Bernd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JAMES v2.4 Road Map (Status Update)
Stefano wrote: Noel wrote: Stefano Bagnara wrote: I don't agree with your version numbers, but if you can read my message you will find that I never talked about 2.4 or 3.0 See the subject header. Then now that I explained you that it was not related to 2.4 you can read it again and give your real reply. Yes, that makes a very big difference. More later, but yes, this makes a very big difference now that we are closer to being on the same page. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JAMES v2.4 Road Map (Status Update) Switched to PMC
Thanks for sending this, Steve, really! I very heartfully agree with you. This is a mail for printing out and double-checking everytime before hitting the send button. Thanks again! Bernd On 10/25/06, Steve Brewin [EMAIL PROTECTED] wrote: Hi, I stumbled across this unsent message in my drafts. I had decided not to send it, but in the light of current server-dev discussions I've changed my mind (obviously). The original context was Version numbers (Was: LONG JAMES v2.4 Road Map). I'm sending this to the PMC as I don't think it good to air these issues publicly on server-dev and its for the PMC to resolve. --- /snipped 'cos I don't want anyone to feel I'm aiming at them in person. I think we all should review how we are discussing and proceeding. Compared to other ASF lists we don't convey a good impression (IMHO). Like good wine, discussions need time to breathe. Instead of rapidly firing point and counterpoint its sometimes better to wait for everyone to air their views before responding. Diving straight in often leads to more confusion than illumination. While the intent is to arrive at a conclusion, often the reverse happens. Discussions are unneccesarily extended leaving less time to get the real work done. Once a position has been stated, taking time to view, absorb and understand all of the different points of view and then assembling a coherent response offering a positive way forward before adding to the discussion is often the best way to go. While I understand the need to maintain momentum, constantly putting issues to a time constrained vote disenfranchises the time constrained. It also leaves me, and perhaps others, feeling forced into making micro-choices which ignore macro-issues, edging us along a roadmap which, ironically, I have never voted on. There is the illusion of democracy, but often I feel like a vegetarian being asked how I would like my beef steak cooked. -- Steve Not dead, just not voting :) --- James is a community. Some are more active than others right now. Some have deeper and longer experience. Some have been elected by their peers to be members of the PMC. This confers both greater powers and greater responsibility. We should use the former wisely and always remember the latter. Those of us with longer experience know that the kind of flame wars we are starting to see develop amongst PMC members here most often have unhappy outcomes. Let's not go there. Can we all take a step back and find a way through this? A moderator perhaps? Cheers -- Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JAMES v2.4 Road Map (Status Update)
Noel J. Bergman schrieb: Steve Brewin wrote: Norman wrote: Vincenzo Gianferrari Pini wrote: On 10/24/06, Stefano Bagnara [EMAIL PROTECTED] wrote: I've added this point because Noel and Vincenzo brought this as animportant point in the 2.4 roadmap discussion. I personally don't care of config.xml compatibility: I was just reporting what I understood was important (and feasible) to the PMC. We just stressed the fact that life must be kept as much as possible easy for users when upgrading to new release, otherwise they may stay behind. Regarding configurations, this goal can be achieved either keeping as much as possible backward compatibility for existing features, either providing (safe and thoroughly tested) conversion tools. But we have to be aware that slowly adding small configuration incompatibilities can sum up to require complex conversion tools, that nobody would develop and would become a bottleneck when releasing a new version. Thats right but with no new features we will loose users and not get new. We have never said NO NEW FEATURES. STOP SPREADING A FALSE MEME! Sorry man... but is your CAPS key maybe broken... You don't need to use the CAPS key if you want me to read the text... So stop frontin! Such things make me really angry. For JAMES v2.4, the changes should be compatible. For JAMES v3, they can be incompatible. We all agreed on that when we met at ApacheCon. And we can deliver both in parallel. I would expect most work from most of us to focus on JAMES v3, and if we don't want to backport something, then it doesn't get backported. I think we just need to document what to change in config.xml. Not good enough. That doesn't address that overtime, these incremental changes could add up to a lot of require changes to migrate. Sure it can .. but sometimes it is impossible to keep the config compatiblilty.. and have a clear UPGRADING.txt in the release will hopefully help the users. Thats was other projects also do. Absolutely. This is why in my commercial endeavours we consider the upgrade code to be a vital part of the core product and subject to the same testing regime as all other code. It isn't an after thought, its a selling point. Something that allows our customers to easily buy into new versions, which earns us revenue, which keeps me in a job. While James doesn't have the same commercial drivers, we will lose users and kudos if we do not provide a smooth migration path between releases. Exactly. --- Noel bye Norman - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JAMES v2.4 Road Map (Status Update)
Norman, (I seem to have missed alot of mail, and got it all in one batch!) I've replied about vhosting in a new thread, I think the most problems of people are that they fear to break james.. But why we should fear with new junit tests :-P This is true, but it is also true that some proposals take longer and have more impact, its not *just* about breaking James, but also about blocking the project. We have had some bad blocks in the past. I think I will propose the use of the status file, and we can see what we think once we've tried it, unless it gets shot down by the veto brigade ;-). Go ahead Ok :-) d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JAMES v2.4 Road Map (Status Update)
Noel J. Bergman wrote: All I want is some discipline about what goes into a release, and then I'll be a happy camper again. Stop telling me about releasing trunk, and start talking about how we'll put together a safe, stable, reliable distribution with all of the new features we want, and my doctor (who measures my blood pressure) will be a much happier man. I think I will use again the terms release from trunk, release based on trunk, based on branch 2.3 or something similar. I always used that terms and I will use this again. I can try being more specific every time, but now you know that when I say releasing from trunk I don't mean tag trunk one random day and make an official release but I mean branch trunk at a decided day, start consolidation on the branch. Trunk is not consistent quality. I just want to hear that we will have some discipline about what we release. Today, I wouldn't trust trunk to pass gas much less handle my e-mail. But whatever we pull from trunk to make the next major release WILL be stable and reliable before we release it. I have a lot of confidence in what we have currently in trunk: Norman is already using it on a live site, and I'm planning to switch to trunk soon (I just wanted to test some day more the 2.3.0 final). Btw consolidation belongs to the branch: now we should concentrate on the features without breaking the whole thing. These are the issues I raised with Stefano, and he agrees with the concern about being stable and safe. When he talks about releasing from trunk, it is a language issue. It means one thing to me, but is another in his mind. He's much more specific about what he feels should be copied from trunk when we plan the release, and on those issues we are more in agreement. To quote him: I want to make it clear that I simply want to refactor James so that it will be pluggable, and that the default should be backward compatible. I want to be sure you've not misunderstood me again: I talked about refactor James so that it will be pluggable in a long context. This is my main goal, but not the only goal for the next-major. If you want to publish the whole chat we had on skype, feel free to do that. About being more specific about what I feel should be copied from trunk i'm a bit lost. My proposed plan is: - branch trunk on Dec2006/Jan2007 (so everything there by that day will be copied in the branch) - start consolidation of the branch for the release (ETA 2-3 months later) Consolidation means: - fixing bugs - changing default configurations - ensure we have the best backward compatibility - if needed disable portion of code we decide are not ready to be released (e.g: IMAP) If you have problems with a specific feature being included in trunk or you have problem with a specific commit please let's talk about it, but I don't want to start a commit-by-commit discussion to decide what to bring in the release: and this is the sense of the release based on trunk that I described in the currently running vote. We also talked about discussions. He wants to know why when he posts so many e-mails, he gets no reply. I tried to explain that one e-mail gets replies, 100 e-mails get none. When there is so much volume, people feel that they need to read more, and they don't feel that they have time to reply to everything at once, so they reply to little if anything. I reminded him about Bernd asking him to please try to say things in fewer words because it was too much to read. I suggested that we try to pick a high priority list of things to discuss first, and work through the list rather than try all things at once. I don't have a solution to this: we are moving much faster than in the last 2 years, and this needs a lot more activity on the list. It takes me a lot of time to do that, also, but I feel this is my duty as PMC member: I don't have a proposal to fix this. Danny is proposing a status file: let's see if this helps or it will be another outdated wiki page. Going to the specific, I would like to have a next-minor with some fast-fail features there (like jspf and other filters) plus other minor things Agreed. And I want to incorporate Norman's patch for per-IP connection limiting. Until now everyone voted +0 to next-minor and everyone +1 to next-major. If you still believe in a next-minor please make it more clear what you will include and maybe you will find more supporters. Stefano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JAMES v2.4 Road Map (Status Update)
Noel J. Bergman wrote: Stefano and I certainly had a misunderstanding over his intent for 2.4 (the next minor release), due to the subject heading. If were were in physical proximity, I'd shake his hand. We've already apologized for the misunderstanding, and had a very long chat (each of us missed a meeting or two to have it). As I wrote to Noel in IM I think most of the misunderstanding is because we have this numbers in our minds: RELEASENOEL STEFANO next-minor 2.4 n/a (2.4) next-major n/a (3.0)2.4 (2.5 if next-minor) next-grater3.0 3.0 I always understood this difference in version numbers we have in our minds, and that's why I started using next-labels to try to slow down the flame about numbers. But everytime a number is used again the flame starts again. As I said multiple time I believe we can decide the number when we'll be ready to branch but we should avoid number flames until that day. In IM I explained Noel that next-major is different from what it described as 3.0 because I described it as a backward-compatible (storage+config) release (like his 2.4/next-minor). The only difference between next-minor and next-major is that next-minor would include a small set of features selected by trunk and should be released sooner (Dec2006), while next-major would include all the features we have in trunk and would have a longer release cycle (Mar2007). If we also add that the 3.0/v3 number has also been used years ago to define even something else (in wiki we have mailet-v3 and james-v3 pages describing things that won't probably be part of next-minor/next-major release and some other things that maybe we already included in 2.3) it is much more clear why numbers are creating the hell here. I know that next-* is not a solution to our problems, but I don't have a better solution to this: if anyone has a better way I can only be happy for this. That said once the roadmap vote will be closed I'll try to make a wiki page/status file/ml message/jira version to describe what we have in trunk, what I think must be included in next-major, what I think could be included, what I think cannot be included. And I hope we can find an agreement on next-major without too much discussion. Stefano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JAMES v2.4 Road Map (Status Update)
Slightly more than a month ago I wrote a roadmap, here is an update for people that has not time for a day to day oversight. And I disagreed with you then, and so did others, and I am really getting tired of decision by message volume. I don't believe that I am alone in that sentiment. Trunk should be JAMES v3.0. No major concerns at the moment to discuss. JAMES v2.4 should be incremental changes to the newly released JAMES v2.3. We can even release concurrently, supporting JAMES v2 and JAMES v3 for as long as we need the need. Ironically, to comment on an old claim, most of what I want to work on is for JAMES v3, but we still need to support our existing user base. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JAMES v2.4 Road Map (Status Update)
Steve Brewin wrote: Norman wrote: Vincenzo Gianferrari Pini wrote: On 10/24/06, Stefano Bagnara [EMAIL PROTECTED] wrote: I've added this point because Noel and Vincenzo brought this as animportant point in the 2.4 roadmap discussion. I personally don't care of config.xml compatibility: I was just reporting what I understood was important (and feasible) to the PMC. We just stressed the fact that life must be kept as much as possible easy for users when upgrading to new release, otherwise they may stay behind. Regarding configurations, this goal can be achieved either keeping as much as possible backward compatibility for existing features, either providing (safe and thoroughly tested) conversion tools. But we have to be aware that slowly adding small configuration incompatibilities can sum up to require complex conversion tools, that nobody would develop and would become a bottleneck when releasing a new version. Thats right but with no new features we will loose users and not get new. We have never said NO NEW FEATURES. STOP SPREADING A FALSE MEME! For JAMES v2.4, the changes should be compatible. For JAMES v3, they can be incompatible. We all agreed on that when we met at ApacheCon. And we can deliver both in parallel. I would expect most work from most of us to focus on JAMES v3, and if we don't want to backport something, then it doesn't get backported. I think we just need to document what to change in config.xml. Not good enough. That doesn't address that overtime, these incremental changes could add up to a lot of require changes to migrate. Absolutely. This is why in my commercial endeavours we consider the upgrade code to be a vital part of the core product and subject to the same testing regime as all other code. It isn't an after thought, its a selling point. Something that allows our customers to easily buy into new versions, which earns us revenue, which keeps me in a job. While James doesn't have the same commercial drivers, we will lose users and kudos if we do not provide a smooth migration path between releases. Exactly. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JAMES v2.4 Road Map (Status Update)
Noel J. Bergman wrote: Slightly more than a month ago I wrote a roadmap, here is an update for people that has not time for a day to day oversight. And I disagreed with you then, and so did others, and I am really getting tired of decision by message volume. I don't believe that I am alone in that sentiment. I don't know what's the problem with you. And I don't know the meaning of decision by message volume. My message was simply a status update on a set of features I proposed 1 month ago to be included in what I called next-major release. Active committers did some progress so I decided to give an update. I don't understand what exactly you disagree. Trunk should be JAMES v3.0. No major concerns at the moment to discuss. JAMES v2.4 should be incremental changes to the newly released JAMES v2.3. We can even release concurrently, supporting JAMES v2 and JAMES v3 for as long as we need the need. I don't agree with your version numbers, but if you can read my message you will find that I never talked about 2.4 or 3.0, I simply updated a list of issues I described in a previous post and I left the subject unchanged. I just started a vote to have a better overview on what we can do about next-minor and next-major. We'll vote for the numbers later. Ironically, to comment on an old claim, most of what I want to work on is for JAMES v3, but we still need to support our existing user base. --- Noel As you proposed the next-minor (branch 2.3 and add backport few features from 2.4) please feel free to write the same status update for this goal. I simply did my duties. Stefano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JAMES v2.4 Road Map (Status Update)
Noel J. Bergman wrote: My proposal is: - everything we have in trunk now: now I can't see anything critical enough to be removed. Well, this was already there ;-) Release planning by fiat? I think that we would have to be INSANE to release trunk as JAMES v2.4! 1) This was not a relase planning, it was a status update on what we did. 2) I don't mind being INSANE. 3) I never said we should release trunk as 2.4: I said we should branch from trunk the release I called next-major and that we should start working on stabilization for a release in the branch. More to come. And, no, I am not just reading this now. I have been reading it all every day, and getting angrier every day. Since I don't seem to be getting less angry about what I am reading, I might as well start replying. --- Noel If you're angry for something concrete please write your concern, if you're angry because something in my message was unclear give me more details and I would be happy to provide more informations. If you're angry because you didn't find slaves to work on your personal goals, then I can't help with this ;-) Stefano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JAMES v2.4 Road Map (Status Update)
Noel J. Bergman wrote: Steve Brewin wrote: Norman wrote: Vincenzo Gianferrari Pini wrote: On 10/24/06, Stefano Bagnara [EMAIL PROTECTED] wrote: I've added this point because Noel and Vincenzo brought this as animportant point in the 2.4 roadmap discussion. I personally don't care of config.xml compatibility: I was just reporting what I understood was important (and feasible) to the PMC. We just stressed the fact that life must be kept as much as possible easy for users when upgrading to new release, otherwise they may stay behind. Regarding configurations, this goal can be achieved either keeping as much as possible backward compatibility for existing features, either providing (safe and thoroughly tested) conversion tools. But we have to be aware that slowly adding small configuration incompatibilities can sum up to require complex conversion tools, that nobody would develop and would become a bottleneck when releasing a new version. Thats right but with no new features we will loose users and not get new. We have never said NO NEW FEATURES. STOP SPREADING A FALSE MEME! For JAMES v2.4, the changes should be compatible. For JAMES v3, they can be incompatible. We all agreed on that when we met at ApacheCon. And we can deliver both in parallel. I would expect most work from most of us to focus on JAMES v3, and if we don't want to backport something, then it doesn't get backported. Just to let everyone know that I was not at ApacheCon and I never agreed on this. In detail I don't agree on version numbers, and to overcome this problem I started talking about next-minor (what Noel calls v2.4), next-major (being defined 2.4, 2.5 or 3.0 by different authors), next-greater (what Noel calls v3). I agreed that we can deliver next-minor and next-major in parallel, never agreed on a v3 incompatible to be released in parallel. I defined next-major as compatible (whatever number we'll assign to it). I think we just need to document what to change in config.xml. Not good enough. That doesn't address that overtime, these incremental changes could add up to a lot of require changes to migrate. I already gave a lot of importance of your (you, Vincenzo, and others) concerns about config.xml changes and I'm working with Norman to make sure trunk we'll start also using a config.xml from 2.3.0 (but not the reverse thing). We everytime keep this in mind when working on trunk. Some minor backward incompatibilities can't be avoided and are needed because we have to fix bugs or bad behaviours previously present in James. See for example the ignoreCase issues I described and I started fixing in trunk. James 2.3.0 and previous had a WEIRD behaviour wrt ignoreCase and as an example behaviour was different between files and jdbc repositories. Trunk will support the same configuration with the same syntax but will fix this differences (so in some scenario it will work slightly different). Stefano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JAMES v2.4 Road Map (Status Update) Switched to PMC
Hi, I stumbled across this unsent message in my drafts. I had decided not to send it, but in the light of current server-dev discussions I've changed my mind (obviously). The original context was Version numbers (Was: LONG JAMES v2.4 Road Map). I'm sending this to the PMC as I don't think it good to air these issues publicly on server-dev and its for the PMC to resolve. --- /snipped 'cos I don't want anyone to feel I'm aiming at them in person. I think we all should review how we are discussing and proceeding. Compared to other ASF lists we don't convey a good impression (IMHO). Like good wine, discussions need time to breathe. Instead of rapidly firing point and counterpoint its sometimes better to wait for everyone to air their views before responding. Diving straight in often leads to more confusion than illumination. While the intent is to arrive at a conclusion, often the reverse happens. Discussions are unneccesarily extended leaving less time to get the real work done. Once a position has been stated, taking time to view, absorb and understand all of the different points of view and then assembling a coherent response offering a positive way forward before adding to the discussion is often the best way to go. While I understand the need to maintain momentum, constantly putting issues to a time constrained vote disenfranchises the time constrained. It also leaves me, and perhaps others, feeling forced into making micro-choices which ignore macro-issues, edging us along a roadmap which, ironically, I have never voted on. There is the illusion of democracy, but often I feel like a vegetarian being asked how I would like my beef steak cooked. -- Steve Not dead, just not voting :) --- James is a community. Some are more active than others right now. Some have deeper and longer experience. Some have been elected by their peers to be members of the PMC. This confers both greater powers and greater responsibility. We should use the former wisely and always remember the latter. Those of us with longer experience know that the kind of flame wars we are starting to see develop amongst PMC members here most often have unhappy outcomes. Let's not go there. Can we all take a step back and find a way through this? A moderator perhaps? Cheers -- Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JAMES v2.4 Road Map (Status Update)
I don't know what's the problem with you. And I don't know the meaning of decision by message volume. See Steve Brewin's e-mail. I don't agree with your version numbers, but if you can read my message you will find that I never talked about 2.4 or 3.0 See the subject header. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JAMES v2.4 Road Map (Status Update)
Noel J. Bergman wrote: I don't know what's the problem with you. And I don't know the meaning of decision by message volume. See Steve Brewin's e-mail. I don't agree with your version numbers, but if you can read my message you will find that I never talked about 2.4 or 3.0 See the subject header. --- Noel Then now that I explained you that it was not related to 2.4 you can read it again and give your real reply. I replied to the message without changing the subject because we kept that subject for a month and we already talked about every version number we could think of. Of course feel free to change the subject if you think you have a better one. Stefano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JAMES v2.4 Road Map (Status Update)
Hi Stefano, Thanks for your detailed reply, I hope my comments below will reassure you that I'm not proposing anything radical, just a slightly more visible planning process, and some small refactorings. I also hope that we're beginning to reach a common understanding of what James project is lacking and how to take the next step from having tactical (I don't want to pretend you are stupid, but I know that English is not everyone's best language, tactical means short term) decision making towards strategic (means long term). On 10/24/06, Stefano Bagnara [EMAIL PROTECTED] wrote: I'm happy enough with what JIRA roadmaps give us. I don't know what exactly you mean with status file but I would not like having more pieces to mantain. the STATUS file is a mechanism used by Apache projects to record what work is planned and who is doing it. It allows the project cope with both a rapid cycle of defect fixes and minor enhancements, and with a longer cycle of major refactorings. It is already boring enough to manually update the changelog in our website at each release. Yes that is a painful task, but this is not the same thing, it isn't about what has changed but about everyone being able to record what they are working on and what state it is in. It can make planning releases much easier. I've added this point because Noel and Vincenzo brought this as an important point in the 2.4 roadmap discussion. I personally don't care of config.xml compatibility: I was just reporting what I understood was important (and feasible) to the PMC. Fair enough, in that case I direct my point to Noel and Vincezo ;-) Well, don't take me wrong: I never intended to stop you from working on this. If you have the time and will to do that then feel free to start some proposal (either with code or discussion as you prefer). I just would avoid starting discussions on things that have no champion to do the concrete work at the end because I'm running short in time and I prefer to concentrate on things that I already thought in past. Oh no! I wasn't suggesting that anyone other than me do this, and yes I'll propose it in more detail first. The problem is that it results in a major release (because the API changes) and this can mess up the schedule of defect and minor enhancement releases. I admit I didn't think to mailet apis too much but I did this in past and I wrote something (also in the mailet-api list) and it seems we (all) have really different ideas about the next mailet apis, so I decided to avoid the topic to concentrate on something simpler. OK, I agree that we have different ideas, I would hope to show that mine is just a normalising refactoring and doesn't conflict with any API enhancements others may have in mind. Maybe someone receiving less vetoes to proposals ;-) will be more likely to do this step. Ha! :-D :-D As I said we probably don't agree on the future of the mailet apis ;-) Beside joking, I believe that now that we are here we should wait to find a good solution to services to be provided to handlers plugins and maybe the same patterns could be used in the next mailet. +1 I agree, I'm not suggesting that the mailet changes be released quickly, just that work could start soon. I simply thought at this roadmap because I thought it was convenient: unfortunately the time is really much less than what I would like to do on James. I know, I'm just using this opportunity to put my cards on the table again. Btw you shouldn't fear me: I rerely use vetoes and always prefer an average/partial solution to no solution. And I would be really happy to see some new concrete effort by less active committers! I've been very busy for a long time now, but I'm finding more opportunities now, and I'm keen to re-start where I left off, which was looking at vhosting and a mailet API SDK (which requires some small chages to the API as an enabler). Ok, so if we let pop3 users to have the @domain and we add to the pop3server a configuration for a default domain to be used when no domain is passed would solve both issues, right? Right. Now if we want to bind the pop3server to multiple IPs we have to declare multiple pop3server blocks anyway: is this right? Right. All we need to do is to allow the pop3server blocks to take the repository as a config param. and to let the local delivery mailet do the same thing. Well, ToMultiRepository try first to retrieve the user inbox via MailServer.getUserInbox method. IIRC it shouldn't be so hard to isolate also this method in the new services we added lately. Agree. I'll try to remember this the next time I'll review the code about this issue. Thanks Well thats true to some extent. but only if you accept that your proposal is enough and as far as we'd want to go. I accept this ;-) :-D :-D. You can read more at the end of this comment: https://issues.apache.org/jira/browse/JAMES-414#action_12322582 Problem accessing this just now
Re: JAMES v2.4 Road Map (Status Update)
Danny Angus wrote: Hi Stefano, Thanks for your detailed reply, I hope my comments below will reassure you that I'm not proposing anything radical, just a slightly more visible planning process, and some small refactorings. I also hope that we're beginning to reach a common understanding of what James project is lacking and how to take the next step from having tactical (I don't want to pretend you are stupid, but I know that English is not everyone's best language, tactical means short term) decision making towards strategic (means long term). Thank you for remembering this! I splitted this reply in 4 because we have too much things in the same thread. For virtual hosting and status file I branched the topic on server-dev, while for maielt apis discussion I branched to the mailet-api list! http://mail-archives.apache.org/mod_mbox/james-mailet-api/ On 10/24/06, Stefano Bagnara [EMAIL PROTECTED] wrote: I tried for more than an year to do some bigger planning and bigger changes but I failed. I know, and I think that the problem for some people was that the proposals involved a lot of change, and the discussions went into a lot of detail and moved very quickly. I'm suggesting that one way to get these things agreed may be to record the proposals (on the wiki?) discuss them here and revise them then vote them into the status file where they are officially recorded, rather than record discuss and vote all in one mail thread. IIRC Many of your high level proposals were rejected because whilst people agreed with the high level, and many aspects of the detail it was only one or two aspects of the detail which put people off. Separating the high level proposal from the detailed design of its implementation might allow more things to be agreed in principle, and then we can delay arguing over details until we are ready to implement the details, by which time we may be clearer about what is required and what is achievable. Do you see what I mean? I'm not a fan of WIKIs, and the fact that there are already a lot of outdated proposals there make me fear. Btw I can live with WIKIs too, so if you think using wiki give us a better workflow we can give it a try (as a sidenote I would prefer confluence over the current wiki). About Wiki I saw that felix, directory and geronimo projects started using Confluence also for their website creation: they use confluence to edit the structure and then export it statically to update the official website. I think that if we want to re-introduce wiki in the james project it would be cool to solve the website updates problems. If I understood it there is also a maven2 plugin to include in the website generation pages retrieved from confluence. Unfortunately there is no such facility for MoinMoin. I personally don't have a fixed roadmap: it depends on my mood and sometimes on what features my clients are willing to pay me for ;-) but I always try to keep trunk consistent and to commit things only when I know I can finish it. Thats the right approach, and (if you don't mind me saying so) one of several reasons that your contributions have been such a sucess, which in turn has encouraged others to become more involved. d. Feel free to say this as many times as you can ;-) Stefano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JAMES v2.4 Road Map (Status Update)
Vincenzo Gianferrari Pini wrote: Danny Angus wrote: On 10/24/06, Stefano Bagnara [EMAIL PROTECTED] wrote: I've added this point because Noel and Vincenzo brought this as an important point in the 2.4 roadmap discussion. I personally don't care of config.xml compatibility: I was just reporting what I understood was important (and feasible) to the PMC. Fair enough, in that case I direct my point to Noel and Vincezo ;-) We just stressed the fact that life must be kept as much as possible easy for users when upgrading to new release, otherwise they may stay behind. Regarding configurations, this goal can be achieved either keeping as much as possible backward compatibility for existing features, either providing (safe and thoroughly tested) conversion tools. But we have to be aware that slowly adding small configuration incompatibilities can sum up to require complex conversion tools, that nobody would develop and would become a bottleneck when releasing a new version. Open Source Communities can create better and smarter software than Commercial Companies, but the latter normally care more of existing dumb users: we should always try to reach a good compromise ;-) . Vincenzo Well, I won't write conversion tools, so I preferred to remember your ideas/suggestions when I thought at the proposed roadmap. I personally prefer a new feature that break backward compatibility than no new feature but we have a lot of stuff that can be done without breaking backward compatibility. I simply pointed out that what Noel and Vincenzo proposed to release was already breaking assembly.xml compatiblity so only could try to achieve config.xml compatibility (and storage compatibility) and at least Norman and I always think at this issue when we implement/test new features. I'm sure most of you already know this, but I rewrite it again for Danny: my idea was that storage compatibility would have been enough, with no conversion tools (that's what we did with 2.2.0 to 2.3.0), but we are a community and I'm not as fanatic as someone could think. Stefano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JAMES v2.4 Road Map (Status Update)
Danny Angus wrote: Right, and thats the right thing to do. If everyone adds their own thing to a list (the status file?) we can see what everyone is capable of achieving, and outline the contents of planned releases without having to comit to dates. Releases need to be roughly planned for major and minor cycles to prevent major changes from blocking defect fixes. I just saw that you didn't partecipate to this thread 1 month ago. You should read it and maybe add your comments: http://www.mail-archive.com/search?l=server-dev%40james.apache.orgq=JAMES+v2.4+Road+Map I say this because I see you're asking for roadmaps, for issue list, for discussions about that. I think that if you read the whole thread you will notice that I tried to do this already 1 month ago. We saw 2 different approaches, they was not one against the other but simply 2 road maps. You can find many messages from me with no replies... It was clear that I, Norman and Bernd shared a common goal, so we simply started working on this one. Stefano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JAMES v2.4 Road Map (Status Update)
Hi Danny, something to say .. Danny Angus schrieb: Hi Stefano, Thanks for your detailed reply, I hope my comments below will reassure you that I'm not proposing anything radical, just a slightly more visible planning process, and some small refactorings. I also hope that we're beginning to reach a common understanding of what James project is lacking and how to take the next step from having tactical (I don't want to pretend you are stupid, but I know that English is not everyone's best language, tactical means short term) decision making towards strategic (means long term). On 10/24/06, Stefano Bagnara [EMAIL PROTECTED] wrote: I'm happy enough with what JIRA roadmaps give us. I don't know what exactly you mean with status file but I would not like having more pieces to mantain. the STATUS file is a mechanism used by Apache projects to record what work is planned and who is doing it. It allows the project cope with both a rapid cycle of defect fixes and minor enhancements, and with a longer cycle of major refactorings. We can test it but i aspect not much of it.. Anyway i will be happy if im wrong. It is already boring enough to manually update the changelog in our website at each release. Yes that is a painful task, but this is not the same thing, it isn't about what has changed but about everyone being able to record what they are working on and what state it is in. It can make planning releases much easier. I've added this point because Noel and Vincenzo brought this as an important point in the 2.4 roadmap discussion. I personally don't care of config.xml compatibility: I was just reporting what I understood was important (and feasible) to the PMC. Fair enough, in that case I direct my point to Noel and Vincezo ;-) Well, don't take me wrong: I never intended to stop you from working on this. If you have the time and will to do that then feel free to start some proposal (either with code or discussion as you prefer). I just would avoid starting discussions on things that have no champion to do the concrete work at the end because I'm running short in time and I prefer to concentrate on things that I already thought in past. Oh no! I wasn't suggesting that anyone other than me do this, and yes I'll propose it in more detail first. The problem is that it results in a major release (because the API changes) and this can mess up the schedule of defect and minor enhancement releases. I lookin forward to this... Please go ahead. I admit I didn't think to mailet apis too much but I did this in past and I wrote something (also in the mailet-api list) and it seems we (all) have really different ideas about the next mailet apis, so I decided to avoid the topic to concentrate on something simpler. OK, I agree that we have different ideas, I would hope to show that mine is just a normalising refactoring and doesn't conflict with any API enhancements others may have in mind. We should just find a good solution to lookup Services without bundle the mailets to tight to james. If i understand it right then the mailets should work without james.. Maybe someone receiving less vetoes to proposals ;-) will be more likely to do this step. Ha! :-D :-D Maybe i should try .. I'm everyones most loved guy :-P As I said we probably don't agree on the future of the mailet apis ;-) Beside joking, I believe that now that we are here we should wait to find a good solution to services to be provided to handlers plugins and maybe the same patterns could be used in the next mailet. +1 I agree, I'm not suggesting that the mailet changes be released quickly, just that work could start soon. I simply thought at this roadmap because I thought it was convenient: unfortunately the time is really much less than what I would like to do on James. I know, I'm just using this opportunity to put my cards on the table again. Btw you shouldn't fear me: I rerely use vetoes and always prefer an average/partial solution to no solution. And I would be really happy to see some new concrete effort by less active committers! I've been very busy for a long time now, but I'm finding more opportunities now, and I'm keen to re-start where I left off, which was looking at vhosting and a mailet API SDK (which requires some small chages to the API as an enabler). Im happy to hear. Ok, so if we let pop3 users to have the @domain and we add to the pop3server a configuration for a default domain to be used when no domain is passed would solve both issues, right? Right. I think thats a very good solution and should also fix noels -1 . Now if we want to bind the pop3server to multiple IPs we have to declare multiple pop3server blocks anyway: is this right? Right. All we need to do is to allow the pop3server blocks to take the repository as a config param. and to let the local delivery mailet do the same thing. I think thats cool.. but i don't see so
Re: JAMES v2.4 Road Map (Status Update)
Vincenzo Gianferrari Pini schrieb: Danny Angus wrote: On 10/24/06, Stefano Bagnara [EMAIL PROTECTED] wrote: I've added this point because Noel and Vincenzo brought this as an important point in the 2.4 roadmap discussion. I personally don't care of config.xml compatibility: I was just reporting what I understood was important (and feasible) to the PMC. Fair enough, in that case I direct my point to Noel and Vincezo ;-) We just stressed the fact that life must be kept as much as possible easy for users when upgrading to new release, otherwise they may stay behind. Regarding configurations, this goal can be achieved either keeping as much as possible backward compatibility for existing features, either providing (safe and thoroughly tested) conversion tools. But we have to be aware that slowly adding small configuration incompatibilities can sum up to require complex conversion tools, that nobody would develop and would become a bottleneck when releasing a new version. Open Source Communities can create better and smarter software than Commercial Companies, but the latter normally care more of existing dumb users: we should always try to reach a good compromise ;-) . Vincenzo Thats right but with no new features we will loose users and not get new.. I think we just need to document what to change in config.xml. I allready add an UPGRADING.txt to the 2.3 branch. If we add some new feature which need things the get changed in config.xml we just should document it in a UPGRADING.txt bye Norman - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JAMES v2.4 Road Map (Status Update)
Vincenzo Gianferrari Pini wrote: Norman Maurer wrote: Vincenzo Gianferrari Pini schrieb: Danny Angus wrote: On 10/24/06, Stefano Bagnara [EMAIL PROTECTED] wrote: I've added this point because Noel and Vincenzo brought this as an important point in the 2.4 roadmap discussion. I personally don't care of config.xml compatibility: I was just reporting what I understood was important (and feasible) to the PMC. Fair enough, in that case I direct my point to Noel and Vincezo ;-) We just stressed the fact that life must be kept as much as possible easy for users when upgrading to new release, otherwise they may stay behind. Regarding configurations, this goal can be achieved either keeping as much as possible backward compatibility for existing features, either providing (safe and thoroughly tested) conversion tools. But we have to be aware that slowly adding small configuration incompatibilities can sum up to require complex conversion tools, that nobody would develop and would become a bottleneck when releasing a new version. Open Source Communities can create better and smarter software than Commercial Companies, but the latter normally care more of existing dumb users: we should always try to reach a good compromise ;-) . Vincenzo Thats right but with no new features we will loose users and not get new.. I think we just need to document what to change in config.xml. I allready add an UPGRADING.txt to the 2.3 branch. If we add some new feature which need things the get changed in config.xml we just should document it in a UPGRADING.txt The right thing to do would be to keep UPGRADING.txt up to date *as soon as the related code change is done*, so the documentation is fresh and rich. Doing it just before releasing would be less effective, because things tend to be forgotten :-) . Vincenzo Absolutely. This is why in my commercial endeavours we consider the upgrade code to be a vital part of the core product and subject to the same testing regime as all other code. It isn't an after thought, its a selling point. Something that allows our customers to easily buy into new versions, which earns us revenue, which keeps me in a job. While James doesn't have the same commercial drivers, we will lose users and kudos if we do not provide a smooth migration path between releases. Cheers -- Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JAMES v2.4 Road Map (Status Update)
Stefano Bagnara wrote: I think that the solution I found out-there to provide easy out-of-the-box v hosting support is to put [EMAIL PROTECTED] into the UsersRepository and change LocalDelivery (ToMultiRepository) to use the full recipient instead of the recipient.getName() when retrieving the mailbox. In POP3 people would have to use [EMAIL PROTECTED] as login and no more user. -1 Unacceptable solution to break everyone's mailboxes in order to implement an unnecessary feature. At most, we could allow [EMAIL PROTECTED] as a valid mailbox identity. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JAMES v2.4 Road Map (Status Update)
On 10/21/06, Stefano Bagnara [EMAIL PROTECTED] wrote: Can we consider timetabling some other changes now that we've made such good progress? Well, I think important things are: 1) don't delay the next release cycle once we added the features we planned (and currenlty the only missing big piece is handlerapi, imho) I think perhaps its time we moved to having a status file. 2) don't break the storage compatibility and the config.xml compatibility (I think we currenlty kept both compatibilities). Not sure why you're so keen on this as one of only two things. Yes this is important to end users for ease of upgrade, but it isn't sacred. Tools can be provided to migrate content and configuration if necessary. Rewriting mailet apis is not a simple task and I think it does not belong to a short timed release like the one we're trying to do. Maybe the following one. Yeah I figured. Same as always ;-) I think that mailet api changes will need much more efforts and thoughts and I think we should better delay this to a point where currenct active committers will have a better overall overview of what services mailets needs and how to try to fix this. Well current active commiters are not everyone, there are still some of us less active people who know and understand the API, what it can be used for, and how it should be written. and whats more we also know and understand its weaknesses and flaws.This work needs to be done, and has been needed for a long time. It will have little effect on James's mailets. Furthermore I think we should better wait to have a clean handlerapi structure because we should try to find a common way to access some of the services offered by the container from in-protocol handlers and from mailets. Not sure I agree, unless the handlerapi is being proposed for adding to mailet. Theres no reason why the same services shouldn't be available in different ways, its just a case of wrapping and decorating things. I don't understand the nameing convetion v hosting thing: SMTP and POP3 servers do not receive informations on the name used to reach them, but only the IP used. Yeah, correct. But people keep proposing that POP3 vhosting involve people logging in with [EMAIL PROTECTED] or some other work-around. this *is* name based vhosting for pop3, the name is derived from the log-in, you propose such a solution youself below. The other option is to bind certain domains to certain IP addresses in the same James instance. I think that the solution I found out-there to provide easy out-of-the-box v hosting support is to put [EMAIL PROTECTED] into the UsersRepository and change LocalDelivery (ToMultiRepository) to use the full recipient instead of the recipient.getName() when retrieving the mailbox. That locks you into using one repository, I'm proposing that a different repository can be used per host and that hosts can be distinguished by either IP address or naming convention. In POP3 people would have to use [EMAIL PROTECTED] as login and no more user. Unless you used IP based Vhosting. We should also add DomainList service from the UsersRepository so that James would automatically know what are the local domains by looking the domains used in the UsersRepository names. Yeah, not 100% sure it would work for all scenarios, but it would be worth the effort to do the analysis. This should be relatively easy to be implemented now that we isolated most of the services in few clean interfaces. If my memory is right the only missing piece for this scenario is to enhance the ToMultiRepository to let it use some parameter to define the repository name. Well thats true to some extent. but only if you accept that your proposal is enough and as far as we'd want to go. You can read more at the end of this comment: https://issues.apache.org/jira/browse/JAMES-414#action_12322582 Problem accessing this just now :-( Imho the key is to split every big task in many small tasks because everyone here fear major changes so we should analyze the big goal (that's why I ask you the concrete goal) and find out if we can do this with small steps. Yeah OK, but it is necessary to catalogue our goals and do some planning. Otherwise we get into a rut of making small changes all the time with no longer term plan. Unfortunately there are things that cannot be splitted in small tasks and we have to delay: I have full DSN support for James waiting since almost 2 years to be included because it needs a lot of changes in the core of james and I don't have enough will and time to explain why every change is needed so I gave up including it. We'll perhaps the time is right for us to start to perpare some proper plans. and a proper timetable of releases. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JAMES v2.4 Road Map (Status Update)
On 10/21/06, Norman Maurer [EMAIL PROTECTED] wrote: In POP3 people would have to use [EMAIL PROTECTED] as login and no more user. Thats exactly what i whould like to see as next steps.. The path of the mailboxes should also switch then to : /var/mail/domain/user The enabling/disabling should be configurable to allow backwards compatiblity. Disabled by default Yeah, no disagreement about the paths, I just don't think it needs to be tied to a specific naming convention for user log-ins. I think we should think about adding DSN for the next release which break the compatiblity.. I think we should be looking at our planning process. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JAMES v2.4 Road Map (Status Update)
Danny Angus wrote: On 10/21/06, Stefano Bagnara [EMAIL PROTECTED] wrote: Can we consider timetabling some other changes now that we've made such good progress? Well, I think important things are: 1) don't delay the next release cycle once we added the features we planned (and currenlty the only missing big piece is handlerapi, imho) I think perhaps its time we moved to having a status file. I'm happy enough with what JIRA roadmaps give us. I don't know what exactly you mean with status file but I would not like having more pieces to mantain. It is already boring enough to manually update the changelog in our website at each release. 2) don't break the storage compatibility and the config.xml compatibility (I think we currenlty kept both compatibilities). Not sure why you're so keen on this as one of only two things. Yes this is important to end users for ease of upgrade, but it isn't sacred. Tools can be provided to migrate content and configuration if necessary. I've added this point because Noel and Vincenzo brought this as an important point in the 2.4 roadmap discussion. I personally don't care of config.xml compatibility: I was just reporting what I understood was important (and feasible) to the PMC. Rewriting mailet apis is not a simple task and I think it does not belong to a short timed release like the one we're trying to do. Maybe the following one. Yeah I figured. Same as always ;-) I think that mailet api changes will need much more efforts and thoughts and I think we should better delay this to a point where currenct active committers will have a better overall overview of what services mailets needs and how to try to fix this. Well current active commiters are not everyone, there are still some of us less active people who know and understand the API, what it can be used for, and how it should be written. and whats more we also know and understand its weaknesses and flaws.This work needs to be done, and has been needed for a long time. It will have little effect on James's mailets. Well, don't take me wrong: I never intended to stop you from working on this. If you have the time and will to do that then feel free to start some proposal (either with code or discussion as you prefer). I just would avoid starting discussions on things that have no champion to do the concrete work at the end because I'm running short in time and I prefer to concentrate on things that I already thought in past. I admit I didn't think to mailet apis too much but I did this in past and I wrote something (also in the mailet-api list) and it seems we (all) have really different ideas about the next mailet apis, so I decided to avoid the topic to concentrate on something simpler. Maybe someone receiving less vetoes to proposals ;-) will be more likely to do this step. Furthermore I think we should better wait to have a clean handlerapi structure because we should try to find a common way to access some of the services offered by the container from in-protocol handlers and from mailets. Not sure I agree, unless the handlerapi is being proposed for adding to mailet. Theres no reason why the same services shouldn't be available in different ways, its just a case of wrapping and decorating things. As I said we probably don't agree on the future of the mailet apis ;-) Beside joking, I believe that now that we are here we should wait to find a good solution to services to be provided to handlers plugins and maybe the same patterns could be used in the next mailet. I simply thought at this roadmap because I thought it was convenient: unfortunately the time is really much less than what I would like to do on James. Btw you shouldn't fear me: I rerely use vetoes and always prefer an average/partial solution to no solution. And I would be really happy to see some new concrete effort by less active committers! I don't understand the nameing convetion v hosting thing: SMTP and POP3 servers do not receive informations on the name used to reach them, but only the IP used. Yeah, correct. But people keep proposing that POP3 vhosting involve people logging in with [EMAIL PROTECTED] or some other work-around. this *is* name based vhosting for pop3, the name is derived from the log-in, you propose such a solution youself below. The other option is to bind certain domains to certain IP addresses in the same James instance. Ok, so if we let pop3 users to have the @domain and we add to the pop3server a configuration for a default domain to be used when no domain is passed would solve both issues, right? Now if we want to bind the pop3server to multiple IPs we have to declare multiple pop3server blocks anyway: is this right? I think that the solution I found out-there to provide easy out-of-the-box v hosting support is to put [EMAIL PROTECTED] into the UsersRepository and change LocalDelivery (ToMultiRepository) to use the full recipient instead of the
Re: JAMES v2.4 Road Map (Status Update)
Danny Angus wrote: On 10/20/06, Stefano Bagnara [EMAIL PROTECTED] wrote: Slightly more than a month ago I wrote a roadmap, here is an update for people that has not time for a day to day oversight. Thanks Stefano ;-) Can we consider timetabling some other changes now that we've made such good progress? Well, I think important things are: 1) don't delay the next release cycle once we added the features we planned (and currenlty the only missing big piece is handlerapi, imho) 2) don't break the storage compatibility and the config.xml compatibility (I think we currenlty kept both compatibilities). 1/ One thing I have been trying to get on the table for a couple of years(!) now is a re-write of the mailet API. We need to make the API support *all* of the functions required by Mailets and a Mailet container. This means for example that amongst other smaller stuff some of the service interfaces for repositories need to be sorted and refactored into the API Rewriting mailet apis is not a simple task and I think it does not belong to a short timed release like the one we're trying to do. Maybe the following one. I think that mailet api changes will need much more efforts and thoughts and I think we should better delay this to a point where currenct active committers will have a better overall overview of what services mailets needs and how to try to fix this. Furthermore I think we should better wait to have a clean handlerapi structure because we should try to find a common way to access some of the services offered by the container from in-protocol handlers and from mailets. 2/ Another thing I'd like to do would be to sort out IP based v hosting and nameing convetion v hosting. Effectively certain per-instance things, like the local repository, become per-vhost, and local delivery gets to take the name of the repo as a param. ? d. I think that we already did the bigger steps to make this possible. Now it should be easy to alter the services to have a better support for virtualhosting. Can you elaborate some concrete solution? I don't understand the nameing convetion v hosting thing: SMTP and POP3 servers do not receive informations on the name used to reach them, but only the IP used. I think that the solution I found out-there to provide easy out-of-the-box v hosting support is to put [EMAIL PROTECTED] into the UsersRepository and change LocalDelivery (ToMultiRepository) to use the full recipient instead of the recipient.getName() when retrieving the mailbox. In POP3 people would have to use [EMAIL PROTECTED] as login and no more user. We should also add DomainList service from the UsersRepository so that James would automatically know what are the local domains by looking the domains used in the UsersRepository names. This should be relatively easy to be implemented now that we isolated most of the services in few clean interfaces. If my memory is right the only missing piece for this scenario is to enhance the ToMultiRepository to let it use some parameter to define the repository name. You can read more at the end of this comment: https://issues.apache.org/jira/browse/JAMES-414#action_12322582 Imho the key is to split every big task in many small tasks because everyone here fear major changes so we should analyze the big goal (that's why I ask you the concrete goal) and find out if we can do this with small steps. Unfortunately there are things that cannot be splitted in small tasks and we have to delay: I have full DSN support for James waiting since almost 2 years to be included because it needs a lot of changes in the core of james and I don't have enough will and time to explain why every change is needed so I gave up including it. Stefano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JAMES v2.4 Road Map (Status Update)
Stefano Bagnara schrieb: Danny Angus wrote: On 10/20/06, Stefano Bagnara [EMAIL PROTECTED] wrote: Slightly more than a month ago I wrote a roadmap, here is an update for people that has not time for a day to day oversight. Thanks Stefano ;-) Can we consider timetabling some other changes now that we've made such good progress? Well, I think important things are: 1) don't delay the next release cycle once we added the features we planned (and currenlty the only missing big piece is handlerapi, imho) 2) don't break the storage compatibility and the config.xml compatibility (I think we currenlty kept both compatibilities). 1/ One thing I have been trying to get on the table for a couple of years(!) now is a re-write of the mailet API. We need to make the API support *all* of the functions required by Mailets and a Mailet container. This means for example that amongst other smaller stuff some of the service interfaces for repositories need to be sorted and refactored into the API Rewriting mailet apis is not a simple task and I think it does not belong to a short timed release like the one we're trying to do. Maybe the following one. I think that mailet api changes will need much more efforts and thoughts and I think we should better delay this to a point where currenct active committers will have a better overall overview of what services mailets needs and how to try to fix this. Furthermore I think we should better wait to have a clean handlerapi structure because we should try to find a common way to access some of the services offered by the container from in-protocol handlers and from mailets. +1 2/ Another thing I'd like to do would be to sort out IP based v hosting and nameing convetion v hosting. Effectively certain per-instance things, like the local repository, become per-vhost, and local delivery gets to take the name of the repo as a param. ? d. I think that we already did the bigger steps to make this possible. Now it should be easy to alter the services to have a better support for virtualhosting. Can you elaborate some concrete solution? I don't understand the nameing convetion v hosting thing: SMTP and POP3 servers do not receive informations on the name used to reach them, but only the IP used. I think that the solution I found out-there to provide easy out-of-the-box v hosting support is to put [EMAIL PROTECTED] into the UsersRepository and change LocalDelivery (ToMultiRepository) to use the full recipient instead of the recipient.getName() when retrieving the mailbox. In POP3 people would have to use [EMAIL PROTECTED] as login and no more user. Thats exactly what i whould like to see as next steps.. The path of the mailboxes should also switch then to : /var/mail/domain/user The enabling/disabling should be configurable to allow backwards compatiblity. Disabled by default We should also add DomainList service from the UsersRepository so that James would automatically know what are the local domains by looking the domains used in the UsersRepository names. +1 This should be relatively easy to be implemented now that we isolated most of the services in few clean interfaces. If my memory is right the only missing piece for this scenario is to enhance the ToMultiRepository to let it use some parameter to define the repository name. The my comment above.. You can read more at the end of this comment: https://issues.apache.org/jira/browse/JAMES-414#action_12322582 Imho the key is to split every big task in many small tasks because everyone here fear major changes so we should analyze the big goal (that's why I ask you the concrete goal) and find out if we can do this with small steps. +1 Unfortunately there are things that cannot be splitted in small tasks and we have to delay: I have full DSN support for James waiting since almost 2 years to be included because it needs a lot of changes in the core of james and I don't have enough will and time to explain why every change is needed so I gave up including it. Stefano I think we should think about adding DSN for the next release which break the compatiblity.. bye Norman - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JAMES v2.4 Road Map (Status Update)
Slightly more than a month ago I wrote a roadmap, here is an update for people that has not time for a day to day oversight. Stefano Bagnara wrote: Norman Maurer wrote: 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. Well, this was already there ;-) - JAMES-426 - Make james use virtual user table domains for servernames This is done. - JAMES-52 - 8bitmime capabilities missing It seems that javamail 1.4.1ea fixed the problem and we reenabled the support for it! - JAMES-487 - Refactor Bundled handlers to use the HandlerChain pattern This is blocked by the handlerapi work in sandbox. - JAMES-577 - Switch default sendpartial to true for RemoteDelivery Done. - JAMES-607 - Rewrite MBoxMailRepository to use mstor We wrote the support for this: Joachim found 3 blocking bugs in mstor. 2 of them have been fixed, so as soon as mstor will fix the third and make a release this will be fixed. - JAMES-611 - Remove finalizers and make sure we always call dispose when unreferencing objects Done. - JAMES-461 - Javamail Store based MailRepository support (was: Maildir support) Joachim contributed this. Applied. - JAMES-614 - Add more actions to FastFailHandlers In progress: Norman is working on this. - JAMES-549 - Refactoring SMTPHandler to allow better integration of more the one class per command Blocked by the new handlerapi in sandbox. - JAMES-599 - BeanShell Scripting in James Code has been provided by Guillermo. We should probably vote to decide wethere to include this or not. I wrote a message in past to understand wether there was preference for this BeanShell solution or on the BSF mailet: I would like to see the BSF mailet code before deciding, but I can't find it. - JAMES-562 - Aliasmanagment should not depend on a user (see as VUT-UsersAliasingForwarding common interface and remove tightly dependencies between James and JamesUser) Almost done. - JAMES-595 - Change names of release artifacts to use james-server instead of james. Open (but easy to do). That said, currenlty blocking issues are: 1) dnsjava 2.0.3 release (to support JSPF) (we are currenlty including a snapshot of dnsjava trunk) 2) javamail 1.4.1 release (8bitmime bugs) (we are currenlty including 1.4.1ea-SNAPSHOT from their m2 repository) 3) mstor release (to replace internal mbox management with mstor) (2 of 3 bugs have been fixed in cvs, so we should be able soon to include a working snapshot or the fixed release) 4) handlerapi v2. (If I understood it right, Noel is almost ready with his work) I think that if we can comlpete the handlerapi stuff soon we could realistically consider branching for a release at the start of december (almost a month before what was in the plans) Stefano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JAMES v2.4 Road Map (Status Update)
On 10/20/06, Stefano Bagnara [EMAIL PROTECTED] wrote: Slightly more than a month ago I wrote a roadmap, here is an update for people that has not time for a day to day oversight. Thanks Stefano ;-) Can we consider timetabling some other changes now that we've made such good progress? 1/ One thing I have been trying to get on the table for a couple of years(!) now is a re-write of the mailet API. We need to make the API support *all* of the functions required by Mailets and a Mailet container. This means for example that amongst other smaller stuff some of the service interfaces for repositories need to be sorted and refactored into the API 2/ Another thing I'd like to do would be to sort out IP based v hosting and nameing convetion v hosting. Effectively certain per-instance things, like the local repository, become per-vhost, and local delivery gets to take the name of the repo as a param. ? d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JAMES v2.4 Road Map
Stefano Bagnara wrote: Vincenzo Gianferrari Pini wrote: Yes, but we already used a different scheme for 2.1, 2.2 and 2.3.. so why change it for 2.4? Because IMHO it was wrong :-) . Ok, What I'm trying to say that consistency helps understanding: if you change the rules in the middle you don't help people. And if you really have to change the rule for the next minor why don't we change the yet-to-be-release 2.3? I simply say that imho this discussion does not belong to a 2.4. My intent is to stress that IMO, for our project, a next minor release should not be just a subset of features of a next major release, but that there are some compatibility/ease-of-install/risk differences from the point of view of the user, that could drive/justify one branching strategy or another. The numbering scheme is just a suggestion on how to evidentiate it, but is not the substance :-) . Anyway, I always said that I don't care about the number while discussing, I just care about what we release and when. So we can even talk about the next release and skip the number if this helps (we'll vote the number just before the release). 2.x releases have been storage compatible in past, so I think we can safely put in the 2.x scheme every future storage compatible release and keep 3.0 for bigger steps, but mine is only a +1 vs +0, no vetoes about this meaningless thing: we need code to make releases, not numbers. Not only storage compatible, but also configuration compatible etc. About numbering, it is like naming: helps in stating things. And please breathe a second and take it easy before ironizing and telling other people that they say meaningless things etc. You won't convince anybody this way, you will only put them off. This is not true: 2.x releases have been only storage compatible. I had to upgrade config.xml for evey second-digit step from 2.0 to 2.1.* to 2.2.0 to current 2.3.0rc3. I know. In fact I'm stressing the compatibility/ease-of-install/risk issue (see above) as something to take care of, for our users sake (*we* committers don't have too many problems of this kind). I don't say that what you say is meaningless, I say that numbering is meaningless in a roadmap: a roadmap should include features, maybe dates, but numbers are simply labels used to understand each other. Right. see above. So my proposal is to choose 2 names: one for the release you and Noel are proposing and that will be a branch of 2.3.0 with a few features from trunk to be released before the end of november and the other for the release I and Norman want to work for and to be branched from trunk at start of January 2007 and released in March 2007. I removed the (unused) 2.4 tag from our JIRA and renamed the 3.0 tag to Trunk so that we don't introduce much more confusion. We marked things resolved against 3.0, it is better to say that we resolved them in trunk so we can rename trunk to something else when we'll branch. My fantasy is limited so I would define then next-minor-release and next-major-release (and we could have a next-greater-release for storage incompatibility and other major changes). I think that you can create a new version in jira and call it next-minor and make a list of things you want to merge back in this release. I hope it is fine for you if I won't work on this branch and to agree that this release should not block trunk development or the start of the next-major release. I agree. But, if the next-minor is worth doing, we all need some of your and Norman's help. Otherwise it probably can't be done. I'm not trying to convince anyone, and I'm simply trying to define something that works for me. If you say something that I think is not correct I tell you: this is the way I discuss. I think I worked much more than most of other committers on the James code in the last year so I think that you may not have the same visibility I had on some of the code that has been included in trunk and 2.3 branch, and that's why I write them here. Take into consideration that I will always read and try to understand your point: this doesn't mean I change my ideas easily, but I change them very often (only stupids never change idea). I perfectly know that I don't know perfectly the new code (Socrates teaches ;-) ), and this is the reason why I'm now wary and conservative, and want to be assured and convinced by you (the one that knows the most about the new code) and by Noel (the one that has the widest knowledge of the James code in general) about how sound and feasible and costly and safe is to build the next-minor release (that we all agree that would be worth doing) from the 2.3 branch. And this is the kernel of the discussion going on between you and Noel, that I'm observing to build my final choice. And I would like to hear something from Serge, Danny and the others, because this is going to be a very an important decision. It's more
Re: JAMES v2.4 Road Map
Vincenzo Gianferrari Pini wrote: I think that you can create a new version in jira and call it next-minor and make a list of things you want to merge back in this release. I hope it is fine for you if I won't work on this branch and to agree that this release should not block trunk development or the start of the next-major release. I agree. But, if the next-minor is worth doing, we all need some of your and Norman's help. Otherwise it probably can't be done. I already said that I won't work for the next-minor. At my best I could help you with the website stuff (as I refactored all and maybe I better know the new maven2 site builds), with the maven spf builds (but I need an answer to my repository proposal and if no answer I need Noel to setup the svn notifications so I can really work on james repository) and few other things. I'm not ready to test that releases or to look for bugs in that release. Btw if you find a bug in next-minor and the bug is also in trunk (as when we'll start next-major, next-minor should be already closed), as always, I'll put that on top of my priorities. I'm not trying to convince anyone, and I'm simply trying to define something that works for me. If you say something that I think is not correct I tell you: this is the way I discuss. I think I worked much more than most of other committers on the James code in the last year so I think that you may not have the same visibility I had on some of the code that has been included in trunk and 2.3 branch, and that's why I write them here. Take into consideration that I will always read and try to understand your point: this doesn't mean I change my ideas easily, but I change them very often (only stupids never change idea). I perfectly know that I don't know perfectly the new code (Socrates teaches ;-) ), and this is the reason why I'm now wary and conservative, and want to be assured and convinced by you (the one that knows the most about the new code) and by Noel (the one that has the widest knowledge of the James code in general) about how sound and feasible and costly and safe is to build the next-minor release (that we all agree that would be worth doing) from the 2.3 branch. And this is the kernel of the discussion going on between you and Noel, that I'm observing to build my final choice. I never agreed that it WORTH doing: I said that it would be a good thing to James project and to James users, but I think that it does not worth the efforts and this is the very reason why I say I will work on next-major and not on next-minor. If the efforts are not mine, then I'm really happy with a next-minor release. I think that a +1 should always means I will work for this to happen, and a +0 is it's ok for me but I won't actively help. I'm simply +0 for the next-minor and +1 for the next-major. And I would like to hear something from Serge, Danny and the others, because this is going to be a very an important decision. Well, I always welcome involvement in votes and code, but I think this is not a so big decision: if you fill you can do the next-minor work on it. If it is feasible it will be done, otherwise we have the next-major on the road.. so no big problems either way. It's more than one year that I write to this list, you should have learned that my discussion are a little rude. Don't take it so hard. Ok :-) . But we italians (especially we emiliani and romagnoli) have sometimes to remember that we have sangue caldo ;-) . And the language doesn't help. Right, I'm much more polite (sometimes) when I speak italian. [...] I simply think that with almost the same efforts needed to release 2.3+new improved fastfail (next-minor) we would release the next-major because that one is one of the few things that still deserve much attention. And *this is the key point* :-) . As an alternative approach, what would you think about not backporting the new improved fastfail to 2.3, but instead backporting the new filters (like spf, graylisting etc.) to the old fastfail availble in 2.3? Would it be simpler and safer or not? Maybe Norman has a better overview of this. I always thought and said that fastfail in v2.3 should have not been included or marked as experimental because I know that it was not our final solution and we would have broken backward compatibility later, so I'm not so happy in releasing a new minor release just to improve an experimental feature, but I could leave with it (-0). I really don't know what are the efforts and the risk of backporting the additional filters to the old fastfail pattern. Never thought at this possibility but as a first guess I don't think this is a better approach. I still run heavily modified local branches and my main reason for being a committer to james is reduce my costs to keep them updated by sharing my work with the community: 2.3 has been a failure in my roadmap, I simply can't put more efforts in a
Re: JAMES v2.4 Road Map
On 9/14/06, Norman Maurer [EMAIL PROTECTED] wrote: Vincenzo Gianferrari Pini schrieb: I think that we have different goals and views about what is a minor release, and how it should be reflected in the naming (numbering) scheme. For me (and as I understand also for Noel) a James x.(y+1) release should be a release that (i) comes out after no more than 2-3 months after an x.y release, and (ii) that can be put into production just replacing the james.sar file and maybe adding/replacing/deleting some lib jars, (iii) keeping storage compatibility, (iv) without any need to change either config.xml, assembly.xml etc. and (v) without any database schema changes (btw, IMHO point (iv) is very important). James should be able to restart without problems, and changes to the configuration files should be needed only to activate new functionalities, and such functionalities should have been well tested and reasonably safe and useful. I know that it was not this way in the past, but I feel it should have been, and should be from now on. Based on this definition, 2.3 should have been 3.0 (and what we are calling 3.0 should be 4.0, but let's forget that :-) ). This numbering scheme discussion obviously is useful only to better understand each other, also in the future. So this is how I think 2.4 should be: useful things that deserve and *can* be added to 2.3 in a short time frame, without too much work: very first among others the new fastfail (*if* the without too much work applies). Time driven instead of feature driven for minor releases. Now, how to do that? I think that the only way is through Noel's approach: carefully evolve 2.3 to 2.4, adding at least (at most?) the new fastfail, plus other carefully chosen things. The code from trunk currently would not allow conditions (i), (ii) and (iv) above, and should be used to become 3.0 following Stefano's and Norman's suggested roadmap. And after 3.0, any 3.x probably should evolve from 3.0, and a 4.0 would come out from trunk. Who will do this merge and test it ? I don't think it will be more stable then the code in trunk. For me that make no sense.. Then we have to maintain 3 trees. We are to few developer for that. I share Norman's objections. Maintaining 3 trees will not help us progressing, it will only help stalling the project. For me its: 2.3.x = bugfixes 2.4 = 2.3.x + new features ( compatible) 3.0 = incompatible changes addition: 3.0 = incompatible changes, big new features +1, thats absolutely my take, and my understanding about what is common sense in the industry And I don't think its only a number. It is a means of communication to the user base. Bernd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JAMES v2.4 Road Map
On 9/14/06, Noel J. Bergman [EMAIL PROTECTED] wrote: I will read and reply to the various comments later, but I want to put some figures into the picture. $ du -hs branches/v2.3/src/java trunk/src/java 13M branches/v2.3/src/java 15M trunk/src/java $ svn diff --old=https://svn.apache.org/repos/asf/james/server/branches/v2.3/src/j ava \ --new=https://svn.apache.org/repos/asf/james/server/trunk/src/ja va diff.txt $ ls -l diff.txt -rw-rw-r-- 1 noel noel 2056010 Sep 14 13:19 diff.txt So there are 2MB worth of differences in the Java code between trunk and v2.3. Some of the 2MB are overhead in the diff format, some are license headers, some are refactoring, some are more substantial and functional changes. I am *not* willing to effectively accept blindly changes of roughly 15% (and that's only the current stuff, not including major new development) of a stable codebase. I *am* willing to go through it with everyone, change by change, and decide what is reasonably safe to add in the short term, and what needs much more attention for a later merger. I am having a hard time understanding this. Do you say, that all commits in current trunk since branching have a silent -1 from you? What specific changes do you object? I think there are enough eyeballs constantly monitoring trunk, which does not mean to _release_ it blindly without testing. But having an audit on a commit-per-commit basis makes no sense, since many of them where applied to 2.3 branch anyway. The rest simply has to be tested. This is also the reason for me to propose following our original reasoning when branching 2.3 (read: not 2.x-branch, but 2.3.x-branch): This is the maintainence branch where we apply bugfixes for 2.3.x. Fixes are isolated, well tested and thus a branch is maintainable. Bernd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JAMES v2.4 Road Map
On 9/15/06, Vincenzo Gianferrari Pini [EMAIL PROTECTED] wrote: Stefano Bagnara wrote: Vincenzo Gianferrari Pini wrote: It's more than one year that I write to this list, you should have learned that my discussion are a little rude. Don't take it so hard. Ok :-) . But we italians (especially we emiliani and romagnoli) have sometimes to remember that we have sangue caldo ;-) . And the language doesn't help. :-) ... my salt pot is always right here, just for the grain of salt ;-) everyone reading apache lists has to have one! keep in mind, still not everybody has. Bernd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JAMES v2.4 Road Map
Bernd Fondermann wrote: For me its: 2.3.x = bugfixes 2.4 = 2.3.x + new features ( compatible) 3.0 = incompatible changes addition: 3.0 = incompatible changes, big new features +1, thats absolutely my take, and my understanding about what is common sense in the industry And I don't think its only a number. It is a means of communication to the user base. Bernd When I say that it is only a number and I don't care of the number I mean *NOW* that we are planning a ROADMAP I don't care too much of the numbers. I agree that the number is really important for a release but I think we could simply decide the right number for our marketing purposes just before releasing it. Either way we need a way to talk each others about the different roadmaps/branches, so I thought at the next-minor, next-major labels... I'm trying to reduce the number of things to be discussed now to the minimum so to increase the probability that we come to some agreement on what to do. If anyone want to start a proposal for a new numbering, I suggest to do it as a separated thread, and I will add my ideas and I will vote about it. I already said that I'm not against the numbering proposed by Vincenzo (or your), and we discussed few times about the current 2.3 in terms of 3.0: we finally decided to use the 2.3 number. I think we should have no worry to make proposals and cast our votes. You know I really used few -1 in past, so don't think that every time I have a different idea it means I will veto it. I usually say I would probably veto this if I think I will do that and when I say I don't agree / I have a different idea it means that I will probably vote -0 and propose something alternative. I don't start that proposal now because I already wrote 2 proposals that are awaiting answers or actions by the people with karma so I don't want to put too many things in the in-progress list. Stefano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JAMES v2.4 Road Map
Bernd Fondermann schrieb: On 9/14/06, Noel J. Bergman [EMAIL PROTECTED] wrote: I will read and reply to the various comments later, but I want to put some figures into the picture. $ du -hs branches/v2.3/src/java trunk/src/java 13M branches/v2.3/src/java 15M trunk/src/java $ svn diff --old=https://svn.apache.org/repos/asf/james/server/branches/v2.3/src/j ava \ --new=https://svn.apache.org/repos/asf/james/server/trunk/src/ja va diff.txt $ ls -l diff.txt -rw-rw-r-- 1 noel noel 2056010 Sep 14 13:19 diff.txt So there are 2MB worth of differences in the Java code between trunk and v2.3. Some of the 2MB are overhead in the diff format, some are license headers, some are refactoring, some are more substantial and functional changes. I am *not* willing to effectively accept blindly changes of roughly 15% (and that's only the current stuff, not including major new development) of a stable codebase. I *am* willing to go through it with everyone, change by change, and decide what is reasonably safe to add in the short term, and what needs much more attention for a later merger. I am having a hard time understanding this. Do you say, that all commits in current trunk since branching have a silent -1 from you? What specific changes do you object? I think there are enough eyeballs constantly monitoring trunk, which does not mean to _release_ it blindly without testing. But having an audit on a commit-per-commit basis makes no sense, since many of them where applied to 2.3 branch anyway. The rest simply has to be tested. I fully agree on this. I review every commit. I think every commiter should try todo it. If i see any problems with a commit i whould raise my voice. This is also the reason for me to propose following our original reasoning when branching 2.3 (read: not 2.x-branch, but 2.3.x-branch): This is the maintainence branch where we apply bugfixes for 2.3.x. Fixes are isolated, well tested and thus a branch is maintainable. Bernd Agree.. bye Norman - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JAMES v2.4 Road Map
On 9/15/06, Stefano Bagnara [EMAIL PROTECTED] wrote: Bernd Fondermann wrote: For me its: 2.3.x = bugfixes 2.4 = 2.3.x + new features ( compatible) 3.0 = incompatible changes addition: 3.0 = incompatible changes, big new features +1, thats absolutely my take, and my understanding about what is common sense in the industry And I don't think its only a number. It is a means of communication to the user base. Bernd When I say that it is only a number and I don't care of the number I mean *NOW* that we are planning a ROADMAP I don't care too much of the numbers. I agree that the number is really important for a release but I think we could simply decide the right number for our marketing purposes just before releasing it. Either way we need a way to talk each others about the different roadmaps/branches, so I thought at the next-minor, next-major labels... I'm trying to reduce the number of things to be discussed now to the minimum so to increase the probability that we come to some agreement on what to do. If anyone want to start a proposal for a new numbering, I suggest to do it as a separated thread, and I will add my ideas and I will vote about it. I already said that I'm not against the numbering proposed by Vincenzo (or your), and we discussed few times about the current 2.3 in terms of 3.0: we finally decided to use the 2.3 number. I think we should have no worry to make proposals and cast our votes. You know I really used few -1 in past, so don't think that every time I have a different idea it means I will veto it. I usually say I would probably veto this if I think I will do that and when I say I don't agree / I have a different idea it means that I will probably vote -0 and propose something alternative. ok, sure, fine. what's the point? I don't start that proposal now because I already wrote 2 proposals that are awaiting answers or actions by the people with karma so I don't want to put too many things in the in-progress list. trying to get through to it, but you are writing _lots_ of text, man! that's really eating up my time. Bernd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JAMES v2.4 Road Map
I think that we have different goals and views about what is a minor release, and how it should be reflected in the naming (numbering) scheme. For me (and as I understand also for Noel) a James x.(y+1) release should be a release that (i) comes out after no more than 2-3 months after an x.y release, and (ii) that can be put into production just replacing the james.sar file and maybe adding/replacing/deleting some lib jars, (iii) keeping storage compatibility, (iv) without any need to change either config.xml, assembly.xml etc. and (v) without any database schema changes (btw, IMHO point (iv) is very important). James should be able to restart without problems, and changes to the configuration files should be needed only to activate new functionalities, and such functionalities should have been well tested and reasonably safe and useful. I know that it was not this way in the past, but I feel it should have been, and should be from now on. Based on this definition, 2.3 should have been 3.0 (and what we are calling 3.0 should be 4.0, but let's forget that :-) ). This numbering scheme discussion obviously is useful only to better understand each other, also in the future. So this is how I think 2.4 should be: useful things that deserve and *can* be added to 2.3 in a short time frame, without too much work: very first among others the new fastfail (*if* the without too much work applies). Time driven instead of feature driven for minor releases. Now, how to do that? I think that the only way is through Noel's approach: carefully evolve 2.3 to 2.4, adding at least (at most?) the new fastfail, plus other carefully chosen things. The code from trunk currently would not allow conditions (i), (ii) and (iv) above, and should be used to become 3.0 following Stefano's and Norman's suggested roadmap. And after 3.0, any 3.x probably should evolve from 3.0, and a 4.0 would come out from trunk. So, if the new fastfail is not mature enough, an effort should be put on it to become so in the 2-3 months timeframe. If not possible (but I don't think so), the remaining things may not be enough to justify a 2.4 (unless we have bugs in 2.3 to solve that would force us to build a 2.3.1: -- 2.4 = 2.3 + bug fixes + new features --), and we would have to wait for a 3.0 coming out of trunk when we decide to branch it. Who would do this 2.4 work? We know that *currently* the most active committers are Stefano, Norman and (slightly less Noel), followed by myself and Bernd that are both more oriented to contributions in specific areas (btw more release independent). So Noel and Norman could hopefully concentrate on fastfail and related functionalities, I would work on Bayesian, Crypto (+something else that may come out) , and Bernd on whatever he feels useful, appropriate and possible. And Stefano can concentrate on more long term things for 3.0 and jump into 2.4 when possible. To wrap up, a final consideration: as a James user, I prefer to have *soon* a *few* new and safe functionalities rather than to wait a long time for a lot of new functionalities. But in the long term I want James to evolve ambitiously. I hope all this makes sense :-) . Vincenzo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JAMES v2.4 Road Map
Vincenzo Gianferrari Pini wrote: I think that we have different goals and views about what is a minor release, and how it should be reflected in the naming (numbering) scheme. For me (and as I understand also for Noel) a James x.(y+1) release should be a release that (i) comes out after no more than 2-3 months after an x.y release, and (ii) that can be put into production just replacing the james.sar file and maybe adding/replacing/deleting some lib jars, (iii) keeping storage compatibility, (iv) without any need to change either config.xml, assembly.xml etc. and (v) without any database schema changes (btw, IMHO point (iv) is very important). James should be able to restart without problems, and changes to the configuration files should be needed only to activate new functionalities, and such functionalities should have been well tested and reasonably safe and useful. I know that it was not this way in the past, but I feel it should have been, and should be from now on. Imho this is a point release definition: what I would expect in a 2.3.0 to 2.3.1 upgrade. Based on this definition, 2.3 should have been 3.0 (and what we are calling 3.0 should be 4.0, but let's forget that :-) ). This numbering scheme discussion obviously is useful only to better understand each other, also in the future. Yes, but we already used a different scheme for 2.1, 2.2 and 2.3.. so why change it for 2.4? If you really want to follow this numbering we should renumber the current 2.3.0rc3 to 3.0.0 and not 2.3 and start working on 4.0.0, but as we have 3 numbers, why should we only use the first? Anyway, I always said that I don't care about the number while discussing, I just care about what we release and when. So we can even talk about the next release and skip the number if this helps (we'll vote the number just before the release). 2.x releases have been storage compatible in past, so I think we can safely put in the 2.x scheme every future storage compatible release and keep 3.0 for bigger steps, but mine is only a +1 vs +0, no vetoes about this meaningless thing: we need code to make releases, not numbers. So this is how I think 2.4 should be: useful things that deserve and *can* be added to 2.3 in a short time frame, without too much work: very first among others the new fastfail (*if* the without too much work applies). Time driven instead of feature driven for minor releases. If we take everything we have in trunk now and compare with 2.3 I think that fastfail is one of the few things that cannot be backported as is. As I already wrote we have uncomplete code both in trunk and in an unfinished handlerv2 branch, so it's unfair (imo) to think that merging fastfail to 2.3 is less work or it is safer than releasing current trunk. Furthermore what you define useful is not what others may define useful, so don't be so blind: I did a lot of changes for 2.3 that were not useful for 2.3 itself but now are the basis for the new developments. If I didn't include them in 2.3 we now would have much more code to test for the next release. Now, how to do that? I think that the only way is through Noel's approach: carefully evolve 2.3 to 2.4, adding at least (at most?) the new fastfail, plus other carefully chosen things. The code from trunk currently would not allow conditions (i), (ii) and (iv) above, and should be used to become 3.0 following Stefano's and Norman's suggested roadmap. And after 3.0, any 3.x probably should evolve from 3.0, and a 4.0 would come out from trunk. If this is your conditions then I say let's skip 2.4 (we can't afford it) and work on 3.0 (see my 2.4 proposal and call it 3.0). I don't agree with this change in the numbering (why shouldn't we use the third number ???) but I really don't care now.. We can vote the preferred number the day that we'll have to release. Furthermore I want to let you know that the new fastfail stuff need changes to configuration files and would no allow conditions (ii) and (iv), so using your numbering scheme would not be suitable for 2.4. So, if the new fastfail is not mature enough, an effort should be put on it to become so in the 2-3 months timeframe. If not possible (but I don't think so), the remaining things may not be enough to justify a 2.4 (unless we have bugs in 2.3 to solve that would force us to build a 2.3.1: -- 2.4 = 2.3 + bug fixes + new features --), and we would have to wait for a 3.0 coming out of trunk when we decide to branch it. This matches what Norman and me said, but you simply want to call the next release 3.0 and not 2.4. Who would do this 2.4 work? We know that *currently* the most active committers are Stefano, Norman and (slightly less Noel), followed by myself and Bernd that are both more oriented to contributions in specific areas (btw more release independent). So Noel and Norman could hopefully concentrate on fastfail and related functionalities, I
Re: JAMES v2.4 Road Map
Vincenzo Gianferrari Pini schrieb: I think that we have different goals and views about what is a minor release, and how it should be reflected in the naming (numbering) scheme. For me (and as I understand also for Noel) a James x.(y+1) release should be a release that (i) comes out after no more than 2-3 months after an x.y release, and (ii) that can be put into production just replacing the james.sar file and maybe adding/replacing/deleting some lib jars, (iii) keeping storage compatibility, (iv) without any need to change either config.xml, assembly.xml etc. and (v) without any database schema changes (btw, IMHO point (iv) is very important). James should be able to restart without problems, and changes to the configuration files should be needed only to activate new functionalities, and such functionalities should have been well tested and reasonably safe and useful. I know that it was not this way in the past, but I feel it should have been, and should be from now on. Based on this definition, 2.3 should have been 3.0 (and what we are calling 3.0 should be 4.0, but let's forget that :-) ). This numbering scheme discussion obviously is useful only to better understand each other, also in the future. So this is how I think 2.4 should be: useful things that deserve and *can* be added to 2.3 in a short time frame, without too much work: very first among others the new fastfail (*if* the without too much work applies). Time driven instead of feature driven for minor releases. Now, how to do that? I think that the only way is through Noel's approach: carefully evolve 2.3 to 2.4, adding at least (at most?) the new fastfail, plus other carefully chosen things. The code from trunk currently would not allow conditions (i), (ii) and (iv) above, and should be used to become 3.0 following Stefano's and Norman's suggested roadmap. And after 3.0, any 3.x probably should evolve from 3.0, and a 4.0 would come out from trunk. Who will do this merge and test it ? I don't think it will be more stable then the code in trunk. For me that make no sense.. Then we have to maintain 3 trees. We are to few developer for that. I also see no problems with i - v. If you look at Stefanos list of things todo for 2.4 you will notice that this things will not require such changes. Only for new features like you said.. I think we can do most of the changes in about 6 Month. So a new powerfull release in 6 Month is cool... So why loose time with mergin.. it will take weeks . So, if the new fastfail is not mature enough, an effort should be put on it to become so in the 2-3 months timeframe. If not possible (but I don't think so), the remaining things may not be enough to justify a 2.4 (unless we have bugs in 2.3 to solve that would force us to build a 2.3.1: -- 2.4 = 2.3 + bug fixes + new features --), and we would have to wait for a 3.0 coming out of trunk when we decide to branch it. For me its: 2.3.x = bugfixes 2.4 = 2.3.x + new features ( compatible) 3.0 = incompatible changes Who would do this 2.4 work? We know that *currently* the most active committers are Stefano, Norman and (slightly less Noel), followed by myself and Bernd that are both more oriented to contributions in specific areas (btw more release independent). So Noel and Norman could hopefully concentrate on fastfail and related functionalities, I would work on Bayesian, Crypto (+something else that may come out) , and Bernd on whatever he feels useful, appropriate and possible. And Stefano can concentrate on more long term things for 3.0 and jump into 2.4 when possible. To wrap up, a final consideration: as a James user, I prefer to have *soon* a *few* new and safe functionalities rather than to wait a long time for a lot of new functionalities. But in the long term I want James to evolve ambitiously. I hope all this makes sense :-) . Vincenzo bye Norman - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JAMES v2.4 Road Map
Stefano Bagnara wrote: Vincenzo Gianferrari Pini wrote: I think that we have different goals and views about what is a minor release, and how it should be reflected in the naming (numbering) scheme. For me (and as I understand also for Noel) a James x.(y+1) release should be a release that (i) comes out after no more than 2-3 months after an x.y release, and (ii) that can be put into production just replacing the james.sar file and maybe adding/replacing/deleting some lib jars, (iii) keeping storage compatibility, (iv) without any need to change either config.xml, assembly.xml etc. and (v) without any database schema changes (btw, IMHO point (iv) is very important). James should be able to restart without problems, and changes to the configuration files should be needed only to activate new functionalities, and such functionalities should have been well tested and reasonably safe and useful. I know that it was not this way in the past, but I feel it should have been, and should be from now on. Imho this is a point release definition: what I would expect in a 2.3.0 to 2.3.1 upgrade. Well, I consider a point release a simple bug fixing release, with no new features, as a 2.3.1 would be (possibly not needed). Based on this definition, 2.3 should have been 3.0 (and what we are calling 3.0 should be 4.0, but let's forget that :-) ). This numbering scheme discussion obviously is useful only to better understand each other, also in the future. Yes, but we already used a different scheme for 2.1, 2.2 and 2.3.. so why change it for 2.4? Because IMHO it was wrong :-) . If you really want to follow this numbering we should renumber the current 2.3.0rc3 to 3.0.0 and not 2.3 and start working on 4.0.0, but as we have 3 numbers, why should we only use the first? See above. Anyway, I always said that I don't care about the number while discussing, I just care about what we release and when. So we can even talk about the next release and skip the number if this helps (we'll vote the number just before the release). 2.x releases have been storage compatible in past, so I think we can safely put in the 2.x scheme every future storage compatible release and keep 3.0 for bigger steps, but mine is only a +1 vs +0, no vetoes about this meaningless thing: we need code to make releases, not numbers. Not only storage compatible, but also configuration compatible etc. About numbering, it is like naming: helps in stating things. And please breathe a second and take it easy before ironizing and telling other people that they say meaningless things etc. You won't convince anybody this way, you will only put them off. So this is how I think 2.4 should be: useful things that deserve and *can* be added to 2.3 in a short time frame, without too much work: very first among others the new fastfail (*if* the without too much work applies). Time driven instead of feature driven for minor releases. If we take everything we have in trunk now and compare with 2.3 I think that fastfail is one of the few things that cannot be backported as is. As I already wrote we have uncomplete code both in trunk and in an unfinished handlerv2 branch, so it's unfair (imo) to think that merging fastfail to 2.3 is less work or it is safer than releasing current trunk. I don't say that it can be backported as is. My hope (and I know that I may be wrong) is that it can be backported with some work. And releasing current trunk means releasing the *whole* current trunk. Furthermore what you define useful is not what others may define useful, so don't be so blind: I did a lot of changes for 2.3 that were not useful for 2.3 itself but now are the basis for the new developments. If I didn't include them in 2.3 we now would have much more code to test for the next release. I'm saying *functionally* useful from a James user point of view, not useful for *new development*. But in general you are right. Now, how to do that? I think that the only way is through Noel's approach: carefully evolve 2.3 to 2.4, adding at least (at most?) the new fastfail, plus other carefully chosen things. The code from trunk currently would not allow conditions (i), (ii) and (iv) above, and should be used to become 3.0 following Stefano's and Norman's suggested roadmap. And after 3.0, any 3.x probably should evolve from 3.0, and a 4.0 would come out from trunk. If this is your conditions then I say let's skip 2.4 (we can't afford it) and work on 3.0 (see my 2.4 proposal and call it 3.0). I don't agree with this change in the numbering (why shouldn't we use the third number ???) but I really don't care now.. We can vote the preferred number the day that we'll have to release. The point is timing: I would like to have a sound release come out in 2-3 months, while working in parallel on a major one expected to come out in a longer time frame. And the numbering scheme just expresses
Re: JAMES v2.4 Road Map
Vincenzo Gianferrari Pini wrote: Yes, but we already used a different scheme for 2.1, 2.2 and 2.3.. so why change it for 2.4? Because IMHO it was wrong :-) . Ok, What I'm trying to say that consistency helps understanding: if you change the rules in the middle you don't help people. And if you really have to change the rule for the next minor why don't we change the yet-to-be-release 2.3? I simply say that imho this discussion does not belong to a 2.4. Anyway, I always said that I don't care about the number while discussing, I just care about what we release and when. So we can even talk about the next release and skip the number if this helps (we'll vote the number just before the release). 2.x releases have been storage compatible in past, so I think we can safely put in the 2.x scheme every future storage compatible release and keep 3.0 for bigger steps, but mine is only a +1 vs +0, no vetoes about this meaningless thing: we need code to make releases, not numbers. Not only storage compatible, but also configuration compatible etc. About numbering, it is like naming: helps in stating things. And please breathe a second and take it easy before ironizing and telling other people that they say meaningless things etc. You won't convince anybody this way, you will only put them off. This is not true: 2.x releases have been only storage compatible. I had to upgrade config.xml for evey second-digit step from 2.0 to 2.1.* to 2.2.0 to current 2.3.0rc3. I don't say that what you say is meaningless, I say that numbering is meaningless in a roadmap: a roadmap should include features, maybe dates, but numbers are simply labels used to understand each other. So my proposal is to choose 2 names: one for the release you and Noel are proposing and that will be a branch of 2.3.0 with a few features from trunk to be released before the end of november and the other for the release I and Norman want to work for and to be branched from trunk at start of January 2007 and released in March 2007. I removed the (unused) 2.4 tag from our JIRA and renamed the 3.0 tag to Trunk so that we don't introduce much more confusion. We marked things resolved against 3.0, it is better to say that we resolved them in trunk so we can rename trunk to something else when we'll branch. My fantasy is limited so I would define then next-minor-release and next-major-release (and we could have a next-greater-release for storage incompatibility and other major changes). I think that you can create a new version in jira and call it next-minor and make a list of things you want to merge back in this release. I hope it is fine for you if I won't work on this branch and to agree that this release should not block trunk development or the start of the next-major release. I'm not trying to convince anyone, and I'm simply trying to define something that works for me. If you say something that I think is not correct I tell you: this is the way I discuss. I think I worked much more than most of other committers on the James code in the last year so I think that you may not have the same visibility I had on some of the code that has been included in trunk and 2.3 branch, and that's why I write them here. Take into consideration that I will always read and try to understand your point: this doesn't mean I change my ideas easily, but I change them very often (only stupids never change idea). It's more than one year that I write to this list, you should have learned that my discussion are a little rude. Don't take it so hard. So this is how I think 2.4 should be: useful things that deserve and *can* be added to 2.3 in a short time frame, without too much work: very first among others the new fastfail (*if* the without too much work applies). Time driven instead of feature driven for minor releases. If we take everything we have in trunk now and compare with 2.3 I think that fastfail is one of the few things that cannot be backported as is. As I already wrote we have uncomplete code both in trunk and in an unfinished handlerv2 branch, so it's unfair (imo) to think that merging fastfail to 2.3 is less work or it is safer than releasing current trunk. I don't say that it can be backported as is. My hope (and I know that I may be wrong) is that it can be backported with some work. And releasing current trunk means releasing the *whole* current trunk. I can only repeat my vision of the current trunk: there are a lot of finished things applied to that tree, and only one thing is for sure in-progress and still subject to design analysis. This thing is the fastfail, that is one of the core components of your next-minor release. I simply think that with almost the same efforts needed to release 2.3+new improved fastfail (next-minor) we would release the next-major because that one is one of the few things that still deserve much attention. Btw I don't know the future and I can
RE: JAMES v2.4 Road Map
I will read and reply to the various comments later, but I want to put some figures into the picture. $ du -hs branches/v2.3/src/java trunk/src/java 13M branches/v2.3/src/java 15M trunk/src/java $ svn diff --old=https://svn.apache.org/repos/asf/james/server/branches/v2.3/src/j ava \ --new=https://svn.apache.org/repos/asf/james/server/trunk/src/ja va diff.txt $ ls -l diff.txt -rw-rw-r-- 1 noel noel 2056010 Sep 14 13:19 diff.txt So there are 2MB worth of differences in the Java code between trunk and v2.3. Some of the 2MB are overhead in the diff format, some are license headers, some are refactoring, some are more substantial and functional changes. I am *not* willing to effectively accept blindly changes of roughly 15% (and that's only the current stuff, not including major new development) of a stable codebase. I *am* willing to go through it with everyone, change by change, and decide what is reasonably safe to add in the short term, and what needs much more attention for a later merger. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JAMES v2.4 Road Map
Noel J. Bergman schrieb: I will read and reply to the various comments later, but I want to put some figures into the picture. $ du -hs branches/v2.3/src/java trunk/src/java 13M branches/v2.3/src/java 15M trunk/src/java $ svn diff --old=https://svn.apache.org/repos/asf/james/server/branches/v2.3/src/j ava \ --new=https://svn.apache.org/repos/asf/james/server/trunk/src/ja va diff.txt $ ls -l diff.txt -rw-rw-r-- 1 noel noel 2056010 Sep 14 13:19 diff.txt So there are 2MB worth of differences in the Java code between trunk and v2.3. Some of the 2MB are overhead in the diff format, some are license headers, some are refactoring, some are more substantial and functional changes. I am *not* willing to effectively accept blindly changes of roughly 15% (and that's only the current stuff, not including major new development) of a stable codebase. I *am* willing to go through it with everyone, change by change, and decide what is reasonably safe to add in the short term, and what needs much more attention for a later merger. --- Noel Well you don't need. Like Stefano said.. We can split development. I would focus with stefano on trunk and you and others can do the merge. I will help for sure if any problems raise. bye Norman - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JAMES v2.4 Road Map
Noel J. Bergman wrote: I will read and reply to the various comments later, but I want to put some figures into the picture. [..] $ ls -l diff.txt -rw-rw-r-- 1 noel noel 2056010 Sep 14 13:19 diff.txt So there are 2MB worth of differences in the Java code between trunk and v2.3. Some of the 2MB are overhead in the diff format, some are license headers, some are refactoring, some are more substantial and functional changes. Ante scriptum: This 2MB things MEANS NOTHING to me (if not the RAM leaked by your server :-P ): a. 1MB is the header update patch (svn diff -r426006:426007 https://svn.apache.org/repos/asf/james/server/trunk/src/java diff-license.txt) b. 466K are in the smtpserver package c. Most of other changes are small refactorings (where code has been moved in another class so it creates big diff) and new classes (we added new mailets, and a lot of remotemanager/jmx stuff). As an example 45K of this remaining bytes (almost 10%) are the new mailets I committed 3 days ago: new mailets (even if they may be buggy) are much less dangerous than the fastfail change. That said I hope you now have a better overview of what we are talking about and that you understand that MOST code changes are in the smtpserver package that is the one now under branching/redesign. I am *not* willing to effectively accept blindly changes of roughly 15% (and that's only the current stuff, not including major new development) of a stable codebase. I *am* willing to go through it with everyone, change by change, and decide what is reasonably safe to add in the short term, and what needs much more attention for a later merger. Why blindly? I always check what we commit in trunk: imho trunk is not special. If you never looked at it then feel free to start reviewing it, but the fact that you never looked at it doesn't mean that we did the same. I don't feel blind about trunk: in fact I tried to reproduce in trunk every single bug we found in 2.3 and I always fixed it in trunk before checking wether the solution could be applied to the branch. I'm not ready to start an issue by issue, commit by commit discussion for a next-minor release. I trust your judgement about it, so feel free to do this with Vincenzo and anyone else that want to be part of this selection work. My reply now would be either let's wait, we are not ready to branch or +1 to include every single patch, but we'll need to decide what to do with the 2 handlerchain trees so it doesn't make sense that we work *together* for this. I hope you won't need 2 months to review the 2MB or your roadmap will have some delay (just joking ;-) ), so feel free to review and to add any useful consideration to this thread! Sincerely I suggest you to finish the fastfail/handlerchain stuff before starting this selection work as this is the bigger of the steps in your roadmap and If I understood your roadmap fastfail is the key component of the next-minor release. I hope you will accept the next-minor / next-major proposal and that we are ready to start. Stefano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JAMES v2.4 Road Map
Vincenzo Gianferrari Pini wrote: Furthermore I want to let you know that the new fastfail stuff need changes to configuration files and would no allow conditions (ii) and (iv), so using your numbering scheme would not be suitable for 2.4. My point is (without integralism) to be able to get 2.4, and have my production system run doing the same things as before with no or at least little effort (no or very little changes to configuration) and then, when I'm confortable, start exploiting the new features by changing the configuration files. By little effort I mean also the ability to easily rollback if weird things happen. And you know that going from 2.2 to 2.3 was not simple at all! *If* those things turn out to be impossible, then obviously we will follow your and Norman's roadmap :-) . But *if* it is feasible, as also Noel thinks, this is my choice. As a note, the new fastfail stuff needs also changes to the assembly.xml, so even if the config.xml could be kept compatible this would not be the same for assembly.xml. This is not to say that you don't have to follow that roadmap (as I said I'm happy if you produce an interim release and I don't have to put my efforts for this to happen), but to give you more information on what you can expect to achieve. Stefano -- PS: is weird how having the componet assembly in xml instead of hardcoded in a file is creating incompatibility issues that we wouldn't care of otherwise. We should keep this in mind when/if we'll ever move to another container. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JAMES v2.4 Road Map
Noel J. Bergman wrote: Stefano Bagnara wrote: Noel J. Bergman wrote: As I said long ago, if you want to move trunk to 2.4, we should review every difference. Then, if we agree that each one represents a suitable risk/reward, fine. I'm sorry but (as I also said long ago) I'm on the opposite position about the 2.4 roadmap. So what is your position? That we should simply dump trunk on users without proper review? Without comparing it to what we have spent so long testing and reviewing in the 2.3 branch? ??? I already review and test trunk, we'll start more consolidation as soon as we'll branch: every project and every release works like this. I never thought about a blind tag trunk and make a final release without even building it. 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 think that we need features much more than releases. As I always said we'll loose users if we keep making monthly releases with NO CHANGES. My proposal is to start at least 2 months of free development in trunk and then create the 2.4 branch to start the consolidation process. And if we do it my way, we can release 2.4 in less than 2 months. And work on v3 at the same time. And I want to branch soon, so that we can start working on the major changes that we should be doing for v3, and not just the safe but useful changes for v2.4. Well, let's talk about facts: who is willing to work on your 2.4 as a 2.3 + selective branch? I won't work on it, but if you think you, and other committers will have the time and willing to put out a 2.4 in 2 months without blocking the trunk development we can work on both releases at the same time: 2.4 in 2 month, 2.5 in 6 months. I think that the differences between my roadmap and the Norman roadmap can be removed with few more discussions while your approach is not compatible. Imo trunk is now more safe than any 2.3+selective merge work because both I and Norman tested trunk but no-one tested the merge work. Everything we currently have in trunk deserve inclusion in the next release and much more of this. Wrong. Most of what is in trunk has had a fraction of the review and testing that we have spent on v2.3, and you're talking about a free-for-all of development. Free-for-all? I had flame wars for a fetchmail refactoring and you talk of free-for-all?? 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: Yes, I think that now fastfail is not mature, but working on it for 2-3 more months we can find a good solution: we were simply too busy on 2.3 to work on fastfail stabilization. Many new things have been written in the fastfail package and I still have to test them. Your 2 months roadmap is simply not concrete to me: we need weeks to simply vote an alpha release and you think you can produce a new final in 2 months? Imo if you start a selective work you will need 2 months only to discuss what to include and what to exclude... btw as I said before I don't think I need to convince you, we can simply try. If you can manage a 2.4 release that will not block us from working on the 3 months development/3 months consolidation work I can leave with it. There is a lot of stuff that has been removed by the 2.3 branch but should really fit the 2.4 branch: database read/write streaming (we have write streaming in 2.3 but disabled by default because we had no time to test it enough), spool manager refactorings, 8bitmime (try again with new javamail fixes). We should refactor pop3 to follow the same smtp handlerchain pattern (and maybe do the same for remotemanager and nntp). We could try to include easier virtualhosting support, support for APOP and much other features that don't introduce storage incompatibility problems. Not all of those share the same level of testing, value or urgency, and yet you just want to dump it all on users as if we had carefully developed and tested them? It would take months of discussion to decide what deserve inclusion and what not. Imo 2.4 can't be your own needs release, but if you are able to work on it, test it, document it, and publish it in 2 months then I won't stop you from doing this: a new stable release is for sure good to James. That said
Re: JAMES v2.4 Road Map
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 -
Re: JAMES v2.4 Road Map
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
Re: JAMES v2.4 Road Map
Noel J. Bergman wrote: Norman Maurer wrote: Personally, I'm ready to make it a release, and start work on 2.4, which should be a careful selection of things to add, not a core dump from trunk. We never agreed on this roadmap. And I think I won't agree on this approach even later. I agree with Stefano. For me we should use the current trunk as 2.4 ( with handler-api2 merged when its complete). I don't see any problems with it. We don't did critical changes which whould break compatibly. It should still be a careful selection. As I said long ago, if you want to move trunk to 2.4, we should review every difference. Then, if we agree that each one represents a suitable risk/reward, fine. I'm sorry but (as I also said long ago) I'm on the opposite position about the 2.4 roadmap. We've just finished with a lot of efforts to put out a stable release to replace the old 2.2.0. 2.3.0 didn't introduce so much changes, but included a lot of fixes and a lot of refactoring useful for future improvements. 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. We kept storage compatibility between 2.2.0 and 2.3.0 and imho we can do the same for 2.3.0 to 2.4.0. config.xml will change, assembly.xml will change, maybe a few minor methods in the mailet apis could change. My proposal is to start at least 2 months of free development in trunk and then create the 2.4 branch to start the consolidation process. Considering that 2 months would be just before Christmas I would say let 's develop new features in trunk including the whole Christmas and we'll branch on the first days of 2007. Everything we currently have in trunk deserve inclusion in the next release and much more of this. We worked hard on 2.3 and I'm not ready and I'm not willing to start a new consolidation work just now. We have to look the long term also: I don't care if some of the feature we implemented in trunk will not be used by 2.4, I care that we use the next release also to consolidate that code so we'll be much more ready for 2.5 or 3.0. 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 (we still have an incomplete branch with a fastfail-v2 attempt). I don't want to make another release where fastfail is again marked as experimental because we're still working on it. There is a lot of stuff that has been removed by the 2.3 branch but should really fit the 2.4 branch: database read/write streaming (we have write streaming in 2.3 but disabled by default because we had no time to test it enough), spool manager refactorings, 8bitmime (try again with new javamail fixes). We should refactor pop3 to follow the same smtp handlerchain pattern (and maybe do the same for remotemanager and nntp). We could try to include easier virtualhosting support, support for APOP and much other features that don't introduce storage incompatibility problems. Another thing is that we should wait for dnsjava 2.0.3 to include full SPF support and we should wait for javamail 1.4.1 to try to enable 8bitmime stuff again. 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 and we should really avoid having 3 open branches (2.3, 2.4, trunk). Stefano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JAMES v2.4 Road Map
Stefano Bagnara wrote: Noel J. Bergman wrote: As I said long ago, if you want to move trunk to 2.4, we should review every difference. Then, if we agree that each one represents a suitable risk/reward, fine. I'm sorry but (as I also said long ago) I'm on the opposite position about the 2.4 roadmap. So what is your position? That we should simply dump trunk on users without proper review? Without comparing it to what we have spent so long testing and reviewing in the 2.3 branch? We've just finished with a lot of efforts to put out a stable release to replace the old 2.2.0. Exactly. 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. My proposal is to start at least 2 months of free development in trunk and then create the 2.4 branch to start the consolidation process. And if we do it my way, we can release 2.4 in less than 2 months. And work on v3 at the same time. And I want to branch soon, so that we can start working on the major changes that we should be doing for v3, and not just the safe but useful changes for v2.4. Everything we currently have in trunk deserve inclusion in the next release and much more of this. Wrong. Most of what is in trunk has had a fraction of the review and testing that we have spent on v2.3, and you're talking about a free-for-all of development. 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: There is a lot of stuff that has been removed by the 2.3 branch but should really fit the 2.4 branch: database read/write streaming (we have write streaming in 2.3 but disabled by default because we had no time to test it enough), spool manager refactorings, 8bitmime (try again with new javamail fixes). We should refactor pop3 to follow the same smtp handlerchain pattern (and maybe do the same for remotemanager and nntp). We could try to include easier virtualhosting support, support for APOP and much other features that don't introduce storage incompatibility problems. Not all of those share the same level of testing, value or urgency, and yet you just want to dump it all on users as if we had carefully developed and tested them? You've just ennumerated a whole raft of issues. We should examine each one to decide if THAT SPECIFIC PIECE is stable enough to go into the release, not conflate a dozen or more items. So we can start with ones that we all agree ARE stable enough to go into v2.4, and not just dump a load of immature code on top of our stable release. 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JAMES v2.4 Road Map
Am Dienstag, den 12.09.2006, 21:44 -0400 schrieb Noel J. Bergman: Stefano Bagnara wrote: Noel J. Bergman wrote: As I said long ago, if you want to move trunk to 2.4, we should review every difference. Then, if we agree that each one represents a suitable risk/reward, fine. I'm sorry but (as I also said long ago) I'm on the opposite position about the 2.4 roadmap. So what is your position? That we should simply dump trunk on users without proper review? Without comparing it to what we have spent so long testing and reviewing in the 2.3 branch? Well we should start testing the trunk ;-) (I have trunk running allready on a testserver) So we can get sure its stable and fix bugs! We've just finished with a lot of efforts to put out a stable release to replace the old 2.2.0. Exactly. And it seems that is do a much better job. I agree. 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. My proposal is to start at least 2 months of free development in trunk and then create the 2.4 branch to start the consolidation process. And if we do it my way, we can release 2.4 in less than 2 months. And work on v3 at the same time. And I want to branch soon, so that we can start working on the major changes that we should be doing for v3, and not just the safe but useful changes for v2.4. See my comment above. Everything we currently have in trunk deserve inclusion in the next release and much more of this. Wrong. Most of what is in trunk has had a fraction of the review and testing that we have spent on v2.3, and you're talking about a free-for-all of development. See my comment above.. We need a roadmap. 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. There is a lot of stuff that has been removed by the 2.3 branch but should really fit the 2.4 branch: database read/write streaming (we have write streaming in 2.3 but disabled by default because we had no time to test it enough), spool manager refactorings, 8bitmime (try again with new javamail fixes). We should refactor pop3 to follow the same smtp handlerchain pattern (and maybe do the same for remotemanager and nntp). We could try to include easier virtualhosting support, support for APOP and much other features that don't introduce storage incompatibility problems. Not all of those share the same level of testing, value or urgency, and yet you just want to dump it all on users as if we had carefully developed and tested them? Thats why we should try to test it again. It will never get stable if noone tests. Please don't let us do the same mistake as in 2.3... We all need to test it more. I have always a trunk server on a testsystem which serve some not so importent stuff. You've just ennumerated a whole raft of issues. We should examine each one to decide if THAT SPECIFIC PIECE is stable enough to go into the release, not conflate a dozen or more items. So we can start with ones that we all agree ARE stable enough to go into v2.4, and not just dump a load of immature code on top of our stable release. See other comments. 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
