Hi Jacques:
Please, lets discuss. Here's what I'd like to see:
A download button that points to a known, good release of OFBiz. I don't
care if its a 4.x or 9.x version. Just one that has been built and at
least runs the eCommerce demo with a minimum of problems. This version
should pass the agreed upon unit tests and functional tests. Problems
(including testing issues) that are known to exist should be document in
the README file or some other "Release Notes".
WDYT?
Regards,
Ruth
----------------------------------------------------
Find me on the web at http://www.myofbiz.com or Google Keyword "myofbiz"
ruth.hoff...@myofbiz.com
Jacques Le Roux wrote:
From: "David E Jones" <d...@me.com>
I suppose we are shameless optimists and hope that people will choose
to collaborate with other people using the software, and perhaps even
participate in the development.
Still, I agree the big download button is a bad design and I never
liked it given that there are various options to download and
personally I like the idea of making people make choices... ;)
If number of people don't like it, then it should be discussed
Jacques
() ascii ribbon campaign against HTML e-mail
/\ www.asciiribbon.org
-David
On Dec 7, 2009, at 11:28 AM, Ruth Hoffman wrote:
HI David:
If that resource is the "definitive" answer, then why does that "BIG
FAT DOWNLOAD" button/link point to a "trunk" build? Shouldn't it
point to a "release branch tag" build with a good probability of
working?
Am I missing something here?
Am I not reading all this information correctly?
Why does that button point to a build using Java 1.6 when that
couldn't possibly be a build that has any history of testing behind
it..you just started using Java 1.6 after all.
TIA
Ruth
David E Jones wrote:
This page might be helpful, and answers the more general question
behind the question:
http://cwiki.apache.org/confluence/display/OFBADMIN/Apache+OFBiz+Getting+Started
-David
On Dec 7, 2009, at 11:05 AM, Ruth Hoffman wrote:
Hi Anil:
I feel like I'm spitting in the wind here...Please, let's just
start this conversation over again. Under the following
circumstances, which version or release of OFBiz should I use?
I'm a new user and I want to customize my OFBiz instance for a new
ERP deployment.
TIA
Ruth
Find me on the web at http://www.myofbiz.com or Google Keyword
"myofbiz"
Anil Patel wrote:
Ruth,
Why don't you consider using one of the release branches?
Thanks and Regards
Anil Patel
HotWax Media Inc
Find us on the web at www.hotwaxmedia.com or Google Keyword "ofbiz"
On Dec 7, 2009, at 10:06 AM, Ruth Hoffman wrote:
Hi Scott:
Then stop the committing and do some reviewing. There is more to
software development than committing code to a repository.
This is interesting perspective. Trunk is expected to remain
active. New development must continue. For the people who needs
more stable version we do have release branch.
Regards,
Ruth
Scott Gray wrote:
On 7/12/2009, at 10:22 PM, Jeroen van der Wal wrote:
Thank you Jacques for addressing this as this situation
worries me
too. Although I think the power of the Ofbiz community can
handle it
:-)
My suggestions would be:
- Assign volunteers and a lead to each of the components. They
can
watch issues of their components and should can be consulted if
anybody wants to make changes in their neighbourhood.
We already have these volunteers, they're called people who
review commits and I could probably count them on one hand.
Everything you've suggested requires more resources than this
community can provide.
- Work bottom up: start with the framework, then the core modules
(party, product, accounting, workeffort, manufactureing,
order) and
finally the specialpurpose modules (I personally consider
humanres and
marketing to be specialpurpose)
- Communicate changes to dependent components so they can
sanitize
their components
- Don't allow code without tests
- Use branching for work in progress to maintain a stable
trunk (I
prefer Git over SVN but that's another topic...)
I'm a big fan of branching, this explains why:
- Code each task (or related set of tasks) in its own branch,
then you
will have the flexibility of when you would like to merge
these tasks
and perform a release.
- QA should be done on each branch before it is merged to the
trunk.
- By doing QA on each individual branch, you will know exactly
what
caused the bug easier.
- This solution scales to any number of developers.
- This method works since branching is an almost instant
operation in SVN.
- Tag each release that you perform.
- You can develop features that you don't plan to release for
a while
and decide exactly when to merge them.
- For all work you do, you can have the benefit of committing
your
code. If you work out of the trunk only, you will probably
keep your
code uncommitted a lot, and hence unprotected and without
automatic
history.
If you try to do the opposite and do all your development in
the trunk
you'll be plagged by:
- Constant build problems for daily builds
- Productivity loss when a a developer commits a problem for
all other
people on the project
- Longer release cycles, because you need to finally get a
stable version
- Less stable releases
Best,
Jeroen van der Wal
On Sat, Dec 5, 2009 at 8:51 PM, Jacques Le Roux
<jacques.le.r...@les7arts.com> wrote:
Hi,
I'd like to express a feeling I have. Actually it's not only
my own feeling but also something some users have expressed
recently.
I'm quite happy to see that these last times a lot of effort
have been made in order to fix OFBiz (yes to fix OFBiz!)
It's really great to see new features in OFBiz. But I really
wonder if we should not slow down the pace in integrating new
features for a short period of time and should not make and
even greatest effort to have a more stable OFBiz.
There are 180 bugs opened in Jira. Don't you think it's time
for the community to have a look at them and to fix the most
important ones (109 are considered as at least important) ?
Thanks
Jacques
