james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bernd Fondermann <bf_...@brainlounge.de>
Subject Re: Status of trunk [WAS: Re: [jira] Commented: (JAMES-876) cannot start as spring-deployment when built from trunk as described in HOW-TO.TXT]
Date Wed, 01 Oct 2008 20:21:11 GMT
Stefano Bagnara wrote:
> 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?

No, I am not asking that. I'm not asking anything. Just expressing my 
personal view how I would feel responsible when I'd broke something.

> 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,

We review commits to make sure the code is legit and can expected to go 
into the right direction. If something breaks, this can not neccessarily 
  be judged by reviewing a commit. You'd have to actually run that thing.

> and we never asked people to sign a contract saying they will
> mantain the code they write.

An unwritten law says: Fix what you break. At least for me. I thought 
this would also reflect what others in this project are thinking, but 
you are right, this is not written down anywhere, so other's opinions 
may vary. To my surprise, but anyway.

> This (non working deployments) is indeed an issue. 

So basically we agree that their is an issue. This is good.

> Manually checking
> phoenix and spring is a cost.

Agreed. Maybe we (including me, of course) should try and fix that.

> 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 wonder how you manage that. It's impressive. But building the code 
is only half the victory.

> I don't want to feel responsible for manually testing
> our multiple deployments. 

But at least I feel responsible for my own changes, so I test James 
after I change something.

> 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, 

Whoever, I don't care.

> and I simply decided to answer
> because I don't think Robert made a mistake. 

I don't think so either.

 > 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.

ok, then I will be patient and try to find the time to fix it myself.

> 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.

Honestly, I think this is not good. It is also not ok that we (including 
me) did not more regulary test the deployments. That's why I want to 
have a testing environment.

My understanding of the server project is that this should be a running 
mail server, not only a code collection of something that builds 
successfully. To make that managable, I worked on unit tests, on 
end-to-end tests (Postage) and I'm preparing (very slooowly) a testbed 
This James Server project makes no freaking sense if the server cannot 
be run.

> 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.

ok, I see. this must be fixed. ;-)


To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message