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.
Harbs On Nov 3, 2015, at 12:04 AM, Alex Harui <aha...@adobe.com> wrote: > > > 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
