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? Regards, Dave Sent from my iPhone > On May 24, 2017, at 1:20 PM, Alex Harui <aha...@adobe.com.INVALID> wrote: > > > >> On 5/24/17, 10:35 AM, "Josh Tynjala" <joshtynj...@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 <aha...@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" <joshtynj...@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" <aha...@adobe.com.invalid> wrote: >>>> >>>> >>>> >>>> On 5/23/17, 1:03 PM, "Christofer Dutz" <christofer.d...@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 >>> >>> >
