On 11/5/15, 3:56 AM, "Harbs" <harbs.li...@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. -Alex > >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 >
