flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harbs <harbs.li...@gmail.com>
Subject Re: [DISCUSS] Release Apache FlexJS 0.5.0
Date Thu, 05 Nov 2015 11:56:49 GMT
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.


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 greater
>> time commitment that I currently have available. You’ve never quite sure
>> 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 the
> 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 manner.
> IMO, freezing a branch and not allowing important bug fixes that might
> make a difference in whether someone becomes more active in our community
> 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 one.
> 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 can
> more efficiently achieve the goal of serving our customers and attracting
> 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 scripts
> so testing what is in development takes less time.  In theory, you can now
> 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 for
> 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 who
> 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 and
> bugs and other discussions to know whether what you find is a duplicate or
> not, but at this point, I don’t care if you report a duplicate.  At least
> 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.
> It is certainly fine to be too busy to vote on a release.  I was hoping to
> get more folks to poke at the bits before starting a vote because it will
> 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 soon,
> and Peter and I will vote and maybe Josh and/or Harbs and we’ll be good to
> go.  Hopefully any others jumping in late won’t find release blockers and
> we’ll just make another release later.
> -Alex

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message