I'm not sure I understand your question. We are either going to treat this file as external 3rd party and not change the package name, or we are going to make our repo the new home for further development of this file in which case we can rename the package. What would be the advantages of retaining the package name if this is the new home for this file? For regular Flex the main reason we didn't rename packages was that folks had a ton of existing code that referenced those package names. Otherwise, I think we would have renamed the packages.
My 2 cents, -Alex On 7/14/17, 9:02 AM, "Harbs" <harbs.li...@gmail.com> wrote: >Maybe. Not sure. > >What’s standard practice with this kind of thing? I’ve never done this >before. > >> On Jul 14, 2017, at 6:59 PM, Dave Fisher <dave2w...@comcast.net> wrote: >> >> 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%2 >>>>>>>>>>>F%2F >>>>>>>>>>> gi >>>>>>>>>>> th >>>>>>>>>>> ub >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>.com%2Fjimojon%2FMultipart.as%2Fissues%2F9&data=02%7C01%7C%7C61a >>>>>>>>>>>62bf >>>>>>>>>>> 56 >>>>>>>>>>> 17 >>>>>>>>>>> 14 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>5e9929708d4c95e9650%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7 >>>>>>>>>>>C636 >>>>>>>>>>> 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%7C61a62 >>>>>>>>>>>bf56 >>>>>>>>>>> 17 >>>>>>>>>>> 14 >>>>>>>>>>> 5e >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>9929708d4c95e9650%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6 >>>>>>>>>>>3635 >>>>>>>>>>> 48 >>>>>>>>>>> 55 >>>>>>>>>>> 46 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>5043104&sdata=2SKnAIfWKXwDacqORK3Td9AyYffkEXBYr%2BTPdtm6efo%3D&r >>>>>>>>>>>eser >>>>>>>>>>> ve >>>>>>>>>>> d= >>>>>>>>>>> 0> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
