Robert Burrell Donkin ha scritto: > On Wed, May 20, 2009 at 2:23 PM, Stefano Bagnara <[email protected]> wrote: >> I agree. I would probably test and review an RC from trunk but not any >> build from v2.3. > > so: you wouldn't be willing to review a 2.3.2 RC?
If 2.3.2rc is what we currently have in v2.3 branch then I already reviewed it :-) I review critical bugs as soon as they are submitted to JIRA because they are related to code I have in production and I care about this. I already have in production most of the fixes that are in v2.3 (e.g: JAMES-846, JAMES-899, JAMES-875, JAMES-693, JAMES-816). The remaining JIRAs are Won't fix or documentation or other trivial fixes. >>>>> * The recent threads from users are telling us that we really need to >>>>> have a 2.x roadmap for mail server users (as opposed to mail >>>>> application developers) >>>> they don't care about 2.x or 3.x. IMO they simply would like to have new >>>> features that are in svn since years. >>> i used to think that but the upshot of the discussion with users is >>> that no they don't. james 2.x already has lots of features. most just >>> want releases plus much better documentation. any users who really >>> cares about features more than stability is probably already on 3.x. >>> >>> the great thing about already having the features in trunk is that we >>> can decant them in bite-sized pieces ensuring they have been tested >>> and documentation written. >> ???? Why should an *user* upgrade to an hypotetical 2.4.0 that do not >> include a single feature more than 2.3.1 but simply require java5 and >> has some more smaller jars? > > it's just a mailet API upgrade and java version bump, simple as that. > new users will probably pick it up (and stop complaining about > obsolete JREs), old users can take their time evaluating it. James 2.3.1 succesfully run in JRE6 for me. Developers are complaining about JDK versions, not users. I understand the upgrade and version bumb, and that is simple, but still it is not a critical bugfix. Not a dot release issue. >> Can you link the discussions that led you think that such a release >> would find an userbase? I really don't remember one. > > take a look a the current thread here on dev I read it, but I didn't had the perception that releasing a 2.4.0 that is a clone of 2.3.0 with no new features will make a single user happier. Maybe I missed a key post? >>>>> Proposal: >>>>> * Use 2.x for mature, stable releases aimed at mail server users >>>>> retaining pheonix as the container >>>>> * Target 3.x at mail application developers focussing on OSGi and Spring >>>>> * Move code from 3.x to 2.x by factoring out libraries with multiple >>>>> modules to allow optional avalon and OSGi service support >>>>> >>>>> Roadmap: >>>>> * Release 2.3.2 now (after deprecating mordered, crypto) >>>>> * Release standard mailets 1.0 >>>>> * Release crypto mailets 1.1 targeting java 1.5 >>>> Make sense. >>>> >>>>> * Release 2.4 soon replacing source with jars released so far (with >>>>> note about standard mailets) >>>>> * Compiled against Java 1.5 >>>>> * Remove mordred >>>>> * Replace 2.x crypto source with released jar >>>>> * Replace 2.x mailet API with released jars >>>>> * Release 2.5 later replacing source with released jars >>>>> * Add jSPF support >>>>> * Replace standard mailet source with released jar >>>>> * Replace whichever other services have been released by then >>>> My main concern is that this does not give features to the users. Users >>>> are asking for a roadmap because they want easy virtualhosting, fastfail >>>> and other features that are in trunk since *3 years* (yes, some stuff >>>> was there when we released 2.3.0 and didn't land v2.3), are trunk >>>> specific, and backporting them is a PITA. I don't think that the roadmap >>>> above does worth the required work, but if anyone think so and is >>>> willing to work on that then it will not be a bad thing. >>> the advantage of the above is that it's a road map and it's easy >> Come on, this is not the main goal of a roadmap. Not following that is >> easier and gives our users the same benefits. > > a road map just shows a way forward Or simply something to discuss about instead of coding. I tried the roadmap way in past and it didn't work. I don't care of roadmaps anymore. I care about patches, commits, releases, vetos. >>> but it won't fly without support and we need a road map before 2.3.2 >>> can be released >> Why do we need a roadmap for a bugfix release? v2.3.2 can be released >> anytime from v2.3 branch, as is. No roadmap needed, just a release manager. > > it's the first question we're going to get so we need an answer > > we need to give developers and user hope that james isn't dead Well, if releasing something new but without features works let's re-release v2.3.1 as v2.4, then v2.5, updating the year and the version number ;-) When I'll see more work on "core" code in trunk I'll find a new hope that james is not dead. You did a damn good job with Imap, with mailets and libraries releases, but unfortunately no new developer joined the team (except for mime4j). Maybe tomorrow some new developer will come to James and make it survive, but he won't care about our roadmap and the best thing we can do is not to force him into the roadmap of inactive developers. >>>> The only real features for end users in that roadmap is jSPF and this >>>> could be released as a mailet anyway. jSPF as it is in trunk cannot be >>>> done in v2.3 because of different fastfail stuff (IIRC). >>> fine - so let's factor out an SMTP library as well (multi-module with >>> avalon and OSGi service bindings) >>> >>> this means a DNS service library as well but IMHO that's a good thing. >>> UserRepository is a little too much to chew ATM but i think we should >>> be able to bridge the interfaces. >>> >>> AIUI this'd give us improved fail fast as well >> This is trunk, isn't it? >> If you take v2.3 and replace smtp, userrepositories, dnsservice and >> every dependency that need changes because of this (most components >> depend on dnsservice) then you have trunk (just with less modules: take >> a revision from 1 year ago and you'll have v2.3 with that stuff and no >> modules ;-) ). > > not really > > it doesn't include IMAP or any of the other code that would need to be > reviewed and tested to release 3.0, just the new features which users > seem to want. factoring them into libraries means that any heated > debates about design can happen in isolated not as part of a bigger > quality argument about 3.x verses 2.x. Do you really think IMAP is the issue? trunk is modular, it is easy to release it without IMAP (but I don't think this is the real issue). > (maybe you're starting to understand the plan now ;-) No, we discussed this at least twice in past, and I didn't change my mind. Looking at v2.3 is waste. Trunk is not anything revolutionary. It include really *MINOR* changes and they are in trunk only because they break some interface or compatibility. >>>> I will not work and I will not use such a branch: I don't need any >>>> feature from that so why should I upgrade and risk bugs? >>> i'm running out of time to devote to james (as a project). karaf gives >>> me the way out i've been looking for. >> That's a real pity. If Karaf is a way out then we'll have to pay more >> attention to understand exactly what we are embracing or it will be the >> next iron ball at the leg of any future release manager. > > that's not needed. karaf does the stuff that i need it to do for my > interests but the spring deployment should still work independently. > >>> you and norman are busy, as are most of the other developers. james >>> server is really close to actually dying. >> Sure, but why defining a roadmap that give us useless releases should >> change things? > > james - as a project - needs to be able to start agreeing on road > maps. if not, then the project will die. I thought JAMES was dead when the roadmap proposed by Norman and me (the main developers in 2007) was refused. Now I see that JAMES made improvements only when there was no roadmap. As soon as someone tried a roadmap JAMES stopped. At least this is what happened since I lurk in here. >>> no road map is going to work without your support. this is the best >>> plan i could think of. if you can see a better alternative way forward >>> then please propose it. >> I don't have time, but if I'll ever have time it won't go into v2.3. I >> repeated this in the last 2 years and I didn't change my idea about >> this. v2.3 works fine, is really stable, but architecturally at its end >> of life. In my view working on that source code is a waste of time. >> If I'll see activity I'll try to convince people to put their effort in >> trunk and I'll try to help as much as possible that people (as I tried >> with you). >> If you have limited time to spend on james I would prefer you to simply >> make imap better as a standalone library. As a PMC member I think this >> is much more strategic for the community than a feature-less release of >> a v2.4. > > IMAP now works and has been tested by martin on the major mail clients > but support for avalon and pheonix will become increasingly limited > (or quite possibly non-existent) > > the problem james - as a project - has with releasing is not cutting > releases (any more) but with ensuring that they are tested and > agreeing on road maps. unless something changes soon, as soon as i > start focusing elsewhere, james is going to die. How a roadmap can save JAMES? A developer can save james, not a roadmap. BTW I don't want to waste more time with this discussion. IMHO the roadmap is still the one I proposed 2 years ago, but the problem is that I'm no more able to push it. I'll +1 any roadmap supported by active developers. >>>> IMHO the above roadmap is mainly a developer exercise to replace source >>>> code with libraries and to upgrade v2.3 to java5. >>> it's been 3 years since the last release. it's not ambitious but at >>> least it's a start. >> I can only repeat myself. If you like to refactor v2.3 into v2.4 by >> upgrading to java5 and to more fine grained libraries just do it, but >> don't ask me to help or to agree that this will make our users happier ;-) > > without your help in review releases, no road map is feasible I'll review anything but v2.3 enhancement. If there are at least 2 PMC member thinking your v2.4 roadmap is good then they will review the releases. If you can't find the 2 PMC that wants such a release then we have an agreement that the roadmap is not useful. >>> it's not good releasing 2.3.2 without some sort of road map >> dot releases are bug fix releases. I never ever defined a roadmap for >> bugfix releases in my life: this kind of roadmap is called "open >> critical/major bugs report" in JIRA and it is automatically created when >> filed *bug* reports are confirmed. > > james needs to release 2.3.2 together with a road map to stop what > users we have moving to other less sophisticated but more actively > developed servers I won't push anything. I can't afford it. But I'll support any trunk based action, as I did in the last year with your work in trunk. This is all I can do. >>>> Backporting stuff from 3.x to 2.x is simply unfeasible for most >>>> interesting code because we had to change interfaces and break some >>>> compatibility in order to support the new features. I BET backporting >>>> some of them will take *much* more time than testing trunk as a whole. >>>> People keep claiming that v2.3 is stable and trunk is not, but the fact >>>> is that simply no one tested trunk and confirmed it is unstable. Maybe >>>> it is, but until I'll see bug reports about instability against trunk I >>>> won't consider this. >>> i wasn't proposing to backport but to factor out multi-module >>> libraries which can be shared. bugs can then be fixed against trunk. >> components are linked together via interfaces. To factor out modules >> that can work in both v2.3 and trunk we have to deal on common >> interfaces. The components you talked about rely on changed interfaces >> or define the interfaces used by the rest of james. > > yes, there would need to be some glue code back ported. this don't > think that this should be a major issue. > > it does mean that the interfaces can be agreed by a release and > versioned independently. I think this will be harder than releasing trunk. It is my humble opinion, but I allocate my spare time based on my opinion ;-) Stefano --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
