I do agree 48 hours might be a little short timespan for regressions. On Tue, Jul 26, 2011 at 01:45, Michael Jurewitz <[email protected]> wrote: > Likewise, Aaron, you have made incredible contributions to this whole > process. Increasing the bus-factor and having more folks who are able to > handle a release would indeed be great. > > On the release timing front, I actually think something longer than four > weeks should be the default goal. Artificially limiting to four weeks may > make it difficult to get larger scale feature work completed. I also think > that more frequent releases won't actually benefit the users and businesses > who rely on Rails. Instead, it will only make it more complex to keep in > step with changes in the frameworks while ensuring existing apps still run. > > Along those lines, 48 hours for regressions is entirely too short. It > doesn't do the project any good to aggressively declare GM on a release only > to have to spin fast subsequent updates because a major issue was not > identified fast enough. I wouldn't want to see any less than a week for > regression reports. > > -Jury > > On Jul 25, 2011, at 7:01 PM, Prem Sichanugrist wrote: > >> Aaron, >> >> 1) I'm totally agree on that one. Let's stick with this four weeks release >> cycle >> for RC cut, and 48 hours for regression report. >> >> 2) You've always done a great job for the Ruby on Rails community. From what >> you said, I think it make a lot of sense to rotate the release >> responsibility to >> every core team member. I mean, it should not be *your* responsibility to do >> the hard work and release the gem every time. And you shouldn't be the only >> one to take the blame if the release is broken. >> >> It would be totally worth it if you can provide everybody the process of >> cutting a >> release. In that case, everybody will have a reference on what to do, and >> will >> be able to cut the release, in the perfect quality as you did, in the future. >> >> Thank you for your contribution to Rails community. I think we're all >> appreciate >> your contribution. <3 <3 <3 >> >> - Prem >> >> On Jul 25, 2011, at 8:15 PM, Aaron Patterson wrote: >> >>> Hi folks, >>> >>> I want to talk about the release process. Specifically, I want to talk >>> about >>> how we can improve our release process. >>> >>> There are a couple things I want to see in our release process: >>> >>> 1) Regular, periodic releases. >>> >>> I had been shooting for every four weeks for the 3.0.x series. I don't >>> think >>> this means we have to be held to a particular deadline. I think that if >>> people >>> know that approximately every N weeks, we'll have a release, it will help >>> reduce upgrade friction. >>> >>> Mainly what this means to me is setting expectations with the community, and >>> sticking to what we say. >>> >>> 2) Distributed responsibility >>> >>> I would like to improve our Bus Factor. Today, I am the only one doing >>> releases. That means we have a Bus Factor of one. If I get hit, who will >>> take >>> responsibility? >>> >>> In order to fix this, I think we need other core team members to do >>> releases. >>> In fact, I think it should be a requirement *as a core team member* to do >>> releases. >>> >>> We require that core team members are able to work on all aspects of Rails >>> (AR, >>> AS, AP, etc). If we make this requirement for the code base, we need to >>> make >>> this requirement of our process. >>> >>> We all need to go through the pain of the rubber actually hitting the road. >>> We all need to make the tough decision to release, or to face our users and >>> tell them why it is late. >>> >>> I propose that we each take turns releasing Rails, and we publish who will >>> be >>> doing which release. I think it will improve our Bus Factor, frequency and >>> stability of our releases, and improve our team overall. >>> >>> If we can agree on these items, I will put together documentation about how >>> to >>> release Rails, along with a roster of who will be releasing what. I will >>> even >>> personally work with each core team member until we're all comfortable with >>> the >>> process. >>> >>> The status quo cannot remain. I can't be around all the time to do >>> releases, >>> as frankly, it's burning me out. >>> >>> -- >>> Aaron Patterson >>> http://tenderlovemaking.com/ >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Ruby on Rails: Core" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/rubyonrails-core?hl=en. >> > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Core" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/rubyonrails-core?hl=en. > >
-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
