On Sep 24, 2009, at 12:16 PM, Tim Ruppert wrote:
Understood David - but where are these magical elves that come by
and test the entire system? They don't exist - that's the fact of
the matter - or we'd see more business users sitting here and
putting tests in place for the stuff that already exists.
Who said anything about business users?
The fact is they do exist. There are people who test and contribute
fixes. We need more of them, not less.
For my money, it goes back to putting tests around what you're doing
so that you know that when someone else makes a change it doesn't
break your functionality. Unfortunately it would require tests
everywhere - something to aspire to for sure - to ensure you didn't
break other people's work - but if they cared enough about their
code working, then tests and reproduceability steps would seem a
must to everyone.
I agree that it would be better for people to contribute automated
tests along with things they develop. However, that doesn't excuse
other people for complaining and not doing anything but complain if
something that someone else develops doesn't do what they think it
should. Different people and organizations have different
requirements, and not all of us have a sufficient level of omniscience
to guess at the requirements that others are facing (I know I
certainly don't!).
Hopefully more people will get involved in doing it on the existing
functionality. Manually testing a system of this size, watching
each and every commit that people do and tracking down the places
where that commit could cause problems is something that we do for
the good of the community, but as you know better than most, it
relies on expert level people - not just anyone. If there were more
tests, then anyone could add code and know that they needn't be
scared about it.
On that magical day when we do have a majority coverage for automated
tests I hope we don't start thinking that we don't need to be scared
about changes! On the other hand, I think most us aren't scared enough
about changes. On the other other hand, we do have a pretty healthy
level of peer review and peer pressure that keeps things fairly
straight. On that note, while a comment is a good form of peer
pressure an automated test case would be far more clear and more
persuasive...
Since there aren't, I guess I'll either hire more elves or hope that
other people start to contribute at this level as well.
I don't think we need more expert people, just more careful people,
and more people willing to write automated tests. I think that's what
we're talking about anyway. Maybe people being afraid that they aren't
experts is more of a problem than not having enough experts?
On the other hand, if the da#$ experts weren't so lazy and selfish
with their time they could solve all of our problems for us and none
of us would have to worry about any of this! It's all the expert's
fault that this is happening. Those $%^#ing selfish *&(t#$ds. ;)
-David
On Sep 24, 2009, at 12:04 PM, David E Jones wrote:
There are other ways to do this without requiring automated tests
for everything.
For example, if someone cares about quality or more specifically
about a particular thing working a particular way, what is stopping
them from writing and contributing an automated test for it?
In other words, there's no reason that the same people have to do
implementation of functionality and test cases, and IMO if anyone
blames a developer and is unwilling to do anything about it, that
is just an excuse and an attempt to avoid taking responsibility and
getting involved.
The general idea is we need to do things that encourage more
contribution, not less. Requiring automated tests for everything
committed would likely reduce contributions. Encouraging people who
care about things working in a certain way to contribute automated
tests for those things would, hopefully, increase contributions.
-David
On Sep 24, 2009, at 11:59 AM, Tim Ruppert wrote:
Being a test-first, test-driven community would still be the best
way to avoid that. Until we take a stance and reject everything
that doesn't do this, then I guess I'd have to agree with David
that the community must not care. The fact this project has
gotten this far along without doing this is amazing and a
testament to the tools (and the people) that have been put in
place being helpful enough to make it so these major flaws don't
happen very often.
I'm looking forward to that being a major shift in the way
contributions and work is committed to the project - I think it
would do worlds of good.
Cheers,
Ruppert
--
Tim Ruppert
HotWax Media
http://www.hotwaxmedia.com
o:801.649.6594
f:801.649.6595
On Sep 24, 2009, at 11:46 AM, David E Jones wrote:
It really is a bad sign. In a community driven project what this
means is that no one cares enough about it to do anything about
it... and I guess that's sad. Too much committing without
testing, or even running, things. Too much not caring about
existing functionality and creating new things that steamroll and
break existing things. All in all, the stuff I tried to guide
away from when I wrote the stuff here in the General
Responsibilities of Committers:
http://docs.ofbiz.org/display/OFBADMIN/OFBiz+Committers+Roles+and+Responsibilities
Like I've said recently on another topic... if no one else cares
what can I do about it? I guess like everyone else I'll just keep
doing my own thing... and collaborate with others when I can, and
when they'll let me.
-David
On Sep 24, 2009, at 11:23 AM, Ruth Hoffman wrote:
Hi David:
Thanks for your comments. As usually, they are well thought out
and invaluable in helping furthering the understanding of the
OFBiz project. IMHO, project releases are a really important
concern for new users. By new users, I mean new users of the
many and varied applications that come with the OFBiz
distribution. Maybe we could call these users new "end-users". I
don't mean users intent on building new applications and/or
modifying existing project files (i.e. Java code, CSS, HTML,
Javascript, Groovy, XML etc.). New users may get to a point
where they feel compelled to modify project files...but I
suggest we don't put the cart before the horse.
Please see my comments below:
David E Jones wrote:
I wouldn't say release4.0 or release09.04 have "been proven
either through formal release management practices or through
actual experience in the field." In fact, 4.0 was a much more
arbitrary cutoff point and not planned or acted on as much as
09.04.
OK, point well taken. Maybe I should have said "...through time
in service..."? Regardless, the applications as they exist in
the 4.x release work. Maybe the framework is not as advanced as
the current trunk or 9.04 release, but the demo store works and
the supporting applications work.
Just out of curiosity, have there been any bugs reported after
the 9.04 branch, that would make me believe that the Catalog
Manager, Order Manager and eCommerce component are not stable
and reliable in the 4.x release?
You mentioned issues in 09.04, could you be more specific?
Unfortunately I think many issues are related to the theme,
Yes - themes seem to be problematic. And, since the very first
encounter with OFBiz out-of-the-box is the presentation as
rendered by the theme - I think there is a big issue here. In
fact, IMHO this is what we use to call a "show stopper" and
makes the release unstable. Doesn't matter how good the
underlying product is, first impressions always count. Again,
this is just my opinion.
Back to themes: not only are themes problematic, I would point
out the documentation concerning how to work around theme based
issues with the flatgrey theme was vague and contradictory (as
was discussed here on this mailing list.)
and pretty or not it really does cause problems and it's
probably better to use it with the old flatgrey theme. There
could certainly be other problems, but in general I'd say 09.04
is more solid and certainly much more feature complete.
How about Jira #2602 - the very first thing you see when you
start up the demo store is broken (in my book and in my
browser). Sorry, but this does not bode well for the remainder
of the demonstration and for a successful outcome should one be
a new user testing the waters.
As far as "ad advertised" goes, I wasn't aware there was
anything advertised either way... ;)
Exactly my point! Its all implied. And since we have nothing
else to work with, older is better in this case.
One nice thing about 09.04 is that the business processes are
much more complete. In other words you can run through a
business process and not find the big functional gaps that
exist in 4.0. A LOT happened in the 2 years between the two
releases, and probably around 50 man-years of effort went into
things.
Actually, the devil is in the details. I'm not "dissing" 50 man-
years of work, but how many years of work went into the code
base prior to the 9.x release? And how many implementations are
there of 4.x code vs. trunk releases since the branch?
This really isn't a small difference. When doing gap analysis
based on a set of requirements I haven't seen any business
looking for anything, ever, where the feature set of 4.0 would
hit even close to the percentage of overlap that 09.04 does.
That is good to know. Sounds like OFBiz is moving in the right
direction.
Whatever the case, depending on the circumstances I'd still
recommend going with the trunk. For reasons we've discussed
before in many cases the trunk is actually more bug-free than
any release branch as long as you stay updated with it, of
course with the release branches you have to stay updated with
them too if you want bug fixes (ie that is the "patching"
process for them and it's BAD BAD BAD to not update when using
the release branches).
I guess this is where we differ. I'd say a new user - out to
kick the tires - is not interested in updating or reporting
bugs. They just want to get started with a minimum of
frustration and a maximum of success.
That said, the basic idea behind the releases and what to
choose still holds pretty true, and the release branches are
definitely more "stable" (meaning they don't change, not
meaning more bug-free, but it does help some with that), see
the "How Do I Decide What To Use" section here:
http://docs.ofbiz.org/display/OFBADMIN/Apache+OFBiz+Getting+Started
-David
On Sep 24, 2009, at 9:49 AM, Ruth Hoffman wrote:
Hi Jacques:
I understand and respect where both of you are coming from.
But I think you need to consider that for new users (and this
is only for new users), they should be guided towards using a
stable, proven release. The 4.x release is the only release
that is proven and works out-of-the-box as advertised.
Your reference to beginner documentation aside (and, BTW, this
is developer documentation not end-user documentation), I
can't in good conscience suggest to anyone to use code that
hasn't been proven either through formal release management
practices or through actual experience in the field.
Just my 2 cents.
Ruth
Jacques Le Roux wrote:
I totally agree with Ashish (not surprising) but Ruth is also
right to say that we have still some bugs in R9.04, but it's
improving day after day and have a lot more features and a
better architecture. For instance there is still issues with
Minerva in R4. And IMO, the main reason is you will not get
much help (if any) from the community with R4. We are almost
all turned to the future, not the past...
Jacques
From: "Ashish Vijaywargiya" <ashish.vijaywarg...@hotwaxmedia.com
>
-1 for starting with OFBiz 4.0 release.
Instead of this I will recommend to start with either
Release branch 9.04 or trunk and report any bug found.
The main reason of my recommendation is that the beginner
document(http://docs.ofbiz.org/x/UBE) and some other
document best support to Release Branch 9.04 & trunk.
PS: "4.x trunk release" - Ruth, If I am not wrong "trunk"
word is used for the repository on which current development
is going on.
--
Regards
Ashish Vijaywargiya
HotWax Media Pvt. Ltd.
http://www.hotwaxmedia.com
Helping hand around the World ...
USA | Italy | India | New Zealand
Ruth Hoffman wrote:
Hello Olindo:
IMHO - and not to ruffle any feathers - there are a number
of minor but very visible bugs (mostly in the presentation
layer) in the 9.04 release that could easily discourage and
frustrate a first time user. I found this out the hard way
while trying to use the 9.04 release as a basis for screen
shots in my 2 books (and for the myofbiz.com website.)
My advice for what it is worth: if you are a beginner,
start with the 4.x trunk release (it's rock solid and
proven) and then, when you understand how OFBiz should
work, move on to 9.04 if needed.
Again,
Just my 2 cents.
Ruth
Olindo Pindaro wrote:
What is the difference beetween this 2 branches?
TNX
