Jonathon, I thought about all that and at this point I believe, regarding licence issues, the only way is for you
1. to create Jira issues for your own proper additions/modifications (being careful to don't mix "joint work", and checking ASL granted of course) 2. to comment in existing Jira issues the results of your tests (and vote if positive) to help commiters and accelerate commits Hope this help and you agree Jacques > Jacques, > > Glad I seem to be making sense to you. Please pardon my inability to explain some concepts; I'm > more a worker than a teacher/discusser. > > > To be able to test your changes it'd be really better to at least have > > an idea of the features that are added (or withdrawed f any). If they > > are many changes and we don't know which they are, just funding our > > reviewing work from a diff might be a nightmare. > > Yes, every commit does have some comments about what is added or changed. However, there are also > some comments that say: "Brought in Chris Howe's Rico experiment.". Again, the trick is I brought > in a huge wide-spanning stuff on a short-lived exploratory branch. Sort of like me saying, "Let me > try out being a casanova for a short time, just a quick try". I'm not a casanova, not > french/italian (sorry for stereotype, blame the movies), and I'd probably get in a lot of trouble > for trying. But SVN is not like real life. > > My ability/inability to "compatibilize" a huge patch with my work will determine whether or not > the exploratory branch dies or gets merged into my trunk. If I do have a casanova in me, I can try > some casanova lifestyle in the "main branch (trunk)" of my life; if not, that exploratory branch > gets pruned off for good, never to be merged into my trunk. > > > Yes I understand your POV. It stays that merging your change might be a > > challenge. > > No more a challenge than merging OFBiz trunk into our own work, due to the instability of the > trunk. If you recall, there are some folks who tried to "marry latest of OFiz with own > enhancements", and they failed. > > If I can use exploratory branches to bring in OFBiz trunk updates _wholesale_ (my commit logs go > like "brought in OFBiz trunk r123:456), the question still remains: Should it be that tough for > OFBiz SVN to bring in radical enhancements the way I bring in OFBiz trunk updates? > > OFBiz trunk updates, especially when they span a week, are just as "radical/un-atomic" as the > enhancements Karl or the rest of us try to submit. > > > Also remember this discussion we had with Chris (and others) about > > "joint work" and licence. This is perhaps the worse issue in your case ! > > You may Googlize or use Nabble if you need explanations... > > That's why I was following Chris Howes' dissertations on the "joint work" issue. > > I've since read the ASL 2.0. > > Merging my changes shouldn't be that difficult, since I only pull in stuff from JIRA and other > donations clearly labelled as ASL. Unless... I misunderstood that all patches/comments in JIRA > were explicitly contributed under ASL. > > As with all merges, the further the deviation (given time), the more difficult to reconcile. > Karl's contribution was 2 years in the making; that's 1.99 years too late to bring in. Yet, that > is still earlier than 2.01 years. The longer we wait (eg "please hold, we're busy, we'll look into > your enhancements soon"), the more difficult to reconcile. > > Similarly, for the release branch, there really is no point at all in waiting to fork one. OFBiz > is already very full-featured as it is now; it's a different case when OFBiz has not even ONE > function working. > > Hope all that makes sense to you. > > Jonathon > > Jacques Le Roux wrote: > > Jonathon, > > > > You should read other messages, then you w'd have seen Chris's about the > > new thread. Ok not a big deal. ;o) > > > > Happy that you did not feel my last message "rude" and that your answer > > is understandable by me (I must aknowledge that sometimes you lost me). > > > > Perhaps kepping the habit of using numbered points will help our > > communication (we have to keep it as concise as possible), trying : > > > > Seems that only the 3d point needs some comments, they are inline... > > > > > > ----- Message d'origine ----- > > De : "Jonathon -- Improov" <[EMAIL PROTECTED]> > > À : <[email protected]> > > Envoyé : dimanche 22 avril 2007 12:27 > > Objet : Re: Ofbiz Contribution Proposal > > > > > >> Jacques, > >> > >> You lost me. I don't see where you are (or were ever) rude. > >> > >> > a. You have your own branch(es) of OFBiz > >> > >> Yes, I have multiple branches sometimes, which will stabilize and > > collapse into a few (possibly 2 > >> or 3) branches, and then eventually come down to trunk. > >> > >> Usually, when I see a huge patch(es) I might like, I'll see many > > branches popping up. > >> > b. Not using our standard strategy (moving with the community, > >> > not alone) you "losed" the control about the changes you made > >> > respectively to the OFBiz trunk > >> > >> Hmm. That didn't happen. > >> > >> The trick is to keep a record of exactly where you branched off, to > > know how and which > >> files/folders to do a diff. Of course, you'll need to know which > > direction to do the diff-patch. > >> > c. This is not a problem for you (your branch is a fork but good > >> > for you) > >> > >> If my branch isn't kept in step with OFBiz trunk, that's not ok for > > me. The OFBiz trunk is > >> constantly getting updates and bugfixes. Like I said, the "loss of > > control" didn't happen. I am > >> still in step with OFBiz trunk. Only issue I have is that the OFBiz > > trunk can't keep in step with > >> my own updates, which is fine by me if I really don't mind kicking > > back and relaxing after > >> finishing my own work. > >> > >> > d. You don't have time to extract your changes atomically but > >> > with a huge patch (unusable by commiters) > >> > >> You're right on this count. Due to the way I perform wholesale > > aggressive merges (to bring in big > >> enhancements), my commits are not small. They are quite mostly large > > and wide in scope. I perform > >> such wholesale merges, then somehow systematically pick off all > > incompatibilities. > >> Hence, I can only feed large patches to the community, not atomic ones > > like "Added feature A" or > >> "Fixed bug B". > >> > >> > 3. So your only solution to have your changes in the trunk is for > > us to > >> > open a branch for you > >> > >> No, the solution is for myself to give you a patch that will bring 2 > > things together: the latest > >> of OFBiz and the latest of my work. I can tell you that I've tested > > this patch, but it's really up > >> to the community to trust me. > >> > >> On your part, the solution would be to just dump my patch into your > > trunk. Or if you want to have > >> a cautious look-see first, you could open a new branch just to test > > out my patch. This > >> "exploratory/probationary" branch will be very short-lived, possibly > > 2-3 updates in the timeline. > >> After the few updates, you can decide: > >> > >> a. My patch is playing well with the latest of OFBiz, and you merge it > > into > >> trunk. > >> > >> OR > >> > >> b. My patch still has too many incompatibilities with OFBiz, and you > > discard > >> it. > > > > To be able to test your changes it'd be really better to at least have > > an idea of the features that are added (or withdrawed f any). If they > > are many changes and we don't know which they are, just funding our > > reviewing work from a diff might be a nightmare. > > > > > >> As you can see, the bulk of the work is on my part, in "bringing the > > latest of OFBiz and my work > >> together". The fact that I already have the latest of OFBiz playing > > with my enhancements is > >> already more than half the work done. > >> > >> Most folks I come across don't know how to do that part. I was > > suggesting that someone among us, > >> someone comfortable with version control adventures, perform that > > merge for those who can't. > > > > Following http://tinyurl.com/2o5bld this should not be too hard I guess. > > Even for people (like me for instance) that have never played with > > branches in their own work (ok I have an advantage : I read the book) > > > >> I'm gonna assume you understand the concepts I tried to describe > > above. It's dinner time now. > >> Ultimately, the concepts involve "maximizing concurrency". It won't be > > good if I find myself > >> limiting my rate/size of progress just so I don't "lose control" or > > lose sight of OFBiz trunk. I > >> just moved ahead at full speed, all the while being confident that > > OFBiz trunk will always be > >> mergeable into my SVN. The question is whether the OFBiz SVN is > > similarly confident about merging > >> our mad-cap-paced work into OFBiz trunk. > > > > Yes I understand your POV. It stays that merging your change might be a > > challenge. And I'm not sure who will want to take it or rather have > > enough "free" time to do it. Explaining clearly what these changes > > might bring to OFBiz (at the businnes and technical levels) would surely > > be a *1st step* in this direction. > > > > Please, don't misunderstand me. Here, I'm trying to find a way to be > > able to merge your changes because I'm sure they are worth it. > > > > Also remember this discussion we had with Chris (and others) about > > "joint work" and licence. This is perhaps the worse issue in your case ! > > You may Googlize or use Nabble if you need explanations... > > > > Jacques > > > >> Jonathon > >> > >> Jacques Le Roux wrote: > >>> Jonathon, > >>> > >>> I don't want to be agressive or let you thing that I like to make > >>> "off-tangent" remarks. Here is what I think (I can't tell that > > facts): > >>> 1. I'm sure you might be able to be a great help for the community. > >>> 2. I better understand now why you'd like to have an "open" branch, > >>> correct me if I'm wrong > >>> a. You have your own branch(es) of OFBiz > >>> b. Not using our standard strategy (moving with the community, > > not > >>> alone) you "losed" the control about the changes you made > > respectively > >>> to the OFBiz trunk > >>> c. This is not a problem for you (your branch is a fork but good > > for > >>> you) > >>> d. You don't have time to extract your changes atomically but > > with a > >>> huge patch (unusable by commiters) > >>> 3. So your only solution to have your changes in the trunk is for us > > to > >>> open a branch for you > >>> > >>> Okay I'm a bit rude but you forced me and that's really what I > > think. > >>> Of course I'm open to discussion, you may also pass by my comments. > >>> > >>> Sorry and good luck > >>> > >>> Jacques > >>> > >>> ----- Message d'origine ----- > >>> De : "Jonathon -- Improov" <[EMAIL PROTECTED]> > >>> À : <[email protected]> > >>> Envoyé : dimanche 22 avril 2007 04:21 > >>> Objet : Re: Ofbiz Contribution Proposal > >>> > >>> > >>>> Tim, > >>>> > >>>> I've already taken those "first steps" long ago. Like I said, I > > don't > >>> know which Jira "feature > >>>> requests" are not reviewed; I only know those I have merged into my > >>> own SVN. I really don't have > >>>> time to send up itemized or clearly demarcated patches. > >>>> > >>>> Many patches I grabbed from folks (sorry I did it so fast, I don't > >>> even know who), they work. Some > >>>> require streamlining mainly to match OFBiz coding standards and > > such, > >>> but still they do work. By > >>>> now, radical patches (like those from Chris Howes?) have gone > > through > >>> merging, and have even taken > >>>> a life (progressed) of their own. That's why I can't tell you > > "which > >>> Jira issues", because my > >>>> "private Jira store", so to speak, has "moved on". If I can do this > >>> aggressively merging without > >>>> problems (please use branches for sanity's sake), I am assuming the > >>> community of 400 here can do > >>>> the same, if not better. (And I'm guessing a good majority of this > > 400 > >>> might just be doing what I > >>>> am doing, and OFBiz is none the better for it.) > >>>> > >>>> For now, let's just all do what we're good at, and keep at it. > > Maybe > >>> some day, I can submit a > >>>> gigantic patch and it will somehow translate into a bigger better > >>> OFBiz. For now, I can't help but > >>>> leech off of OFBiz, every single update, but still can't feed the > >>> whole sum back to OFBiz. Tough > >>>> on my conscience, but something I'll have to live with. > >>>> > >>>> By the way, I have no idea what some folks here are intending to > >>> achieve with some off-tangent > >>>> remarks. If it's "status quo" they want (in relation to me and "my" > >>> patches, ie), they've got it. > >>>> If you can understand what I'm doing in my own computers (with > > OFBiz > >>> and radical patches), that's > >>>> good and you may do the same good(?) thing in time. If not, I may > >>> change my bad(?) tactics over > >>>> time. Either way, let's just get back to what we're good at. > >>>> > >>>> Jonathon > >>>> > >>>> Tim Ruppert wrote: > >>>>> Jonathon - as has always been the case - the role of reviewing > >>> "complex" > >>>>> patches does not fall strictly on the committers - it falls on the > >>>>> entire community. The committers then have the role of putting > > the > >>> code > >>>>> into the trunk. > >>>>> > >>>>> If you are so concerned that valid works are not being put back > > into > >>> the > >>>>> trunk aggressively enough (which I think that everyone who spends > >>> time > >>>>> over here would agree), could you try the proactive approach of > >>> looking > >>>>> at more patches and letting the community know which ones you > > think > >>> are > >>>>> tested well enough and offer enough value to go back into the > > trunk? > >>>>> That would be a GREAT first step and a very nice change of pace > > from > >>> the > >>>>> aggressive tone you seem to think is appropriate. > >>>>> > >>>>> Cheers, > >>>>> Tim > >>>>> -- > >>>>> Tim Ruppert > >>>>> HotWax Media > >>>>> http://www.hotwaxmedia.com > >>>>> > >>>>> o:801.649.6594 > >>>>> f:801.649.6595 > >>>>> > >>>>> > >>>>> On Apr 20, 2007, at 10:49 PM, Jonathon -- Improov wrote: > >>>>> > >>>>>> David, > >>>>>> > >>>>>>> "We" do not now, nor have we ever, turned away a contribution > >>> because it > >>>>>>> was complex. > >>>>>> Very well, I'll just use the word "you" then. I take it that you > > do > >>>>>> not turn away contributions because they were complex. > >>>>>> > >>>>>> The question from me would be whether you do or do not turn away, > >>>>>> knowingly or not, contributions that are valid but too complex > > for > >>>>>> review. It's not rhetorical, but you're free to do your own > >>>>>> sanity/verification checks on that supposed phenomenon and deem > > it > >>>>>> rhetorical or invalid. > >>>>>> > >>>>>>> Could you do us all a big favor Jonathon? Your comments seem to > >>> be > >>>>>>> fairly consistent along these lines. I think what would be > >>> helpful to > >>>>>>> you, and to anyone reading and agreeing with your comments, is > > to > >>> step > >>>>>>> back and try to explain why things are the way they are. Feel > >>> free to > >>>>>>> share that with the group for a sanity check if you'd like. > >>>>>> I'm not so sure of the "why" of things, but am only more certain > > of > >>>>>> the "what" of things. Things are the way they are, no matter how > > we > >>>>>> interpret the "why". > >>>>>> > >>>>>> So, for now, I continue to merge in (to my own SVN) several > >>>>>> contributions that are deemed too difficult to review/merge by > > the > >>>>>> committers. I continue to keep such enhancements in step with > >>> updates > >>>>>> from OFBiz trunk. And I continue in my failure(?) to feed such > >>>>>> "compatibilized/merged" enhancements back to OFBiz trunk even > >>> though > >>>>>> they really are the same license. > >>>>>> > >>>>>> And the phenomenon of several of us (incompatible contributors?) > >>>>>> holding on to our own enhancements will continue. Some of us may > >>> not > >>>>>> know how to keep in step with OFBiz trunk updates; others may. > >>> Those > >>>>>> of us who can keep in step will continue to benefit from OFBiz > >>>>>> progress, but be unable to feed the benefit back to OFBiz. There > >>> will > >>>>>> still be enhancements out there that are kept away/apart from > >>> OFBiz. > >>>>>> That's the way of things? Or maybe not? > >>>>>> > >>>>>> I stand corrected. I think I am "helping" OFBiz in the wrong way. > >>> I'll > >>>>>> stop that. :) Thanks for reminding me. > >>>>>> > >>>>>> I was waiting to dump the loads of my enhancements into your > > trunk, > >>>>>> but I think I should take a sanity check for now. Anyway, there > >>> needs > >>>>>> to be at least one stabilizing branch (save point, so to speak) > >>> before > >>>>>> we can go full steam with the trunk. And there's still no such > >>> branch yet. > >>>>>> Jonathon > >>>>>> > >>>>>> David E. Jones wrote: > >>>>>>> On Apr 20, 2007, at 9:04 PM, Jonathon -- Improov wrote: > >>>>>>>> We shouldn't turn away complex contributions anymore. > >>>>>>> "We" do not now, nor have we ever, turned away a contribution > >>> because > >>>>>>> it was complex. > >>>>>>>> I myself have loads of enhancements (mostly to widget module) > >>> that I > >>>>>>>> feel uneasy about releasing to the community, simply because of > >>> this > >>>>>>>> odd use of trunk: it's used like a slow-moving release branch > >>> that > >>>>>>>> is unable to handle introductions of radical enhancements. > >>>>>>>> > >>>>>>>> Yet, this somewhat slow-moving trunk isn't still enough and > >>> focused > >>>>>>>> enough on achieving release-quality stability. It's the worst > > of > >>>>>>>> both worlds: it's not rapid enough to allow for radical > > progress, > >>>>>>>> and not calm and focused-on-cleaning-up enough to produce a > >>> stable > >>>>>>>> release for non-OFBiz developers. > >>>>>>> Could you do us all a big favor Jonathon? Your comments seem to > > be > >>>>>>> fairly consistent along these lines. I think what would be > > helpful > >>> to > >>>>>>> you, and to anyone reading and agreeing with your comments, is > > to > >>>>>>> step back and try to explain why things are the way they are. > > Feel > >>>>>>> free to share that with the group for a sanity check if you'd > >>> like. > >>>>>>> -David > >>> > > > >
