Ok... I missed the right now. I definitely understand that it takes a bit to put together a "clean patch." However, I would like to see if we could have people even send in to jira their messy patches if they did some work that will probably be of real value and don't have the time. Last year it seemed like every few months someone would be working on Authorize.net and asking if anyone had started the effort.
-- > The same SVN tricks can be applied to an Apache sandbox, so I don't > understand the "too much work > to create and manage" argument. In the original idea, anyone would be able to become a committer, only they would be limited to working in the sandbox. Unfortunately becoming an Apache contributor is a big deal with a significant bit of paperwork, a process that is much better reserved for dedicated developers. If anyone who wanted was allowed commit access the sandbox, it would likely become a huge mess. Managing it might then take more time and effort than it was worth. It's possible this could be avoided, but the point is moot due to the difficultly of allowing anyone Apache contributor status. This, with the fact that we may soon be almost doubling the number of committers suggests that sandboxed features applied by the contributors would much better be applied in the appropriate module in a way that won't effect the operation of the software unless it is manually switched on until it's well tested. Thanks Daniel On Mon, 2007-01-29 at 12:48 +0800, Jonathon -- Improov wrote: > Daniel, > > > Jonathan, you confuse me. > > That's because I (and possibly whole OFBiz team) am now in a conundrum. :) > > I see the problems. I know the dangers. I've since done what I can do with > interim measures, such > as a private sandbox that I personally guide regularly to parallel main OFBiz > branch as much as > possible (I hope my explanation of SVN concepts were clear enough). > > My interim measure, in short, is to have a well-managed private sandbox (like > your suggestion) in > which I crash-test every patch to death. Then when I have a lull period, I do > a quick diff and > submit all patches systematically and cleanly to OFBiz. That's exactly what > I'm doing now. I was > trying to explain how it really is easy to do this with SVN, hence the few > "technical notes" I > drop in your threads. > > The same SVN tricks can be applied to an Apache sandbox, so I don't > understand the "too much work > to create and manage" argument. > > And here is where my road forks from yours. The OFBiz SVN is not mine/yours, > it's a community > resource that needs to be carefully managed for everybody. Loading a few > messy sandbox branches > onto that official SVN will certainly bloat the SVN contents. > > While we can easily prune off great ideas (branches) gone wrong, we will make > a mess of the OFBiz > SVN "timeline": you'll see the revision number going into the millions after > Jonathon has checked > in 100s of 1000s of mistakes that he needed to fix by checking in another > similar number of > corrections. > > I am ok with setting up another SVN, a sandbox, apart from OFBiz's. We can > check in millions of > mistakes and corrections into that sandbox, and our haphazardness will still > be inconsequential to > the official OFBiz SVN. > > > And then in another e-mail you will not make any effort to share what > > you're working on apparently because you're too busy. > > My project should've ended by January. Well, anyway, due to some > non-OFBiz-related issues (yes, > plus some OFBiz-related difficulties earlier on, 50/50 I'd say), I'm playing > catch-up now. I > should be free to serve the OFBiz community some time after mid-Feb, after my > project is done or I > get fired by then. > > But I hope you see that I am doing it out of altruism, if I ever do it. :P :) > > Also, we should understand that if OFBiz committers will review or otherwise > help me integrate my > sandbox's produce into OFBiz, they'll be doing it at their own costs. > > And I'll also be helping out in the integration effort at my own costs too. > > Hence my reason/excuse(?) that I'm too busy to make a clean and organized > contribution to OFBiz > right now. > > Jonathon > > Daniel Kunkel wrote: > > Jonathan, you confuse me. > > > > On one hand, you seem to agree that collaborating in open source > > software is a good thing... > > > >> > and that has meant that the community hasn't been able to do the one > >> thing > >> > open-source software does better than any other development modality > >> I've > >> > ever seen, make gold out of an idea and a buggy proto-type through the > >> > collaboration of many hands. > >> > >> That, in my opinion, is 99% true... > > > > And then in another e-mail you will not make any effort to share what > > you're working on apparently because you're too busy. > > > >> > So, does anyone have any works-in-progress they would like to share with > >> > the community and open up to a more collaborative development? > >> > >> Yes, I have. But I can't find the time to post it up anymore. Read my > >> first few posts to the ML to > >> see why. My reasons are the same as everybody else's here: need to get > >> real work done first to > >> earn bread and butter. > > > > Maybe I didn't make my points clearly enough, so I'm going to try again. > > > > It seems to me that OFBiz is at a point where it can shift gears in terms > > of > > collaborating on projects that are generally beneficial. In years past, > > functionality wasn't possible without a champion pushing it through, > > usually > > to completion. Now there may be a chance to work more collaboratively. > > > > A couple examples of the help that may come from sharing is Chris' > > suggestion for > > using the body id tag. Furthermore, who to better ensure the accuracy of > > the > > documents describing how each screen functions but the actual authors. > > > > However, we will need to start sharing our works-in-progress in order for > > that to happen. No one can take your work and build on it as long as the > > ideas and code stay hidden on your computer. > > > > On another subject, I left the conversation on the dev list thinking > > that there may not be an efficient way at this point for making an > > external sandbox that more than one entity has collaborated on. The best > > way to collaborate for now seems to be through jira. > > > > Finally, please don't expect much in the way of contributions from me... My > > goal in writing these emails is to try help OFBiz make it into the next > > gear > > of collaborative development, and share some of my ideas on where this > > project > > might go. I know that doesn't earn me any real merit in this meritocracy, > > but I'll consider my > > efforts well rewarded if even one other company says: "Here's some code we > > wrote > > for our own needs to do ____. It wont work as is with OFBiz, but it might > > be a > > better starting spot for someone else who wants the same functionality." > > > > > > > > > > > > > > > >> > One idea that was proposed was to create a collaborative space outside > >> of > >> > Apache OFBiz (external sandbox) to work on these various project. > >> > Unfortunately, collaborative works designed outside of Apache OFBiz need > >> > special treatment before they can be integrated into the project, an > >> onerous > >> > task that limits the run-away viability of these efforts. > >> > >> Then perhaps we should work on educating folks like me on how to set up an > >> OFBiz-compliant private > >> sandbox. > >> > >> > I then suggested an svn sandbox where non-committers could work on > >> > contributions that are not fit for production, but are considered a > >> > legal Apache OFBiz contribution, but idea was nixed because it would > >> > take too much work to create and manage the space and committers, and, > >> > it'd probably be a real mess. > >> > >> I don't really understand the "too much work to create and manage" > >> argument. > >> > >> In my own SVN trees, I have "experimental branches" all the time. It's no > >> work at all. I merge my > >> experimental branches back into trunk after I've tested it sufficiently. > >> Well, ok, this merge can > >> be quick tricky if you're not used to working with numerous prototyping > >> branches like it's your > >> 2nd nature. I've been practicing the "branch and conquer" prototyping > >> approach for years now; > >> reason that works is due to this: hindsight is cheaper and more accurate > >> than foresight. > >> > >> (Quick technical note. If a tree branch grows too far out from trunk, > >> it'll be hard to bring it > >> back to trunk. But if we occasionally guide the branch to parallel the > >> trunk, the eventual > >> merge-back will be easy.) > >> > >> The argument "it'd probably be a real mess" is real, though. > >> > >> It's like my private sandbox assuming it's thoroughly badly coded (non-MVC > >> even). Say I completely > >> mess up the structure of my codes such that they don't follow OFBiz > >> framework at all. It'd be > >> close to impossible to merge my horribly managed sandbox into OFBiz. > >> > >> > The most workable idea at this time involves using the jira issue > >> tracker to > >> > submit patches that implement a new feature. This solution isn't the > >> best > >> > because it may involve a lot of patch applications, that can be > >> alleviated if > >> > a committer creates what I'll call a feature sandbox, or inactive code > >> in the > >> > svn repository that can be developed collaboratively. This process > >> should go > >> > much more smoothly soon, however, as OFBiz is intending to almost > >> double the > >> > number of committers. > >> > >> More QUALIFIED committers will certainly help the situation. Bringing in > >> folks like "crazy > >> Jonathon" could hinder the process instead. :) > >> > >> The OFBiz project manager(s) need to put in lots of work to build and > >> educate their committer > >> team, not easy. Which feeds back to the "it'd probably be a real mess" > >> argument for sandboxes run > >> by untrained committers. > >> > >> > So, does anyone have any works-in-progress they would like to share with > >> > the community and open up to a more collaborative development? > >> > >> Yes, I have. But I can't find the time to post it up anymore. Read my > >> first few posts to the ML to > >> see why. My reasons are the same as everybody else's here: need to get > >> real work done first to > >> earn bread and butter. > >> > >> Jonathon > >> > >> Daniel Kunkel wrote: > >>> Hi > >>> > >>> There's been an interesting discussion going on in the OFBiz dev e-mail > >>> forum that has some ramifications on users, and any contributions they > >>> care to make. You can follow the actual discussion from starting here: > >>> http://www.nabble.com/Refactoring-Create-Order-process-during-OFBiz- > >>> Developers-Conference-Sponsored-by-Hotwax-Media-tf3118353.html#a8668236 > >>> and under a new subject line, Intellectual Property and Sandbox SVN. > >>> (not in nabble yet.) > >>> > >>> Anyway, to over-simplify things we were discussing the procedure and > >>> legalities of making collaborative contributions to OFBiz. > >>> > >>> The way OFBiz is currently structured, any new code, because it can go > >>> right into production, needs to have a high degree of usefulness and > >>> general testing before it is even be considered for inclusion into the > >>> project. This is good, but it has meant that half-baked user > >>> contributions, or works-in-progress have often not been shared with the > >>> community, and that has meant that the community hasn't been able to do > >>> the one thing open-source software does better than any other > >>> development modality I've ever seen, make gold out of an idea and a > >>> buggy proto-type through the collaboration of many hands. > >>> > >>> I would to see if we can attract more of these works-in-progress > >>> contributions and organize them within the Apache OFBiz project so we > >>> can collaborate on their development. > >>> > >>> One idea that was proposed was to create a collaborative space outside > >>> of Apache OFBiz (external sandbox) to work on these various project. > >>> Unfortunately, collaborative works designed outside of Apache OFBiz need > >>> special treatment before they can be integrated into the project, an > >>> onerous task that limits the run-away viability of these efforts. > >>> > >>> I then suggested an svn sandbox where non-committers could work on > >>> contributions that are not fit for production, but are considered a > >>> legal Apache OFBiz contribution, but idea was nixed because it would > >>> take too much work to create and manage the space and committers, and, > >>> it'd probably be a real mess. > >>> > >>> The most workable idea at this time involves using the jira issue > >>> tracker to submit patches that implement a new feature. This solution > >>> isn't the best because it may involve a lot of patch applications, that > >>> can be alleviated if a committer creates what I'll call a feature > >>> sandbox, or inactive code in the svn repository that can be developed > >>> collaboratively. This process should go much more smoothly soon, > >>> however, as OFBiz is intending to almost double the number of > >>> committers. > >>> > >>> So, does anyone have any works-in-progress they would like to share with > >>> the community and open up to a more collaborative development? > >>> > >>> Thanks > >>> > > > > >
