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.
