Bugs and open Jira issues
Locked
123
123
Bugs and open Jira issues
 
Administrator
|
Re: Bugs and open Jira issues
|
Re: Bugs and open Jira issues
|
|
Re: Bugs and open Jira issues
|
Administrator
|
Re: Bugs and open Jira issues
|
|
Re: Bugs and open Jira issues
|
|
Re: Bugs and open Jira issues
|
|
Re: Bugs and open Jira issues
|
|
Re: Bugs and open Jira issues
|
|
Re: Bugs and open Jira issues
|
|
Re: Bugs and open Jira issues
|
Administrator
|
Re: Bugs and open Jira issues
|
|
I disagree, there always have been and always will be bugs in OFBiz,
there is no escaping this fact. The only reason there are more bugs now than there were 3 years ago is because there is more community activity. Fixing the bugs in jira will not prevent new bugs from replacing them (and some of the replacements will be the same bugs we just fixed). IMO the best thing we can do for the stability of the project is to create tests every time we create or modify a service, be it during a bug fix or while implementing new functionality. Doing so locks in the desired behavior and prevents anyone from unknowingly changing that behavior. Even without intervention, bugs naturally get fixed over time as people come to require the functionality being blocked by the bug, the key is to do everything we can to reduce the number of new bugs being created. Regards Scott HotWax Media http://www.hotwaxmedia.com On 7/12/2009, at 8:49 PM, Jacques Le Roux wrote: > Thi is all great, > > Put please ladies/gents don't get out of subject. > I still think the 1st step is to fix the bugs we know exist, are > documented in Jira and even ready to be fixed with patches for some. > > Jacques > () ascii ribbon campaign against HTML e-mail > /\ www.asciiribbon.org > > > From: "Anil Patel" <[hidden email]> >> We do see some great Ideas around what is needed. There was lot of >> conversation on this topic in ApacheCon 2008 and then in 2009 >> (based on messages on list). >> >> You will be surprised there is lot done. We have seen lot of >> activity in documenting business processes and end user >> documentation. >> >> More recently David proposed a simple system derived from Ofbiz >> that will address needs of small business. >> >> We have lot more Ofbiz technical contributors then Business process >> knowledge contributors. It will be really nice if people in this >> part of community will step up. It will be nice if business users >> or power business users who are technical developers as well >> started to take part of requirement documents and add to UBPL or >> EZBIZ effort. >> >> If users can document their business processes needs, give some >> wireframe help then technical developers will be able to help map >> them to OOTB features (Gap Analysis). >> >> Unless we get real business requirements documents coming from user >> community there is no way for us to fulfill them. >> >> I hope you understand I am not asking anybody to break NDA or >> whatever. >> >> Thanks and Regards >> Anil Patel >> HotWax Media Inc >> Find us on the web at www.hotwaxmedia.com or Google Keyword "ofbiz" >> >> On Dec 6, 2009, at 8:22 PM, Cimballi wrote: >> >>> Hi devs, >>> >>> Here my opinion about the subject. >>> To make things clear, it makes about 3-4 month I am working with >>> OFBiz, using it to implement a project. >>> >>> I thing one way to have more people involved in the project is to >>> lower the "difficulty level" required to understand OFBiz. >>> >>> And for this there are several possbilities, and I will focus on >>> two : >>> - modularize the project >>> - more functional documentation inside the source files >>> >>> Modularize the project >>> >>> I've seen this subject has already been discussed and I think it can >>> profit to the project in several points : >>> - more modules means less code in each module, which means modules >>> are >>> eaiser to understand, which means more developer may be >>> interesting to >>> participate to its development, test, ... There is at least one >>> obvious module which could be very interesting to externalize, it's >>> the entity engine. I don't know so much OFBiz architecture but I >>> think >>> it should be possible to externalize this module and a lot of >>> projects >>> totally different of OFBiz could be interesting in it, and so >>> potentially a lot more developers to maintain and enhance it. >>> - on another side, more modules would also make it easier to >>> distribute the issues, each developer specialized on a specific >>> module. Maybe it's already the case... >>> >>> More functional documentation inside the source files >>> >>> Here my feeling is that with OFBiz, you really requires both >>> technical >>> and functional knowledge to understand how the project work. Some >>> part >>> like the entity engine are purely technical, but the order module >>> for >>> example is really functional, I mean, you need to know a lot about >>> how >>> ordering works in a company to be able to use the module and even >>> more >>> to custommize or propose enhancements to it. So, with more >>> documentation in the source files, like the XML entity files, and >>> then >>> in the source code for example explaining what a method concretly >>> does >>> may help a lot to understand OFBiz. It seems the link David sent >>> about >>> UBML is about his. >>> >>> Here is my feeling about OFBiz as a fresh developers. I try to >>> participate to the project at least by providing bug reports, I >>> still >>> feel for away from providing patches ! :-) >>> >>> Hope this will help you, devs, the project is already great, let's >>> make it more accessible ! >>> >>> Cimballi >> > > |
smime.p7s (4K)
Re: Bugs and open Jira issues
|
Administrator
|
Re: Bugs and open Jira issues
|
|
Re: Bugs and open Jira issues
|
|
In reply to this post by Jacques Le Roux
On 7/12/2009, at 10:05 PM, Jacques Le Roux wrote:
> Please Scott, > > Inline... > > From: "Scott Gray" <[hidden email]> >> I disagree, there always have been and always will be bugs in >> OFBiz, there is no escaping this fact. The only reason there are >> more bugs now than there were 3 years ago is because there is more >> community activity. Fixing the bugs in jira will not prevent new >> bugs from replacing them (and some of the replacements will be the >> same bugs we just fixed). > > Don't misundersand me. I'm not worried about new bugs. I totally > understand that this is intrinsic nature of software. > My point is only for us to give more love to these 109 issues > waiting attention in Jira, nothing else... for those bugs first. Every code change (even bug fixes) carries the risk of introducing new bugs and the only thing we can do to reduce that risk is to write tests. Without tests the number of bugs in jira will never do anything but increase. >> IMO the best thing we can do for the stability of the project is >> to create tests every time we create or modify a service, be it >> during a bug fix or while implementing new functionality. Doing >> so locks in the desired behavior and prevents anyone from >> unknowingly changing that behavior. > > Yes, I plenty agree > >> Even without intervention, bugs naturally get fixed over time as >> people come to require the functionality being blocked by the bug, >> the key is to do everything we can to reduce the number of new >> bugs being created. > > I totally agree, I can agree more I should say. i think I should > have used "Opened important Jira issues" as subject :/ > > Jacques > () ascii ribbon campaign against HTML e-mail > /\ www.asciiribbon.org > >> Regards >> Scott >> HotWax Media >> http://www.hotwaxmedia.com >> On 7/12/2009, at 8:49 PM, Jacques Le Roux wrote: >>> Thi is all great, >>> >>> Put please ladies/gents don't get out of subject. >>> I still think the 1st step is to fix the bugs we know exist, are >>> documented in Jira and even ready to be fixed with patches for some. >>> >>> Jacques >>> () ascii ribbon campaign against HTML e-mail >>> /\ www.asciiribbon.org >>> >>> >>> From: "Anil Patel" <[hidden email]> >>>> We do see some great Ideas around what is needed. There was lot >>>> of conversation on this topic in ApacheCon 2008 and then in >>>> 2009 (based on messages on list). >>>> >>>> You will be surprised there is lot done. We have seen lot of >>>> activity in documenting business processes and end user >>>> documentation. >>>> >>>> More recently David proposed a simple system derived from Ofbiz >>>> that will address needs of small business. >>>> >>>> We have lot more Ofbiz technical contributors then Business >>>> process knowledge contributors. It will be really nice if people >>>> in this part of community will step up. It will be nice if >>>> business users or power business users who are technical >>>> developers as well started to take part of requirement documents >>>> and add to UBPL or EZBIZ effort. >>>> >>>> If users can document their business processes needs, give some >>>> wireframe help then technical developers will be able to help >>>> map them to OOTB features (Gap Analysis). >>>> >>>> Unless we get real business requirements documents coming from >>>> user community there is no way for us to fulfill them. >>>> >>>> I hope you understand I am not asking anybody to break NDA or >>>> whatever. >>>> >>>> Thanks and Regards >>>> Anil Patel >>>> HotWax Media Inc >>>> Find us on the web at www.hotwaxmedia.com or Google Keyword "ofbiz" >>>> >>>> On Dec 6, 2009, at 8:22 PM, Cimballi wrote: >>>> >>>>> Hi devs, >>>>> >>>>> Here my opinion about the subject. >>>>> To make things clear, it makes about 3-4 month I am working with >>>>> OFBiz, using it to implement a project. >>>>> >>>>> I thing one way to have more people involved in the project is to >>>>> lower the "difficulty level" required to understand OFBiz. >>>>> >>>>> And for this there are several possbilities, and I will focus >>>>> on two : >>>>> - modularize the project >>>>> - more functional documentation inside the source files >>>>> >>>>> Modularize the project >>>>> >>>>> I've seen this subject has already been discussed and I think it >>>>> can >>>>> profit to the project in several points : >>>>> - more modules means less code in each module, which means >>>>> modules are >>>>> eaiser to understand, which means more developer may be >>>>> interesting to >>>>> participate to its development, test, ... There is at least one >>>>> obvious module which could be very interesting to externalize, >>>>> it's >>>>> the entity engine. I don't know so much OFBiz architecture but >>>>> I think >>>>> it should be possible to externalize this module and a lot of >>>>> projects >>>>> totally different of OFBiz could be interesting in it, and so >>>>> potentially a lot more developers to maintain and enhance it. >>>>> - on another side, more modules would also make it easier to >>>>> distribute the issues, each developer specialized on a specific >>>>> module. Maybe it's already the case... >>>>> >>>>> More functional documentation inside the source files >>>>> >>>>> Here my feeling is that with OFBiz, you really requires both >>>>> technical >>>>> and functional knowledge to understand how the project work. >>>>> Some part >>>>> like the entity engine are purely technical, but the order >>>>> module for >>>>> example is really functional, I mean, you need to know a lot >>>>> about how >>>>> ordering works in a company to be able to use the module and >>>>> even more >>>>> to custommize or propose enhancements to it. So, with more >>>>> documentation in the source files, like the XML entity files, >>>>> and then >>>>> in the source code for example explaining what a method >>>>> concretly does >>>>> may help a lot to understand OFBiz. It seems the link David >>>>> sent about >>>>> UBML is about his. >>>>> >>>>> Here is my feeling about OFBiz as a fresh developers. I try to >>>>> participate to the project at least by providing bug reports, I >>>>> still >>>>> feel for away from providing patches ! :-) >>>>> >>>>> Hope this will help you, devs, the project is already great, let's >>>>> make it more accessible ! >>>>> >>>>> Cimballi >>>> >>> >>> >> > |
Re: Bugs and open Jira issues
|
|
Re: Bugs and open Jira issues
|
|
Re: Bugs and open Jira issues
|
|
In reply to this post by Jeroen van der Wal-2
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 > <[hidden email]> 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 >> >> >> |
Re: Bugs and open Jira issues
|
Re: Bugs and open Jira issues
|
|
| Free forum by Nabble | Edit this page |