Hi Harbs, If the package naming is kept is there any risk of a user having a classname collision if they use the original GitHub project?
Regards, Dave > On Jul 14, 2017, at 8:34 AM, Harbs <harbs.li...@gmail.com> wrote: > > I contacted the other contributors. > > I already got permission from the one who did the critical fix. (forwarded to > the dev list) That only leaves one more who did convenience code changes. We > can remove that code if necessary. > > The document changes were not in the class file. It was to the readme in the > repo. > > Question: I assume that we keep the same package naming if we include it on > the repo unless it’s specifically donated to Apache. Correct? > > What about a modified class that I changed to work with FlexJS? Would that > get an apache package path or not? > >> On Jul 14, 2017, at 6:18 PM, Alex Harui <aha...@adobe.com.INVALID> wrote: >> >> AIUI, we are supposed to try to contact all contributors, no matter how >> small. If you don't hear from all of them, the PMC has to make a risk >> assessment. If we take un-permitted lines of code and someone later >> objects, could we quickly remove those lines of code and replace it? Or, >> should our initial check-in not include un-permitted lines of code and the >> first commits replace them? >> >> Of course, I could be wrong... >> -Alex >> >> On 7/13/17, 2:40 PM, "Harbs" <harbs.li...@gmail.com> wrote: >> >>> One of them was documentation edits. >>> >>> Another was a workaround for a Flash permissions issue. It was a sometime >>> yes, sometimes no problem. I finally found where the problem lay that >>> required that code. You can see the comments in old issues on that repo. >>> That piece of code is very necessary for Flash. There’s really only one >>> way to solve that particular issue. Not sure if he can own that solution. >>> >>> The third was some convenience methods. Not a major contribution. >>> >>>> On Jul 14, 2017, at 12:07 AM, Alex Harui <aha...@adobe.com.INVALID> >>>> wrote: >>>> >>>> Made two comments in the GH issue. Looks like there were other >>>> contributors so we may need to get their permission to make the license >>>> ALv2. >>>> >>>> Of course, I could be wrong,... >>>> -Alex >>>> >>>> On 7/12/17, 9:14 PM, "Harbs" <harbs.li...@gmail.com> wrote: >>>> >>>>> I don’t think he has plans on modifying it. >>>>> >>>>> Do you mind making the suggestion about the header to the Github issue? >>>>> >>>>>> On Jul 13, 2017, at 7:10 AM, Alex Harui <aha...@adobe.com.INVALID> >>>>>> wrote: >>>>>> >>>>>> IMO, if the original author will be helping make changes to this file, >>>>>> we >>>>>> want an ICLA. If he has no plans to work on it, then attaching it to >>>>>> a >>>>>> JIRA would be sufficient documentation of his intent to donate it. >>>>>> >>>>>> Either way, it would help if he put the 3rd-party ALv2 header in the >>>>>> file. >>>>>> >>>>>> -Alex >>>>>> >>>>>> On 7/12/17, 8:59 PM, "Harbs" <harbs.li...@gmail.com> wrote: >>>>>> >>>>>>> In our repo with my modifications for FlexJS. >>>>>>> >>>>>>> >>>>>>>> On Jul 13, 2017, at 1:22 AM, Alex Harui <aha...@adobe.com.INVALID> >>>>>>>> wrote: >>>>>>>> >>>>>>>> What do you mean by "adopt". That the new home for further >>>>>>>> improvements >>>>>>>> is in our repo or that we're using it as a third-party dependency? >>>>>>>> >>>>>>>> -Alex >>>>>>>> >>>>>>>> On 7/12/17, 12:45 PM, "Harbs" <harbs.li...@gmail.com> wrote: >>>>>>>> >>>>>>>>> There’s a great class for uploading multi-part HTTP requests. I’ve >>>>>>>>> been >>>>>>>>> using it for years, and I’ve ported it for use with FlexJS. It >>>>>>>>> works >>>>>>>>> great in that context too. >>>>>>>>> >>>>>>>>> I just asked the author if he minds if we adopt it and he’s very >>>>>>>>> happy >>>>>>>>> for us to do so.[1] >>>>>>>>> >>>>>>>>> It’s one class. Do we need to go through an ICLA, or can we just >>>>>>>>> bring >>>>>>>>> it >>>>>>>>> in with no fuss? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Harbs >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> [1]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2F >>>>>>>>> gi >>>>>>>>> th >>>>>>>>> ub >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> .com%2Fjimojon%2FMultipart.as%2Fissues%2F9&data=02%7C01%7C%7C61a62bf >>>>>>>>> 56 >>>>>>>>> 17 >>>>>>>>> 14 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 5e9929708d4c95e9650%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636 >>>>>>>>> 35 >>>>>>>>> 48 >>>>>>>>> 55 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 465043104&sdata=2SKnAIfWKXwDacqORK3Td9AyYffkEXBYr%2BTPdtm6efo%3D&res >>>>>>>>> er >>>>>>>>> ve >>>>>>>>> d= >>>>>>>>> 0 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi >>>>>>>>> th >>>>>>>>> ub >>>>>>>>> .c >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> om%2Fjimojon%2FMultipart.as%2Fissues%2F9&data=02%7C01%7C%7C61a62bf56 >>>>>>>>> 17 >>>>>>>>> 14 >>>>>>>>> 5e >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 9929708d4c95e9650%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63635 >>>>>>>>> 48 >>>>>>>>> 55 >>>>>>>>> 46 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 5043104&sdata=2SKnAIfWKXwDacqORK3Td9AyYffkEXBYr%2BTPdtm6efo%3D&reser >>>>>>>>> ve >>>>>>>>> d= >>>>>>>>> 0> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
signature.asc
Description: Message signed with OpenPGP
