Hi all,
> - A quickly disappearing svn code state that the patch was created against.
Just thought I'd comment quickly on this, since it's technical and it's in my
field.
1. Audit differences between my sandbox and OFBiz regularly.
2. Update regularly (after audit).
3a. Complain quickly if I see a commit in OFBiz that breaks my work.
3b. Change my wrong work direction quickly if my direction is gonna make my
private branch literally break off of OFBiz main branch due to severe
incompatibilities.
As for the "quickly disappearing svn code state", it's always there for me, never disappeared. I
always know which revision I forked from, so I know which revision to "diff upwards from" when
doing a merge-in from official OFBiz branch.
Hope that was clear. I've done it so often that it's become 2nd nature to me. Not even sure if
it's right. It just works right, feels right, somehow.
I don't know about the other not-so-technical issues.
I'm touching on SVN topic regarding synchronizing sandboxes with official OFBiz branch. Not
off-topic, I hope.
Jonathon
Daniel Kunkel wrote:
Hi
Ok, Chris, now you've confused me.
I don't have a problem understanding that collaborative efforts co-
mingled outside of "Apache Assigned" jira issues could have severe
issues, but it seems to me that collaboration is currently possible via
the inefficient jira patch process.
Isn't it completely appropriate for Collaborator A, say Phani to make an
"Apache Assigned" contribution in jira which Collaborator B improves and
again assigns it to Apache in an updated patch?
This still has all of the challenges I've mentioned before,
- One collaborator at a time.
- A quickly disappearing svn code state that the patch was created
against.
- inefficient and often chaotic patch handling.
- likelihood of losing the work to history
- lost opportunity to create strong community with more active energized
contributors.
- duplication of effort as more than one developer independently work on
features.
etc.
If this jira patch process is legal, then I think we're at the point of
beating a dead horse, but hopefully with the wheels of change in motion.
Daniel
On Sat, 2007-01-27 at 08:28 -0800, Chris Howe wrote:
Tim,
I do agree that there is a protocol in place, but I do not agree that
everyone is following it. Those that seem the most opposed to a
discussion about a sandbox are the ones that keep pumping out the joint
works. From my limited understanding, this does not appear to be a
legal format to license under open source without exposing the
contributor to partnership liability and the exposing the community
with the task of rooting out the offending code.
I gave you a list of 10 environments that are complex enough and
require
more than incremental changes. Tabling this discussion will continue to
lose many of the valuable contributions of the community (Like Phani's
work on Google Checkout integration).
In addition, continuing to table this discussion will increase the
likelihood that offending code makes its way into the project. If
someone makes a stink about it, my understanding is that the remedy is
for the ASF and anyone using Apache OFBiz to cease and desist until the
offending code is removed. If a business is running off Apache OFBiz,
how much will it cost them to cease and desist? If they choose not to
C & D, how much will it cost them to defend against a copyright
infringement claim?
If my legal understanding is incorrect, someone please post the
question to legal-discuss and get a real lawyer's opinion. If there is
no real risk in these joint works being added to the project, address
it as such.
Regards,
Chris
--- Tim Ruppert <[EMAIL PROTECTED]> wrote:
Can we all agree on the fact that there is a protocol in place, that
if followed, allows everyone the ability to pass code around in a
legal format? This may or may not be the most optimal format for
said collaboration, but it does permit us to contribute back to the
community in a meaningful way.
Let's table this sandbox discussion until we find a movement complex
enough that it requires something more than incremental changes to be
made to the trunk before we can agree to include it. Does that sound
reasonable? Once there is an idea to build something that cannot
follow this incremental pattern, we can evaluate where we are in
terms of resources and determine the best course of action to follow.
Cheers,
Tim
--
Tim Ruppert
HotWax Media
http://www.hotwaxmedia.com
o:801.649.6594
f:801.649.6595
