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