Mailing-List: contact dev-help@flex.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@flex.apache.org
From: Christofer Dutz <christofer.dutz@c-ware.de>
To: dev <dev@flex.apache.org>
Subject: AW: [Discuss]Accept donation of drawing APIs
Thread-Topic: [Discuss]Accept donation of drawing APIs
Thread-Index: AQHRmJlDPCm8QDcRIE6u94H9z3cxx5+Pm3kAgAAGLXQ=
Date: Mon, 18 Apr 2016 12:29:53 +0000
Message-ID: 
 <DB5PR05MB1285A2E179426E4826ED6572A26B0@DB5PR05MB1285.eurprd05.prod.outlook.com>
References: 
 <D1D8F9EF-EC80-46E7-AF1C-3AEED8A13187@gmail.com>,<CANcBHECPB7OjhF5Mcc=RBZXnniQtxgL0fTFjmj_H3L+iAfZajw@mail.gmail.com>
In-Reply-To: 
 <CANcBHECPB7OjhF5Mcc=RBZXnniQtxgL0fTFjmj_H3L+iAfZajw@mail.gmail.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Apr 2016 12:29:53.3713
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 9d387546-1437-4b89-846c-691d64a7e74d
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR05MB1285

Hi Jude,

I couldn't refrain from commenting this:

1) We have a responsibility to our customers/users that we deliver stuff th=
at is safe to use. Safe doesn't only mean, that it works well, but also tha=
t all legal issues have been set aside. If we were to accept anything witho=
ut checking that all is ok, we could get into serious trouble ... and just =
imagine we ship something that turns out to be problematic in a few years, =
making all SW that has been built with that lib "illegal". So I hope you se=
e that we do a check. Sort of like that nice guy at the central station off=
ering you a genuine Rolex as a present ... doubt you would take that, would=
 you? ;-)

2) Do you accept everything you are offered? I bet not ... cause you don't =
want your house full of stuff you don't need. In the past we have accepted =
a lot of stuff, that now just rots in our repositories. Even if memory is c=
heap ... checking out "flex-utilities" for even a small project seems to ta=
ke about 10 minutes on the ASK Jenkins (the rest of the build is then done =
in 10 seconds) so I hope you see that we also want to check what we want to=
 add and what not. Even if Alex may have said that he wants to gather every=
thing, I think I'm on the complete opposite part, I only want to accept stu=
ff that is beneficial to the project. As everyone here has a vote, all the =
others have a saying in this too.

3) Thriving doesn't mean that 10 people work on 1000 sub-projects instead o=
f 100. Thriving would be that instead of 10 People working on 100 projects =
we grow to 100 working on 200. Just accumulating more stuff tends to stand =
in our way. I for my part would really like to start working on a lot of st=
uf, but I'm completely saturated with cleaning up in this (some times) dump=
 we call Apache Flex so please understand that I'm hesitant to add new stuf=
f that probably I will have to clean up cause most of the times after the d=
onation the donators tend to disappear.

4) I strongly object to your proposal to auto-accept stuff ...=20

Chris


________________________________________
Von: jude <flexcapacitor@gmail.com>
Gesendet: Montag, 18. April 2016 13:34
An: dev
Betreff: Re: [Discuss]Accept donation of drawing APIs

Slightly off topic, but if someone is kind enough to give you a gift, the
proper response is to say thank you and accept it. What you do after you
accept it is another story.

The Apache process of discussing if we should accept said gift is kind of a
dick move. No offence, but IMHO this behaviour has to stop. And this is not
directed at you Harbs or anyone in particular.

I'm not saying we don't need to vet a donation, or decide if it should go
into core or be setup as a side project. But if someone wants to donate
code they own or built and it's legal then accept it and move on.

People, and myself thought that Apache Flex was going to be the place where
we make Flash and Flex thrive again. I thought we'd have plenty of donated
components and projects but you hear someone offer to donate something and
then it seems to die and you don't hear from them again.

It's a huge turn off to work on a project, want to donate it and then hear
your  community start talking about if they should accept your donation or
not. That's not progress is suppression.

IIRC Alex once said he's interested in collecting everything related to
Flex (and the Flash Platform?) here. So am I. And that's good enough for
me.

>From my perspective, Apache has some anti social processes and procedures
in practice. But the guidelines say quite clearly that a community can run
itself how it seems fit. So, something needs to change in my opinion.
Sorry, if I'm ranting.

Anyway, I want to include lihzi's code and keep the package name the same
for the reasons Harbs mentioned and if any future projects are cross
compiled we avoid problems by that as well.

I also suggest we adopt a process to accept license compatible platform
related future donations automatically and let our discussions focus on
whether they should be in core or in a secondary location.
On Apr 17, 2016 6:06 AM, "Harbs" <harbs.lists@gmail.com> wrote:

> Lizhi has put together some impressive classes to implement the Flash
> drawing APIs for FlexJS using Canvas.[1]
>
> Lizhi has offered to donate the code[2] and I believe has just filed an
> ICLA.
>
> The question now remains whether we want to include the code. I personall=
y
> see a lot of value in the code as it offers a lot of functionality users
> are used to out of the box using the same APIs.
>
> I do have some questions about accepting the code:
> 1. Whether to keep the packages as they are. Currently, they use the
> flash.* packages to match the ones in playerglobal. One the one hand, thi=
s
> makes a lot of sense in terms of migrating code because everything stays
> exactly the same. On the other hand, the package names are misleading as
> it=92s not =93Flash=94 packages. The alternate would be to wrap things in=
 apache
> flex packages, but that would add a lot of work in terms of conditional
> compilation and redirection. I also don=92t know if there are legal issue=
s
> with using the =93flash=94 package. I can=92t imagine what they might be,=
 but
> INOL=85
>
> 2. How should these files be organized in FlexJS? This might be related t=
o
> the package names, but might not. I assume this is not =93core=94. Should=
 it
> all go into a single project, or should it be split up into multiple
> projects?
>
> Harbs
>
> [1]https://github.com/matrix3d/spriteflexjs
> [2]http://mail-archives.apache.org/mod_mbox/flex-dev/201604.mbox/browser