Summarizing my opinion: +1 - if you want to create a branch in the sandbox folder using "noel" in the name to indicate it is a personal area and is not intended to be used as a release branch.
+1 - if you want to create a proposal (or reuse the next-minor one) to start a "v2.4" branch as a base to release a 2.3.1 backward compatible release including some new feature/bugfix from trunk. If none of the 2 +1 satisfy your request then please explain because I probably misunderstood your message ;-) ....details in line: Noel J. Bergman ha scritto: > Stefano Bagnara wrote: > >> Noel J. Bergman ha scritto: >>> I'm looking at a defect (one or more, but seemingly related) in the > current >>> release code, so I'll be forking a branch that is maintainable. > >> Is this "next-minor" or something new? If it is next-minor (delayed 6 >> months), then simply go ahead, we already agreed on it. > > I've no idea what you call next-minor or anything else. This is a branch in > which I can put necessary fixes. If people want them, fine. If not, > consider it an interim fork to have something that works while we do the > various major re-developments that have been discussed. If you don't plan to manage a release or to play teamwork on that branch then I suggest to use sandbox folder and prefix it with "noel-". Otherwise if you have a description (a branch proposal) for what the branch is for and you will accept other to commit there respecting the rule of your branch proposal, imo you can name it v2.4 and we can use it with the old "next-minor" proposal. If you don't remember what is next-minor you should read the STATUS file ;-) . In the mean time you could update the STATUS file, too :-) >>> I have already generated a complete diff between 2.3.0 and 2.3.1 to see > what >>> was done to the code and packaging > >> I don't understand why did you need to compare 2.3.0 to 2.3.1 for a new >> branch: am I missing something? You will branch from "v2.3" and not from >> build_2.3.0, right? > > I wanted to see the differences between what we used to have in 2.3.0, and > what we have now. The tag is stable, so I could compare against the tag > without that diff changing on me, and separately compare 2.3.1 to the 2.3 > branch to see what else is different. I've been reviewing every line that > was changed. Thank you! Are you telling this because you found something interesting by this line-to-line compare or only to let us know you finally reviewed the code we released? >>> Other than fixing outstanding defects, adding the per-IP connection > support, >>> and fixing what appears to be a problem related to partial delivery in > the >>> face of exceptions [...] is there anything on anyone's wish list for a >>> 2.working version? > >> My only request is that you open a JIRA issue (or post a message here) >> for the OOM exception ASAP and that you explain us what did you find >> about this OOM issue :-) > > I didn't do anything to "find" it. The things are sitting in my log files. > I have a specific message (actually a couple of them), which are *tiny* and > yet easily reproduce the problem. I've experimented with expanding the > heap, reducing the number of concurrent delivery threads, etc., but none of > that resolved the problem. It is not a persistent OOM. You can see the OOM > get thrown, JAMES recovers, there is plenty of heap, and we start to rebuild > our resources (e.g., mailboxes that were discarded), and then the same > message hits and the OOM is thrown. It is very specifically linked to > sending a message to bellsouth.net that is has a dozen or more users > attached, and where we are getting some sort of partial failure. As you talked of this OOM when proposing what to include in your branch I thought you already had some code or identified something more. If this is useful to your investigation I don't restart my main JAMES Server deployment since 2 months and I deliver almost 1 million message per day (using 50 threads) and I don't see any OOM. In this deploument I use a remotedelivery service but most code is inherited by standard RemoteDelivery, so it is much probable that the OOM is related to a very specific condition (like you described). Please keep us updated and open a JIRA issue as soon as you will have found more informations about the OOM. >> My personal preference is that you copy "v2.3" to "v2.4" branch > > <<shrug>> I couldn't care less what it is called. The last time I put fixes > into JAMES, they were discarded, and our users get to deal with the > consequences of that action, so this time I'll create a separate branch. I'm sorry you don't accept the PMC decisions. Fortunately no user (but you) complained for this yet, so maybe the PMC made the right thing about this. > As > far as I'm concerned, it can be called JAMES-noel, and you can take whatever > you do or don't want from it. I really don't care. I just need something > stable to run in production while we work on trunk. Anyone else who wants > to benefit from it is welcome. If you guys want to vote it as a release, > and give it a number, fine. Otherwise, it's just code. Btw if you don't plan to work on a release based on that code then my preference is to create a "noel-v2.3" sandbox. I prefer to not use branches for code that is not a result of a team work and collective decisions. If you work on your own custom sandbox I won't oversight the quality of the code with release in mind and I will do this only if someone will eventually propose to create a release or to start a releasing branch from there. If you start a "v2.4" of course this will instead result in direct oversight and team-work. >> and work there by backporting from trunk. > > Yes, I was planning to backport, as I had before. Noel, you don't really need to remind me what happened, I have a very clear picture of what happened :-) >> we agreed in past we don't want diverging live branches > > LOL Yeah, right. I'm the one who pushed that point, because some of us have > already had the joyful experience of having to merge things, but that horse > seems to be long out of the barn. With all of the many development branches > in the sandbox ... what else do you call some of the more active ones except > for branches ... it'll be a good year or more before things come back > together. Robert is working hard to make that somewhat less painful, so > we'll see. > > --- Noel Experimental or dead sandboxes are not an issue to me: most of them have been created with the only purpose to show some ideas or to experiment something. My point is that if you plan to make a release from a branch then it has not to diverge from trunk. If you don't plan to release than I don't care at all: the more code you share in the repository in sandboxes the more I'm happy (I prefer to read a new java file in sandbox than most messages on server-dev). I think none of our current sandboxes is alive (excluding the new jcr experiment) and none of them is near to be merged back. FWIW I updated the STATUS file about the only sandbox I worked on. It would be cool if others can do the same for other sandboxes. Stefano --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
