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 I can't simply spend more time consolidating a product that I won't use so I have to keep my feet on trunk for a while, including features and changes I plan since I started working on James. 2.3 took to much of my time and delayed trunk development too much. > 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. Maybe you want to go ahead and make the exact list of what you need in 2.4. I already did it: ALL + the "whole raft of issues". > 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. I believe we will have different opinions on what is stable and what is not. In 2 months we'll probably find out that we have different lists ;-). This is why I think we can skip the whole discussion and talk about who is willing to work on what: I now need to work on trunk for new features and to finish at least a few things I started there and I'm willing to work on new features only. In few months I will be ready again to do some more testing and consolidation work. >> 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 Sorry but I don't believe that 2.4 will be out in 2 months and if we find critical bugs in 2.3 then we will need a 2.3.1 as soon as possible. Stefano --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
