I’m not sure I understood when I asked my question… ;-)
> On Jul 14, 2017, at 7:21 PM, Alex Harui 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 f
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
retain
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 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?
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 wrote:
>
> I contacted the other contributors.
>
> I already got permission from the one who did the cr
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
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 in
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
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" wrote:
>I don’t think he has plans on modifying it.
>
>Do you mind making the suggesti
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 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, t
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
In our repo with my modifications for FlexJS.
> On Jul 13, 2017, at 1:22 AM, Alex Harui 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" 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" wrote:
>There’s a great class for uploading multi-part HTTP requests. I’ve been
>using it for years, and I’ve ported it
12 matches
Mail list logo
