Bernd Fondermann ha scritto: > Stefano Bagnara wrote: >> Bernd Fondermann ha scritto: >>> Stefano Bagnara (JIRA) wrote: >>>> [ >>>> https://issues.apache.org/jira/browse/JAMES-876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12635775#action_12635775 >>>> >>>> ] >>>> Stefano Bagnara commented on JAMES-876: >>>> --------------------------------------- >>>> >>>> @Joerg: yes, imap (and mailboxmanager stuff belongs to imap) has been >>>> moved out from server tree to its own module. >>>> Now imap is no more in the source tree but is included with jars in >>>> stage/org.apache.james/jars/ folder. In the mean time many classes >>>> have been repackaged so it probably is incomplete yet. >>> Mmmh. Who's going to fix it, then? >> >> Anyone with commit rights. Or even people with no commit rights by >> submitting patches. >> >>> Or maybe we should roll back some >>> weeks? >> >> If you think something should be rolled back just propose it. >> >>> Anyway, I'd like to have a compiling and (at least barely) >>> running trunk. Really. At the moment this all looks a little bit like >>> deconstruction work. >> >> There is an ongoing work. Robert just made a big refactoring by moving >> out IMAP. >> >> I've done some update after the repackaging in imap to make sure the >> trunk was building. >> >> All of our trunks build fine in my environment and in hudson. >> >> If you want trunk to always work then we should start using branches for >> r/evolutionary changes and merge back once in a while. AFAICT Robert is >> against this kind of workflow, so feel free to find an agreement with >> him. >> >> Another option is to put your hands fixing things that do not work for >> your kindly asking for help when you don't understand what to do ;-) >> >>> There are other trunks which do not build for me >>> either. Hopefully it turns out to be just a local problem. I follow up >>> with details as soon as I have a minute to concentrate on that. >> >> Just take your time and feel free to fix things. Everyone hands are >> needed there to shape the next james. > > At first, I apologize. My original comments were too harsh.
> But, you know, I am used to a development process where when I change > something I try to test the overall application, if it still works. And > by working I mean it not only builds without errors but it starts > without failures and does some actual useful things. I don't rely on CI > or any other tool alone. And if I break something, I feel very > responsible to fix it. > > But probably that's just me ;-) Then you should feel responsible for having added code to trunk (spring-deployment) and not updating it as the remaining codebase evolve. Do you added a feature and now you are asking others to mantain it? I don't think you should feel responsible for that, because the whole community is responsible for whatever anyone do. We review commits for this, and we never asked people to sign a contract saying they will mantain the code they write. This (non working deployments) is indeed an issue. Manually checking phoenix and spring is a cost. I already take care of too many projects to make sure they at least build (we have hudson builds for all of them and I try to monitor it and keep it clean), I don't want to feel responsible for manually testing our multiple deployments. I don't even feel responsible for the hudson stuff, but I like to have working builds. If this is something important to you then we should at least evaluate whether to remove one of the 2 deployments and concentrate our efforts into a single deployment (being it spring or phoenix). Just to be clear I also guess that this specific issue has been introduced by Robert and not by me, and I simply decided to answer because I don't think Robert made a mistake. We are in a big refactoring and we decided to work in trunk: this is expected until someone will write integration tests for the deployment. The last time I checked both Phoenix and Spring to launch succesfully has been a couple of months ago. I remember it took a few hours to "update" them. https://issues.apache.org/jira/browse/JAMES-848 is a blocker for running spring-deploymnet. I opened it when I did that work, and if you want to help you could start there. Stefano --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
