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
server.
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. ;-)
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
