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 >> >>
