Aaron Mulder wrote:
Dude, need you use the f-bomb? Is this -- "Non-technical
tip: think about the f***ing users" -- honestly your idea of a
professional interaction with your peers?
Dude, do you think ignoring the needs of users is professional software
development? That breaking everyone's application because you couldn't
be bothered to think of an upgradable solution is professional
behaviour? Before throwing the p-word around look in the mirror.
By the way, I think you were exaggerating when you said "tell them
this is a *good* thing because we're going to keep changing things until
1.0 finally comes out". Do you feel that's an accurate representation of
the other side of this conversation?
"+100000000 before we release 1.0 is the exactly when we should be
encouraging this type of drastic change." I read that as saying there
will continue to be drastic changes until the 1.0 release - is that
interpretation inaccurate? If you were a user, in light of that
statement would you look at this software now or would you wait until
after 1.0?
As far as stability goes, I hate to say it, but we're not there
yet. I'm going to have to make massive change to my book for the next
milestone. The entire security system looks nothing like it did in M3,
web services were not present in M3, MDBs did not work in M3, CMP was
incomplete in M3, there was no Tomcat option at all in M3, and the list
goes on. Add all that up, and removing 6 characters from a namespace is a
trivial change. I don't think anyone *should* be contemplating Geronimo
for anything "serious". We haven't even released a beta yet!
You might want to re-read what you said here. M3 was incomplete, which
is different from incompatible. You make a good point with respect to
security though - immediately after M3 was cut, all the security
definitions incompatibly changed showing that, indeed, this project
really does place little value on compatibility.
It's not that the change itself isn't trivial, but that it is
unnecessary and impacts EVERYONE. I would have hoped someone with your
extensive "professional" experience would have understood that.
And on the topic of coordination for builds, it's true we could do
better. But you know what? Flaming me (or David, not sure who you were
targeting, really) doesn't help. If you'd like to propose a build, such
as M4, and ask for a feature freeze while we prepare and test it, I think
that would be a great idea. It would have been nice to have done that
before we announced that we pass the test, but let's go from where we are.
I wasn't flaming anyone in particular but everyone in general. Where is
the co-ordination? There was an M4 proposal about a month ago - who is
co-ordinating it? When will it be there, what will it contain? Why
*isn't* there a feature freeze, or even a branch?
As far as design work goes, we've historically not had the
position of review-then-commit. I think we're trying to increase the
amount of discussion and planning on the list, but I'm not prepared to go
to a review-then-commit strategy. Are you? Short of that, yes, let's
talk on the list as we have been, but we also need to be prepared to make
adjustments to code that's committed as issues are identified.
Now who's exaggerating? You asked for "constructive" tips, one of those
is "when you're about to break everyone's application, bring it up on
the list first as other people may be able to help you find a way to
avoid doing so." That avoids firedrills after and keeps users happier.
--
Jeremy
