Ofbiz Contribution Proposal
Locked
123
123
Ofbiz Contribution Proposal
 
|
Hi,
we use Ofbiz (mostly the entity engine) for over 2 years now. Last year I had mail contact with David. He recommended to contribute changes to the Ofbiz Community regularly whenever possible and useful. It is a long time since this happened, but we finally convinced our management to try to contribute some changes and extensions to the Ofbiz community. I read the FAQ and found out that especially complex changes might take a long time and we may need some "community attendance". David told me to place our proposal at the Ofbiz-WIKI and to send a link to this mailing list. This is our "trial balloon" to find out whether our changes and improvements are welcome and how we could integrate them during the next months. I.e. the following extensions may also be interesting for other members of the community: * Advanced custom SQL integration * advanced sorting (locale, collation, natural sort) * completely refactored TransactionUtil with documentation and hints * on-demand "real"-sql-logging for ALL ofbiz statements ... I placed our stuff at http://docs.ofbiz.org/display/OFBIZ/Key-Work+Ofbiz+Contribution+Proposal and hope one of the "Ofbiz gurus" will have a look at the attached stuff to make a statement. Thank you in advance! Best regards Karl Eilebrecht -- Karl Eilebrecht Key-Work Consulting GmbH Kriegsstr. 100 - 76133 Karlsruhe - Germany Fon: +49-721-78203-277 - Fax: +49-721-78203-10 [hidden email] Key-Work Consulting GmbH Karlsruhe, HRB 108695, HRG Mannheim Geschäftsführer: Andreas Stappert, Tobin Wotring |
|
|
Thanks for your. Contribution, they are always welcome. Contributions
of this size may take long to before they get into trunk, in this case timing if also a factor. Community is planning a release after long time so they will try to avoid major changes to framework component. Please be patient I am sure some body will look at it. In order to make it easy to review ca it be broken into smaller patches. Regards On 4/20/07, Eilebrecht, Karl (Key-Work) <[hidden email]> wrote: > Hi, > > > > we use Ofbiz (mostly the entity engine) for over 2 years now. > > > > Last year I had mail contact with David. > > > > He recommended to contribute changes to the Ofbiz Community regularly > whenever possible and useful. > > > > It is a long time since this happened, but we finally convinced our > management to try > > > > to contribute some changes and extensions to the Ofbiz community. > > > > I read the FAQ and found out that especially complex changes might take a > long time > > > > and we may need some "community attendance". > > > > David told me to place our proposal at the Ofbiz-WIKI > > and to send a link to this mailing list. > > > > This is our "trial balloon" to find out whether our changes and improvements > > > > are welcome and how we could integrate them during the next months. > > > > I.e. the following extensions may also be interesting for other members > > of the community: > > > > * Advanced custom SQL integration > > * advanced sorting (locale, collation, natural sort) > > * completely refactored TransactionUtil with documentation and hints > > * on-demand "real"-sql-logging for ALL ofbiz statements > > ... > > > > I placed our stuff at > http://docs.ofbiz.org/display/OFBIZ/Key-Work+Ofbiz+Contribution+Proposal > > and hope one of the "Ofbiz gurus" will have a look at the attached stuff to > make a statement. > > > > Thank you in advance! > > > > Best regards > > > > Karl Eilebrecht > > -- > Karl Eilebrecht > Key-Work Consulting GmbH > > Kriegsstr. 100 - 76133 Karlsruhe - Germany > Fon: +49-721-78203-277 - Fax: +49-721-78203-10 > [hidden email] > > > Key-Work Consulting GmbH Karlsruhe, HRB 108695, HRG Mannheim > Geschäftsführer: Andreas Stappert, Tobin Wotring > > |
|
|
Karl,
I believe the community is branching a release this Friday (now?). After forking a release branch, the trunk can and SHOULD be free to blaze ahead rapidly, even with loads of new enhancements from yourself. The idea of separate branches is simply to have multiple prongs of activity for various intentions, each prong insulated from the others. The release branch will be "slow-moving waters", gradually and surely stabilizing into a solid-in-stone release. The trunk is NOT meant for stabilizing, but for ongoing progress. In the worst case, the community should consider forking an "exploratory" branch to test out your contributions, and then merge those contributions into trunk after ironing out any incompatibilities between OFBiz codes and your codes. I believe you are already maintaining your own SVN for your own modified OFBiz, and you should be pulling in updates regularly from OFBiz trunk. I am doing just that. If this is your objective: To get the latest and greatest of OFBiz merged with your proven (2 years) enhancements, let me know. I'll take in your enhancements and merge them in with OFBiz trunk right now, and then hand the whole "greater than sum of parts" assembly back to you. We'll iron out incompatibilities rapidly in another "slow-moving waters" branch called "Karl's Exploratory Branch". Only condition, of course, is that you expressly indicate that your enhancements are to be put under ASL, or any other license completely compatible with the one OFBiz is currently using. We shouldn't turn away complex contributions anymore. I myself have loads of enhancements (mostly to widget module) that I feel uneasy about releasing to the community, simply because of this odd use of trunk: it's used like a slow-moving release branch that is unable to handle introductions of radical enhancements. Yet, this somewhat slow-moving trunk isn't still enough and focused enough on achieving release-quality stability. It's the worst of both worlds: it's not rapid enough to allow for radical progress, and not calm and focused-on-cleaning-up enough to produce a stable release for non-OFBiz developers. Jonathon Anil Patel wrote: > Thanks for your. Contribution, they are always welcome. Contributions > of this size may take long to before they get into trunk, in this case > timing if also a factor. Community is planning a release after long > time so they will try to avoid major changes to framework component. > > Please be patient I am sure some body will look at it. > > In order to make it easy to review ca it be broken into smaller patches. > > Regards > > > On 4/20/07, Eilebrecht, Karl (Key-Work) <[hidden email]> > wrote: >> Hi, >> >> >> >> we use Ofbiz (mostly the entity engine) for over 2 years now. >> >> >> >> Last year I had mail contact with David. >> >> >> >> He recommended to contribute changes to the Ofbiz Community regularly >> whenever possible and useful. >> >> >> >> It is a long time since this happened, but we finally convinced our >> management to try >> >> >> >> to contribute some changes and extensions to the Ofbiz community. >> >> >> >> I read the FAQ and found out that especially complex changes might take a >> long time >> >> >> >> and we may need some "community attendance". >> >> >> >> David told me to place our proposal at the Ofbiz-WIKI >> >> and to send a link to this mailing list. >> >> >> >> This is our "trial balloon" to find out whether our changes and >> improvements >> >> >> >> are welcome and how we could integrate them during the next months. >> >> >> >> I.e. the following extensions may also be interesting for other members >> >> of the community: >> >> >> >> * Advanced custom SQL integration >> >> * advanced sorting (locale, collation, natural sort) >> >> * completely refactored TransactionUtil with documentation and hints >> >> * on-demand "real"-sql-logging for ALL ofbiz statements >> >> ... >> >> >> >> I placed our stuff at >> http://docs.ofbiz.org/display/OFBIZ/Key-Work+Ofbiz+Contribution+Proposal >> >> and hope one of the "Ofbiz gurus" will have a look at the attached >> stuff to >> make a statement. >> >> >> >> Thank you in advance! >> >> >> >> Best regards >> >> >> >> Karl Eilebrecht >> >> -- >> Karl Eilebrecht >> Key-Work Consulting GmbH >> >> Kriegsstr. 100 - 76133 Karlsruhe - Germany >> Fon: +49-721-78203-277 - Fax: +49-721-78203-10 >> [hidden email] >> >> >> Key-Work Consulting GmbH Karlsruhe, HRB 108695, HRG Mannheim >> Geschäftsführer: Andreas Stappert, Tobin Wotring >> >> > > |
Re: Ofbiz Contribution Proposal
|
|
On Apr 20, 2007, at 9:04 PM, Jonathon -- Improov wrote: > We shouldn't turn away complex contributions anymore. "We" do not now, nor have we ever, turned away a contribution because it was complex. > I myself have loads of enhancements (mostly to widget module) that > I feel uneasy about releasing to the community, simply because of > this odd use of trunk: it's used like a slow-moving release branch > that is unable to handle introductions of radical enhancements. > > Yet, this somewhat slow-moving trunk isn't still enough and focused > enough on achieving release-quality stability. It's the worst of > both worlds: it's not rapid enough to allow for radical progress, > and not calm and focused-on-cleaning-up enough to produce a stable > release for non-OFBiz developers. fairly consistent along these lines. I think what would be helpful to you, and to anyone reading and agreeing with your comments, is to step back and try to explain why things are the way they are. Feel free to share that with the group for a sanity check if you'd like. -David |
smime.p7s (3K) |
|
David,
> "We" do not now, nor have we ever, turned away a contribution because it > was complex. Very well, I'll just use the word "you" then. I take it that you do not turn away contributions because they were complex. The question from me would be whether you do or do not turn away, knowingly or not, contributions that are valid but too complex for review. It's not rhetorical, but you're free to do your own sanity/verification checks on that supposed phenomenon and deem it rhetorical or invalid. > Could you do us all a big favor Jonathon? Your comments seem to be > fairly consistent along these lines. I think what would be helpful to > you, and to anyone reading and agreeing with your comments, is to step > back and try to explain why things are the way they are. Feel free to > share that with the group for a sanity check if you'd like. I'm not so sure of the "why" of things, but am only more certain of the "what" of things. Things are the way they are, no matter how we interpret the "why". So, for now, I continue to merge in (to my own SVN) several contributions that are deemed too difficult to review/merge by the committers. I continue to keep such enhancements in step with updates from OFBiz trunk. And I continue in my failure(?) to feed such "compatibilized/merged" enhancements back to OFBiz trunk even though they really are the same license. And the phenomenon of several of us (incompatible contributors?) holding on to our own enhancements will continue. Some of us may not know how to keep in step with OFBiz trunk updates; others may. Those of us who can keep in step will continue to benefit from OFBiz progress, but be unable to feed the benefit back to OFBiz. There will still be enhancements out there that are kept away/apart from OFBiz. That's the way of things? Or maybe not? I stand corrected. I think I am "helping" OFBiz in the wrong way. I'll stop that. :) Thanks for reminding me. I was waiting to dump the loads of my enhancements into your trunk, but I think I should take a sanity check for now. Anyway, there needs to be at least one stabilizing branch (save point, so to speak) before we can go full steam with the trunk. And there's still no such branch yet. Jonathon David E. Jones wrote: > > On Apr 20, 2007, at 9:04 PM, Jonathon -- Improov wrote: > >> We shouldn't turn away complex contributions anymore. > > "We" do not now, nor have we ever, turned away a contribution because it > was complex. > >> I myself have loads of enhancements (mostly to widget module) that I >> feel uneasy about releasing to the community, simply because of this >> odd use of trunk: it's used like a slow-moving release branch that is >> unable to handle introductions of radical enhancements. >> >> Yet, this somewhat slow-moving trunk isn't still enough and focused >> enough on achieving release-quality stability. It's the worst of both >> worlds: it's not rapid enough to allow for radical progress, and not >> calm and focused-on-cleaning-up enough to produce a stable release for >> non-OFBiz developers. > > Could you do us all a big favor Jonathon? Your comments seem to be > fairly consistent along these lines. I think what would be helpful to > you, and to anyone reading and agreeing with your comments, is to step > back and try to explain why things are the way they are. Feel free to > share that with the group for a sanity check if you'd like. > > -David > > |
|
|
I sense this discussion may be hijacking Karl's thread, thus the
subject change. Karl's proposal looks very interesting and deserves its own thread. <trying to turn this to constructive dialog> Jonathon, which enhancement are you speaking of that hasn't had the opportunity to be reviewed sufficiently? As soon as the formal vote concludes on the branch, I'm sure there will be a lot of dialog about direction and features and approaches to bug fixes in the coming days and weeks. If someone replies to this, please cut of the (was...) in the subject --- Jonathon -- Improov <[hidden email]> wrote: > David, > > > "We" do not now, nor have we ever, turned away a contribution > because it > > was complex. > > Very well, I'll just use the word "you" then. I take it that you do > not turn away contributions > because they were complex. > > The question from me would be whether you do or do not turn away, > knowingly or not, contributions > that are valid but too complex for review. It's not rhetorical, but > you're free to do your own > sanity/verification checks on that supposed phenomenon and deem it > rhetorical or invalid. > > > Could you do us all a big favor Jonathon? Your comments seem to be > > fairly consistent along these lines. I think what would be helpful > to > > you, and to anyone reading and agreeing with your comments, is to > step > > back and try to explain why things are the way they are. Feel free > to > > share that with the group for a sanity check if you'd like. > > I'm not so sure of the "why" of things, but am only more certain of > the "what" of things. Things > are the way they are, no matter how we interpret the "why". > > So, for now, I continue to merge in (to my own SVN) several > contributions that are deemed too > difficult to review/merge by the committers. I continue to keep such > enhancements in step with > updates from OFBiz trunk. And I continue in my failure(?) to feed > such "compatibilized/merged" > enhancements back to OFBiz trunk even though they really are the same > license. > > And the phenomenon of several of us (incompatible contributors?) > holding on to our own > enhancements will continue. Some of us may not know how to keep in > step with OFBiz trunk updates; > others may. Those of us who can keep in step will continue to benefit > from OFBiz progress, but be > unable to feed the benefit back to OFBiz. There will still be > enhancements out there that are kept > away/apart from OFBiz. That's the way of things? Or maybe not? > > I stand corrected. I think I am "helping" OFBiz in the wrong way. > I'll stop that. :) Thanks for > reminding me. > > I was waiting to dump the loads of my enhancements into your trunk, > but I think I should take a > sanity check for now. Anyway, there needs to be at least one > stabilizing branch (save point, so to > speak) before we can go full steam with the trunk. And there's still > no such branch yet. > > Jonathon > > David E. Jones wrote: > > > > On Apr 20, 2007, at 9:04 PM, Jonathon -- Improov wrote: > > > >> We shouldn't turn away complex contributions anymore. > > > > "We" do not now, nor have we ever, turned away a contribution > because it > > was complex. > > > >> I myself have loads of enhancements (mostly to widget module) that > I > >> feel uneasy about releasing to the community, simply because of > this > >> odd use of trunk: it's used like a slow-moving release branch that > is > >> unable to handle introductions of radical enhancements. > >> > >> Yet, this somewhat slow-moving trunk isn't still enough and > focused > >> enough on achieving release-quality stability. It's the worst of > both > >> worlds: it's not rapid enough to allow for radical progress, and > not > >> calm and focused-on-cleaning-up enough to produce a stable release > for > >> non-OFBiz developers. > > > > Could you do us all a big favor Jonathon? Your comments seem to be > > fairly consistent along these lines. I think what would be helpful > to > > you, and to anyone reading and agreeing with your comments, is to > step > > back and try to explain why things are the way they are. Feel free > to > > share that with the group for a sanity check if you'd like. > > > > -David > > > > > > |
|
|
Chris,
I don't know offhand which enhancements (currently on Jira) are not reviewed. I only know those I have with me. I feel we should never let newcomers (or even old timers) hear something like "please dump your stuff in that corner, and we'll get to it in time". No, not that we'd be rude. Just that we'd lose that contribution! We're on the receiving end, so I suggest we start begging for the contribution instead. Being reasonably experienced/adept with version control systems (SVN/CVS), I can't see why we can't have someone perform a wholesale merge (to resolve incompatibilities) on a "crazy, no holds barred branch". Then we may ask, "ok, so who's gonna test that crazy branch and deem it adequately compatilibized/merged to be patched back into trunk"? That's why I'm guessing that our (contributors') main motivation for donating codes is to have the latest and greatest of OFBiz work with our tested enhancements. The code contributor himself will start using that crazy branch, just to see his own enhancements working in tandem with the latest and greatest of OFBiz. Jonathon Chris Howe wrote: > I sense this discussion may be hijacking Karl's thread, thus the > subject change. Karl's proposal looks very interesting and deserves > its own thread. > > <trying to turn this to constructive dialog> > Jonathon, which enhancement are you speaking of that hasn't had the > opportunity to be reviewed sufficiently? > > As soon as the formal vote concludes on the branch, I'm sure there will > be a lot of dialog about direction and features and approaches to bug > fixes in the coming days and weeks. > > If someone replies to this, please cut of the (was...) in the subject > > > --- Jonathon -- Improov <[hidden email]> wrote: > >> David, >> >> > "We" do not now, nor have we ever, turned away a contribution >> because it >> > was complex. >> >> Very well, I'll just use the word "you" then. I take it that you do >> not turn away contributions >> because they were complex. >> >> The question from me would be whether you do or do not turn away, >> knowingly or not, contributions >> that are valid but too complex for review. It's not rhetorical, but >> you're free to do your own >> sanity/verification checks on that supposed phenomenon and deem it >> rhetorical or invalid. >> >> > Could you do us all a big favor Jonathon? Your comments seem to be >> > fairly consistent along these lines. I think what would be helpful >> to >> > you, and to anyone reading and agreeing with your comments, is to >> step >> > back and try to explain why things are the way they are. Feel free >> to >> > share that with the group for a sanity check if you'd like. >> >> I'm not so sure of the "why" of things, but am only more certain of >> the "what" of things. Things >> are the way they are, no matter how we interpret the "why". >> >> So, for now, I continue to merge in (to my own SVN) several >> contributions that are deemed too >> difficult to review/merge by the committers. I continue to keep such >> enhancements in step with >> updates from OFBiz trunk. And I continue in my failure(?) to feed >> such "compatibilized/merged" >> enhancements back to OFBiz trunk even though they really are the same >> license. >> >> And the phenomenon of several of us (incompatible contributors?) >> holding on to our own >> enhancements will continue. Some of us may not know how to keep in >> step with OFBiz trunk updates; >> others may. Those of us who can keep in step will continue to benefit >> from OFBiz progress, but be >> unable to feed the benefit back to OFBiz. There will still be >> enhancements out there that are kept >> away/apart from OFBiz. That's the way of things? Or maybe not? >> >> I stand corrected. I think I am "helping" OFBiz in the wrong way. >> I'll stop that. :) Thanks for >> reminding me. >> >> I was waiting to dump the loads of my enhancements into your trunk, >> but I think I should take a >> sanity check for now. Anyway, there needs to be at least one >> stabilizing branch (save point, so to >> speak) before we can go full steam with the trunk. And there's still >> no such branch yet. >> >> Jonathon >> >> David E. Jones wrote: >>> On Apr 20, 2007, at 9:04 PM, Jonathon -- Improov wrote: >>> >>>> We shouldn't turn away complex contributions anymore. >>> "We" do not now, nor have we ever, turned away a contribution >> because it >>> was complex. >>> >>>> I myself have loads of enhancements (mostly to widget module) that >> I >>>> feel uneasy about releasing to the community, simply because of >> this >>>> odd use of trunk: it's used like a slow-moving release branch that >> is >>>> unable to handle introductions of radical enhancements. >>>> >>>> Yet, this somewhat slow-moving trunk isn't still enough and >> focused >>>> enough on achieving release-quality stability. It's the worst of >> both >>>> worlds: it's not rapid enough to allow for radical progress, and >> not >>>> calm and focused-on-cleaning-up enough to produce a stable release >> for >>>> non-OFBiz developers. >>> Could you do us all a big favor Jonathon? Your comments seem to be >>> fairly consistent along these lines. I think what would be helpful >> to >>> you, and to anyone reading and agreeing with your comments, is to >> step >>> back and try to explain why things are the way they are. Feel free >> to >>> share that with the group for a sanity check if you'd like. >>> >>> -David >>> >>> >> > > |
Re: Post Branch Enhancements (Re: Ofbiz Contribution Proposal)
|
|
Jonathon,
Jonathon -- Improov wrote: > Chris, > > I don't know offhand which enhancements (currently on Jira) are not > reviewed. I only know those I have with me. > What are these enhancements? Are they in Jira? > I feel we should never let newcomers (or even old timers) hear something > like "please dump your stuff in that corner, and we'll get to it in > time". No, not that we'd be rude. Just that we'd lose that contribution! > We're on the receiving end, so I suggest we start begging for the > contribution instead. > Who said this? Jira is not a 'corner', it's the main (and only, for non committers) channel for accepting a contribution. > Being reasonably experienced/adept with version control systems > (SVN/CVS), I can't see why we can't have someone perform a wholesale > merge (to resolve incompatibilities) on a "crazy, no holds barred branch". > I think it's funny that, because you don't like Jira, you are proposing to make everyone a committer. Jacopo |
|
|
In reply to this post by Eilebrecht, Karl (Key-Work)
Hi Karl,
I had the opportunity today to quickly read over your introductions. And must say it looks very interesting. Unfortunately, for my being able to add input to the process, the improvements are in areas as an OFBiz user, that I take for granted and don't really get my hands dirty with. I'll need to read over the transaction part again to ask any intelligent questions, so I'll leave that for later. The custom SQL stuff looked very interesting and probably one of the larger areas of benefit as more and more people are getting to the point of locating bottlenecks in their applications. I was wondering if there might be some benefit in encapsulating the stored sql statements it in an XML structure to be able to better take advantage of some META data/commenting that you discussed as well as potential of some reusability and structuring of those custom statements. Perhaps, I need to reread the logging discussion again, and ask if this is largely supported among other databases, but can't most of these logging of the sql statements be handled in the database's log, if configured to do so? I recall a mention that the developer may not have sufficient access to the database server to ascertain the database logs...is this case where the logging proposal would be more beneficial? Thank you and Key-Work very much for bringing these enhancements back to the community! Chris --- "Eilebrecht, Karl (Key-Work)" <[hidden email]> wrote: > Hi, > > > > we use Ofbiz (mostly the entity engine) for over 2 years now. > > > > Last year I had mail contact with David. > > > > He recommended to contribute changes to the Ofbiz Community regularly > whenever possible and useful. > > > > It is a long time since this happened, but we finally convinced our > management to try > > > > to contribute some changes and extensions to the Ofbiz community. > > > > I read the FAQ and found out that especially complex changes might > take a long time > > > > and we may need some "community attendance". > > > > David told me to place our proposal at the Ofbiz-WIKI > > and to send a link to this mailing list. > > > > This is our "trial balloon" to find out whether our changes and > improvements > > > > are welcome and how we could integrate them during the next months. > > > > I.e. the following extensions may also be interesting for other > members > > of the community: > > > > * Advanced custom SQL integration > > * advanced sorting (locale, collation, natural sort) > > * completely refactored TransactionUtil with documentation and hints > > > * on-demand "real"-sql-logging for ALL ofbiz statements > > ... > > > > I placed our stuff at > > > and hope one of the "Ofbiz gurus" will have a look at the attached > stuff to make a statement. > > > > Thank you in advance! > > > > Best regards > > > > Karl Eilebrecht > > -- > Karl Eilebrecht > Key-Work Consulting GmbH > > Kriegsstr. 100 - 76133 Karlsruhe - Germany > Fon: +49-721-78203-277 - Fax: +49-721-78203-10 > [hidden email] > > > Key-Work Consulting GmbH Karlsruhe, HRB 108695, HRG Mannheim > Geschäftsführer: Andreas Stappert, Tobin Wotring > > |
|
|
In reply to this post by David E Jones
+1
David E. Jones sent the following on 4/20/2007 7:52 PM: > > On Apr 20, 2007, at 9:04 PM, Jonathon -- Improov wrote: > >> We shouldn't turn away complex contributions anymore. > > "We" do not now, nor have we ever, turned away a contribution because it > was complex. > >> I myself have loads of enhancements (mostly to widget module) that I >> feel uneasy about releasing to the community, simply because of this >> odd use of trunk: it's used like a slow-moving release branch that is >> unable to handle introductions of radical enhancements. >> >> Yet, this somewhat slow-moving trunk isn't still enough and focused >> enough on achieving release-quality stability. It's the worst of both >> worlds: it's not rapid enough to allow for radical progress, and not >> calm and focused-on-cleaning-up enough to produce a stable release for >> non-OFBiz developers. > > Could you do us all a big favor Jonathon? Your comments seem to be > fairly consistent along these lines. I think what would be helpful to > you, and to anyone reading and agreeing with your comments, is to step > back and try to explain why things are the way they are. Feel free to > share that with the group for a sanity check if you'd like. > > -David > > |
|
|
In reply to this post by jonwimp
Jonathon - as has always been the case - the role of reviewing "complex" patches does not fall strictly on the committers - it falls on the entire community. The committers then have the role of putting the code into the trunk.
If you are so concerned that valid works are not being put back into the trunk aggressively enough (which I think that everyone who spends time over here would agree), could you try the proactive approach of looking at more patches and letting the community know which ones you think are tested well enough and offer enough value to go back into the trunk? That would be a GREAT first step and a very nice change of pace from the aggressive tone you seem to think is appropriate.
Cheers, Tim -- Tim Ruppert HotWax Media o:801.649.6594 f:801.649.6595 On Apr 20, 2007, at 10:49 PM, Jonathon -- Improov wrote:
|
Re: Ofbiz Contribution Proposal
Administrator
|
I totally agree with Tim POV. Even I you don't want to become a commiter (yeah, they have some duties and they give some of their time for free) helping them to do their job is the best way to accelerate commiting. Especially if you have already tested things (means patches I guess) in you own code. I'm quite sure your help would be very valuable !
Jacques ----- Message d'origine ----- De : Tim Ruppert À : [hidden email] Envoyé : samedi 21 avril 2007 17:47 Objet : Re: Ofbiz Contribution Proposal Jonathon - as has always been the case - the role of reviewing "complex" patches does not fall strictly on the committers - it falls on the entire community. The committers then have the role of putting the code into the trunk. If you are so concerned that valid works are not being put back into the trunk aggressively enough (which I think that everyone who spends time over here would agree), could you try the proactive approach of looking at more patches and letting the community know which ones you think are tested well enough and offer enough value to go back into the trunk? That would be a GREAT first step and a very nice change of pace from the aggressive tone you seem to think is appropriate. Cheers, Tim -- Tim Ruppert HotWax Media http://www.hotwaxmedia.com o:801.649.6594 f:801.649.6595 On Apr 20, 2007, at 10:49 PM, Jonathon -- Improov wrote: David, > "We" do not now, nor have we ever, turned away a contribution because it > was complex. Very well, I'll just use the word "you" then. I take it that you do not turn away contributions because they were complex. The question from me would be whether you do or do not turn away, knowingly or not, contributions that are valid but too complex for review. It's not rhetorical, but you're free to do your own sanity/verification checks on that supposed phenomenon and deem it rhetorical or invalid. > Could you do us all a big favor Jonathon? Your comments seem to be > fairly consistent along these lines. I think what would be helpful to > you, and to anyone reading and agreeing with your comments, is to step > back and try to explain why things are the way they are. Feel free to > share that with the group for a sanity check if you'd like. I'm not so sure of the "why" of things, but am only more certain of the "what" of things. Things are the way they are, no matter how we interpret the "why". So, for now, I continue to merge in (to my own SVN) several contributions that are deemed too difficult to review/merge by the committers. I continue to keep such enhancements in step with updates from OFBiz trunk. And I continue in my failure(?) to feed such "compatibilized/merged" enhancements back to OFBiz trunk even though they really are the same license. And the phenomenon of several of us (incompatible contributors?) holding on to our own enhancements will continue. Some of us may not know how to keep in step with OFBiz trunk updates; others may. Those of us who can keep in step will continue to benefit from OFBiz progress, but be unable to feed the benefit back to OFBiz. There will still be enhancements out there that are kept away/apart from OFBiz. That's the way of things? Or maybe not? I stand corrected. I think I am "helping" OFBiz in the wrong way. I'll stop that. :) Thanks for reminding me. I was waiting to dump the loads of my enhancements into your trunk, but I think I should take a sanity check for now. Anyway, there needs to be at least one stabilizing branch (save point, so to speak) before we can go full steam with the trunk. And there's still no such branch yet. Jonathon David E. Jones wrote: On Apr 20, 2007, at 9:04 PM, Jonathon -- Improov wrote: We shouldn't turn away complex contributions anymore. "We" do not now, nor have we ever, turned away a contribution because it was complex. I myself have loads of enhancements (mostly to widget module) that I feel uneasy about releasing to the community, simply because of this odd use of trunk: it's used like a slow-moving release branch that is unable to handle introductions of radical enhancements. Yet, this somewhat slow-moving trunk isn't still enough and focused enough on achieving release-quality stability. It's the worst of both worlds: it's not rapid enough to allow for radical progress, and not calm and focused-on-cleaning-up enough to produce a stable release for non-OFBiz developers. Could you do us all a big favor Jonathon? Your comments seem to be fairly consistent along these lines. I think what would be helpful to you, and to anyone reading and agreeing with your comments, is to step back and try to explain why things are the way they are. Feel free to share that with the group for a sanity check if you'd like. -David |
|
|
In reply to this post by Tim Ruppert
Tim,
I've already taken those "first steps" long ago. Like I said, I don't know which Jira "feature requests" are not reviewed; I only know those I have merged into my own SVN. I really don't have time to send up itemized or clearly demarcated patches. Many patches I grabbed from folks (sorry I did it so fast, I don't even know who), they work. Some require streamlining mainly to match OFBiz coding standards and such, but still they do work. By now, radical patches (like those from Chris Howes?) have gone through merging, and have even taken a life (progressed) of their own. That's why I can't tell you "which Jira issues", because my "private Jira store", so to speak, has "moved on". If I can do this aggressively merging without problems (please use branches for sanity's sake), I am assuming the community of 400 here can do the same, if not better. (And I'm guessing a good majority of this 400 might just be doing what I am doing, and OFBiz is none the better for it.) For now, let's just all do what we're good at, and keep at it. Maybe some day, I can submit a gigantic patch and it will somehow translate into a bigger better OFBiz. For now, I can't help but leech off of OFBiz, every single update, but still can't feed the whole sum back to OFBiz. Tough on my conscience, but something I'll have to live with. By the way, I have no idea what some folks here are intending to achieve with some off-tangent remarks. If it's "status quo" they want (in relation to me and "my" patches, ie), they've got it. If you can understand what I'm doing in my own computers (with OFBiz and radical patches), that's good and you may do the same good(?) thing in time. If not, I may change my bad(?) tactics over time. Either way, let's just get back to what we're good at. Jonathon Tim Ruppert wrote: > Jonathon - as has always been the case - the role of reviewing "complex" > patches does not fall strictly on the committers - it falls on the > entire community. The committers then have the role of putting the code > into the trunk. > > If you are so concerned that valid works are not being put back into the > trunk aggressively enough (which I think that everyone who spends time > over here would agree), could you try the proactive approach of looking > at more patches and letting the community know which ones you think are > tested well enough and offer enough value to go back into the trunk? > That would be a GREAT first step and a very nice change of pace from the > aggressive tone you seem to think is appropriate. > > Cheers, > Tim > -- > Tim Ruppert > HotWax Media > http://www.hotwaxmedia.com > > o:801.649.6594 > f:801.649.6595 > > > On Apr 20, 2007, at 10:49 PM, Jonathon -- Improov wrote: > >> David, >> >> > "We" do not now, nor have we ever, turned away a contribution because it >> > was complex. >> >> Very well, I'll just use the word "you" then. I take it that you do >> not turn away contributions because they were complex. >> >> The question from me would be whether you do or do not turn away, >> knowingly or not, contributions that are valid but too complex for >> review. It's not rhetorical, but you're free to do your own >> sanity/verification checks on that supposed phenomenon and deem it >> rhetorical or invalid. >> >> > Could you do us all a big favor Jonathon? Your comments seem to be >> > fairly consistent along these lines. I think what would be helpful to >> > you, and to anyone reading and agreeing with your comments, is to step >> > back and try to explain why things are the way they are. Feel free to >> > share that with the group for a sanity check if you'd like. >> >> I'm not so sure of the "why" of things, but am only more certain of >> the "what" of things. Things are the way they are, no matter how we >> interpret the "why". >> >> So, for now, I continue to merge in (to my own SVN) several >> contributions that are deemed too difficult to review/merge by the >> committers. I continue to keep such enhancements in step with updates >> from OFBiz trunk. And I continue in my failure(?) to feed such >> "compatibilized/merged" enhancements back to OFBiz trunk even though >> they really are the same license. >> >> And the phenomenon of several of us (incompatible contributors?) >> holding on to our own enhancements will continue. Some of us may not >> know how to keep in step with OFBiz trunk updates; others may. Those >> of us who can keep in step will continue to benefit from OFBiz >> progress, but be unable to feed the benefit back to OFBiz. There will >> still be enhancements out there that are kept away/apart from OFBiz. >> That's the way of things? Or maybe not? >> >> I stand corrected. I think I am "helping" OFBiz in the wrong way. I'll >> stop that. :) Thanks for reminding me. >> >> I was waiting to dump the loads of my enhancements into your trunk, >> but I think I should take a sanity check for now. Anyway, there needs >> to be at least one stabilizing branch (save point, so to speak) before >> we can go full steam with the trunk. And there's still no such branch yet. >> >> Jonathon >> >> David E. Jones wrote: >>> On Apr 20, 2007, at 9:04 PM, Jonathon -- Improov wrote: >>>> We shouldn't turn away complex contributions anymore. >>> "We" do not now, nor have we ever, turned away a contribution because >>> it was complex. >>>> I myself have loads of enhancements (mostly to widget module) that I >>>> feel uneasy about releasing to the community, simply because of this >>>> odd use of trunk: it's used like a slow-moving release branch that >>>> is unable to handle introductions of radical enhancements. >>>> >>>> Yet, this somewhat slow-moving trunk isn't still enough and focused >>>> enough on achieving release-quality stability. It's the worst of >>>> both worlds: it's not rapid enough to allow for radical progress, >>>> and not calm and focused-on-cleaning-up enough to produce a stable >>>> release for non-OFBiz developers. >>> Could you do us all a big favor Jonathon? Your comments seem to be >>> fairly consistent along these lines. I think what would be helpful to >>> you, and to anyone reading and agreeing with your comments, is to >>> step back and try to explain why things are the way they are. Feel >>> free to share that with the group for a sanity check if you'd like. >>> -David >> > |
|
|
All,
Again, can we please not hijack threads. We have relatively few eyes that understand the underpinnings of the entity-engine enough to possibly improve upon it that it would be a shame for that discussion to get lost in the noise of project administration discussion. Jonathon, Hmph, I only have about ten patches in Jira that affect OFBiz code directly (thus would suffer from difficulty in sharing a progressed revision) and none of them seem to have comment from you. It's one thing to leach code; we yield that risk by using the Apache license specifically and OSS in general, however it seems counter-intuitive to take the time to review code enough to put it into your private project but not offer the constructive criticism necessary to get it improved upon or draw the attention of others to get it into the project. This seems like a lose-lose-lose approach. You're forced to maintain obscure code on your own, the author is forced to maintain or abandon the obscure code and the community doesn't gain the benefit of the code or the administrative benefit of knowing to ignore the contribution if it's not a good idea for the project. --- Jonathon -- Improov <[hidden email]> wrote: > Tim, > > I've already taken those "first steps" long ago. Like I said, I don't > know which Jira "feature > requests" are not reviewed; I only know those I have merged into my > own SVN. I really don't have > time to send up itemized or clearly demarcated patches. > > Many patches I grabbed from folks (sorry I did it so fast, I don't > even know who), they work. Some > require streamlining mainly to match OFBiz coding standards and such, > but still they do work. By > now, radical patches (like those from Chris Howes?) have gone through > merging, and have even taken > a life (progressed) of their own. That's why I can't tell you "which > Jira issues", because my > "private Jira store", so to speak, has "moved on". If I can do this > aggressively merging without > problems (please use branches for sanity's sake), I am assuming the > community of 400 here can do > the same, if not better. (And I'm guessing a good majority of this > 400 might just be doing what I > am doing, and OFBiz is none the better for it.) > > For now, let's just all do what we're good at, and keep at it. Maybe > some day, I can submit a > gigantic patch and it will somehow translate into a bigger better > OFBiz. For now, I can't help but > leech off of OFBiz, every single update, but still can't feed the > whole sum back to OFBiz. Tough > on my conscience, but something I'll have to live with. > > By the way, I have no idea what some folks here are intending to > achieve with some off-tangent > remarks. If it's "status quo" they want (in relation to me and "my" > patches, ie), they've got it. > > If you can understand what I'm doing in my own computers (with OFBiz > and radical patches), that's > good and you may do the same good(?) thing in time. If not, I may > change my bad(?) tactics over > time. Either way, let's just get back to what we're good at. > > Jonathon > > Tim Ruppert wrote: > > Jonathon - as has always been the case - the role of reviewing > "complex" > > patches does not fall strictly on the committers - it falls on the > > entire community. The committers then have the role of putting the > code > > into the trunk. > > > > If you are so concerned that valid works are not being put back > into the > > trunk aggressively enough (which I think that everyone who spends > time > > over here would agree), could you try the proactive approach of > looking > > at more patches and letting the community know which ones you think > are > > tested well enough and offer enough value to go back into the > trunk? > > That would be a GREAT first step and a very nice change of pace > from the > > aggressive tone you seem to think is appropriate. > > > > Cheers, > > Tim > > -- > > Tim Ruppert > > HotWax Media > > http://www.hotwaxmedia.com > > > > o:801.649.6594 > > f:801.649.6595 > > > > > > On Apr 20, 2007, at 10:49 PM, Jonathon -- Improov wrote: > > > >> David, > >> > >> > "We" do not now, nor have we ever, turned away a contribution > because it > >> > was complex. > >> > >> Very well, I'll just use the word "you" then. I take it that you > do > >> not turn away contributions because they were complex. > >> > >> The question from me would be whether you do or do not turn away, > >> knowingly or not, contributions that are valid but too complex for > > >> review. It's not rhetorical, but you're free to do your own > >> sanity/verification checks on that supposed phenomenon and deem it > > >> rhetorical or invalid. > >> > >> > Could you do us all a big favor Jonathon? Your comments seem to > be > >> > fairly consistent along these lines. I think what would be > helpful to > >> > you, and to anyone reading and agreeing with your comments, is > to step > >> > back and try to explain why things are the way they are. Feel > free to > >> > share that with the group for a sanity check if you'd like. > >> > >> I'm not so sure of the "why" of things, but am only more certain > of > >> the "what" of things. Things are the way they are, no matter how > we > >> interpret the "why". > >> > >> So, for now, I continue to merge in (to my own SVN) several > >> contributions that are deemed too difficult to review/merge by the > > >> committers. I continue to keep such enhancements in step with > updates > >> from OFBiz trunk. And I continue in my failure(?) to feed such > >> "compatibilized/merged" enhancements back to OFBiz trunk even > though > >> they really are the same license. > >> > >> And the phenomenon of several of us (incompatible contributors?) > >> holding on to our own enhancements will continue. Some of us may > not > >> know how to keep in step with OFBiz trunk updates; others may. > Those > >> of us who can keep in step will continue to benefit from OFBiz > >> progress, but be unable to feed the benefit back to OFBiz. There > will > >> still be enhancements out there that are kept away/apart from > OFBiz. > >> That's the way of things? Or maybe not? > >> > >> I stand corrected. I think I am "helping" OFBiz in the wrong way. > I'll > >> stop that. :) Thanks for reminding me. > >> > >> I was waiting to dump the loads of my enhancements into your > trunk, > >> but I think I should take a sanity check for now. Anyway, there > needs > >> to be at least one stabilizing branch (save point, so to speak) > before > >> we can go full steam with the trunk. And there's still no such > branch yet. > >> > >> Jonathon > >> > >> David E. Jones wrote: > >>> On Apr 20, 2007, at 9:04 PM, Jonathon -- Improov wrote: > >>>> We shouldn't turn away complex contributions anymore. > >>> "We" do not now, nor have we ever, turned away a contribution > because > >>> it was complex. > >>>> I myself have loads of enhancements (mostly to widget module) > that I > >>>> feel uneasy about releasing to the community, simply because of > this > >>>> odd use of trunk: it's used like a slow-moving release branch > that > >>>> is unable to handle introductions of radical enhancements. > >>>> > >>>> Yet, this somewhat slow-moving trunk isn't still enough and > focused > >>>> enough on achieving release-quality stability. It's the worst of > > >>>> both worlds: it's not rapid enough to allow for radical > progress, > >>>> and not calm and focused-on-cleaning-up enough to produce a > stable > >>>> release for non-OFBiz developers. > >>> Could you do us all a big favor Jonathon? Your comments seem to > be > >>> fairly consistent along these lines. I think what would be > helpful to > >>> you, and to anyone reading and agreeing with your comments, is to > > >>> step back and try to explain why things are the way they are. > Feel > >>> free to share that with the group for a sanity check if you'd > like. > >>> -David > >> > > > > |
|
|
Chris,
The patches/enhancements I bring in are not totally "assessed/reviewed", if that's what you mean by "review code". I only begin to take apart pinpointed portions of those enhancements when I need to. I'll try to explain again how I work: I really don't know OFBiz, but I pinpoint exact portions of what needs to be changed for what effect. If you know how little time it takes for me to assimilate (like the bad old Borgs, if you watch Star Trek?) your enhancements into my little playground, you'll likely call me crazy or careless or both. I don't know how to explain this anymore, except to say that SVN does allow us to be that reckless, and it does provide facilities for us to minimize risks. I can probably only give you a counter example. Have you seen developers stare at a somewhat small portion of code, albeit core codes in framework, and think and rethink over weeks about immediate directions? Ever seen a group of 5-10 developers discuss that small portion over and over, and go on to project repercussions/ramifications for each direction that is suggested? It's as if this group of developers expect ZERO human error to occur. That's not how we should force us humans to work. We make mistakes, live with that. We just need to devise mechanisms to minimize the risks/repurcussions of those mistakes. If you play computer games, you'll know a mechanism called "save games" or something. We can't have "save points" in real life, can't go back in time. But did you know that version control systems, with their branch and "timeline" concepts, allow us to border on reckless while giving us ability to drastically minimize costs of mistakes? Imagine if you could start multiple branches in your real life. You could try out being a movie star, a casanova, a do-gooder. Each branch perfectly insulated from the others, no rippling effect for whatever mistakes you made. Wouldn't you be bolder and more reckless in your moves? Incidentally, I have a personal motto: Fail fast to learn fast. If you don't try things quickly, you won't find out quickly that you were wrong. Problem-solving by "process of RAPID elimination" is very efficient: it's easier to say "what doesn't work" than to say "what does work (in all universal cases)". You'd have to test a solution in all universal cases for the 2nd type of proof. I don't know how else to explain these concepts. At the risk of being misconstrued as "un-helpful", I'm gonna just stop here for such topics, and leave OFBiz to it's way of handling the "real life" that is the OFBiz SVN. Maybe I could be all wrong. Jonathon Chris Howe wrote: > All, > Again, can we please not hijack threads. We have relatively few eyes > that understand the underpinnings of the entity-engine enough to > possibly improve upon it that it would be a shame for that discussion > to get lost in the noise of project administration discussion. > > Jonathon, > Hmph, I only have about ten patches in Jira that affect OFBiz code > directly (thus would suffer from difficulty in sharing a progressed > revision) and none of them seem to have comment from you. It's one > thing to leach code; we yield that risk by using the Apache license > specifically and OSS in general, however it seems counter-intuitive to > take the time to review code enough to put it into your private project > but not offer the constructive criticism necessary to get it improved > upon or draw the attention of others to get it into the project. > > This seems like a lose-lose-lose approach. You're forced to maintain > obscure code on your own, the author is forced to maintain or abandon > the obscure code and the community doesn't gain the benefit of the code > or the administrative benefit of knowing to ignore the contribution if > it's not a good idea for the project. > > > > --- Jonathon -- Improov <[hidden email]> wrote: > >> Tim, >> >> I've already taken those "first steps" long ago. Like I said, I don't >> know which Jira "feature >> requests" are not reviewed; I only know those I have merged into my >> own SVN. I really don't have >> time to send up itemized or clearly demarcated patches. >> >> Many patches I grabbed from folks (sorry I did it so fast, I don't >> even know who), they work. Some >> require streamlining mainly to match OFBiz coding standards and such, >> but still they do work. By >> now, radical patches (like those from Chris Howes?) have gone through >> merging, and have even taken >> a life (progressed) of their own. That's why I can't tell you "which >> Jira issues", because my >> "private Jira store", so to speak, has "moved on". If I can do this >> aggressively merging without >> problems (please use branches for sanity's sake), I am assuming the >> community of 400 here can do >> the same, if not better. (And I'm guessing a good majority of this >> 400 might just be doing what I >> am doing, and OFBiz is none the better for it.) >> >> For now, let's just all do what we're good at, and keep at it. Maybe >> some day, I can submit a >> gigantic patch and it will somehow translate into a bigger better >> OFBiz. For now, I can't help but >> leech off of OFBiz, every single update, but still can't feed the >> whole sum back to OFBiz. Tough >> on my conscience, but something I'll have to live with. >> >> By the way, I have no idea what some folks here are intending to >> achieve with some off-tangent >> remarks. If it's "status quo" they want (in relation to me and "my" >> patches, ie), they've got it. >> >> If you can understand what I'm doing in my own computers (with OFBiz >> and radical patches), that's >> good and you may do the same good(?) thing in time. If not, I may >> change my bad(?) tactics over >> time. Either way, let's just get back to what we're good at. >> >> Jonathon >> >> Tim Ruppert wrote: >>> Jonathon - as has always been the case - the role of reviewing >> "complex" >>> patches does not fall strictly on the committers - it falls on the >>> entire community. The committers then have the role of putting the >> code >>> into the trunk. >>> >>> If you are so concerned that valid works are not being put back >> into the >>> trunk aggressively enough (which I think that everyone who spends >> time >>> over here would agree), could you try the proactive approach of >> looking >>> at more patches and letting the community know which ones you think >> are >>> tested well enough and offer enough value to go back into the >> trunk? >>> That would be a GREAT first step and a very nice change of pace >> from the >>> aggressive tone you seem to think is appropriate. >>> >>> Cheers, >>> Tim >>> -- >>> Tim Ruppert >>> HotWax Media >>> http://www.hotwaxmedia.com >>> >>> o:801.649.6594 >>> f:801.649.6595 >>> >>> >>> On Apr 20, 2007, at 10:49 PM, Jonathon -- Improov wrote: >>> >>>> David, >>>> >>>>> "We" do not now, nor have we ever, turned away a contribution >> because it >>>>> was complex. >>>> Very well, I'll just use the word "you" then. I take it that you >> do >>>> not turn away contributions because they were complex. >>>> >>>> The question from me would be whether you do or do not turn away, >>>> knowingly or not, contributions that are valid but too complex for >>>> review. It's not rhetorical, but you're free to do your own >>>> sanity/verification checks on that supposed phenomenon and deem it >>>> rhetorical or invalid. >>>> >>>>> Could you do us all a big favor Jonathon? Your comments seem to >> be >>>>> fairly consistent along these lines. I think what would be >> helpful to >>>>> you, and to anyone reading and agreeing with your comments, is >> to step >>>>> back and try to explain why things are the way they are. Feel >> free to >>>>> share that with the group for a sanity check if you'd like. >>>> I'm not so sure of the "why" of things, but am only more certain >> of >>>> the "what" of things. Things are the way they are, no matter how >> we >>>> interpret the "why". >>>> >>>> So, for now, I continue to merge in (to my own SVN) several >>>> contributions that are deemed too difficult to review/merge by the >>>> committers. I continue to keep such enhancements in step with >> updates >>>> from OFBiz trunk. And I continue in my failure(?) to feed such >>>> "compatibilized/merged" enhancements back to OFBiz trunk even >> though >>>> they really are the same license. >>>> >>>> And the phenomenon of several of us (incompatible contributors?) >>>> holding on to our own enhancements will continue. Some of us may >> not >>>> know how to keep in step with OFBiz trunk updates; others may. >> Those >>>> of us who can keep in step will continue to benefit from OFBiz >>>> progress, but be unable to feed the benefit back to OFBiz. There >> will >>>> still be enhancements out there that are kept away/apart from >> OFBiz. >>>> That's the way of things? Or maybe not? >>>> >>>> I stand corrected. I think I am "helping" OFBiz in the wrong way. >> I'll >>>> stop that. :) Thanks for reminding me. >>>> >>>> I was waiting to dump the loads of my enhancements into your >> trunk, >>>> but I think I should take a sanity check for now. Anyway, there >> needs >>>> to be at least one stabilizing branch (save point, so to speak) >> before >>>> we can go full steam with the trunk. And there's still no such >> branch yet. >>>> Jonathon >>>> >>>> David E. Jones wrote: >>>>> On Apr 20, 2007, at 9:04 PM, Jonathon -- Improov wrote: >>>>>> We shouldn't turn away complex contributions anymore. >>>>> "We" do not now, nor have we ever, turned away a contribution >> because >>>>> it was complex. >>>>>> I myself have loads of enhancements (mostly to widget module) >> that I >>>>>> feel uneasy about releasing to the community, simply because of >> this >>>>>> odd use of trunk: it's used like a slow-moving release branch >> that >>>>>> is unable to handle introductions of radical enhancements. >>>>>> >>>>>> Yet, this somewhat slow-moving trunk isn't still enough and >> focused >>>>>> enough on achieving release-quality stability. It's the worst of >>>>>> both worlds: it's not rapid enough to allow for radical >> progress, >>>>>> and not calm and focused-on-cleaning-up enough to produce a >> stable >>>>>> release for non-OFBiz developers. >>>>> Could you do us all a big favor Jonathon? Your comments seem to >> be >>>>> fairly consistent along these lines. I think what would be >> helpful to >>>>> you, and to anyone reading and agreeing with your comments, is to >>>>> step back and try to explain why things are the way they are. >> Feel >>>>> free to share that with the group for a sanity check if you'd >> like. >>>>> -David >> > > |
Re: Ofbiz Contribution Proposal
|
Administrator
|
In reply to this post by jonwimp
Jonathon,
I don't want to be agressive or let you thing that I like to make "off-tangent" remarks. Here is what I think (I can't tell that facts): 1. I'm sure you might be able to be a great help for the community. 2. I better understand now why you'd like to have an "open" branch, correct me if I'm wrong a. You have your own branch(es) of OFBiz b. Not using our standard strategy (moving with the community, not alone) you "losed" the control about the changes you made respectively to the OFBiz trunk c. This is not a problem for you (your branch is a fork but good for you) d. You don't have time to extract your changes atomically but with a huge patch (unusable by commiters) 3. So your only solution to have your changes in the trunk is for us to open a branch for you Okay I'm a bit rude but you forced me and that's really what I think. Of course I'm open to discussion, you may also pass by my comments. Sorry and good luck Jacques ----- Message d'origine ----- De : "Jonathon -- Improov" <[hidden email]> À : <[hidden email]> Envoyé : dimanche 22 avril 2007 04:21 Objet : Re: Ofbiz Contribution Proposal > Tim, > > I've already taken those "first steps" long ago. Like I said, I don't know which Jira "feature > requests" are not reviewed; I only know those I have merged into my own SVN. I really don't have > time to send up itemized or clearly demarcated patches. > > Many patches I grabbed from folks (sorry I did it so fast, I don't even know who), they work. Some > require streamlining mainly to match OFBiz coding standards and such, but still they do work. By > now, radical patches (like those from Chris Howes?) have gone through merging, and have even taken > a life (progressed) of their own. That's why I can't tell you "which Jira issues", because my > "private Jira store", so to speak, has "moved on". If I can do this aggressively merging without > problems (please use branches for sanity's sake), I am assuming the community of 400 here can do > the same, if not better. (And I'm guessing a good majority of this 400 might just be doing what I > am doing, and OFBiz is none the better for it.) > > For now, let's just all do what we're good at, and keep at it. Maybe some day, I can submit a > gigantic patch and it will somehow translate into a bigger better OFBiz. For now, I can't help but > leech off of OFBiz, every single update, but still can't feed the whole sum back to OFBiz. Tough > on my conscience, but something I'll have to live with. > > By the way, I have no idea what some folks here are intending to achieve with some off-tangent > remarks. If it's "status quo" they want (in relation to me and "my" patches, ie), they've got it. > > If you can understand what I'm doing in my own computers (with OFBiz and radical patches), that's > good and you may do the same good(?) thing in time. If not, I may change my bad(?) tactics over > time. Either way, let's just get back to what we're good at. > > Jonathon > > Tim Ruppert wrote: > > Jonathon - as has always been the case - the role of reviewing "complex" > > patches does not fall strictly on the committers - it falls on the > > entire community. The committers then have the role of putting the code > > into the trunk. > > > > If you are so concerned that valid works are not being put back into the > > trunk aggressively enough (which I think that everyone who spends time > > over here would agree), could you try the proactive approach of looking > > at more patches and letting the community know which ones you think are > > tested well enough and offer enough value to go back into the trunk? > > That would be a GREAT first step and a very nice change of pace from the > > aggressive tone you seem to think is appropriate. > > > > Cheers, > > Tim > > -- > > Tim Ruppert > > HotWax Media > > http://www.hotwaxmedia.com > > > > o:801.649.6594 > > f:801.649.6595 > > > > > > On Apr 20, 2007, at 10:49 PM, Jonathon -- Improov wrote: > > > >> David, > >> > >> > "We" do not now, nor have we ever, turned away a contribution > >> > was complex. > >> > >> Very well, I'll just use the word "you" then. I take it that you do > >> not turn away contributions because they were complex. > >> > >> The question from me would be whether you do or do not turn away, > >> knowingly or not, contributions that are valid but too complex for > >> review. It's not rhetorical, but you're free to do your own > >> sanity/verification checks on that supposed phenomenon and deem it > >> rhetorical or invalid. > >> > >> > Could you do us all a big favor Jonathon? Your comments seem to > >> > fairly consistent along these lines. I think what would be helpful to > >> > you, and to anyone reading and agreeing with your comments, is to step > >> > back and try to explain why things are the way they are. Feel free to > >> > share that with the group for a sanity check if you'd like. > >> > >> I'm not so sure of the "why" of things, but am only more certain of > >> the "what" of things. Things are the way they are, no matter how we > >> interpret the "why". > >> > >> So, for now, I continue to merge in (to my own SVN) several > >> contributions that are deemed too difficult to review/merge by the > >> committers. I continue to keep such enhancements in step with updates > >> from OFBiz trunk. And I continue in my failure(?) to feed such > >> "compatibilized/merged" enhancements back to OFBiz trunk even though > >> they really are the same license. > >> > >> And the phenomenon of several of us (incompatible contributors?) > >> holding on to our own enhancements will continue. Some of us may not > >> know how to keep in step with OFBiz trunk updates; others may. Those > >> of us who can keep in step will continue to benefit from OFBiz > >> progress, but be unable to feed the benefit back to OFBiz. There will > >> still be enhancements out there that are kept away/apart from OFBiz. > >> That's the way of things? Or maybe not? > >> > >> I stand corrected. I think I am "helping" OFBiz in the wrong way. I'll > >> stop that. :) Thanks for reminding me. > >> > >> I was waiting to dump the loads of my enhancements into your trunk, > >> but I think I should take a sanity check for now. Anyway, there needs > >> to be at least one stabilizing branch (save point, so to speak) before > >> we can go full steam with the trunk. And there's still no such branch yet. > >> > >> Jonathon > >> > >> David E. Jones wrote: > >>> On Apr 20, 2007, at 9:04 PM, Jonathon -- Improov wrote: > >>>> We shouldn't turn away complex contributions anymore. > >>> "We" do not now, nor have we ever, turned away a contribution because > >>> it was complex. > >>>> I myself have loads of enhancements (mostly to widget module) that I > >>>> feel uneasy about releasing to the community, simply because of this > >>>> odd use of trunk: it's used like a slow-moving release branch that > >>>> is unable to handle introductions of radical enhancements. > >>>> > >>>> Yet, this somewhat slow-moving trunk isn't still enough and focused > >>>> enough on achieving release-quality stability. It's the worst of > >>>> both worlds: it's not rapid enough to allow for radical progress, > >>>> and not calm and focused-on-cleaning-up enough to produce a stable > >>>> release for non-OFBiz developers. > >>> Could you do us all a big favor Jonathon? Your comments seem to be > >>> fairly consistent along these lines. I think what would be helpful to > >>> you, and to anyone reading and agreeing with your comments, is to > >>> step back and try to explain why things are the way they are. Feel > >>> free to share that with the group for a sanity check if you'd like. > >>> -David > >> > > |
Re: Post Branch Enhancements (was Re: Ofbiz Contribution Proposal)
|
Administrator
|
In reply to this post by cjhowe
Sorry Chris,
I did not read your message before "answering" to Jonathon, so I kept the wrong thread (Re: Ofbiz Contribution Proposal) Jacques De : "Chris Howe" <[hidden email]> Objet : Re: Post Branch Enhancements (was Re: Ofbiz Contribution Proposal) > All, > Again, can we please not hijack threads. We have relatively few eyes > that understand the underpinnings of the entity-engine enough to > possibly improve upon it that it would be a shame for that discussion > to get lost in the noise of project administration discussion. > > Jonathon, > Hmph, I only have about ten patches in Jira that affect OFBiz code > directly (thus would suffer from difficulty in sharing a progressed > revision) and none of them seem to have comment from you. It's one > thing to leach code; we yield that risk by using the Apache license > specifically and OSS in general, however it seems counter-intuitive to > take the time to review code enough to put it into your private > but not offer the constructive criticism necessary to get it improved > upon or draw the attention of others to get it into the project. > > This seems like a lose-lose-lose approach. You're forced to maintain > obscure code on your own, the author is forced to maintain or abandon > the obscure code and the community doesn't gain the benefit of the code > or the administrative benefit of knowing to ignore the contribution if > it's not a good idea for the project. > > > > --- Jonathon -- Improov <[hidden email]> wrote: > > > Tim, > > > > I've already taken those "first steps" long ago. Like I said, I > > know which Jira "feature > > requests" are not reviewed; I only know those I have merged into my > > own SVN. I really don't have > > time to send up itemized or clearly demarcated patches. > > > > Many patches I grabbed from folks (sorry I did it so fast, I don't > > even know who), they work. Some > > require streamlining mainly to match OFBiz coding standards and such, > > but still they do work. By > > now, radical patches (like those from Chris Howes?) have gone through > > merging, and have even taken > > a life (progressed) of their own. That's why I can't tell you "which > > Jira issues", because my > > "private Jira store", so to speak, has "moved on". If I can do this > > aggressively merging without > > problems (please use branches for sanity's sake), I am assuming the > > community of 400 here can do > > the same, if not better. (And I'm guessing a good majority of this > > 400 might just be doing what I > > am doing, and OFBiz is none the better for it.) > > > > For now, let's just all do what we're good at, and keep at it. Maybe > > some day, I can submit a > > gigantic patch and it will somehow translate into a bigger better > > OFBiz. For now, I can't help but > > leech off of OFBiz, every single update, but still can't feed the > > whole sum back to OFBiz. Tough > > on my conscience, but something I'll have to live with. > > > > By the way, I have no idea what some folks here are intending to > > achieve with some off-tangent > > remarks. If it's "status quo" they want (in relation to me and "my" > > patches, ie), they've got it. > > > > If you can understand what I'm doing in my own computers (with OFBiz > > and radical patches), that's > > good and you may do the same good(?) thing in time. If not, I may > > change my bad(?) tactics over > > time. Either way, let's just get back to what we're good at. > > > > Jonathon > > > > Tim Ruppert wrote: > > > Jonathon - as has always been the case - the role of reviewing > > "complex" > > > patches does not fall strictly on the committers - it falls on the > > > entire community. The committers then have the role of putting > > code > > > into the trunk. > > > > > > If you are so concerned that valid works are not being put back > > into the > > > trunk aggressively enough (which I think that everyone who spends > > time > > > over here would agree), could you try the proactive approach of > > looking > > > at more patches and letting the community know which ones you > > are > > > tested well enough and offer enough value to go back into the > > trunk? > > > That would be a GREAT first step and a very nice change of pace > > from the > > > aggressive tone you seem to think is appropriate. > > > > > > Cheers, > > > Tim > > > -- > > > Tim Ruppert > > > HotWax Media > > > http://www.hotwaxmedia.com > > > > > > o:801.649.6594 > > > f:801.649.6595 > > > > > > > > > On Apr 20, 2007, at 10:49 PM, Jonathon -- Improov wrote: > > > > > >> David, > > >> > > >> > "We" do not now, nor have we ever, turned away a contribution > > because it > > >> > was complex. > > >> > > >> Very well, I'll just use the word "you" then. I take it that you > > do > > >> not turn away contributions because they were complex. > > >> > > >> The question from me would be whether you do or do not turn away, > > >> knowingly or not, contributions that are valid but too complex > > > > >> review. It's not rhetorical, but you're free to do your own > > >> sanity/verification checks on that supposed phenomenon and deem it > > > > >> rhetorical or invalid. > > >> > > >> > Could you do us all a big favor Jonathon? Your comments seem to > > be > > >> > fairly consistent along these lines. I think what would be > > helpful to > > >> > you, and to anyone reading and agreeing with your comments, is > > to step > > >> > back and try to explain why things are the way they are. Feel > > free to > > >> > share that with the group for a sanity check if you'd like. > > >> > > >> I'm not so sure of the "why" of things, but am only more certain > > of > > >> the "what" of things. Things are the way they are, no matter how > > we > > >> interpret the "why". > > >> > > >> So, for now, I continue to merge in (to my own SVN) several > > >> contributions that are deemed too difficult to review/merge by > > > > >> committers. I continue to keep such enhancements in step with > > updates > > >> from OFBiz trunk. And I continue in my failure(?) to feed such > > >> "compatibilized/merged" enhancements back to OFBiz trunk even > > though > > >> they really are the same license. > > >> > > >> And the phenomenon of several of us (incompatible contributors?) > > >> holding on to our own enhancements will continue. Some of us may > > not > > >> know how to keep in step with OFBiz trunk updates; others may. > > Those > > >> of us who can keep in step will continue to benefit from OFBiz > > >> progress, but be unable to feed the benefit back to OFBiz. There > > will > > >> still be enhancements out there that are kept away/apart from > > OFBiz. > > >> That's the way of things? Or maybe not? > > >> > > >> I stand corrected. I think I am "helping" OFBiz in the wrong way. > > I'll > > >> stop that. :) Thanks for reminding me. > > >> > > >> I was waiting to dump the loads of my enhancements into your > > trunk, > > >> but I think I should take a sanity check for now. Anyway, there > > needs > > >> to be at least one stabilizing branch (save point, so to speak) > > before > > >> we can go full steam with the trunk. And there's still no such > > branch yet. > > >> > > >> Jonathon > > >> > > >> David E. Jones wrote: > > >>> On Apr 20, 2007, at 9:04 PM, Jonathon -- Improov wrote: > > >>>> We shouldn't turn away complex contributions anymore. > > >>> "We" do not now, nor have we ever, turned away a contribution > > because > > >>> it was complex. > > >>>> I myself have loads of enhancements (mostly to widget module) > > that I > > >>>> feel uneasy about releasing to the community, simply because of > > this > > >>>> odd use of trunk: it's used like a slow-moving release branch > > that > > >>>> is unable to handle introductions of radical enhancements. > > >>>> > > >>>> Yet, this somewhat slow-moving trunk isn't still enough and > > focused > > >>>> enough on achieving release-quality stability. It's the worst > > > > >>>> both worlds: it's not rapid enough to allow for radical > > progress, > > >>>> and not calm and focused-on-cleaning-up enough to produce a > > stable > > >>>> release for non-OFBiz developers. > > >>> Could you do us all a big favor Jonathon? Your comments seem to > > be > > >>> fairly consistent along these lines. I think what would be > > helpful to > > >>> you, and to anyone reading and agreeing with your comments, is > > > > >>> step back and try to explain why things are the way they are. > > Feel > > >>> free to share that with the group for a sanity check if you'd > > like. > > >>> -David > > >> > > > > > > > |
|
|
In reply to this post by Jacques Le Roux
Jacques,
You lost me. I don't see where you are (or were ever) rude. > a. You have your own branch(es) of OFBiz Yes, I have multiple branches sometimes, which will stabilize and collapse into a few (possibly 2 or 3) branches, and then eventually come down to trunk. Usually, when I see a huge patch(es) I might like, I'll see many branches popping up. > b. Not using our standard strategy (moving with the community, > not alone) you "losed" the control about the changes you made > respectively to the OFBiz trunk Hmm. That didn't happen. The trick is to keep a record of exactly where you branched off, to know how and which files/folders to do a diff. Of course, you'll need to know which direction to do the diff-patch. > c. This is not a problem for you (your branch is a fork but good > for you) If my branch isn't kept in step with OFBiz trunk, that's not ok for me. The OFBiz trunk is constantly getting updates and bugfixes. Like I said, the "loss of control" didn't happen. I am still in step with OFBiz trunk. Only issue I have is that the OFBiz trunk can't keep in step with my own updates, which is fine by me if I really don't mind kicking back and relaxing after finishing my own work. > d. You don't have time to extract your changes atomically but > with a huge patch (unusable by commiters) You're right on this count. Due to the way I perform wholesale aggressive merges (to bring in big enhancements), my commits are not small. They are quite mostly large and wide in scope. I perform such wholesale merges, then somehow systematically pick off all incompatibilities. Hence, I can only feed large patches to the community, not atomic ones like "Added feature A" or "Fixed bug B". > 3. So your only solution to have your changes in the trunk is for us to > open a branch for you No, the solution is for myself to give you a patch that will bring 2 things together: the latest of OFBiz and the latest of my work. I can tell you that I've tested this patch, but it's really up to the community to trust me. On your part, the solution would be to just dump my patch into your trunk. Or if you want to have a cautious look-see first, you could open a new branch just to test out my patch. This "exploratory/probationary" branch will be very short-lived, possibly 2-3 updates in the timeline. After the few updates, you can decide: a. My patch is playing well with the latest of OFBiz, and you merge it into trunk. OR b. My patch still has too many incompatibilities with OFBiz, and you discard it. As you can see, the bulk of the work is on my part, in "bringing the latest of OFBiz and my work together". The fact that I already have the latest of OFBiz playing with my enhancements is already more than half the work done. Most folks I come across don't know how to do that part. I was suggesting that someone among us, someone comfortable with version control adventures, perform that merge for those who can't. I'm gonna assume you understand the concepts I tried to describe above. It's dinner time now. Ultimately, the concepts involve "maximizing concurrency". It won't be good if I find myself limiting my rate/size of progress just so I don't "lose control" or lose sight of OFBiz trunk. I just moved ahead at full speed, all the while being confident that OFBiz trunk will always be mergeable into my SVN. The question is whether the OFBiz SVN is similarly confident about merging our mad-cap-paced work into OFBiz trunk. Jonathon Jacques Le Roux wrote: > Jonathon, > > I don't want to be agressive or let you thing that I like to make > "off-tangent" remarks. Here is what I think (I can't tell that facts): > > 1. I'm sure you might be able to be a great help for the community. > 2. I better understand now why you'd like to have an "open" branch, > correct me if I'm wrong > a. You have your own branch(es) of OFBiz > b. Not using our standard strategy (moving with the community, not > alone) you "losed" the control about the changes you made respectively > to the OFBiz trunk > c. This is not a problem for you (your branch is a fork but good for > you) > d. You don't have time to extract your changes atomically but with a > huge patch (unusable by commiters) > 3. So your only solution to have your changes in the trunk is for us to > open a branch for you > > Okay I'm a bit rude but you forced me and that's really what I think. > Of course I'm open to discussion, you may also pass by my comments. > > Sorry and good luck > > Jacques > > ----- Message d'origine ----- > De : "Jonathon -- Improov" <[hidden email]> > À : <[hidden email]> > Envoyé : dimanche 22 avril 2007 04:21 > Objet : Re: Ofbiz Contribution Proposal > > >> Tim, >> >> I've already taken those "first steps" long ago. Like I said, I don't > know which Jira "feature >> requests" are not reviewed; I only know those I have merged into my > own SVN. I really don't have >> time to send up itemized or clearly demarcated patches. >> >> Many patches I grabbed from folks (sorry I did it so fast, I don't > even know who), they work. Some >> require streamlining mainly to match OFBiz coding standards and such, > but still they do work. By >> now, radical patches (like those from Chris Howes?) have gone through > merging, and have even taken >> a life (progressed) of their own. That's why I can't tell you "which > Jira issues", because my >> "private Jira store", so to speak, has "moved on". If I can do this > aggressively merging without >> problems (please use branches for sanity's sake), I am assuming the > community of 400 here can do >> the same, if not better. (And I'm guessing a good majority of this 400 > might just be doing what I >> am doing, and OFBiz is none the better for it.) >> >> For now, let's just all do what we're good at, and keep at it. Maybe > some day, I can submit a >> gigantic patch and it will somehow translate into a bigger better > OFBiz. For now, I can't help but >> leech off of OFBiz, every single update, but still can't feed the > whole sum back to OFBiz. Tough >> on my conscience, but something I'll have to live with. >> >> By the way, I have no idea what some folks here are intending to > achieve with some off-tangent >> remarks. If it's "status quo" they want (in relation to me and "my" > patches, ie), they've got it. >> If you can understand what I'm doing in my own computers (with OFBiz > and radical patches), that's >> good and you may do the same good(?) thing in time. If not, I may > change my bad(?) tactics over >> time. Either way, let's just get back to what we're good at. >> >> Jonathon >> >> Tim Ruppert wrote: >>> Jonathon - as has always been the case - the role of reviewing > "complex" >>> patches does not fall strictly on the committers - it falls on the >>> entire community. The committers then have the role of putting the > code >>> into the trunk. >>> >>> If you are so concerned that valid works are not being put back into > the >>> trunk aggressively enough (which I think that everyone who spends > time >>> over here would agree), could you try the proactive approach of > looking >>> at more patches and letting the community know which ones you think > are >>> tested well enough and offer enough value to go back into the trunk? >>> That would be a GREAT first step and a very nice change of pace from > the >>> aggressive tone you seem to think is appropriate. >>> >>> Cheers, >>> Tim >>> -- >>> Tim Ruppert >>> HotWax Media >>> http://www.hotwaxmedia.com >>> >>> o:801.649.6594 >>> f:801.649.6595 >>> >>> >>> On Apr 20, 2007, at 10:49 PM, Jonathon -- Improov wrote: >>> >>>> David, >>>> >>>>> "We" do not now, nor have we ever, turned away a contribution > because it >>>>> was complex. >>>> Very well, I'll just use the word "you" then. I take it that you do >>>> not turn away contributions because they were complex. >>>> >>>> The question from me would be whether you do or do not turn away, >>>> knowingly or not, contributions that are valid but too complex for >>>> review. It's not rhetorical, but you're free to do your own >>>> sanity/verification checks on that supposed phenomenon and deem it >>>> rhetorical or invalid. >>>> >>>>> Could you do us all a big favor Jonathon? Your comments seem to > be >>>>> fairly consistent along these lines. I think what would be > helpful to >>>>> you, and to anyone reading and agreeing with your comments, is to > step >>>>> back and try to explain why things are the way they are. Feel > free to >>>>> share that with the group for a sanity check if you'd like. >>>> I'm not so sure of the "why" of things, but am only more certain of >>>> the "what" of things. Things are the way they are, no matter how we >>>> interpret the "why". >>>> >>>> So, for now, I continue to merge in (to my own SVN) several >>>> contributions that are deemed too difficult to review/merge by the >>>> committers. I continue to keep such enhancements in step with > updates >>>> from OFBiz trunk. And I continue in my failure(?) to feed such >>>> "compatibilized/merged" enhancements back to OFBiz trunk even > though >>>> they really are the same license. >>>> >>>> And the phenomenon of several of us (incompatible contributors?) >>>> holding on to our own enhancements will continue. Some of us may > not >>>> know how to keep in step with OFBiz trunk updates; others may. > Those >>>> of us who can keep in step will continue to benefit from OFBiz >>>> progress, but be unable to feed the benefit back to OFBiz. There > will >>>> still be enhancements out there that are kept away/apart from > OFBiz. >>>> That's the way of things? Or maybe not? >>>> >>>> I stand corrected. I think I am "helping" OFBiz in the wrong way. > I'll >>>> stop that. :) Thanks for reminding me. >>>> >>>> I was waiting to dump the loads of my enhancements into your trunk, >>>> but I think I should take a sanity check for now. Anyway, there > needs >>>> to be at least one stabilizing branch (save point, so to speak) > before >>>> we can go full steam with the trunk. And there's still no such > branch yet. >>>> Jonathon >>>> >>>> David E. Jones wrote: >>>>> On Apr 20, 2007, at 9:04 PM, Jonathon -- Improov wrote: >>>>>> We shouldn't turn away complex contributions anymore. >>>>> "We" do not now, nor have we ever, turned away a contribution > because >>>>> it was complex. >>>>>> I myself have loads of enhancements (mostly to widget module) > that I >>>>>> feel uneasy about releasing to the community, simply because of > this >>>>>> odd use of trunk: it's used like a slow-moving release branch > that >>>>>> is unable to handle introductions of radical enhancements. >>>>>> >>>>>> Yet, this somewhat slow-moving trunk isn't still enough and > focused >>>>>> enough on achieving release-quality stability. It's the worst of >>>>>> both worlds: it's not rapid enough to allow for radical progress, >>>>>> and not calm and focused-on-cleaning-up enough to produce a > stable >>>>>> release for non-OFBiz developers. >>>>> Could you do us all a big favor Jonathon? Your comments seem to be >>>>> fairly consistent along these lines. I think what would be helpful > to >>>>> you, and to anyone reading and agreeing with your comments, is to >>>>> step back and try to explain why things are the way they are. Feel >>>>> free to share that with the group for a sanity check if you'd > like. >>>>> -David > > |
|
Administrator
|
Jonathon,
You should read other messages, then you w'd have seen Chris's about the new thread. Ok not a big deal. ;o) Happy that you did not feel my last message "rude" and that your answer is understandable by me (I must aknowledge that sometimes you lost me). Perhaps kepping the habit of using numbered points will help our communication (we have to keep it as concise as possible), trying : Seems that only the 3d point needs some comments, they are inline... ----- Message d'origine ----- De : "Jonathon -- Improov" <[hidden email]> À : <[hidden email]> Envoyé : dimanche 22 avril 2007 12:27 Objet : Re: Ofbiz Contribution Proposal > Jacques, > > You lost me. I don't see where you are (or were ever) rude. > > > a. You have your own branch(es) of OFBiz > > Yes, I have multiple branches sometimes, which will stabilize and collapse into a few (possibly 2 > or 3) branches, and then eventually come down to trunk. > > Usually, when I see a huge patch(es) I might like, I'll see many branches popping up. > > > b. Not using our standard strategy (moving with the community, > > not alone) you "losed" the control about the changes you made > > respectively to the OFBiz trunk > > Hmm. That didn't happen. > > The trick is to keep a record of exactly where you branched off, to know how and which > files/folders to do a diff. Of course, you'll need to know which direction to do the diff-patch. > > > c. This is not a problem for you (your branch is a fork but good > > for you) > > If my branch isn't kept in step with OFBiz trunk, that's not ok for me. The OFBiz trunk is > constantly getting updates and bugfixes. Like I said, the "loss of control" didn't happen. I am > still in step with OFBiz trunk. Only issue I have is that the OFBiz trunk can't keep in step with > my own updates, which is fine by me if I really don't mind kicking back and relaxing after > finishing my own work. > > > d. You don't have time to extract your changes atomically but > > with a huge patch (unusable by commiters) > > You're right on this count. Due to the way I perform wholesale aggressive merges (to bring in big > enhancements), my commits are not small. They are quite mostly large and wide in scope. I perform > such wholesale merges, then somehow systematically pick off all incompatibilities. > > Hence, I can only feed large patches to the community, not atomic ones like "Added feature A" or > "Fixed bug B". > > > 3. So your only solution to have your changes in the trunk is for us to > > open a branch for you > > No, the solution is for myself to give you a patch that will bring 2 things together: the latest > of OFBiz and the latest of my work. I can tell you that I've tested this patch, but it's really up > to the community to trust me. > > On your part, the solution would be to just dump my patch into your trunk. Or if you want to have > a cautious look-see first, you could open a new branch just to test out my patch. This > "exploratory/probationary" branch will be very short-lived, possibly 2-3 updates in the timeline. > After the few updates, you can decide: > > a. My patch is playing well with the latest of OFBiz, and you merge it into > trunk. > > OR > > b. My patch still has too many incompatibilities with OFBiz, and you discard > it. To be able to test your changes it'd be really better to at least have an idea of the features that are added (or withdrawed f any). If they are many changes and we don't know which they are, just funding our reviewing work from a diff might be a nightmare. > As you can see, the bulk of the work is on my part, in "bringing the latest of OFBiz and my work > together". The fact that I already have the latest of OFBiz playing with my enhancements is > already more than half the work done. > > Most folks I come across don't know how to do that part. I was suggesting that someone among us, > someone comfortable with version control adventures, perform that merge for those who can't. Following http://tinyurl.com/2o5bld this should not be too hard I guess. Even for people (like me for instance) that have never played with branches in their own work (ok I have an advantage : I read the book) > I'm gonna assume you understand the concepts I tried to describe above. It's dinner time now. > > Ultimately, the concepts involve "maximizing concurrency". It won't be good if I find myself > limiting my rate/size of progress just so I don't "lose control" or lose sight of OFBiz trunk. I > just moved ahead at full speed, all the while being confident that OFBiz trunk will always be > mergeable into my SVN. The question is whether the OFBiz SVN is similarly confident about merging > our mad-cap-paced work into OFBiz trunk. Yes I understand your POV. It stays that merging your change might be a challenge. And I'm not sure who will want to take it or rather have enough "free" time to do it. Explaining clearly what these changes might bring to OFBiz (at the businnes and technical levels) would surely be a *1st step* in this direction. Please, don't misunderstand me. Here, I'm trying to find a way to be able to merge your changes because I'm sure they are worth it. Also remember this discussion we had with Chris (and others) about "joint work" and licence. This is perhaps the worse issue in your case ! You may Googlize or use Nabble if you need explanations... Jacques > Jonathon > > Jacques Le Roux wrote: > > Jonathon, > > > > I don't want to be agressive or let you thing that I like to make > > "off-tangent" remarks. Here is what I think (I can't tell that facts): > > > > 1. I'm sure you might be able to be a great help for the community. > > 2. I better understand now why you'd like to have an "open" branch, > > correct me if I'm wrong > > a. You have your own branch(es) of OFBiz > > b. Not using our standard strategy (moving with the community, not > > alone) you "losed" the control about the changes you made respectively > > to the OFBiz trunk > > c. This is not a problem for you (your branch is a fork but good for > > you) > > d. You don't have time to extract your changes atomically but with a > > huge patch (unusable by commiters) > > 3. So your only solution to have your changes in the trunk is for us to > > open a branch for you > > > > Okay I'm a bit rude but you forced me and that's really what I think. > > Of course I'm open to discussion, you may also pass by my comments. > > > > Sorry and good luck > > > > Jacques > > > > ----- Message d'origine ----- > > De : "Jonathon -- Improov" <[hidden email]> > > À : <[hidden email]> > > Envoyé : dimanche 22 avril 2007 04:21 > > Objet : Re: Ofbiz Contribution Proposal > > > > > >> Tim, > >> > >> I've already taken those "first steps" long ago. Like I said, I > > know which Jira "feature > >> requests" are not reviewed; I only know those I have merged into my > > own SVN. I really don't have > >> time to send up itemized or clearly demarcated patches. > >> > >> Many patches I grabbed from folks (sorry I did it so fast, I don't > > even know who), they work. Some > >> require streamlining mainly to match OFBiz coding standards and such, > > but still they do work. By > >> now, radical patches (like those from Chris Howes?) have gone through > > merging, and have even taken > >> a life (progressed) of their own. That's why I can't tell you "which > > Jira issues", because my > >> "private Jira store", so to speak, has "moved on". If I can do this > > aggressively merging without > >> problems (please use branches for sanity's sake), I am assuming the > > community of 400 here can do > >> the same, if not better. (And I'm guessing a good majority of this 400 > > might just be doing what I > >> am doing, and OFBiz is none the better for it.) > >> > >> For now, let's just all do what we're good at, and keep at it. Maybe > > some day, I can submit a > >> gigantic patch and it will somehow translate into a bigger better > > OFBiz. For now, I can't help but > >> leech off of OFBiz, every single update, but still can't feed the > > whole sum back to OFBiz. Tough > >> on my conscience, but something I'll have to live with. > >> > >> By the way, I have no idea what some folks here are intending to > > achieve with some off-tangent > >> remarks. If it's "status quo" they want (in relation to me and "my" > > patches, ie), they've got it. > >> If you can understand what I'm doing in my own computers (with > > and radical patches), that's > >> good and you may do the same good(?) thing in time. If not, I may > > change my bad(?) tactics over > >> time. Either way, let's just get back to what we're good at. > >> > >> Jonathon > >> > >> Tim Ruppert wrote: > >>> Jonathon - as has always been the case - the role of reviewing > > "complex" > >>> patches does not fall strictly on the committers - it falls on the > >>> entire community. The committers then have the role of putting > > code > >>> into the trunk. > >>> > >>> If you are so concerned that valid works are not being put back into > > the > >>> trunk aggressively enough (which I think that everyone who spends > > time > >>> over here would agree), could you try the proactive approach of > > looking > >>> at more patches and letting the community know which ones you think > > are > >>> tested well enough and offer enough value to go back into the trunk? > >>> That would be a GREAT first step and a very nice change of pace from > > the > >>> aggressive tone you seem to think is appropriate. > >>> > >>> Cheers, > >>> Tim > >>> -- > >>> Tim Ruppert > >>> HotWax Media > >>> http://www.hotwaxmedia.com > >>> > >>> o:801.649.6594 > >>> f:801.649.6595 > >>> > >>> > >>> On Apr 20, 2007, at 10:49 PM, Jonathon -- Improov wrote: > >>> > >>>> David, > >>>> > >>>>> "We" do not now, nor have we ever, turned away a contribution > > because it > >>>>> was complex. > >>>> Very well, I'll just use the word "you" then. I take it that you > >>>> not turn away contributions because they were complex. > >>>> > >>>> The question from me would be whether you do or do not turn away, > >>>> knowingly or not, contributions that are valid but too complex for > >>>> review. It's not rhetorical, but you're free to do your own > >>>> sanity/verification checks on that supposed phenomenon and deem it > >>>> rhetorical or invalid. > >>>> > >>>>> Could you do us all a big favor Jonathon? Your comments seem to > > be > >>>>> fairly consistent along these lines. I think what would be > > helpful to > >>>>> you, and to anyone reading and agreeing with your comments, is to > > step > >>>>> back and try to explain why things are the way they are. Feel > > free to > >>>>> share that with the group for a sanity check if you'd like. > >>>> I'm not so sure of the "why" of things, but am only more certain of > >>>> the "what" of things. Things are the way they are, no matter how we > >>>> interpret the "why". > >>>> > >>>> So, for now, I continue to merge in (to my own SVN) several > >>>> contributions that are deemed too difficult to review/merge by the > >>>> committers. I continue to keep such enhancements in step with > > updates > >>>> from OFBiz trunk. And I continue in my failure(?) to feed such > >>>> "compatibilized/merged" enhancements back to OFBiz trunk even > > though > >>>> they really are the same license. > >>>> > >>>> And the phenomenon of several of us (incompatible contributors?) > >>>> holding on to our own enhancements will continue. Some of us may > > not > >>>> know how to keep in step with OFBiz trunk updates; others may. > > Those > >>>> of us who can keep in step will continue to benefit from OFBiz > >>>> progress, but be unable to feed the benefit back to OFBiz. There > > will > >>>> still be enhancements out there that are kept away/apart from > > OFBiz. > >>>> That's the way of things? Or maybe not? > >>>> > >>>> I stand corrected. I think I am "helping" OFBiz in the wrong way. > > I'll > >>>> stop that. :) Thanks for reminding me. > >>>> > >>>> I was waiting to dump the loads of my enhancements into your > >>>> but I think I should take a sanity check for now. Anyway, there > > needs > >>>> to be at least one stabilizing branch (save point, so to speak) > > before > >>>> we can go full steam with the trunk. And there's still no such > > branch yet. > >>>> Jonathon > >>>> > >>>> David E. Jones wrote: > >>>>> On Apr 20, 2007, at 9:04 PM, Jonathon -- Improov wrote: > >>>>>> We shouldn't turn away complex contributions anymore. > >>>>> "We" do not now, nor have we ever, turned away a contribution > > because > >>>>> it was complex. > >>>>>> I myself have loads of enhancements (mostly to widget module) > > that I > >>>>>> feel uneasy about releasing to the community, simply because of > > this > >>>>>> odd use of trunk: it's used like a slow-moving release branch > > that > >>>>>> is unable to handle introductions of radical enhancements. > >>>>>> > >>>>>> Yet, this somewhat slow-moving trunk isn't still enough and > > focused > >>>>>> enough on achieving release-quality stability. It's the worst > >>>>>> both worlds: it's not rapid enough to allow for radical progress, > >>>>>> and not calm and focused-on-cleaning-up enough to produce a > > stable > >>>>>> release for non-OFBiz developers. > >>>>> Could you do us all a big favor Jonathon? Your comments seem to be > >>>>> fairly consistent along these lines. I think what would be helpful > > to > >>>>> you, and to anyone reading and agreeing with your comments, is to > >>>>> step back and try to explain why things are the way they are. Feel > >>>>> free to share that with the group for a sanity check if you'd > > like. > >>>>> -David > > > > |
|
|
Jacques,
Glad I seem to be making sense to you. Please pardon my inability to explain some concepts; I'm more a worker than a teacher/discusser. > To be able to test your changes it'd be really better to at least have > an idea of the features that are added (or withdrawed f any). If they > are many changes and we don't know which they are, just funding our > reviewing work from a diff might be a nightmare. Yes, every commit does have some comments about what is added or changed. However, there are also some comments that say: "Brought in Chris Howe's Rico experiment.". Again, the trick is I brought in a huge wide-spanning stuff on a short-lived exploratory branch. Sort of like me saying, "Let me try out being a casanova for a short time, just a quick try". I'm not a casanova, not french/italian (sorry for stereotype, blame the movies), and I'd probably get in a lot of trouble for trying. But SVN is not like real life. My ability/inability to "compatibilize" a huge patch with my work will determine whether or not the exploratory branch dies or gets merged into my trunk. If I do have a casanova in me, I can try some casanova lifestyle in the "main branch (trunk)" of my life; if not, that exploratory branch gets pruned off for good, never to be merged into my trunk. > Yes I understand your POV. It stays that merging your change might be a > challenge. No more a challenge than merging OFBiz trunk into our own work, due to the instability of the trunk. If you recall, there are some folks who tried to "marry latest of OFiz with own enhancements", and they failed. If I can use exploratory branches to bring in OFBiz trunk updates _wholesale_ (my commit logs go like "brought in OFBiz trunk r123:456), the question still remains: Should it be that tough for OFBiz SVN to bring in radical enhancements the way I bring in OFBiz trunk updates? OFBiz trunk updates, especially when they span a week, are just as "radical/un-atomic" as the enhancements Karl or the rest of us try to submit. > Also remember this discussion we had with Chris (and others) about > "joint work" and licence. This is perhaps the worse issue in your case ! > You may Googlize or use Nabble if you need explanations... That's why I was following Chris Howes' dissertations on the "joint work" issue. I've since read the ASL 2.0. Merging my changes shouldn't be that difficult, since I only pull in stuff from JIRA and other donations clearly labelled as ASL. Unless... I misunderstood that all patches/comments in JIRA were explicitly contributed under ASL. As with all merges, the further the deviation (given time), the more difficult to reconcile. Karl's contribution was 2 years in the making; that's 1.99 years too late to bring in. Yet, that is still earlier than 2.01 years. The longer we wait (eg "please hold, we're busy, we'll look into your enhancements soon"), the more difficult to reconcile. Similarly, for the release branch, there really is no point at all in waiting to fork one. OFBiz is already very full-featured as it is now; it's a different case when OFBiz has not even ONE function working. Hope all that makes sense to you. Jonathon Jacques Le Roux wrote: > Jonathon, > > You should read other messages, then you w'd have seen Chris's about the > new thread. Ok not a big deal. ;o) > > Happy that you did not feel my last message "rude" and that your answer > is understandable by me (I must aknowledge that sometimes you lost me). > > Perhaps kepping the habit of using numbered points will help our > communication (we have to keep it as concise as possible), trying : > > Seems that only the 3d point needs some comments, they are inline... > > > ----- Message d'origine ----- > De : "Jonathon -- Improov" <[hidden email]> > À : <[hidden email]> > Envoyé : dimanche 22 avril 2007 12:27 > Objet : Re: Ofbiz Contribution Proposal > > >> Jacques, >> >> You lost me. I don't see where you are (or were ever) rude. >> >> > a. You have your own branch(es) of OFBiz >> >> Yes, I have multiple branches sometimes, which will stabilize and > collapse into a few (possibly 2 >> or 3) branches, and then eventually come down to trunk. >> >> Usually, when I see a huge patch(es) I might like, I'll see many > branches popping up. >> > b. Not using our standard strategy (moving with the community, >> > not alone) you "losed" the control about the changes you made >> > respectively to the OFBiz trunk >> >> Hmm. That didn't happen. >> >> The trick is to keep a record of exactly where you branched off, to > know how and which >> files/folders to do a diff. Of course, you'll need to know which > direction to do the diff-patch. >> > c. This is not a problem for you (your branch is a fork but good >> > for you) >> >> If my branch isn't kept in step with OFBiz trunk, that's not ok for > me. The OFBiz trunk is >> constantly getting updates and bugfixes. Like I said, the "loss of > control" didn't happen. I am >> still in step with OFBiz trunk. Only issue I have is that the OFBiz > trunk can't keep in step with >> my own updates, which is fine by me if I really don't mind kicking > back and relaxing after >> finishing my own work. >> >> > d. You don't have time to extract your changes atomically but >> > with a huge patch (unusable by commiters) >> >> You're right on this count. Due to the way I perform wholesale > aggressive merges (to bring in big >> enhancements), my commits are not small. They are quite mostly large > and wide in scope. I perform >> such wholesale merges, then somehow systematically pick off all > incompatibilities. >> Hence, I can only feed large patches to the community, not atomic ones > like "Added feature A" or >> "Fixed bug B". >> >> > 3. So your only solution to have your changes in the trunk is for > us to >> > open a branch for you >> >> No, the solution is for myself to give you a patch that will bring 2 > things together: the latest >> of OFBiz and the latest of my work. I can tell you that I've tested > this patch, but it's really up >> to the community to trust me. >> >> On your part, the solution would be to just dump my patch into your > trunk. Or if you want to have >> a cautious look-see first, you could open a new branch just to test > out my patch. This >> "exploratory/probationary" branch will be very short-lived, possibly > 2-3 updates in the timeline. >> After the few updates, you can decide: >> >> a. My patch is playing well with the latest of OFBiz, and you merge it > into >> trunk. >> >> OR >> >> b. My patch still has too many incompatibilities with OFBiz, and you > discard >> it. > > To be able to test your changes it'd be really better to at least have > an idea of the features that are added (or withdrawed f any). If they > are many changes and we don't know which they are, just funding our > reviewing work from a diff might be a nightmare. > > >> As you can see, the bulk of the work is on my part, in "bringing the > latest of OFBiz and my work >> together". The fact that I already have the latest of OFBiz playing > with my enhancements is >> already more than half the work done. >> >> Most folks I come across don't know how to do that part. I was > suggesting that someone among us, >> someone comfortable with version control adventures, perform that > merge for those who can't. > > Following http://tinyurl.com/2o5bld this should not be too hard I guess. > Even for people (like me for instance) that have never played with > branches in their own work (ok I have an advantage : I read the book) > >> I'm gonna assume you understand the concepts I tried to describe > above. It's dinner time now. >> Ultimately, the concepts involve "maximizing concurrency". It won't be > good if I find myself >> limiting my rate/size of progress just so I don't "lose control" or > lose sight of OFBiz trunk. I >> just moved ahead at full speed, all the while being confident that > OFBiz trunk will always be >> mergeable into my SVN. The question is whether the OFBiz SVN is > similarly confident about merging >> our mad-cap-paced work into OFBiz trunk. > > Yes I understand your POV. It stays that merging your change might be a > challenge. And I'm not sure who will want to take it or rather have > enough "free" time to do it. Explaining clearly what these changes > might bring to OFBiz (at the businnes and technical levels) would surely > be a *1st step* in this direction. > > Please, don't misunderstand me. Here, I'm trying to find a way to be > able to merge your changes because I'm sure they are worth it. > > Also remember this discussion we had with Chris (and others) about > "joint work" and licence. This is perhaps the worse issue in your case ! > You may Googlize or use Nabble if you need explanations... > > Jacques > >> Jonathon >> >> Jacques Le Roux wrote: >>> Jonathon, >>> >>> I don't want to be agressive or let you thing that I like to make >>> "off-tangent" remarks. Here is what I think (I can't tell that > facts): >>> 1. I'm sure you might be able to be a great help for the community. >>> 2. I better understand now why you'd like to have an "open" branch, >>> correct me if I'm wrong >>> a. You have your own branch(es) of OFBiz >>> b. Not using our standard strategy (moving with the community, > not >>> alone) you "losed" the control about the changes you made > respectively >>> to the OFBiz trunk >>> c. This is not a problem for you (your branch is a fork but good > for >>> you) >>> d. You don't have time to extract your changes atomically but > with a >>> huge patch (unusable by commiters) >>> 3. So your only solution to have your changes in the trunk is for us > to >>> open a branch for you >>> >>> Okay I'm a bit rude but you forced me and that's really what I > think. >>> Of course I'm open to discussion, you may also pass by my comments. >>> >>> Sorry and good luck >>> >>> Jacques >>> >>> ----- Message d'origine ----- >>> De : "Jonathon -- Improov" <[hidden email]> >>> À : <[hidden email]> >>> Envoyé : dimanche 22 avril 2007 04:21 >>> Objet : Re: Ofbiz Contribution Proposal >>> >>> >>>> Tim, >>>> >>>> I've already taken those "first steps" long ago. Like I said, I > don't >>> know which Jira "feature >>>> requests" are not reviewed; I only know those I have merged into my >>> own SVN. I really don't have >>>> time to send up itemized or clearly demarcated patches. >>>> >>>> Many patches I grabbed from folks (sorry I did it so fast, I don't >>> even know who), they work. Some >>>> require streamlining mainly to match OFBiz coding standards and > such, >>> but still they do work. By >>>> now, radical patches (like those from Chris Howes?) have gone > through >>> merging, and have even taken >>>> a life (progressed) of their own. That's why I can't tell you > "which >>> Jira issues", because my >>>> "private Jira store", so to speak, has "moved on". If I can do this >>> aggressively merging without >>>> problems (please use branches for sanity's sake), I am assuming the >>> community of 400 here can do >>>> the same, if not better. (And I'm guessing a good majority of this > 400 >>> might just be doing what I >>>> am doing, and OFBiz is none the better for it.) >>>> >>>> For now, let's just all do what we're good at, and keep at it. > Maybe >>> some day, I can submit a >>>> gigantic patch and it will somehow translate into a bigger better >>> OFBiz. For now, I can't help but >>>> leech off of OFBiz, every single update, but still can't feed the >>> whole sum back to OFBiz. Tough >>>> on my conscience, but something I'll have to live with. >>>> >>>> By the way, I have no idea what some folks here are intending to >>> achieve with some off-tangent >>>> remarks. If it's "status quo" they want (in relation to me and "my" >>> patches, ie), they've got it. >>>> If you can understand what I'm doing in my own computers (with > OFBiz >>> and radical patches), that's >>>> good and you may do the same good(?) thing in time. If not, I may >>> change my bad(?) tactics over >>>> time. Either way, let's just get back to what we're good at. >>>> >>>> Jonathon >>>> >>>> Tim Ruppert wrote: >>>>> Jonathon - as has always been the case - the role of reviewing >>> "complex" >>>>> patches does not fall strictly on the committers - it falls on the >>>>> entire community. The committers then have the role of putting > the >>> code >>>>> into the trunk. >>>>> >>>>> If you are so concerned that valid works are not being put back > into >>> the >>>>> trunk aggressively enough (which I think that everyone who spends >>> time >>>>> over here would agree), could you try the proactive approach of >>> looking >>>>> at more patches and letting the community know which ones you > think >>> are >>>>> tested well enough and offer enough value to go back into the > trunk? >>>>> That would be a GREAT first step and a very nice change of pace > from >>> the >>>>> aggressive tone you seem to think is appropriate. >>>>> >>>>> Cheers, >>>>> Tim >>>>> -- >>>>> Tim Ruppert >>>>> HotWax Media >>>>> http://www.hotwaxmedia.com >>>>> >>>>> o:801.649.6594 >>>>> f:801.649.6595 >>>>> >>>>> >>>>> On Apr 20, 2007, at 10:49 PM, Jonathon -- Improov wrote: >>>>> >>>>>> David, >>>>>> >>>>>>> "We" do not now, nor have we ever, turned away a contribution >>> because it >>>>>>> was complex. >>>>>> Very well, I'll just use the word "you" then. I take it that you > do >>>>>> not turn away contributions because they were complex. >>>>>> >>>>>> The question from me would be whether you do or do not turn away, >>>>>> knowingly or not, contributions that are valid but too complex > for >>>>>> review. It's not rhetorical, but you're free to do your own >>>>>> sanity/verification checks on that supposed phenomenon and deem > it >>>>>> rhetorical or invalid. >>>>>> >>>>>>> Could you do us all a big favor Jonathon? Your comments seem to >>> be >>>>>>> fairly consistent along these lines. I think what would be >>> helpful to >>>>>>> you, and to anyone reading and agreeing with your comments, is > to >>> step >>>>>>> back and try to explain why things are the way they are. Feel >>> free to >>>>>>> share that with the group for a sanity check if you'd like. >>>>>> I'm not so sure of the "why" of things, but am only more certain > of >>>>>> the "what" of things. Things are the way they are, no matter how > we >>>>>> interpret the "why". >>>>>> >>>>>> So, for now, I continue to merge in (to my own SVN) several >>>>>> contributions that are deemed too difficult to review/merge by > the >>>>>> committers. I continue to keep such enhancements in step with >>> updates >>>>>> from OFBiz trunk. And I continue in my failure(?) to feed such >>>>>> "compatibilized/merged" enhancements back to OFBiz trunk even >>> though >>>>>> they really are the same license. >>>>>> >>>>>> And the phenomenon of several of us (incompatible contributors?) >>>>>> holding on to our own enhancements will continue. Some of us may >>> not >>>>>> know how to keep in step with OFBiz trunk updates; others may. >>> Those >>>>>> of us who can keep in step will continue to benefit from OFBiz >>>>>> progress, but be unable to feed the benefit back to OFBiz. There >>> will >>>>>> still be enhancements out there that are kept away/apart from >>> OFBiz. >>>>>> That's the way of things? Or maybe not? >>>>>> >>>>>> I stand corrected. I think I am "helping" OFBiz in the wrong way. >>> I'll >>>>>> stop that. :) Thanks for reminding me. >>>>>> >>>>>> I was waiting to dump the loads of my enhancements into your > trunk, >>>>>> but I think I should take a sanity check for now. Anyway, there >>> needs >>>>>> to be at least one stabilizing branch (save point, so to speak) >>> before >>>>>> we can go full steam with the trunk. And there's still no such >>> branch yet. >>>>>> Jonathon >>>>>> >>>>>> David E. Jones wrote: >>>>>>> On Apr 20, 2007, at 9:04 PM, Jonathon -- Improov wrote: >>>>>>>> We shouldn't turn away complex contributions anymore. >>>>>>> "We" do not now, nor have we ever, turned away a contribution >>> because >>>>>>> it was complex. >>>>>>>> I myself have loads of enhancements (mostly to widget module) >>> that I >>>>>>>> feel uneasy about releasing to the community, simply because of >>> this >>>>>>>> odd use of trunk: it's used like a slow-moving release branch >>> that >>>>>>>> is unable to handle introductions of radical enhancements. >>>>>>>> >>>>>>>> Yet, this somewhat slow-moving trunk isn't still enough and >>> focused >>>>>>>> enough on achieving release-quality stability. It's the worst > of >>>>>>>> both worlds: it's not rapid enough to allow for radical > progress, >>>>>>>> and not calm and focused-on-cleaning-up enough to produce a >>> stable >>>>>>>> release for non-OFBiz developers. >>>>>>> Could you do us all a big favor Jonathon? Your comments seem to > be >>>>>>> fairly consistent along these lines. I think what would be > helpful >>> to >>>>>>> you, and to anyone reading and agreeing with your comments, is > to >>>>>>> step back and try to explain why things are the way they are. > Feel >>>>>>> free to share that with the group for a sanity check if you'd >>> like. >>>>>>> -David >>> > > |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |