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 understanding is this constitutes collaboration and therefore the asset you created is owned by the informal partnership between you three, not one individual and not the ASF.
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 maintain than the tool that is designed to do that maintenance? Are you talking about the collaboration part or just the part to merge back into OFBiz? 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. --- 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 ===
