You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Dejan Nenov <de...@jollyobject.com> on 2002/12/19 08:44:28 UTC
There is no active development on James
To any committers / active contributors to James development out there -
can you please review and verify bug 15460 - unless no one else can
reproduce the problem - it seems to be making James totally unusable!
Thank you,
Dejan
file based persitence
Posted by Stephen McConnell <mc...@apache.org>.
From memory there is a virtual file system package in commons or
somewhere like that - does anyone know any details ?
Cheers, Steve.
Danny Angus wrote:
>James in in a code freeze pending release of version 2.1
>
>I can't say when the release is likely to happen, but it is unlikely that
>this issue is going to be addressed before then.
>
>The reason for it not being fixed before now is because we inherit it from
>Avalon.
>We are intending to replace that with our own filesystem code in the next
>cycle.
>
>d.
>
>
>
>
>>-----Original Message-----
>>From: Dejan Nenov [mailto:dejannenov@jollyobject.com]
>>Sent: 19 December 2002 07:44
>>To: james-dev@jakarta.apache.org
>>Subject: There is no active development on James
>>
>>
>>To any committers / active contributors to James development out there -
>>can you please review and verify bug 15460 - unless no one else can
>>reproduce the problem - it seems to be making James totally unusable!
>>
>>
>>
>>Thank you,
>>
>>
>>
>>Dejan
>>
>>
>>
>>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: There is no active development on James
Posted by Danny Angus <da...@apache.org>.
> I understand your frustration with a possible delay. But the feature is
> glaringly broken, and in my mind it is worth fixing. I think holding
> people accountable for knowing 100% of what needs to be done in an
> onsite project is unrealistic at best, and doing so for a globally
> diverse group of volunteers is even more dangerous.
I have to agree with this, this bug has been around and around, I don't have
the time to do anything about it, Serge is offering to.
If the code freeze was over this would not be a problem.
If this had come up earlier it would also not be a problem.
It simply isn't possible to manage the contributions people make, nor the
timing of them, nor the participation people make in discussions.
This bug is not on my personal radar because I have never used James with
the filesystem, but can see why it is a showstopper for those who do, and
having had it brought to my attention I can see why it should delay the
release.
Alternatively make the release and it can be fixed afterwards, there can be
precious little left to do now.
Please also note that your resistance to implementing mirroring have
attracted the intervention of Greg Stein in his role as ASF chairman,
something which I'm sure none of the longer serving commiters are
particularly pleased about, and again if it were not for the drawn out
release this could have been implemented prior or post the freeze.
Therefore I'm prepared to
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: There is no active development on James
Posted by "Peter M. Goldstein" <pe...@yahoo.com>.
Serge,
> We have a release process... we voted on a release plan, and the code is
> now
> frozen. If we see a bug, we raise it, discuss it, and vote whether we
> should fix it. You don't like this process and want to use your own, and
> I
> can't get around your veto.
Excuse me, but this is exactly the process we discussed and approved.
Pre-existing bugs were evaluated and judged. We had an explicit discussion
about this bug.
New bugs are raised, discussed and submitted for evaluation by their
discoverers/committers. Some have been approved (the Oracle resource fix)
some were held off on (the deluser problem). Opportunities for discussion
were always there.
There is no process of "my own". Your implication is erroneous.
We, not me, decided to put it off. Now you're asking, at the 11th hour, to
revisit the decision to put it off. Ok, let's agree that you have the right
to make that request. In fact, you've already made that request. What
you've really got a problem with is that I disagree with you.
You're annoyed that I don't agree with you that it should be reversed. In
fact, it's even worse that that, because I'm advocating a third way that
would allow us to support the user base without further delaying the
release. So I'm willing to grant that the bug should be fixed, and your
problem is that I feel that getting 2.1 out the door is a value above and
beyond fixing this bug right now. And why exactly does this make me a bad,
bad man?
I'm not going to try and vilify you here in the interest of winning points.
I believe that you believe that your proposal is the best path for James. I
just don't agree. Why you find that so inconceivable is beyond me.
> You're just not making very many friends by changing rules and -1
> everything
> you don't want to work on. I voted to support the 2.1 release plan and
> code
> freeze without new rules being introduced.
No rules were changed, nothing was altered. See the above.
And I'm certainly not "-1 everything I don't want to work on". What I am
doing is tightly gating the 2.1 release to try and move it out the door.
> Anyway, I was very supportive of someone bringing rigor to our testing,
> documentation, and release process. I'll admit I'm upset this moment, but
> I'm going to find it difficult to +1 to any more of your release plans
> with
> the way the past month has gone.
Ok. Quite honestly, given the failure of anyone to actually contribute to
the release plan, I doubt I'll be proferring any new ones up. This has, as
may be apparent to you at this point, a tremendously disheartening
experience. I find it sad that the developers on this list (for the most
part) cannot muster up a few hours over the course of months to advance the
pieces of the project that, while they might not be the center of their
interest, nonetheless make the product more appealing to the end users and
hence benefit the whole. That, while many may talk a good game, few seem
willing to put in the actual effort. Certainly it's helped undermine my
belief in the effectiveness of open source development.
> And finally, this is a simple bug and I'm not going to sit here and talk
> for
> days about how to go about this change... I said this is a quick fix,
> maybe
> a bit more to support backwards compatibility. I think you're being
> clearly
> beligerent about the QA issue... pop3 file system DOES NOT WORK!!! To
> your
> comment of it being usable as a simple test configuration... who downloads
> a
> mail server for a simple test configuration? By comparison I suppose you
> would say if the SMTP handler couldn't support remote connections, that's
> acceptable?
I've already explained my view of this bug. You don't like it, that's fine.
You disagree with it, that's fine. That's your prerogative. Feel free to
try and convince me otherwise. Or don't. But this trivialization does you
little credit.
There is certainly no need for you to spend days talking about the change.
Go off and fix it if you want. As I'm trying to make crystal clear, there
is absolutely nothing stopping you from doing so.
Speaking as probably the only committer who does run the file repository on
any system (I use it for one of my low traffic domains, and also for testing
file repository issues in James) I can confirm that the bug behaves exactly
as I stated. Provided the server doesn't restart (inducing renumbering),
things work ok. My server has been running for weeks without a problem.
It's a robustness issue and, as I granted, a nasty one. But there is a work
around, which to me means it isn't critical. Sorry you disagree.
As far as the above analogy, it is false. Your comparison is false
precisely because if the SMTP handler didn't accept remote connections,
there would be no workarounds. False analogies rarely advance arguments.
I'm not sure why you don't see the difference.
I certainly don't feel I'm being belligerent about the QA issue - what I'm
doing is illustrating what real tradeoffs are involved. You can't seriously
believe that a change to the file repository that is so fundamental isn't
going to require at least a little testing, can you? Especially considering
backwards compatibility issues? It's not like it will be months, but it
will probably be at least a week.
> > My view was that if Noel was set with his issues that we'd call for a
> final
> > release vote and get this thing out the door. Obviously, that would be
> in...
>
> Heh, well if you're expect us to need another vote to make the final
> release, you can expect a very loud -1 from me.
Ok. That's your prerogative. As I said, these two views are in conflict.
I mean I don't know what to tell you Serge. I'm not '-1' voting for my
health. Or out of spite. I'm trying to get a reasonable product out the
door. Something I can be proud that my name is on. That's the reason I
spent much of my Thanksgiving vacation writing user docs. It's certainly
not because I enjoyed it. I believe James can be a valuable product.
I'm also trying to get us to institute a process that will lead to better
future versions. I've already presented what I think is a very reasonable
alternative that doesn't block getting the file repository fix out. You
seem to regard it as anathema - so much so that you haven't even addressed
the option directly.
Honestly, when I looked at 2.0a3 several months ago I saw promise, but not
much motion. As a product, James was slow, died under load, poorly
documented at a developer level, and contained tremendously
incomplete/confusing user docs. It had a number of bugs (including this
one) that clearly had gotten no attention. Patches attached to some of the
bug reports hadn't even been reviewed by committers and introduced into the
code base. Patches on the mailing list languished. The changelogs for
2.0a3 and 2.0a2 seemed unambitious for nearly six months of work.
Now look at the changelog for 2.1. It's a similar approximately six month
period. Look at the kind of changes we've seen in the code. That's despite
some rather drawn out arguments. And the greater changes in the product
(i.e. user documentation, marketing) that have come with 2.1. Now we've got
a bug situation that's under control - each bug has been evaluated and
discussed. Most were fixed. The SMTP processing is fast (900%)
improvement, robust (no crashes under continual heavy load), fairly well
documented for developers, and has the core of a decent set of user docs.
Response to users has improved, and all outstanding patch submissions have
been evaluated (most of them being incorporated in the product). So
something seems to be improved.
> I'm so tired of always arguing within this project. Why can't we all just
> get along? We've had a number of users immediately say they want this bug
> fixed when I asked for a vote to do so.... why do we have to argue so
> much?!?
That's real life. Users always want their bugs fixed immediately.
Understandably so. As I mentioned earlier, this was my job for a long time.
Continuing engineering. So I'm more than familiar with users' desires.
But there are questions of completion, stability, robustness, and testing.
It's easy to ignore these but you do so at your peril. Users aren't any
happier if you fix the bug you know about and introduce three more in the
process. Avoiding the latter situation requires some care and, more
importantly, some time. It is my belief that we are late in the game on 2.1
and that the time isn't there. People are already antsy to get on with 3.0
- and understandably so.
None of this stops you from working on and posting your patch. Users on
james-dev (the ones who requested it) could download it and apply it to
their own systems. None of this stops you from preparing it for inclusion
in a 2.1.1 release. There are already a few other bugs (dot-stuffing,
deluser) that would be good candidates for such a beast. If properly
restricted, this could be a very quick release (a la Phoenix 4.0.1 and
4.0.2).
As far as arguments go, they're a natural product of people who have diverse
opinions and feel strongly about them. Quite honestly, I haven't enjoyed
these discussions myself. But that doesn't mean I'm going to cave to every
whim on this list. In each case I've proferred arguments as to why I feel
the way I do. When asked, I've elaborated on my reasoning. While I'll
admit I've been terse, and certainly my frustration has come through on more
than one occasion, I've also tried to work for the good of the product and
the community. It saddens me that you can't see that last part, because
that's the part that has made the arguments tolerable.
--Peter
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: There is no active development on James
Posted by Serge Knystautas <se...@lokitech.com>.
We have a release process... we voted on a release plan, and the code is now
frozen. If we see a bug, we raise it, discuss it, and vote whether we
should fix it. You don't like this process and want to use your own, and I
can't get around your veto.
You're just not making very many friends by changing rules and -1 everything
you don't want to work on. I voted to support the 2.1 release plan and code
freeze without new rules being introduced.
Anyway, I was very supportive of someone bringing rigor to our testing,
documentation, and release process. I'll admit I'm upset this moment, but
I'm going to find it difficult to +1 to any more of your release plans with
the way the past month has gone.
And finally, this is a simple bug and I'm not going to sit here and talk for
days about how to go about this change... I said this is a quick fix, maybe
a bit more to support backwards compatibility. I think you're being clearly
beligerent about the QA issue... pop3 file system DOES NOT WORK!!! To your
comment of it being usable as a simple test configuration... who downloads a
mail server for a simple test configuration? By comparison I suppose you
would say if the SMTP handler couldn't support remote connections, that's
acceptable?
>
> My view was that if Noel was set with his issues that we'd call for a
final
> release vote and get this thing out the door. Obviously, that would be
in...
Heh, well if you're expect us to need another vote to make the final
release, you can expect a very loud -1 from me.
I'm so tired of always arguing within this project. Why can't we all just
get along? We've had a number of users immediately say they want this bug
fixed when I asked for a vote to do so.... why do we have to argue so
much?!?
Serge
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: There is no active development on James
Posted by "Peter M. Goldstein" <pe...@yahoo.com>.
Serge,
> I'm very much sick of 2.1. I don't know why it's taking so long, but
> I'm not helping enough to complain.
You're not alone. It's taking so long because no one is helping. Just look
at the last two months of CVS messages.
> You dodged the issue of whether this was an important bug by saying it
> was "discussed over and over and over again". Rather than doing so
> indirectly, I'd prefer if it you directly answered whether you would
> prefer to ship 2.1 with an unusable configuration (POP3 on, and using
> file mailstore) or fix this bug.
No I didn't. But to be absolutely clear, I would rather see 2.1 released
now with this problem in place than wait to fix this bug. I believe that
the appropriate way to resolve this would be with release note/documentation
and a subsequent bug fix release (2.1.1 or 2.2).
First off, I regard the statement that it makes file repository unusable as
not quite accurate. The truth of the matter is that POP3 file repositories
are not robust upon restart. Agreed, very bad. I certainly wouldn't want
to use a file repository in a production, multi-user system. But not
unusable as a simple test configuration. Or for proof of concept work. As
I said, we can document the problem to make this distinction clear.
Second, my view of release management is that you make a decision at some
point in the process, and you stick with it. We made this decision. It was
discussed. I don't think that fact is irrelevant. I think it's important.
Otherwise there is the tendency to revisit every decision in the release
process. Everything is game, nothing is settled. I think that's one of the
worst ways to do a release.
Third, much as some on the list won't want to hear it, there is a
workaround. Use a database for your production systems. MySQL is free for
personal use, reasonably easy to set up, and consumes minimal resources.
Even the commercial license is very inexpensive. This is a realistic option
that maintains the functionality.
Compare this situation with the bug in 2.0a3 (and I believe in 2.0a2) where
use of SMTP auth automatically opened up the server as an open relay. In
that case there was no workaround whatsoever - SMTP auth is the only way for
James to securely process relayed mail from arbitrary hosts - yet the
release still went out the door.
Finally, we don't even have a patch for this yet. While you've now
volunteered to do this work, we don't know how much time/effort it will take
to fix this. Will it make the upgrade more difficult by breaking file
repository backwards compatibility? Will we have to document the upgrade
procedure? How much testing effort will you be putting in to avoid new
issues? Will it be equivalent testing to the amount done in the Q/A portion
of this release (processing of ~1 million messages, for a total of ~2GB of
disk space consumed)? The time/effort and the potential repercussions are
totally unknown. Given the lateness in the process, I find that highly
undesirable.
I still believe that the correct solution is to document the issue and
commit to a post-2.1 bug fix release (I said 2.2 in my previous email, I
meant 2.1.1). That will allow us to resume development work on 3.0 and get
a little momentum back in the game. You can continue with your work on
patching the problem, and it won't be holding up other features.
> I understand your frustration with a possible delay. But the feature is
> glaringly broken, and in my mind it is worth fixing. I think holding
> people accountable for knowing 100% of what needs to be done in an
> onsite project is unrealistic at best, and doing so for a globally
> diverse group of volunteers is even more dangerous.
I guess. I don't know how you intend to do a release process if people
aren't willing to take some responsibility. Certainly it's going to lead to
a tepid feature set, continual alpha/beta releases because no one want to
make the commitment to a released product, and a general lack of
stability/performance. Having the project maintainers take some level of
responsibility is the only way I know how to avoid these problems. And
other projects with a "globally diverse group of volunteers" (i.e. the
Apache web server) seem to do ok with this.
All projects, open-source or closed-source, require a willingness to say at
some point, "Good enough, push it out the door". That's how imperfect
products both closed source and open source (just look at Linux, Apache,
etc.) get distributed to a user base. Otherwise you might as well call the
product Taligent and accept obsolescence/irrelevance a priori.
At this point we're essentially done. Docs are imperfect, but have enough
coverage so that they answer most of the questions we see on james-user.
Some tweaking can occur post-release, if people feel like it.
Noel has the marketing stuff lined up, and was supposed to return home
yesterday night (I haven't seen him pop up yet, so I don't know if he's
back). He was waiting for answers to questions about the mirroring issue,
but had gotten no response to his enquiries as of Friday (I'm not sure what
this says about the devotion of the ASF to the current mirroring scheme, but
there you go). When he pops back, we'll see where he is with the mirroring,
the marketing, and all of that.
My view was that if Noel was set with his issues that we'd call for a final
release vote and get this thing out the door. Obviously, that would be in
direct conflict with your call to break code freeze. It's got to be one or
the other. Let's pick. I vote get it out the door.
--Peter
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: There is no active development on James
Posted by Serge Knystautas <se...@lokitech.com>.
Peter,
I'm very much sick of 2.1. I don't know why it's taking so long, but
I'm not helping enough to complain.
BUT ANYWAY...
You dodged the issue of whether this was an important bug by saying it
was "discussed over and over and over again". Rather than doing so
indirectly, I'd prefer if it you directly answered whether you would
prefer to ship 2.1 with an unusable configuration (POP3 on, and using
file mailstore) or fix this bug.
I understand your frustration with a possible delay. But the feature is
glaringly broken, and in my mind it is worth fixing. I think holding
people accountable for knowing 100% of what needs to be done in an
onsite project is unrealistic at best, and doing so for a globally
diverse group of volunteers is even more dangerous.
--
Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com
Peter M. Goldstein wrote:
> All,
>
> IMHO, this is ridiculous.
>
> If the bug is glaring now, it was glaring when we
> discussed the list of bugs for release. And when it's
> come up on the list before. Again and again and
> again. There was a conscious decision (with
> discussion) to defer this bug because we're intending
> to redo the repositories.
>
> Consider this a -1 vote on further delaying the
> release for something we've discussed over and over
> and over again.
>
> If you want to update the 2.1 POP3 docs to clarify
> this issue, that would be fine.
>
> If you want to put out a 2.2 with this fix, great.
> Please do it after the seemingly endless 2.1 is out
> the door.
>
> But personally I'm just plain sick of 2.1 and want to
> be done with it.
>
> --Peter
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: There is no active development on James
Posted by "Noel J. Bergman" <no...@devtech.com>.
> I'm only working on my one project and have no idea how much it's costing
> those people in California to support my CVS account and emails and
> downloads... he asks that we start considering this, and so we listen.
I may be new guy on the block, but I have been reading the traffic
reports/graphs, and other e-mails. Yes, this is a serious issue overall for
ASF, but we're a minor bandwidth consumer. Even so, we ARE moving to
implement mirroring, and I get the responses I've asked for, we may be one
of the first mirrored projects, not the last.
We more than "started to consider" this; I acted upon it the same day that
the original request was made.
> Also the open dialogue quickly ends with a -1 vote.
No it does not. On a non-technical matter, a -1 is simply a vote. On a
technical matter, it is the START of a dialog that should have taken place
earlier. A veto on code should always contain the reasons for the veto in
such fashion that eventually the conflict can be resolved.
Did everyone wake up on the wrong side of their beds this week? I can't
believe that I drove 600 miles today, and am still up past 4AM replying to
all of this stuff.
For what it is worth, I exchanged e-mail with Brian discussing using James
v3 to run the Apache mail system. He raised the subject on infrastructure@.
We now have a list of requirements that will be necessary. Looks promising,
and we would all be proud of that accomplishment. One of the requests is to
support file system repositories. Seems to me that if we can patch this bug
for current users (near term), and then replace the entire file system code
with maildir that we'll be well on our way.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Release 2.1
Posted by Stephen McConnell <mc...@apache.org>.
+1
Nicola Ken Barozzi wrote:
>
> As a developer
> ---------------
>
> Please, get this F***ing 2.1 release out of the door.
> It works very well with a DB, just disable the filesystem repos and
> mark them as "unstable" or something. Then get a 2.1.1 release out
> right after.
>
> Release early - release often.
>
> And please, let's stop this thread. It's not constructive and has a
> stupid header that is simply wrong and unfair to you all.
>
> Also, sorry if my mails on mirroring stirred up things, it was not my
> intention.
>
>
> As a user
> ---------------
>
> Please, get this F***ing 2.1 release out of the door. ;-)
>
> And get 2.1.1 our *right after*.
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Release 2.1 (Re: There is no active development on James)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
As a developer
---------------
Please, get this F***ing 2.1 release out of the door.
It works very well with a DB, just disable the filesystem repos and mark
them as "unstable" or something. Then get a 2.1.1 release out right after.
Release early - release often.
And please, let's stop this thread. It's not constructive and has a
stupid header that is simply wrong and unfair to you all.
Also, sorry if my mails on mirroring stirred up things, it was not my
intention.
As a user
---------------
Please, get this F***ing 2.1 release out of the door. ;-)
And get 2.1.1 our *right after*.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: There is no active development on James
Posted by "Noel J. Bergman" <no...@devtech.com>.
> I find it disturbing that a relative newcomer should be *continually*, at
> almost every turn, attempting to block the existing members of a mature
> community.
I don't consider this to be representative of the past season of
development. I don't consider anything about this discussion to be
representative of the past season of development.
Peter (and everyone else) has compromised on any number of issues.
With respect to the recent discussions, Peter expressed his concerns
regarding bugzilla, a bug fix, and mirroring.
WHY are people jumping up and down regarding -1 votes on procedural issues?
So what? He has an opinion and he voted/expressed it. Are people
forgetting that -1 votes are only binding on code? Otherwise, majority
rules, and he's entitled to his opinion. The nice thing is that he also
explains his concerns, immediately opening a discussion on the subject.
On the bugzilla issue, I see that several other folks, including Aaron and
Charles, agreed with his concerns. From what I see, a replacement approach
was suggested that addresses the issues. Plus we all may have learned
something from the discussion.
On the mirroring issue, he is concerned because I'm still waiting to get
some feedback that I think I need to make our mirroring actually work. He
hasn't (and can't) say no. He is simply saying that if we don't get the
answers that we not delay the release while waiting, not that we should not
do the mirroring.
As for the bug fix issue, he is frustrated by delay (as are we all) and the
perceived lack of support/help. But that doesn't mean that he isn't open to
discussion and compromise. I have never seen Peter closed to discussion or
compromise.
C'mon guys, shake hands or something.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: There is no active development on James
Posted by Danny Angus <da...@apache.org>.
> I find this
> assumption that any view which dissents from the current group-think shows
> no consideration to be disturbing. It certainly isn't the way to do good
> software development. Or good community building.
I find it disturbing that a relative newcomer should be *continually*, at
almost every turn, attempting to block the existing members of a mature
community.
Learn how to compromise Peter.
d.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: There is no active development on James
Posted by "Peter M. Goldstein" <pe...@yahoo.com>.
Serge,
> "The Apache Way" is about trust and respect... Greg is someone who's
> trusted
> a lot of people, and I think has earned a huge amount of respect. This
> isn't quaking in fear... it's a response of... my gosh, I'm only working
> on
> my one project and have no idea how much it's costing those people in
> California to support my CVS account and emails and downloads... he asks
> that we start considering this, and so we listen.
I couldn't agree more. It is about respect. Respect for disparate points
of view. Something that seems to be lacking here.
As my last email made clear, I did consider the issue. I find this
assumption that any view which dissents from the current group-think shows
no consideration to be disturbing. It certainly isn't the way to do good
software development. Or good community building.
I considered the issue not simply in response to Greg's email, but in
response to Nicola's original post. I responded to that email with my
belief that the tradeoff wasn't in the best interest of the project.
Mirroring was not objected to on principle, but rather as being yet another
thing that would push back the release. When it became clear that Noel
wanted to pick this up and that he'd still get the marketing stuff done, I
let it drop. If Noel manages to get his questions answered by the Apache
infrastructure people, then mirroring will be part of the 2.1 release cycle.
If he can't (which would indicate to me that it's not exactly a priority
with them), then we'll consider the issue. In that case I'd push for a
release w/o mirroring. What, exactly, is the problem here?
> Also the open dialogue quickly ends with a -1 vote. Because of the Apache
> voting rules, when someone votes -1, the conversation is just about over.
> We can lobby the vetoer, but more than likely whatever brought that person
> to veto will not likely change. And even if the person was open to
> change,
> the lobbying is draining to the community, the lobby'ers, and the vetoer.
> Perhaps you don't appreciate how negative your voting is appearing to the
> community.
Perhaps it is. It is certainly not my intention to damage the community.
But as I've said before, I only have my professional judgment to rely on.
In my view it is equally (if not more so) damaging to make bad decisions and
have to deal with the consequences. So I have (and continue to) express my
opinion as to the best options at assorted decision points.
On some occasions I stick to my guns, because I believe that it's a crucial
issue. On other occasions I have gone along with opinions that differ
substantially from my own because I believe that they won't be horribly
detrimental. On still others I've tried to emphasize the issues that I find
most relevant, and find a third path that addresses both those and the
issues put forward by the other developers. That's how it works.
As far as the open dialogue ending with a '-1' vote, I'll have to disagree.
I certainly haven't felt restrained from debating with '-1' votes with which
I disagree. And I wouldn't expect others to fail to lobby me when they
disagree with my vote. My observation (on this and other lists) has been
that the vote is rarely the end of the story.
As far as this system being "draining", I don't see what your alternative
is. It's a voting system, designed to allow disparate points of view to be
debated. Sometimes it leads to gridlock. Most of the time it doesn't. I
don't see any other way to do it. To me the choice seems to be unproductive
lassitude or some degree of conflict. I'm all for minimizing the latter,
provided we don't accept too much of the former.
> Anyway, I'm done lobbying for you to change your veta of the pop3-
> filestore
> bug. You have the right to block any bug fixes and push the release out.
> So be it.
Ok. As I said in my recent email, your demeanor of "hurt victim" here
baffles me.
--Peter
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: There is no active development on James
Posted by Serge Knystautas <se...@lokitech.com>.
Peter,
> As far as Greg's intervention, it hardly seems in line with "the Apache
Way"
> to quake in fear of the presence/intervention of any individual, ASF
> chairman or other. I appreciate Greg's POV, I'm happy to hear what he has
> to say, and am more than happy to discuss the issue with him. I'm sorry
> this sort of open dialogue doesn't please you, but it hardly seems
> catastrophic or even to be a major issue.
When you came into this project, we gave you huge lattitude to make changes
to the code base. We trusted you to make those changes you showed interest
in the project, fixed things that people wanted fixed, and generally
improved it. And we all respect you for what you've done.
"The Apache Way" is about trust and respect... Greg is someone who's trusted
a lot of people, and I think has earned a huge amount of respect. This
isn't quaking in fear... it's a response of... my gosh, I'm only working on
my one project and have no idea how much it's costing those people in
California to support my CVS account and emails and downloads... he asks
that we start considering this, and so we listen.
Also the open dialogue quickly ends with a -1 vote. Because of the Apache
voting rules, when someone votes -1, the conversation is just about over.
We can lobby the vetoer, but more than likely whatever brought that person
to veto will not likely change. And even if the person was open to change,
the lobbying is draining to the community, the lobby'ers, and the vetoer.
Perhaps you don't appreciate how negative your voting is appearing to the
community.
Anyway, I'm done lobbying for you to change your veta of the pop3-filestore
bug. You have the right to block any bug fixes and push the release out.
So be it.
Serge
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: There is no active development on James
Posted by "Peter M. Goldstein" <pe...@yahoo.com>.
Danny,
> Well lets get it released then, IMO the code freeze has gone on for too
> long
> already.
Well, hey, do you think James 2.1 might be ready to go right now (or a month
ago) if any of the folks here aside from Noel and me had contributed to the
tasks proposed to and agreed upon in the release plan? Just curious...
There seems to be a sense from some of the folks on this list that things
happen by "magic". They don't. As with all things of value, they happen
because people put in effort to make them happen. You want something to
happen, put in a little effort. If you don't put in the effort, don't
complain. See Serge's very correct comment on the matter.
> Please also note that your resistance to implementing mirroring have
> attracted the intervention of Greg Stein in his role as ASF chairman,
> something which I'm sure none of the longer serving commiters are
> particularly pleased about, and again if it were not for the drawn out
> release this could have been implemented prior or post the freeze.
As far as Greg's intervention, it hardly seems in line with "the Apache Way"
to quake in fear of the presence/intervention of any individual, ASF
chairman or other. I appreciate Greg's POV, I'm happy to hear what he has
to say, and am more than happy to discuss the issue with him. I'm sorry
this sort of open dialogue doesn't please you, but it hardly seems
catastrophic or even to be a major issue.
My position remains basically unchanged - I don't see any reason why 2.1
should be gated by getting the mirroring right. Despite Nicola's somewhat
emotional response (I was half expecting a follow-up lecture on Hardin's
"Tragedy of the Commons") it is neither ingratitude nor laziness that
motivated my vote in response to the mirroring proposal. I'm very
appreciative for the resources provided by the Apache foundation, and very
cognizant of the fact that these resources cost money. But I also have some
experience pricing bandwidth, and I found the tradeoff (one more thing to do
before release vs. a change of doubtful financial value) to be undesirable.
While I'm not going to go into a lengthy explanation of my economic
reasoning here, a simple Fermi estimate of the overall percentage of Jakarta
bandwidth consumed by James distribution downloads (remember, mirroring
doesn't affect anything but that) should make it clear why I feel this is
not a priority.
It's pretty clear to me that James downloads are far on the small side of
the 80/20 (or for that matter 90/10 or 95/5) rule. Considering that
bandwidth is not a fungible commodity, and more importantly is not generally
priced that way for larger sites, this is a rather substantial argument as
to the insignificant financial impact of mirroring for James downloads.
Add to that the fact that it is something that can be addressed post-release
with a minimum of bother, and I still don't see why it needs to be done as
part of this release process.
All that said, Noel has been trying to set it up pre-release. He wants to
confirm some things with the Apache infrastructure folks. If he can get a
response, great (he'd been unsuccessful before last Friday). If not, I'd
still like to move for a release if all the marketing channels are lined up.
We can discuss that in the unlikely event Noel doesn't get a response from
the infrastructure folk.
In any case, I'm sorry you're not pleased, but it doesn't please me that no
one save Noel/me has put in any serious effort on James 2.1 since October.
Life is full of unpleasant things.
I agree with you, the drawn out release is unfortunate. I am doing what I
can to get it out the door. Next time around a more general effort would
probably help shrink the release cycle substantially.
--Peter
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: There is no active development on James
Posted by Danny Angus <da...@apache.org>.
> If you want to put out a 2.2 with this fix, great.
> Please do it after the seemingly endless 2.1 is out
> the door.
>
> But personally I'm just plain sick of 2.1 and want to
> be done with it.
Well lets get it released then, IMO the code freeze has gone on for too long
already.
d.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: There is no active development on James
Posted by "Peter M. Goldstein" <pe...@yahoo.com>.
All,
IMHO, this is ridiculous.
If the bug is glaring now, it was glaring when we
discussed the list of bugs for release. And when it's
come up on the list before. Again and again and
again. There was a conscious decision (with
discussion) to defer this bug because we're intending
to redo the repositories.
Consider this a -1 vote on further delaying the
release for something we've discussed over and over
and over again.
If you want to update the 2.1 POP3 docs to clarify
this issue, that would be fine.
If you want to put out a 2.2 with this fix, great.
Please do it after the seemingly endless 2.1 is out
the door.
But personally I'm just plain sick of 2.1 and want to
be done with it.
--Peter
--- Danny Angus <da...@apache.org> wrote:
>
> On the basis that it should be on the list of things
> to fix anyway, having
> hung around for, I say go fix it.
>
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8839
>
> d.
>
> > -----Original Message-----
> > From: Serge Knystautas
> [mailto:sergek@lokitech.com]
> > Sent: 19 December 2002 18:38
> > To: James Developers List
> > Subject: Re: There is no active development on
> James
> >
> >
> > Danny,
> >
> > This is such a glaring bug, to not patch it is to
> say we DO NOT support
> > POP3 file storage support (and would need to
> announce that very loudly
> > since this is the configuration out of the box).
> I think it's great the
> > code is more scalable, cleaner, better documented,
> but this has been
> > such a glaring bug for so long. Heck, it's just
> one of those poorly
> > thought out "features" of Avalon, and it wouldn't
> take much work to just
> > copy the code and undo the change that broke this.
> Ok, it'd be a little
> > more work to be backwards compatible, but still,
> really not that much.
> >
> > Can we vote to let me patch this? (or show me the
> previous vote so I can
> > appeal to however blocked it... I've searched the
> archives for the bug #
> > and can't find it).
> >
> > --
> > Serge Knystautas
> > Loki Technologies - Unstoppable Websites
> > http://www.lokitech.com
> >
> > Danny Angus wrote:
> > > James in in a code freeze pending release of
> version 2.1
> > >
> > > I can't say when the release is likely to
> happen, but it is
> > unlikely that
> > > this issue is going to be addressed before then.
> > >
> > > The reason for it not being fixed before now is
> because we
> > inherit it from
> > > Avalon.
> > > We are intending to replace that with our own
> filesystem code
> > in the next
> > > cycle.
> > >
> > > d.
> > >
> > >
> > >
> > >>-----Original Message-----
> > >>From: Dejan Nenov
> [mailto:dejannenov@jollyobject.com]
> > >>Sent: 19 December 2002 07:44
> > >>To: james-dev@jakarta.apache.org
> > >>Subject: There is no active development on James
> > >>
> > >>
> > >>To any committers / active contributors to James
> development out there -
> > >>can you please review and verify bug 15460 -
> unless no one else can
> > >>reproduce the problem - it seems to be making
> James totally unusable!
> > >>
> > >>
> > >>
> > >>Thank you,
> > >>
> > >>
> > >>
> > >>Dejan
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: There is no active development on James
Posted by Danny Angus <da...@apache.org>.
On the basis that it should be on the list of things to fix anyway, having
hung around for, I say go fix it.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8839
d.
> -----Original Message-----
> From: Serge Knystautas [mailto:sergek@lokitech.com]
> Sent: 19 December 2002 18:38
> To: James Developers List
> Subject: Re: There is no active development on James
>
>
> Danny,
>
> This is such a glaring bug, to not patch it is to say we DO NOT support
> POP3 file storage support (and would need to announce that very loudly
> since this is the configuration out of the box). I think it's great the
> code is more scalable, cleaner, better documented, but this has been
> such a glaring bug for so long. Heck, it's just one of those poorly
> thought out "features" of Avalon, and it wouldn't take much work to just
> copy the code and undo the change that broke this. Ok, it'd be a little
> more work to be backwards compatible, but still, really not that much.
>
> Can we vote to let me patch this? (or show me the previous vote so I can
> appeal to however blocked it... I've searched the archives for the bug #
> and can't find it).
>
> --
> Serge Knystautas
> Loki Technologies - Unstoppable Websites
> http://www.lokitech.com
>
> Danny Angus wrote:
> > James in in a code freeze pending release of version 2.1
> >
> > I can't say when the release is likely to happen, but it is
> unlikely that
> > this issue is going to be addressed before then.
> >
> > The reason for it not being fixed before now is because we
> inherit it from
> > Avalon.
> > We are intending to replace that with our own filesystem code
> in the next
> > cycle.
> >
> > d.
> >
> >
> >
> >>-----Original Message-----
> >>From: Dejan Nenov [mailto:dejannenov@jollyobject.com]
> >>Sent: 19 December 2002 07:44
> >>To: james-dev@jakarta.apache.org
> >>Subject: There is no active development on James
> >>
> >>
> >>To any committers / active contributors to James development out there -
> >>can you please review and verify bug 15460 - unless no one else can
> >>reproduce the problem - it seems to be making James totally unusable!
> >>
> >>
> >>
> >>Thank you,
> >>
> >>
> >>
> >>Dejan
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: There is no active development on James
Posted by Dejan Nenov <de...@jollyobject.com>.
Yes! Yes!
Please, Please patch this!
Here is the bug: http://issues.apache.org/bugzilla/show_bug.cgi?id=8839
Dejan Nenov
-----Original Message-----
From: Serge Knystautas [mailto:sergek@lokitech.com]
Sent: Thursday, December 19, 2002 10:38 AM
To: James Developers List
Subject: Re: There is no active development on James
Danny,
This is such a glaring bug, to not patch it is to say we DO NOT support
POP3 file storage support (and would need to announce that very loudly
since this is the configuration out of the box). I think it's great the
code is more scalable, cleaner, better documented, but this has been
such a glaring bug for so long. Heck, it's just one of those poorly
thought out "features" of Avalon, and it wouldn't take much work to just
copy the code and undo the change that broke this. Ok, it'd be a little
more work to be backwards compatible, but still, really not that much.
Can we vote to let me patch this? (or show me the previous vote so I can
appeal to however blocked it... I've searched the archives for the bug #
and can't find it).
--
Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com
Danny Angus wrote:
> James in in a code freeze pending release of version 2.1
>
> I can't say when the release is likely to happen, but it is unlikely
that
> this issue is going to be addressed before then.
>
> The reason for it not being fixed before now is because we inherit it
from
> Avalon.
> We are intending to replace that with our own filesystem code in the
next
> cycle.
>
> d.
>
>
>
>>-----Original Message-----
>>From: Dejan Nenov [mailto:dejannenov@jollyobject.com]
>>Sent: 19 December 2002 07:44
>>To: james-dev@jakarta.apache.org
>>Subject: There is no active development on James
>>
>>
>>To any committers / active contributors to James development out there
-
>>can you please review and verify bug 15460 - unless no one else can
>>reproduce the problem - it seems to be making James totally unusable!
>>
>>
>>
>>Thank you,
>>
>>
>>
>>Dejan
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: There is no active development on James
Posted by "Noel J. Bergman" <no...@devtech.com>.
As far as I know, there was no "vote" to block this fix, but there WAS a
vote on what would be in the release, and this was either approved by
omission or simply slipped though the cracks.
On that ground, I do disagree with Serge on one issue: "I think holding
people accountable for knowing 100% of what needs to be done in an onsite
project is unrealistic at best." I think that we all ought to become more
familar with the James area of bugzilla. Is it possible, someone please
tell me, to have an report generated and e-mailed reflecting open bugs on,
say, a weekly (serious bugs) or monthly (other requests) basis? Sort of a
tickler to remind us of what is outstanding, and annoy us into fixing them?
I think that IF we can fix this in an isolated fashion, then we might
consider fixing it for the same reason that we fixed the Oracle bug. This
appears to impact a large number of users, is a show stopper (AIUI) if you
reboot the server, and is a Top-5 FAQ by my informal guestimation. Yes, I'd
love to change the default config to use HypersonicSQL, but that is an even
bigger issue than fixing the bug.
The only decent way I can think of to fix this problem is as follows:
1. Take the code from Avalon for the version of the broken classes that
we are using.
2. Move those into a James package: org.apache.james.<wherever>
3. Change the imports, and use our classes.
4. Test.
5. Fix those classes. We have a proposed change ALREADY SUBMITTED.
6. Re-test.
This is the only way I can think of to make this a "simple bug" because I
would NOT want to fix those classes in the Avalon code, and have to rebuild
their jars. That would be far more risky, I think.
IF we follow the above steps, what exposure do we have with this fix?
Please let me know what issues I will need to test for, so that I can
accommodate them.
I further want to know if EVERYONE agrees that IF we can fix this cleanly,
that we have a Release. I can appreciate that people are frustrated. We
ALL want v2.1 out the door, but it has not been delayed by creeping
bug-fix-itis. The primary delay has been that the docs needed work, and no
one seems to have had the time to work on them other than Peter (and, to a
minor extent, me). From the little feedback of any kind that we've had to
them, the new docs are considered a vast improvement, and my hat is off to
Peter for all of his hard work on them.
In the future, I hope that we can keep the docs and code changes more in
synch. I'd also like to see us do minor releases with more frequency,
similar to tomcat, rather than go the better part of a year between major
releases. But that is another discussion.
EVERYONE (Peter included) agrees that this bug is "very bad." I am off-line
for the most part for another few days, but if no one else has the time to
attempt this bugfix, I will personally do it next week. I think that we are
ready for the Release, we have a good product, we do want to be able to
SUPPORT it, and based upon that last issue, I am willing to take the time to
fix this rather than immediately put out a 2.1.1 (think of that marketing
message -- an immediate patch for a long-standing bug of this nature), but I
don't want this to inspire any further delay. I, as does EVERYONE, want to
ship this excellent product.
And, again, for future releases I would like to discuss that weekly/monthly
status e-mail so that we are ALL more aware of defects.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: There is no active development on James
Posted by Serge Knystautas <se...@lokitech.com>.
Danny,
This is such a glaring bug, to not patch it is to say we DO NOT support
POP3 file storage support (and would need to announce that very loudly
since this is the configuration out of the box). I think it's great the
code is more scalable, cleaner, better documented, but this has been
such a glaring bug for so long. Heck, it's just one of those poorly
thought out "features" of Avalon, and it wouldn't take much work to just
copy the code and undo the change that broke this. Ok, it'd be a little
more work to be backwards compatible, but still, really not that much.
Can we vote to let me patch this? (or show me the previous vote so I can
appeal to however blocked it... I've searched the archives for the bug #
and can't find it).
--
Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com
Danny Angus wrote:
> James in in a code freeze pending release of version 2.1
>
> I can't say when the release is likely to happen, but it is unlikely that
> this issue is going to be addressed before then.
>
> The reason for it not being fixed before now is because we inherit it from
> Avalon.
> We are intending to replace that with our own filesystem code in the next
> cycle.
>
> d.
>
>
>
>>-----Original Message-----
>>From: Dejan Nenov [mailto:dejannenov@jollyobject.com]
>>Sent: 19 December 2002 07:44
>>To: james-dev@jakarta.apache.org
>>Subject: There is no active development on James
>>
>>
>>To any committers / active contributors to James development out there -
>>can you please review and verify bug 15460 - unless no one else can
>>reproduce the problem - it seems to be making James totally unusable!
>>
>>
>>
>>Thank you,
>>
>>
>>
>>Dejan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: There is no active development on James
Posted by Danny Angus <da...@apache.org>.
James in in a code freeze pending release of version 2.1
I can't say when the release is likely to happen, but it is unlikely that
this issue is going to be addressed before then.
The reason for it not being fixed before now is because we inherit it from
Avalon.
We are intending to replace that with our own filesystem code in the next
cycle.
d.
> -----Original Message-----
> From: Dejan Nenov [mailto:dejannenov@jollyobject.com]
> Sent: 19 December 2002 07:44
> To: james-dev@jakarta.apache.org
> Subject: There is no active development on James
>
>
> To any committers / active contributors to James development out there -
> can you please review and verify bug 15460 - unless no one else can
> reproduce the problem - it seems to be making James totally unusable!
>
>
>
> Thank you,
>
>
>
> Dejan
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>