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/
+1 all around, a suggestion: Have a release rotation that cycles through the core team/contributor list, so everyone is in charge perhaps only once every other month (or a few weeks). Make sure the last guy to release hounds the next guy (so you, Aaron would be first at bat to hound who''s on deck) to make sure they have their stuff together and know how to do it properly. -Nick On Mon, Jul 25, 2011 at 8:15 PM, Aaron Patterson <aaron@tenderlovemaking.com> 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Just wanted to say thank you Aaron for putting so much of your energy into the rails community. As a developer I know how tiresome the job can be at times and a task as large as the rails gem release should be delegated to more than one person. As a rails developer I can''t thank you enough. Dave On Mon, Jul 25, 2011 at 5:36 PM, Nick Quaranto <nick@quaran.to> wrote:> +1 all around, a suggestion: > > Have a release rotation that cycles through the core team/contributor list, > so everyone is in charge perhaps only once every other month (or a few > weeks). Make sure the last guy to release hounds the next guy (so you, Aaron > would be first at bat to hound who''s on deck) to make sure they have their > stuff together and know how to do it properly. > > -Nick > > > On Mon, Jul 25, 2011 at 8:15 PM, Aaron Patterson < > aaron@tenderlovemaking.com> 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 rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to > rubyonrails-core+unsubscribe@googlegroups.com. > 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
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 rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. > 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
I do agree 48 hours might be a little short timespan for regressions. On Tue, Jul 26, 2011 at 01:45, Michael Jurewitz <jurewitz@gmail.com> 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 rubyonrails-core@googlegroups.com. >> To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. >> 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 rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. > 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
On Tue, July 26, 2011 00:45, Michael Jurewitz wrote:> > 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.I agree an excessively aggressive release schedule would, in the end, likely prove detrimental to ROR. I also feel that 48 hours is inadequate to install, test and report on a new release candidate on anything other than a purely superficial level. On the issue of "lead dog" I leave that to the core team to settle among themselves. I deal with several projects that all take different approaches to that problem and most seem to work well enough that no one of them commends itself above all the rest. Having said that, should my opinion matter then my preference would be for a "team" release system wherein all the "bus" people reach consensus among themselves of when to release a candidate and when to do a general release and no one of them takes the "heat" for delays and regressions. I appreciate very much all of the work that everyone concerned, past and present, has put into this project. -- *** E-Mail is NOT a SECURE channel *** James B. Byrne mailto:ByrneJB@Harte-Lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3 -- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
On Mon, Jul 25, 2011 at 5:15 PM, Aaron Patterson <aaron@tenderlovemaking.com> 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.Deadlines help force the issue of what''s in and out of a release, too. +1. I''m wary of putting too much importance/significance in the fixed schedule itself, rather than the desired outcome: reasonably frequent stable releases that are easy to upgrade to. I doubt this''ll become an issue.> 2) Distributed responsibilityHappy to step back in front of the bus on these. Releases are a pretty tedious exercise. Thanks Aaron! -- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
On Tue, Jul 26, 2011 at 10:13:00AM -0700, Jeremy Kemper wrote:> On Mon, Jul 25, 2011 at 5:15 PM, Aaron Patterson > <aaron@tenderlovemaking.com> 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. > > Deadlines help force the issue of what''s in and out of a release, too. +1. > > I''m wary of putting too much importance/significance in the fixed > schedule itself, rather than the desired outcome: reasonably frequent > stable releases that are easy to upgrade to. I doubt this''ll become an > issue.Agreed. I really don''t want hard deadlines so much as I want to set expectations with users. Maybe we can say something like "approximately once per month". We have to strike a good balance. If we release too frequently, people are annoyed, but upgrades should be easier. If we release too infrequently, releases are harder and upgrades are harder. I guess it''s important to make the distinction between setting expectations with the community vs timeline. I don''t think it really matters what the schedule is, as long as everyone knows.> > 2) Distributed responsibility > > Happy to step back in front of the bus on these. Releases are a pretty > tedious exercise.Yay! I''ll do the next releases (all releases through 3.1.0 and 3.0.10) and document the process along the way. We can start handing releases around after that. -- Aaron Patterson http://tenderlovemaking.com/