flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: [DISCUSS] Release Apache FlexJS 0.5.0
Date Thu, 05 Nov 2015 14:32:05 GMT

On 11/5/15, 3:56 AM, "Harbs" <harbs.lists@gmail.com> wrote:

>I’m a bit confused about the release process.
>I thought we were creating release branches in git for each release to
>“freeze” the code, so we do not have a wildly moving target. It does not
>seem like that’s happening, so I’m not sure if I just misunderstood.

You understand correctly.  I’m cheating right now because it is just more
work to set up release branches, and there isn’t a lot of non-critical
work going on the develop branch.  Peter and I are working on the back
port from JS to AS in a separate branch.  Only important fixes are being
pushed to develop.  If we had more folks contributing more often, then I
would have used a release branch.

Even release branches have historically moved because folks don’t start
testing until late in the game and find important bugs.


>On Nov 3, 2015, at 12:04 AM, Alex Harui <aharui@adobe.com> wrote:
>> On 10/30/15, 3:19 PM, "Justin Mclean" <justin@classsoftware.com> wrote:
>>> Hi,
>>>> Hmm, I was hoping more PMC folks would respond.  Remember that,
>>>> according
>>>> to the release process, the PMC folks planning to vote are supposed to
>>>> be
>>>> running tests now. In theory, the only new test to be run  after we
>>>> start
>>>> the vote is whether the PGP signature is valid.
>>> We’re continually trying to test a moving target which involves a
>>> time commitment that I currently have available. You’ve never quite
>>> if the version you testing is going to be the version in the release
>>> candidate and unless you very carefully follow all of the commits it’s
>>> not obvious what needs to be retested at two different time intervals.
>> Hmm, pleading is working so maybe I’ll try guilt-tripping.
>> Yes, the nightly builds are a moving target.  IMO, we all want to grow
>> community by attracting customers and hopefully convert a few to be
>> committers and the only way I know to do it is to keep making the code
>> better and releasing the best release we can in the most efficient
>> IMO, freezing a branch and not allowing important bug fixes that might
>> make a difference in whether someone becomes more active in our
>> doesn’t make sense.  Taking the time to build out an RC and post it and
>> start a vote thread in order to finally get some testing isn’t very
>> efficient either.
>> Historically, when we produced an RC and immediately started a release
>> vote, bugs would be found and we’d cancel the RC and roll out another
>> The goal of the release process we voted in, IMO, was to reduce this
>> overhead of posting RCs, opening and closing vote threads, etc. so we
>> more efficiently achieve the goal of serving our customers and
>> some of them to becoming committers so we can have more people find bugs
>> sooner by working with the develop branch.
>> Recently, I’ve spent several days on improving build and approval
>> so testing what is in development takes less time.  In theory, you can
>> start up the approval script which will pull down the bits, answer a few
>> questions, then go do something else for 5 to 25 minutes and then come
>> back and poke at it.  I would have rather spent that time on features
>> our customers, but I gambled that this would help us get the release out
>> sooner.  I’m not sure that paid off.
>> I don’t have any other ideas on how to make it easier for those of you
>> contribute in your spare time to stay up on the commits and bugs.  It
>> should be ok to take any nightly build and run it through your tests and
>> report your findings.  Ideally, you would be up to date on the commits
>> bugs and other discussions to know whether what you find is a duplicate
>> not, but at this point, I don’t care if you report a duplicate.  At
>> that means you verified a bunch of other code paths worked for you.  I
>> don’t know how other Apache projects with really active code bases do
>> It is certainly fine to be too busy to vote on a release.  I was hoping
>> get more folks to poke at the bits before starting a vote because it
>> be a waste of community energy to start a vote and then have a bunch of
>> PMC voters jump in and start reporting important bugs.  But I think the
>> community has waited too long already, so I am going to start a vote
>> and Peter and I will vote and maybe Josh and/or Harbs and we’ll be good
>> go.  Hopefully any others jumping in late won’t find release blockers
>> we’ll just make another release later.
>> -Alex

View raw message