flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christofer Dutz <christofer.d...@c-ware.de>
Subject AW: AW: AW: AW: Coding conventions?
Date Fri, 17 Jun 2016 18:34:37 GMT
I think it would be better if the people working on the code would learn what they are doing
wrong ... But I agree that anyone fixing stuff would be good. In the end I'm planning on seeing
a quality gate in the build that breaks the build if any new major issues are added.


Von meinem Samsung Galaxy Smartphone gesendet.

-------- Urspr√ľngliche Nachricht --------
Von: Alex Harui <aharui@adobe.com>
Datum: 17.06.16 20:30 (GMT+01:00)
An: dev@flex.apache.org
Betreff: Re: AW: AW: AW: Coding conventions?

On 6/17/16, 11:04 AM, "Josh Tynjala" <joshtynjala@gmail.com> wrote:

>I think that having SonarQube providing automated analysis ike this is
>good. However, we shouldn't consider its suggestions to be gospel either.
>agree with Alex that we shouldn't hold back the next release just to make
>SonarQube happy. I think it's a good idea to try to get at least some of
>its "blocker" or "critical" suggestions out of the way in the following
>release, though. Higher quality code will help with future stability, and
>we're getting to a place where that's starting to be more important. It'll
>be good to see some kind of measurement of progress there.

FWIW, I've been wondering if we could incentivize some summer students to
pick away at some of these SonarQube issues.  They would learn or practice
Java and GitHub.  How much would they have to know about Flex?  I would
think they wouldn't have to know much.  It would be tweak the code, run
"ant all" or "maven" and if everything passes, send the patch or check it
in.  Or are these issues going to be more involved than that?



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message