Jonathon, Just one word to be sure you understand your responsability by opening your "sandbox" to other users without contracts between you (hence creating a joint work as pointed out by Chris). You will have to get through this procedure http://incubator.apache.org/ip-clearance/index.html
If you don't and don't tell us (commiters) you will be the sole responsable because of our good faith (not knowing that it comes not only from you). This is only my opininon and not commiters's or PMC's or even ASF's, of course. Thanks for your attention Jacques PS : if you have any doubt please consider searching this sentence with Google : "a work prepared by two or more authors with the intention that their contributions be merged into inseparable or interdependent parts of a unitary whole" ----- Original Message ----- From: "Jonathon -- Improov" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Monday, January 29, 2007 3:17 AM Subject: Re: Contributions and Developments > Daniel, > > Really great that you would find time to help us with some kinks in our "feed > it back to OFBiz" > procedures. > > Here are just some of my personal opinions about the state of affairs. > > > 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 isn't entirely true yet. If it were, I wouldn't be occasionally shocked > to find destabilizing > codes check into SVN, or find half-baked functionalities checked in that > appears as tantalizing > red herrings to users. > > Call me a control freak or whatever, but I do wish the main OFBiz trunk is > clean of careless check > ins. Not that it's so unclean now; I'd say maybe 10% of that trunk contains > codes that shouldn't > be checked in yet. > > BUT... but I must stress that we're talking about the OFBiz trunk (not tag or > release branches) > after all. The way I see "trunks", they're meant to take all manner of fast > and furious > enhancements/corrections. > > I don't know if we have enough resources to set up a team to audit OFBiz in > order to produce > stable release branches. > > > This is good, but it has meant that half-baked user contributions, or > > works-in-progress have often not been shared with the community, > > I'd say that's true to 90% extent. Just my opinion here, I think committers > themselves do check in > half-baked contributions; non-committers of course will not have such > privileges. As a > non-committer, I don't think I would like such a privilege. > > Imagine me saying this over a big pot of porridge for everybody's breakfast: > "Hey, you think I can > enhance the flavor by throwing in this herb I found by the roadside?" > > > 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. I've seen open source projects (eg > Thunderbird?) that are > blazing fast in development progress. But those projects usually have > wickedly competent > developers (all hardcore techies) who have the time of day and financial > freedom to obssess (yeah, > obssess) over those projects. > > > 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. > > It's hard to say whether we can succeed there. > > If my private sandbox is clean and well-coded, it'll be easy to go through > Apache's incubation > before merging it into OFBiz. But what if it isn't? > > It's like if I go to Intel and say I want to merge my television into their > next-generation CPU > chip. They'd probably tell me politely (or not) that I should "re-review my > contributions first". > > When there are lots of well-organized private sandboxes out there, I'd say > it'll be time then to > consider this objective again. Like say when I have a staggering number of > users voting for my > JonathonSoGreatSandbox-OFBiz. > > > 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 > >
