Ok, ok. I feel so manipulated (private joke with Scott). :P
I am using OFBiz 4.0 extensively. But haven't found a lot of problems worth mentioning. It
certainly has less problems than the trunk, which is good news!
Come end of 2007, I should have gone through all or most (95%?) of the framework in OFBiz 4.0.
I'll start looking at above-the-framework stuff after that.
Jonathon
Scott Gray wrote:
Exactly right BJ, for releases to move faster the community needs to move
faster. The committers have put a lot more time into contributing to the
release (mostly via back patching) than the rest of the community and IMO
that is the reverse of how it should be. No matter what the release plan
ends up looking like, if the community doesn't support the release via
extensive use, testing and bug reports (with fixes!) then it will always
move more like the tortoise than the hare.
Regards
Scott
On 17/11/2007, BJ Freeman <[EMAIL PROTECTED]> wrote:
about a month ago david ask the community for feed back on those that
have 4.0 in production.
I have not see that much feed back about it so apparently there are not
that many using it in production.
I believe once more report that they are using 4.0 in production and are
not running into problems that would the be point to freeze it and
release.
Jonathon -- Improov sent the following on 11/16/2007 7:18 PM:
Well, clearchris has a point. Is there a defined release date for 4.0?
It depends on the management's view of OFBiz 4.0. If it is considered
alpha, go on ahead and insert any amount of enhancements into it. But if
it is considered beta, it would be good to be strict about things, and
pop in only bug fixes.
The question to ask is whether management intends for OFBiz 4.0 to be
frozen or not. Is it released/published already or not? If it is
considered already published, I'd really like to see further
enhancements in OFBiz 4.1. From a psychological perspective, it's
exciting to see OFBiz 4.1, rather than see OFBiz 4.0 improve
tremendously "behind-the-scenes" over one long year.
Picture what I'd tell my clients: "Boss, I know OFBiz 4.0 was shaky 10
months ago, but the 4.0 then is a far cry from the 4.0 now!". It'd be
easier saying: "Boss, we now have OFBiz 4.4. Here are the list of
improvements over 4.0.".
Then some folks may say that OFBiz 4.0 as it is now is unusable, that no
one in right mind will use 4.0 given the horrible security issue
outstanding. What then? I say, we let 4.0 die. Time to move on! 4.0 was
published, management should stick to that decision. Roll out the next
version!
Now on to technical considerations. SVN branches are "hotlinked", ie
branching 4.1 from 4.0 only creates a cheap reference to 4.0, not an
entire copy of 4.0. Any changes to 4.1 will then take up further
harddisk space, so only deltas above 4.0 are stored on disk. There will
still be only *one* copy of the entire 4.0 code.
Now we question whether there'll be tons of confusion if we roll out a
whole army of the 4.x family. The crucial thing we *must* do is to make
sure the 4.x family are fully compatible with one another such that
upgrading/downgrading along the family line requires zero migration
effort. Also, make sure that any bug fixes can be *uniformly* applied
across the whole family. What that also means is any enhancements that
are too radical and that may break above requirement cannot be put into
the 4.x family.
So what's the point of having 4.0 and 4.1? Ease of bug-reporting! A
non-techie person can say "I found the bug in 4.0". So he didn't have
time to upgrade to 4.1, or maybe 4.1 is an unlucky number for him. Then
the response we give him? "Sir, have you gotten the latest updates for
4.0"? He either says "no" and he updates and retest, or he says "yes"
and we hunt for the bug in that *specific release version that is 4.0*!
Or if we want to, we could say that "4.0 is dead, please use 4.2".
In short, here's the plan. OFBiz 4.1 goes into alpha, and takes in all
sorts of enhancements as long as they don't break backward-compatibility
with 4.0. OFBiz 4.0 continues beta, until such time that it is
super-bugfree. We'll have a series of 4.x members, with the earlier ones
getting more stable than the later ones (later ones take in risky new
enhancements). How will that happen? Anyone finding a bug in the latest
4.x member can also apply the similar bug fix to 4.0 (or 4.y where y <
x). The bug fixes cascade down to earlier 4.x members, making them more
stable over time, even as the community tests only the newest 4.xmember.
Throughout the whole 4.x lineage, no extra harddisk space is taken up.
SVN makes cheap "copies". Only deltas are stored.
Is that clearly explained? Or did I just confuse version control with
cake-baking?
Jonathon
Jacques Le Roux wrote:
Finally, have we an idea about what to do :o)
Do we need a vote for this ? Maybe a generalisation for "security"
case as features to back port in any case ?
Create release4.0 (and later when they will come) branches as proposed
by Jonathon ?
Jacques
De : "clearchris" <[EMAIL PROTECTED]>
I had no idea the can of worms this would open up when I entered the
issue.
I come down on the side of wanting this patch in the release branch.
Further, as there is no defined release date for 4.0, I would
consider it
still open for very high-priority issues that are not traditionally
defined
as "bugs". Ofbiz customers, if they are using the release branch in
production or close to production would probably do well to lag a bit
and
run with an older revision of the release branch. Regressions can
always be
an issue, even with bug "fixes".
Chris
-----Original Message-----
From: David E Jones [mailto:[EMAIL PROTECTED] Sent: Thursday,
November 15, 2007 4:11 PM
To: dev@ofbiz.apache.org
Subject: Re: release4.0: OFBIZ-1106 (in or out?)
On Nov 15, 2007, at 11:18 AM, Michael Jensen wrote:
Using that logic, you could say that almost any previous bugs were
really "as-implemented" features and no changes should ever be made
to
the current release branch.
If it was found somewhere in ofbiz that sensitive information was
submitted over http instead of https, would that be considered a bug?
Or would it be discounted as "well, it's a bad choice but that's
how it
was implemented"?
I understand that the difficult thing about this is that the bug/
feature
line has to be drawn somewhere. (I know where I'd draw it,
especially
on security related issues.)
It's really not that tough... As I described in depth in my previous
post in this thread there is no need to muddy the meaning of "bug".
Maybe the word you are looking for is "issue"?
This isn't a "bug" per-se, but certainly an "issue" and solving that
issue requires a new feature. That doesn't mean it can't go into the
release branch, but non-bug-fixes should be carefully considered
before being added.
I'm curious to see how things pan out on this. It will tell me how
seriously security is taken by the people driving ofbiz.
This is a common misconception. There are no "people driving ofbiz".
OFBiz is a community-driven project and things happen when a user
needs something, implements it, and contributes it back to the
project. Even committers on OFBiz are just users who have a long
history of contributions and are invited to be committers to
facilitate further involvement.
Security or not, things will only be fixed if someone cares enough.
The flip side of that is that if someone doesn't like how something
is in OFBiz and they don't do anything about it, they have only
themselves to blame, as uncomfortable and frighteningly empowering
as that may be. ;)
-David
Ray Barlow wrote:
As you say plenty of good points so rather than repeat lengthy
arguments
for or against I'll keep it simple and just say I don't think it
should
be described as a bug as it was implemented this way. Bad choice
maybe
but it's a feature change.
Having said that I do think it should be seriously considered for
the
release branch because of it's small footprint and improvement on
a very
weak and insecure area.
Ray
Dan Shields wrote:
Thanks Jacques. Is there any further action by me that might be
advised? I was wondering because I was considering declaring a
referendum on the issue on the user list as per David Jones'
suggestion.
Wow I guess that what we have here is "the absence of this new
feature
is a bug".
I must say, the dev-debate that it has inspired has been
impressive!
There are good arguments both for viewing the patch as a bug, as
well
as equally good arguments for viewing it as a feature. It really
surprised me because up until that point in time (when I blindly
stumbled into this) my view was entirely to think about it as a bug
only. The author of OFBIZ-1106 never knew the difference between
'code that failed to hide the password' and 'the complete absence
of
code that successfully hid the password', he just knew that the
software did not do 'as it should', and this was exactly my point
of
view in devising a solution as well. It requires a strong
metaphysical argument to even tell the difference between the
points
of fact that might exist in the software that would reveal the
actual
intent of the original design. My feeling is that it was either
overlooked accidentally, or it was not convenient to declare the
XUI
XPage in a manner that made sense to have both regular input and
password input in the same node of the tree but at different times
(this convenience is what I provided in the patch).
As I said above I am willing to take this to the user list and
invite
all users who run a release4.0 branch to submit an accept/reject
vote,
as I think this feature/bug (or bug/feature) is important enough to
the success of release4.0 to warrant.
I am happily sitting on the fence and content to let this issue go
either way. I am finding it fascinating.
Cheers all
Dan
------------------------------------------------------------------------
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.503 / Virus Database: 269.16.0/1135 - Release Date: 11/16/2007 10:58 PM
