flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Fisher <dave2w...@comcast.net>
Subject Re: [FlexJS] odd license headers on some files
Date Wed, 24 May 2017 20:35:20 GMT
Hi Folks,

I had a great time meeting most of you last week. Alex I met some 3 years ago.

Justin can you please provide a precise diff explaining what is off with these headers? Also
how many files.

Alex - are we really close to cutting a release?


Sent from my iPhone

> On May 24, 2017, at 1:20 PM, Alex Harui <aharui@adobe.com.INVALID> wrote:
>> On 5/24/17, 10:35 AM, "Josh Tynjala" <joshtynjala@gmail.com> wrote:
>> Alex,
>> If Justin were proposing these changes to an RC, I would strongly agree
>> with you that it should wait. However, I thought we all agreed that Last
>> Call was the better time to get things in that we want to get in. It feels
>> to me like you're moving the goal posts to now say that it should wait
>> until after the release. I was frustrated by Justin proposing changes in
>> the RC before, but as we're still in Last Call, I'm going to defend him.
> Last call was sent out on 4/21.  It is now 5/24.  So sure, it is true that
> the window is still open to find issues, but the idea was to find
> important issues and deal with other issues later.  How does fixing these
> headers help the community?  I would discourage all non-critical commits
> at this time.  Now that we know that RAT won't find this kind of error,
> each of us will now have to take time to make sure we have the right
> header before committing new files.  And we will have to at least think
> about it when we review new commits from others.  That seems very wasteful
> to me.  Maybe we'd be past "Last Call" and into RC if we spent our time on
> getting the examples to work instead of this other stuff.
>> I understand that you think licensing details aren't as important as other
>> things, so it's cool if you don't want to focus on that part as we get
>> close to a release. However, that's the itch Justin seems to want to
>> scratch, and I don't think it's fair of you to tell him what he should
>> think is important. It should take little more than a glance for the PMC
>> to
>> review his changes. You often bring up how we should trust the intent of a
>> contributor, and you could trust that he knows what to change for
>> licensing
>> since that's something he knows well. Looking at all 220 headers
>> individually seems unnecessary.
> Justin is great at finding what isn't expected.  But his track record for
> correctly deciding what action to take is not very good.  Just review
> legal-discuss archives.  I'd list them all out, but don't want to spend
> more time on it.  In this case, there is no debate about what to do, just
> when.  There are so many more things that we can do now to make the
> community better.  Burning out committers and release managers is not
> helpful to the community.
>>> Instead, we are discussing headers, trace statements, inlining
>> constants and empty constructors.
>> I don't see why we can't start thinking about things for the next release
>> as we're finishing up the current release. Plus, ApacheCon just happened,
>> and we're all buzzing with ideas after meeting together, so the mailing
>> list activity is up. Let's not discourage the extra enthusiasm from our
>> contributors right now. This enthusiasm is something good for potential
>> new
>> contributors to see.
> Absolutely want to see more discussion about the 9 or 13 points from
> ApacheCon.  I don't agree that discussing trace statements, inlining
> constants, and empty constructors will bring in more contributors.
> Getting quality releases out encourages more contributors.  Getting some
> production apps out there will bring in more contributors.  These big
> things help me make a case to keep working on FlexJS.  I'll be really sad
> if I have to stop working full-time on FlexJS because we spent all of this
> time on other things.
> -Alex
>> - Josh
>> On Wed, May 24, 2017 at 9:45 AM, Alex Harui <aharui@adobe.com.invalid>
>> wrote:
>>> Technically, I am not blocking.  I am saying that there is a better time
>>> to do this change and we need to focus on the big picture and spend
>>> energy
>>> on things that matter.  This topic could have been as simple as an email
>>> from Justin that said "hey, I just noticed we have inconsistent headers.
>>> I would like to clean that up after the release and branch merges."
>>> Instead, the email thread was several posts long already by the time I
>>> had
>>> to read through it.  Harbs put down his work to at least wonder why one
>>> of
>>> his files was named.  Then there will be the time for Justin to actually
>>> make these changes.  Who is volunteering to review the change?  As PMC
>>> members we are all supposed to be watching the commits.
>>> And you get more of what you encourage.  I am trying to encourage folks
>>> to
>>> take stuff that isn't that important and find it early by watching the
>>> commits, or put it off to the next release.  That has been the advice of
>>> several experienced Apache folks.  I'm not making this up.  If you want
>>> to
>>> encourage folks to nitpick at the end of release cycles, well then I can
>>> only tell you from my personal experience that after several releases it
>>> discourages me from wanting to be a release manager.  Should we
>>> encourage
>>> all of us to nitpick more at the end of release cycles?  Would that make
>>> more of you want to be a release manager?  You can't look at this one
>>> change in isolation.
>>> Every day, I am trying to marshall the limited resources we have to
>>> find a
>>> way to bring in more contributors in hopes we can get some FlexJS apps
>>> into production in hopes that Adobe will continue to pay me to work on
>>> this stuff full-time.  Making us review 220 headers is not going to
>>> bring
>>> in more contributors.  Getting our examples to work right, making
>>> progress
>>> on the top 9 things from ApacheCon, helping Harbs and Yishay get their
>>> app
>>> into production will all serve the community better.  Instead, Yishay
>>> got
>>> stuck yesterday because I have not found the time to fix a bug in the
>>> TLF
>>> branch.  Instead, we are discussing headers, trace statements, inlining
>>> constants and empty constructors.
>>> So, if you guys want more nitpicking, then go ahead and encourage it.  I
>>> won't veto the change.  But I'll be even less motivated to be the RM in
>>> the future.
>>> -Alex
>>>> On 5/24/17, 6:34 AM, "Josh Tynjala" <joshtynjala@gmail.com> wrote:
>>>> Alex, by continuing to block Justin, you're making this exactly the
>>> kind
>>>> of
>>>> grind that you've said we should avoid. If you just said "okay cool,
>>> make
>>>> the change!" that's painless and won't discourage any potential release
>>>> managers.
>>>> - Josh
>>>> On May 23, 2017 9:52 PM, "Alex Harui" <aharui@adobe.com.invalid> wrote:
>>>> On 5/23/17, 1:03 PM, "Christofer Dutz" <christofer.dutz@c-ware.de>
>>> wrote:
>>>>> Hi Alex,
>>>>> I disagree … if things like this are found, why do them later instead
>>> of
>>>>> just fixing things and not have to deal with them again?
>>>> Because we want to demonstrate that releasing is simple and fun, not
>>> some
>>>> grind through stuff that doesn't matter.  If we clean this up now, we
>>> will
>>>> again prove that this community cannot focus on important things.  The
>>>> casual observer will take a look at what we talk about and wonder why
>>> we
>>>> are not addressing the top 9 takeaways from ApacheCon.  Is this really
>>>> more important than fixing some NPE or transpiler issue that will
>>> affect
>>>> many of our customers?  Usually, late in a release cycle, the only
>>> changes
>>>> should be stop-ship.
>>>> IMO, best time to clean this up is right after the release when we
>>> flood
>>>> commits@ with merging the release branch back to develop and master.
>>> Then
>>>> 220 header changes will not make significant noise.
>>>> My 2 cents,
>>>> -Alex

View raw message