Contributions and Developments

[Daniel Kunkel]

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

--
Daniel

*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-
Have a GREAT Day!

Daniel Kunkel           [hidden email]
BioWaves, LLC           http://www.BioWaves.com
14150 NE 20th St. Suite F1
Bellevue, WA 98007
800-734-3588    425-895-0050
http://www.Apartment-Pets.com  http://www.Illusion-Optical.com
http://www.Card-Offer.com      http://www.RackWine.com
http://www.JokesBlonde.com     http://www.Brain-Fun.com 
*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-

[jonwimp]

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
>

[Daniel Kunkel]

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
> >
>

[jonwimp]

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
>>>
>
>

[Daniel Kunkel]

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
> >>>
> >
> >
>

[Jacques Le Roux]

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" <[hidden email]>
To: <[hidden email]>
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
> >

[David E Jones]

On Jan 28, 2007, at 11:46 PM, Jacques Le Roux wrote:

> 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

Not necessarily. It is up to the committers to review this, but the  
general guideline is to distinguish (as explained on that page and in  
related documents) based on how and why it was developed.

For example, if someone fixes a bug in OFBiz in almost any case if it  
is contributed back then the how and why is pretty clear. The amount  
of time that lapses between doing it an contributing it doesn't  
really matter.

> 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 a dangerous idea Jacques. It is the responsibility of all  
committers to make sure the source of the code is clear, especially  
where it may have been developed independently and not intended to go  
into OFBiz but someone else took it and contributed it. Under no  
circumstances is it okay for that code to go into OFBiz, and it is  
ultimately the responsibility of the PMC to take care of this, and  
that responsibility is delegated to non-PMC committers (though PMC  
members should still review commits and issues to check on this).

> This is only my opininon and not commiters's or PMC's or even  
> ASF's, of course.

Hopefully what I wrote clears this up a bit. Again, the documents on  
www.apache.org/dev clarify a lot of these issues.

-David

[jonwimp]

David,

 > Hopefully what I wrote clears this up a bit. Again, the documents on
 > www.apache.org/dev clarify a lot of these issues.

Clear.

 > it is ultimately the responsibility of the PMC to take care of this, and that
 > responsibility is delegated to non-PMC committers (though PMC members should
 > still review commits and issues to check on this).

True. I'd say the "ease/rate of integration of contribution into OFBiz" depends on
motivation/impetus. If I wanted my contributions merged in fast, I'd do my part to aid the PMC in
their responsibility to keep the source clean.

Somebody (don't know who) mentioned "sabotage via contribution of unclean codes". I guess that
means it's dangerous to "shake hands with just about any external contributor, and commit
contributions based on good faith alone".

Jonathon

David E. Jones wrote:

>
> On Jan 28, 2007, at 11:46 PM, Jacques Le Roux wrote:
>
>> 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
>
> Not necessarily. It is up to the committers to review this, but the
> general guideline is to distinguish (as explained on that page and in
> related documents) based on how and why it was developed.
>
> For example, if someone fixes a bug in OFBiz in almost any case if it is
> contributed back then the how and why is pretty clear. The amount of
> time that lapses between doing it an contributing it doesn't really matter.
>
>> 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 a dangerous idea Jacques. It is the responsibility of all
> committers to make sure the source of the code is clear, especially
> where it may have been developed independently and not intended to go
> into OFBiz but someone else took it and contributed it. Under no
> circumstances is it okay for that code to go into OFBiz, and it is
> ultimately the responsibility of the PMC to take care of this, and that
> responsibility is delegated to non-PMC committers (though PMC members
> should still review commits and issues to check on this).
>
>> This is only my opininon and not commiters's or PMC's or even ASF's,
>> of course.
>
> Hopefully what I wrote clears this up a bit. Again, the documents on
> www.apache.org/dev clarify a lot of these issues.
>
> -David
>
>

[cjhowe]

http://incubator.apache.org/ip-clearance/index.html 

makes it _almost clear to me. Two things remain cloudy to me (my
original reading of that link assumed that did not apply to TLPs,
thanks for clarifying Jacques!):

1) What is the lowest common denominator of when contributions should
be utilizing the incubator's IP Clearance procedures?  It would seem
that many contributions already should have utilized such protocol
(especially the additional notes section of that link for - multiple
contributors, specifically).  If many OFBiz contributions have already
utilized such, is this a process transparent to the community or is it
more internal to the ASF?  Judging by the other links on that page, the
former seems true.

2)The bug scenario
Since a non-committing contributor can have no reasonable expectation
that his contribution will get put into the project, the only intent
that he can show (through individual, joint work or otherwise) is that
he wished his local copy to be free of that bug and that he wanted
others, not specifically the ASF, to benefit from his exercise.  This
would suggest the need for a greater use of the incubator's IP
clearance procedures as nothing really qualifies as "created _for
Apache OFBiz".

In any event, absent posing questions regarding these topics to legal
discuss, I guess the only way my fears can be alleviated is by seeing
the PMC more frequently (or more transparently if it is already
frequent) using the incubator IP clearance procedures.  The rest can be
left to the invisible hand of the open source market to balance the
burdens of administrivia and the benefits of community cohesiveness.

--- "David E. Jones" <[hidden email]> wrote:

>
> On Jan 28, 2007, at 11:46 PM, Jacques Le Roux wrote:
>
> > 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
>
> Not necessarily. It is up to the committers to review this, but the  
> general guideline is to distinguish (as explained on that page and in
>  
> related documents) based on how and why it was developed.
>
> For example, if someone fixes a bug in OFBiz in almost any case if it
>  
> is contributed back then the how and why is pretty clear. The amount
>
> of time that lapses between doing it an contributing it doesn't  
> really matter.
>
> > 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 a dangerous idea Jacques. It is the responsibility of all  
> committers to make sure the source of the code is clear, especially  
> where it may have been developed independently and not intended to go
>  
> into OFBiz but someone else took it and contributed it. Under no  
> circumstances is it okay for that code to go into OFBiz, and it is  
> ultimately the responsibility of the PMC to take care of this, and  
> that responsibility is delegated to non-PMC committers (though PMC  
> members should still review commits and issues to check on this).
>
> > This is only my opininon and not commiters's or PMC's or even  
> > ASF's, of course.
>
> Hopefully what I wrote clears this up a bit. Again, the documents on
>
> www.apache.org/dev clarify a lot of these issues.
>
> -David
>
>
>

[Jacques Le Roux]

David, all,

----- Original Message -----
From: "David E. Jones" <[hidden email]>

>
> On Jan 28, 2007, at 11:46 PM, Jacques Le Roux wrote:
>
> > 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
>
> Not necessarily. It is up to the committers to review this, but the
> general guideline is to distinguish (as explained on that page and in
> related documents) based on how and why it was developed.

After having read (or re-read) carefully this documents (including
http://www.apache.org/licenses,
http://incubator.apache.org/ip-clearance/ip-clearance-template.html,
http://www.apache.org/licenses/proposed/community.txt,
http://www.apache.org/licenses/proposed/software-grant.txt)

I can't see how the "how and why" is striclty determined.
Could you please explain this more clearly or give the exact links where to find such informations ?

Moreover in
http://www.apache.org/licenses/proposed/community.txt,
I read
<<... you agree to only submit a Contribution
   when you are the copyright owner of that Contribution or when you
   have obtained the owner's permission to make said Contribution on
   their behalf.  It is your responsibility to notify the Foundation of
   any conditions that apply to the communication that might make it
   ineligible for Contribution...>>

That's exactly what I intended to explain to Jonathon. My goal is not to annoy anybody with this kind of mails, including Joanthon
of course. But to try to help Jonathon to understand the "sandbox problem".  I know that this can be really boring (for my part I'm
completly exhausted by those researches, notably on joint work issue) but I'm sure everybody understand the importance and scope.
Finally, I know that this document is not yet official as it's explained on its top. But if I understand well it shall be soon as
explained in http://www.apache.org/licenses/proposed/#clas)

Please note also in http://www.apache.org/licenses/proposed/software-grant.txt
<<...Licensor's patent grant above shall terminate with respect to any
      party that institutes patent litigation against the Licensor
      (including a cross-claim or counterclaim in a lawsuit) alleging
      that the Software constitutes direct or contributory patent
      infringement, as of the date such litigation is filed....>>

> For example, if someone fixes a bug in OFBiz in almost any case if it
> is contributed back then the how and why is pretty clear. The amount
> of time that lapses between doing it an contributing it doesn't
> really matter.
>
> > 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 a dangerous idea Jacques. It is the responsibility of all
> committers to make sure the source of the code is clear, especially
> where it may have been developed independently and not intended to go
> into OFBiz but someone else took it and contributed it. Under no
> circumstances is it okay for that code to go into OFBiz, and it is
> ultimately the responsibility of the PMC to take care of this, and
> that responsibility is delegated to non-PMC committers (though PMC
> members should still review commits and issues to check on this).

What I wanted to point out is how a commiter may know that a contribution is from only one person of a group if that person don't
tell it when proposing to include his work (with of course the eventual needed documents) ?
This is just what may happen if sandbox usage becomes common.

I know that all this may appear for some person too emphatic, but please think a bit about what may happen if OFBiz become more and
more used and recognized...

> > This is only my opininon and not commiters's or PMC's or even
> > ASF's, of course.
>
> Hopefully what I wrote clears this up a bit. Again, the documents on
> www.apache.org/dev clarify a lot of these issues.

Yes thanks and I know that I have still to learn in this area. I hope to have been clear, please correct me if I'm missing or
misunderstanding some points.

Jacques

> -David
>
>
>

[cjhowe]

There is an interesting discussion that has been going on for the last
week on the incubator general mailing list:
http://www.nabble.com/-Vote--Incubating-Project-Policy-tf3158407.html
regarding this and similar topics.

#2 I believe was clarified by Robert Burrell Donkin in
http://tinyurl.com/yqsvdd
I believe David's "almost any case" scenario is speaking specifically
of contributions by committers, not of contributions by noncommitters
as I had understood it when I replied.  Please let me know if I've
misinterpreted Robert's message. I wanted to clarify that for everyone
instead of leaving the question open-ended like it is.


--- Chris Howe <[hidden email]> wrote:

> http://incubator.apache.org/ip-clearance/index.html 
>
> makes it _almost clear to me. Two things remain cloudy to me (my
> original reading of that link assumed that did not apply to TLPs,
> thanks for clarifying Jacques!):
>
> 1) What is the lowest common denominator of when contributions should
> be utilizing the incubator's IP Clearance procedures?  It would seem
> that many contributions already should have utilized such protocol
> (especially the additional notes section of that link for - multiple
> contributors, specifically).  If many OFBiz contributions have
> already
> utilized such, is this a process transparent to the community or is
> it
> more internal to the ASF?  Judging by the other links on that page,
> the
> former seems true.
>
> 2)The bug scenario
> Since a non-committing contributor can have no reasonable expectation
> that his contribution will get put into the project, the only intent
> that he can show (through individual, joint work or otherwise) is
> that
> he wished his local copy to be free of that bug and that he wanted
> others, not specifically the ASF, to benefit from his exercise.  This
> would suggest the need for a greater use of the incubator's IP
> clearance procedures as nothing really qualifies as "created _for
> Apache OFBiz".
>
> In any event, absent posing questions regarding these topics to legal
> discuss, I guess the only way my fears can be alleviated is by seeing
> the PMC more frequently (or more transparently if it is already
> frequent) using the incubator IP clearance procedures.  The rest can
> be
> left to the invisible hand of the open source market to balance the
> burdens of administrivia and the benefits of community cohesiveness.
>
> --- "David E. Jones" <[hidden email]> wrote:
>
> >
> > On Jan 28, 2007, at 11:46 PM, Jacques Le Roux wrote:
> >
> > > 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
> >
> > Not necessarily. It is up to the committers to review this, but the
>  
> > general guideline is to distinguish (as explained on that page and
> in
> >  
> > related documents) based on how and why it was developed.
> >
> > For example, if someone fixes a bug in OFBiz in almost any case if
> it
> >  
> > is contributed back then the how and why is pretty clear. The
> amount
> >
> > of time that lapses between doing it an contributing it doesn't  
> > really matter.
> >
> > > 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 a dangerous idea Jacques. It is the responsibility of all  
> > committers to make sure the source of the code is clear, especially
>  
> > where it may have been developed independently and not intended to
> go
> >  
> > into OFBiz but someone else took it and contributed it. Under no  
> > circumstances is it okay for that code to go into OFBiz, and it is
>
> > ultimately the responsibility of the PMC to take care of this, and
>
> > that responsibility is delegated to non-PMC committers (though PMC
>
> > members should still review commits and issues to check on this).
> >
> > > This is only my opininon and not commiters's or PMC's or even  
> > > ASF's, of course.
> >
> > Hopefully what I wrote clears this up a bit. Again, the documents
> on
> >
> > www.apache.org/dev clarify a lot of these issues.
> >
> > -David
> >
> >
> >
>
>