Re: Refactoring Create Order process during OFBiz Developers Conference Sponsored by Hotwax Media

[Tim Ruppert]

Comments inline - lemme preface this with the fact that these are my thoughts, I'll support whatever we can do to help people be more active, but I don't have time to deliberate this over email for too much longer . . . I hope everyone understands

On Jan 26, 2007, at 10:02 AM, Chris Howe wrote:

Tim,

If Anil and Ashish wrote anything in OFBIZ-510, then that's not
_exactly how anon checkout was created.  By quick glance, of the 61
messages containing the words OFBIZ-510 in them, you were the only one
who attached a patch, Anil and Ashish did not.  You three may have
passed patches amongst yourselves outside of the JIRA issue.  My

one individual and not the ASF.

understanding is this constitutes collaboration and therefore the asset you created is owned by the informal partnership between you three, not

I reviewed patches for Anil and Ashish - that is correct. There's no fancy partnership here - nor is there any any legal concern, but that's truly not what this discussion should be about.

In regards to the patches vs SVN argument, I am not following your
logic at all.  SVN is a tool to manage patches.  That's what it is,
that's what it does.  How could individual patches be easier to

talking about the collaboration part or just the part to merge back
into OFBiz?

maintain than the tool that is designed to do that maintenance? Are you

The point that I obviously didn't articulate very clearly is this :

1. There already is an SVN for managing the OFBiz

2. You will have to manage mods to the trunk in patches regardless - unless you'd want to go with some vendor branch scheme, which in my experience is WAY more trouble than it's worth. 3. Why can't you play on your own box like the rest of us - and only submit (or commit) when you have something to say that you want reviewed or to be shared?

A liberal sub-project SVN does not require patches be attached to a
JIRA issue until it's at a point to be contributed back into the major
work.  The collaborator simply commits his change.  That's what a
sandbox is for, to play in.  Unlike OFBiz itself, no one should expect
that the sandbox work.  At the time when it does work and it is
necessary to merge those changes back into the parent project, it will
require a single patch. Which because of the way OFBiz is set up, is
fairly small work.  That patch should have most bugs worked out and
testing is small work.

Cheers,
Tim

Chris, know that I feel you here, but why don't we just try this and see how it goes? If you end up having a huge following for these types of things, then I'll be the first person backing you and doing the leg work to put more infrastructure in place will be most beneficial.

--- Tim Ruppert <[EMAIL PROTECTED]> wrote:

I know this sounds overly simplified, but someone please explain to
me why this doesn't work:

1. Someone - let's say Chris has a great idea for a new project
2. He creates a JIRA issue describing it
3. He attaches an initial patch
4. Someone else - let's say Daniel decides that he wants to
contribute to this effort and downloads the patch
5. He makes some improvements, so he updates the existing patch as
well as adds another patch containing additional data
6. Chris downloads it and makes some mods and reposts.

Now, to me this doesn't seem that crazy - and is totally legal.
And . . . just so you know - replace Chris with Tim and Daniel with
either Anil or Ashish and you have EXACTLY what happened with the
anonymous checkout process!

This shouldn't be this hard guys.  My suggestion would be to TRY one

of these in this format and if you can't do it this way - THEN let's

try and address it.  A separately maintained sandbox is absolutely no

different  than managing patches - since both have to deal with
integration back into the OFBiz trunk in some form or fashion.

Personally, I think the patches will be EASIER to maintain because
they will allow you to make changes to existing code in an easier,
more trackable format.  The alternative would be for you to maintain

a sandbox - AND patches for updates to the source - doesn't that
sound MORE tedious?

Anyways, thanks for listening to my ramble.

Cheers,
Tim
--
Tim Ruppert
HotWax Media
http://www.hotwaxmedia.com

o:801.649.6594
f:801.649.6595

On Jan 26, 2007, at 3:04 AM, Daniel Kunkel wrote:

Hi

First, please understand I hold you in incredibly high regard, and
apologize for causing any frustration...  You and Andy have created

an

amazing software tool that I'm basing my business on, and you've

given

it away. I love that! As you can see, your efforts are now

multiplying

in to a system that has a life of its own, which will eventually
change
the face of many businesses throughout the world.

During this process, you've needed to exercise great control in
choosing
what to allow into the project, and what to reject. Since I often
update
my production system to the svn head, I'm very glad someone is

there

watching, and if you think about it, it makes sense that access has

been
very limited to just the professionals that have devoted themselves

to

the project.

However, as it grows, there are more and more newbies that want to

help
in their little way. Many *non-committers* who have wanted to give

back
to the project have been stifled and frustrated, often because

their

contributions were not appropriate, but sometimes simply because

the

committers are too busy to review/test/correct their contributions.

In

other cases, the resultant solutions are too specific to just their
business, or as a employee, the business although willing to donate

the
code back, was not willing to devote the time needed to make the
consumable by the project at large.

So, what can we do to create a space where non-committers can share
their bits with the community? Please understand, we are agreed

that

neither of us would want their contributions running on a system.

- The source forge sandbox isn't really a good fit, because, as

Chris

has researched, the legal ramifications of donating it back to the
project outweigh the benefits begotten from the group effort.

- Forcing developers to work alone isn't working very well.

- A sandbox with lots of committers isn't going to work. Thanks for
explaining that in your e-mail, I didn't realize this wasn't

workable

till now.

- Jira isn't working.

- The wiki could possibly work, but it doesn't go through the legal
process with each submission, and I cringe even thinking of trying

to

work with code in wiki. Eek.

- Even using the wiki, to catalog which jira issues are "in play"

is

unwieldy. Patch nightmare actually.

David, can you think of way to make a space in this community where

the
new/non-polished committers can easily share and play together with
their ideas where they won't hurt the bigger project until the
components are well proven?

Would it work to have a sandbox that is managed by the existing
committers, or perhaps a few new committers? As a committer, you
wouldn't need to give nearly the same amount of time and attention

to

trying to make sure the commitment met best practices, free of

bugs,

etc. Any developer could share their stuff that they've implemented

for
their business, or other neat components. And, since the

commitments

would be in svn on the other side of the "Donate to the Apache
Foundation legal radio button, it'd be easy for these developers to
collaborate and slowly bring unworkable buggy messes into gold.
Finally,
users could easily find and try the components without mucking with
patch files, etc.

Thanks

Daniel

On Fri, 2007-01-26 at 00:45 -0700, David E. Jones wrote:

Okay, I just wrote a huge thing and deleted it. There might have

been

good stuff in there, but I am really frustrated because I've said

it

all before and based on the comments from Chris it doesn't seem

like

anything it making it out there.

If you're not a lawyer, then reference documents and processes
already established.

I'm not even going to bother going into detail unless people are
willing to:

1. describe their understanding of how what they want to do would

be

done under current policy
2. describe why that doesn't work for what you want to do
3. describe how the existing processes need to changed in order to
accommodate it

A sandbox is a BAD BAD BAD BAD IDEA. Like you mentioned Daniel it
would create a huge mess. I'm afraid one of two things would

happen:

1. nothing
2. a lot

In the case of number 1 it's not worth the effort to set it up. In
the case of #2 it would required more effort to administer and
monitor than we have resources for in OFBiz. There is no way I'd

even

think about doing this under the ASF umbrella because I am not
willing to take on the responsibility of vetting a large number of
committers and recommending them as committers in the ASF, which

is

BIG DEAL, and a responsibility and some people seem to be

forgetting

that.

If you want to be a committer you have to help with the project.

You

have to take ownership of it, defend it, be committed to it, and

so

on. Okay, now I'm doing what I was in the 2 page email I just

deleted

and I'm stopping.

If you want to know more about becoming and being a committer and
about contributing to OFBiz, READ THE DARN DOCUMENTS!

=== message truncated ===

smime.p7s
Description: S/MIME cryptographic signature