> Being more specific is far more helpful, BTW, than generalities.
Specifically, some of the DTDs contain stuff that are not yet implemented. The recent one that
comes to mind: I asked about in , I think. And BJ also highlighted 1 or 2
issues. Probably more coming up as I run through the codes
Thanks.
over on the User ML it was suggested I use the wiki.
so have created a User Document space there.
Jacques Le Roux sent the following on 11/28/2007 1:15 AM:
> BJ,
>
> If I understand you well, Jira seems the best place
>
> Jacques
>
> De : "BJ Freeman" <[EMAIL PROTECTED]>
>> Well I am p
BJ,
If I understand you well, Jira seems the best place
Jacques
De : "BJ Freeman" <[EMAIL PROTECTED]>
> Well I am pulling my foot out of mouth a lot.
> seems there is a sequence to do this and I have documented them
> question is where to put them so someone else does not have to hunt them
> dow
On Nov 27, 2007, at 7:02 PM, Jonathon -- Improov wrote:
BJ has mentioned a few outstanding issues that could make the binary
release look incomplete.
Frankly, OFBiz 4.0 is far from complete, but not because it doesn't
have anything more than half-baked features. It's because it has so
ma
Well I am pulling my foot out of mouth a lot.
seems there is a sequence to do this and I have documented them
question is where to put them so someone else does not have to hunt them
down and stumble like me.
Jonathon -- Improov sent the following on 11/27/2007 6:02 PM:
> BJ has mentioned a few o
BJ has mentioned a few outstanding issues that could make the binary release
look incomplete.
Frankly, OFBiz 4.0 is far from complete, but not because it doesn't have anything more than
half-baked features. It's because it has so many new features slapped on that are not fully
implemented yet.
De : "Jacques Le Roux" <[EMAIL PROTECTED]>
> De : "David E Jones" <[EMAIL PROTECTED]>
> > The release4.0 branch needs testing, and that is the point of this
> > thread. Of course there are bugs or issues, finding them and the
> > nature of them is the point of doing this. You're right that these
>
Need to decide what to do about code sections that are incomplete.
we have demo software that shows information as to how the software works.
the Demo software circumvents the actual processes to input and process
the actual items.
Case in point is the Feature.
https://localhost:8443/catalog/contro
Jonathon, all,
One day or another "we" will have to pass a vote about exposing officially the
release as tarball and such.
I guess one reason "we" don't do it as fast as you'd like is that it's a one
man process (David has exposed number of other reasons,
which you discussed below).
As David bri
Hmm. I didn't think about this, that we shouldn't release for sake of getting attention. It's true
that it is irritating to end-users if we release something not functional. OFBiz 4.0 is
functional. I haven't found any show-stopping bugs.
The reason for the release, IHMO, isn't to get attention
Call me reckless, but I don't think that bug should block binary release. As mentioned before,
obsolete a bad release if we need to. I'll be testing the framework a lot over the coming month,
so we might see another binary release if I happen to dig up enough critical bugs.
As the release branc
>> Perhaps a good 99% of the population don't want to hear the 3 letters "SVN"
>> when they attempt to download and test OFBiz.
> There is certainly a target audience in that. But consider the nature of
> OFBiz: it is most commonly used by developers or analysts that full-on
> customize or at lea
De : "David E Jones" <[EMAIL PROTECTED]>
> The release4.0 branch needs testing, and that is the point of this
> thread. Of course there are bugs or issues, finding them and the
> nature of them is the point of doing this. You're right that these
> exist and need attention. Whether they should block
Thanks Shi,
This is really the kind of feedbacks we need...
Jacques
De : "Shi Yusen" <[EMAIL PROTECTED]>
> We have 2 programmers developing components on 4.0 branch for 4 months
> and never heard any bugs found until now. The specialpurpose, eCommerce,
> content, manufacturing are the components
I'd suggest to move all the i18n files outside the framework except the
defaults, only well qualified programmers can touch the code.
Shi Yusen/Beijing Langhua Ltd.
在 2007-11-26一的 13:22 -0700，David E Jones写道：
> The release4.0 branch needs testing, and that is the point of this
> thread. Of cou
We have 2 programmers developing components on 4.0 branch for 4 months
and never heard any bugs found until now. The specialpurpose, eCommerce,
content, manufacturing are the components we didn't touch.
BTW, we have started to integrate jbpm with the 4.0 branch.
Regards,
Shi Yusen/Beijing Langh
But +1 for what reason?
We will NOT release this just to get attention. We will release it
when there is at least a small consensus that it is ready.
-David
On Nov 26, 2007, at 1:19 PM, BJ Freeman wrote:
+1 beta
probably the only way it will ever get any attention.
David E Jones sent t
The release4.0 branch needs testing, and that is the point of this
thread. Of course there are bugs or issues, finding them and the
nature of them is the point of doing this. You're right that these
exist and need attention. Whether they should block a binary release
is another question a
+1 beta
probably the only way it will ever get any attention.
David E Jones sent the following on 11/26/2007 11:44 AM:
>
> On Nov 26, 2007, at 9:19 AM, Jacques Le Roux wrote:
>
>> BTW I think the time is coming to answer questions like in
>> http://docs.ofbiz.org/display/OFBADMIN/Demo+and+Test+
as per the bug found today on
Re: HtmlWidget missing a MapStack pop?
there are bugs and ver 40 needs a good test.
per the commit on this bug
Ver 4.0 was not updated.
:(
Jacopo Cappellato sent the following on 11/26/2007 11:52 AM:
> Frankly speaking, my interest for the release branch is low, I'v
Frankly speaking, my interest for the release branch is low, I've not
tested it too much and I usually suggest to clients to build their
fortune on the trunk.
That said it would be great to release it, if there is consensus from
the community.
Jacopo
David E Jones wrote:
On Nov 26, 2007, at
On Nov 26, 2007, at 9:19 AM, Jacques Le Roux wrote:
BTW I think the time is coming to answer questions like in
http://docs.ofbiz.org/display/OFBADMIN/Demo+and+Test+Setup+Guide?focusedCommentId=2604#comment-2604
What to you think, you developpers ?
I think first things first...
The first que
On Nov 26, 2007, at 10:32 AM, Jonathon -- Improov wrote:
The way we are doing it now, it's anal-retentive. It's like saying
"wait, boss, one more bugfix, just one more", and saying that for a
whole long year! I usually publish "release candidates" for my boss,
let him test it, let him scre
> Do you mean that a tag is also a lazy copie like branches are ?
Yup. Under the hood in SVN, it's exactly like a branch. As I said, a "tag" in SVN is really a
"branch" that is frozen. It is frozen by policy or by self-discipline (human endeavor).
In fact, think of it this way, may be easier.
Jonathon,
I just re-read you message below and I'm not quite sure to understand because
for me a tag is just a name for a revision number.
I wrote
> > Notably < > and pre-built package will be issued>>
You answered
> What this means is:
>
> 1. Receive fixes for OFBiz 4.0 branch (it's a progres
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 th
h 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
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 ?
> > >>
> > >>
On 17/11/2007, Jonathon -- Improov <[EMAIL PROTECTED]> wrote:
>
> Ok, ok. I feel so manipulated (private joke with Scott). :P
Don't feel too bad, it's part of my role here to encourage contributions :-)
Scott
on 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@ofb
s" <[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
e 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. Regr
es 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
der 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 P
gt; 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?)
>
>
&g
e-
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
&
De : "Jonathon -- Improov" <[EMAIL PROTECTED]>
> Still, I do understand that it's a hassle to have to apply 10s of mini
> patches every time I deploy
> a new 4.0 implementation.
You cant put them in one sole parch, this is not the harder part, collecting
them might be
> What does everyone think
Still, I do understand that it's a hassle to have to apply 10s of mini patches every time I deploy
a new 4.0 implementation.
What does everyone think of labeling OFBiz 4.0 "beta", and creating an "alpha" OFBiz 4.1 where we
can dump such critical enhancements? See my previous post in this thread
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 o
hehe..
That came across much stronger than I intended.
I love the ofbiz project and a single decision like this one will not
sway me to think that security issues aren't taken seriously by those
driving ofbiz. Many small decisions (if poor ones in _my_ view) would
slowly change _my_ opinion of ho
Michael Jensen wrote:
...
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.
Wow... this is a huge pressure! :-)
Jacopo
Mike
Yeah, no doubt Mike - laying it on thick!
Cheers,
Tim
--
Tim Ruppert
HotWax Media
http://www.hotwaxmedia.com
o:801.649.6594
f:801.649.6595
On Nov 15, 2007, at 11:33 AM, Jacopo Cappellato wrote:
Michael Jensen wrote:
...
I'm curious to see how things pan out on this. It will tell me how
ser
Lets remind everyone that there is a patch for the security.
it is available to anyone that wants to apply it.
I do this to my Ver 4.0 (not svn) on patches that have been done to the
trunk.
You can have access to all patches that are done to both the trunk and
the branch by subscribing to the Commi
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 bu
My concern is that exposes a password and nowhere else in the system does
that happen. We have hundreds (thousands?) of lines of security code and
this undoes all of that by potentially allowing anyone access to the entire
system.
Scott
On 16/11/2007, Ray Barlow <[EMAIL PROTECTED]> wrote:
>
> As
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 cons
6594
f:801.649.6595
On Nov 14, 2007, at 10:59 AM, Scott Gray wrote:
I'm not agiainst it, +1
Scott
On 15/11/2007, Vince M. Clark <[EMAIL PROTECTED]> wrote:
+1
Vince Clark
Global Era
The Freedom of Open Source
[EMAIL PROTECTED]
(303) 493-6723
- Original Message -
From:
PROTECTED]
(303) 493-6723
- Original Message -----
From: "Adrian Crum" <[EMAIL PROTECTED]>
To: dev@ofbiz.apache.org
Sent: Wednesday, November 14, 2007 10:16:31 AM (GMT-0700)
America/
Denver
Subject: Re: release4.0: OFBIZ-1106 (in or out?)
While technically it is not a bug fix
I'm not agiainst it, +1
Scott
On 15/11/2007, Vince M. Clark <[EMAIL PROTECTED]> wrote:
+1
Vince Clark
Global Era
The Freedom of Open Source
[EMAIL PROTECTED]
(303) 493-6723
- Original Message -----
From: "Adrian Crum" <[EMAIL PROTECTED]>
To: dev@ofbiz.apache.org
Sent:
CTED]
(303) 493-6723
----- Original Message -----
From: "Adrian Crum" <[EMAIL PROTECTED]>
To: dev@ofbiz.apache.org
Sent: Wednesday, November 14, 2007 10:16:31 AM (GMT-0700) America/
Denver
Subject: Re: release4.0: OFBIZ-1106 (in or out?)
While technically it is not a bug fix, I be
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,
I have asked Dan to send this question to the dev list since I was shared
between my will to back-port and my duty to not do it on
my sole opinion
+1 for me
Thanks for your work Dan
Jacques
De : "Dan Shields" <[EMAIL PROTECTED]>
> Thanks Jacques for helping get my patch for OFBIZ-1106 into OFB
maybe an approach is to have in the truck . with a note that this is a
ver4.0 compatible patch.
that way if some one wants to apply it they can in there local copy.
This may be the way for all future patches is to note if they can be
applied to a release version..
Dan Shields sent the following o
ednesday, November 14, 2007 10:16:31 AM (GMT-0700) America/
Denver
Subject: Re: release4.0: OFBIZ-1106 (in or out?)
While technically it is not a bug fix, I believe it should go in
anyway - since the release is
intended to be widely deployed, and the problem your patch
addresses might be a deal
gt;>> +1
>>>>
>>>> Vince Clark
>>>> Global Era
>>>> The Freedom of Open Source
>>>> [EMAIL PROTECTED]
>>>> (303) 493-6723
>>>>
>>>> - Original Message -
>>>> From: "Adrian Crum
IL PROTECTED]> wrote:
+1
Vince Clark
Global Era
The Freedom of Open Source
[EMAIL PROTECTED]
(303) 493-6723
- Original Message -
From: "Adrian Crum" <[EMAIL PROTECTED]>
To: dev@ofbiz.apache.org
Sent: Wednesday, November 14, 2007 10:16:31 AM (GMT-0700) America/
Denver
Sub
PROTECTED]
(303) 493-6723
- Original Message -
From: "Adrian Crum" <[EMAIL PROTECTED]>
To: dev@ofbiz.apache.org
Sent: Wednesday, November 14, 2007 10:16:31 AM (GMT-0700) America/
Denver
Subject: Re: release4.0: OFBIZ-1106 (in or out?)
While technically it is not a bug fix,
t;[EMAIL PROTECTED]>
> To: dev@ofbiz.apache.org
> Sent: Wednesday, November 14, 2007 10:16:31 AM (GMT-0700) America/Denver
> Subject: Re: release4.0: OFBIZ-1106 (in or out?)
>
> While technically it is not a bug fix, I believe it should go in anyway -
> since the release is
>
elease4.0: OFBIZ-1106 (in or out?)
While technically it is not a bug fix, I believe it should go in anyway - since
the release is
intended to be widely deployed, and the problem your patch addresses might be a
deal breaker for
those who are considering deploying the release.
+1 for includi
While technically it is not a bug fix, I believe it should go in anyway - since the release is
intended to be widely deployed, and the problem your patch addresses might be a deal breaker for
those who are considering deploying the release.
+1 for including it.
-Adrian
Dan Shields wrote:
Tha
60 matches
Mail list logo
