I’m not sure I understood when I asked my question… ;-)
> On Jul 14, 2017, at 7:21 PM, Alex Harui <aha...@adobe.com.INVALID> wrote:
>
> 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>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
