On 10/30/15, 3:19 PM, "Justin Mclean" <jus...@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
