[Bf-committers] 2.6 Release Cycle Proposal
Hey developers, this is a first draft of my release cycle proposal. :) Please take a look at it and give feedback. http://wiki.blender.org/index.php/User:DingTo/ReleaseCycle-Proposal Idea is to have Cycle after Cycle. I hope we get more quality to have a very strict B-Con 4 Level. Hopefully this lowers the need for a/b releases. :) Best regards, -- Thomas Dinges Blender Developer, Artist and Musician www.dingto.org ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] 2.6 Release Cycle Proposal
On Thu, Jul 28, 2011 at 4:29 AM, Thomas Dinges wrote: > Hey developers, > this is a first draft of my release cycle proposal. :) > Please take a look at it and give feedback. > http://wiki.blender.org/index.php/User:DingTo/ReleaseCycle-Proposal > > Idea is to have Cycle after Cycle. > I hope we get more quality to have a very strict B-Con 4 Level. > Hopefully this lowers the need for a/b releases. :) > > Best regards, > > -- > Thomas Dinges > Blender Developer, Artist and Musician > > www.dingto.org Hi Thomas, This seems good to me, at least - at least we can go ahead with it and make minor changes if needed. I'd like to raise a topic which isn't addressed in you're proposal. By taking more care to stabilize before release I think we could change how we freeze trunk. Currently we do a release: - freeze before release - release ahoy - platform maintainers get builds made - official announcement - keep trunk (mostly) frozen for ~1week to see if we need an 'a' version I worry that we take too much time keeping blender frozen since this can take approx 3 weeks and with the proposal to do better tested releases, this will take longer. If we need to do an 'a' release individualizer fixes could be applied from trunk rather then keeping trunk frozen *just in case* we need to do another release (could branch from the tagged rev and merge only the fixes from trunk). I'd like to know what others think about doing a release and unfreezing soon after ahoy (1-2 days). -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] 2.6 Release Cycle Proposal
Hi, I'll agree with Campbell. It'll be more convenient for some developers (for example, me). This even can work in such way: - Trunk is never frozen - Two weeks before release we create new branch (or replacing branch from previous release). - In trunk usual work could happen. - In that separated branch last changes, fixes, stabilization, blah blah happens. - Some individual fixes can be merged from trunk to that pre-release branch. - After release tagging happens based on that pre-release branch. It's just idea. And about proposal. It can't totally get us free from corrective releases, imo. Sometimes we're updating libraries and time to time errors happens when preparing new libraries -- wrong configuration, wrong compilation flag, forgotten feature to be included. Such things can be handled by corrective releases, but maybe someone got better ideas to handle such kind of problems? Campbell Barton wrote: > > Hi Thomas, This seems good to me, at least - at least we can go ahead > with it and make minor changes if needed. > > I'd like to raise a topic which isn't addressed in you're proposal. > > By taking more care to stabilize before release I think we could > change how we freeze trunk. > > Currently we do a release: > - freeze before release > - release ahoy > - platform maintainers get builds made > - official announcement > - keep trunk (mostly) frozen for ~1week to see if we need an 'a' version > > I worry that we take too much time keeping blender frozen since this > can take approx 3 weeks and with the proposal to do better tested > releases, this will take longer. > > If we need to do an 'a' release individualizer fixes could be applied > from trunk rather then keeping trunk frozen *just in case* we need to > do another release (could branch from the tagged rev and merge only > the fixes from trunk). > > I'd like to know what others think about doing a release and > unfreezing soon after ahoy (1-2 days). > -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] 2.6 Release Cycle Proposal
On 7/29/11, Sergey I. Sharybin wrote: > Hi, > > I'll agree with Campbell. It'll be more convenient for some developers > (for example, me). > > This even can work in such way: > - Trunk is never frozen > - Two weeks before release we create new branch (or replacing branch > from previous release). > - In trunk usual work could happen. > - In that separated branch last changes, fixes, stabilization, blah blah > happens. > - Some individual fixes can be merged from trunk to that pre-release branch. > - After release tagging happens based on that pre-release branch. > > It's just idea. > > And about proposal. It can't totally get us free from corrective > releases, imo. Sometimes we're updating libraries and time to time > errors happens when preparing new libraries -- wrong configuration, > wrong compilation flag, forgotten feature to be included. Such things > can be handled by corrective releases, but maybe someone got better > ideas to handle such kind of problems? This is not my area but is that not what alpha and beta releases are for? -- Douglas E Knapp Creative Commons Film Group, Helping people make open source movies with open source software! http://douglas.bespin.org/CommonsFilmGroup/phpBB3/index.php Massage in Gelsenkirchen-Buer: http://douglas.bespin.org/tcm/ztab1.htm Please link to me and trade links with me! Open Source Sci-Fi mmoRPG Game project. http://sf-journey-creations.wikispot.org/Front_Page http://code.google.com/p/perspectiveproject/ ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] 2.6 Release Cycle Proposal
Hi, I'm not convinced such a branching strategy will work for us. The frustrating aspect of "frozen trunk" is also meant to get focus and discipline for everyone to look for a designated period only at stability of your work and to go over the bug tracker. More-over, I prefer to stick to a serious effort to always keep trunk stable, at any time. Only on well defined moments (branch mergers, patch applying) we can accept a really short while of instability. If people do want to continue developing, they can get own branches... or we get this git thing sorted out one day :) What Campbell proposes - to freeze as short as possible - I rather see happen then. This whole 'a' release tradition should go away once too. Somehow we should attempt to get it right once, before a release! One of the ways to solve it is by getting our release team (or the buildbut) to make more often official builds available. Would be easy to at least make a bcon3 build, a bcon4 build, and a release-candidate bfore the final. -Ton- Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands On 29 Jul, 2011, at 9:28, Sergey I. Sharybin wrote: > Hi, > > I'll agree with Campbell. It'll be more convenient for some developers > (for example, me). > > This even can work in such way: > - Trunk is never frozen > - Two weeks before release we create new branch (or replacing branch > from previous release). > - In trunk usual work could happen. > - In that separated branch last changes, fixes, stabilization, blah > blah > happens. > - Some individual fixes can be merged from trunk to that pre-release > branch. > - After release tagging happens based on that pre-release branch. > > It's just idea. > > And about proposal. It can't totally get us free from corrective > releases, imo. Sometimes we're updating libraries and time to time > errors happens when preparing new libraries -- wrong configuration, > wrong compilation flag, forgotten feature to be included. Such things > can be handled by corrective releases, but maybe someone got better > ideas to handle such kind of problems? > > Campbell Barton wrote: >> >> Hi Thomas, This seems good to me, at least - at least we can go ahead >> with it and make minor changes if needed. >> >> I'd like to raise a topic which isn't addressed in you're proposal. >> >> By taking more care to stabilize before release I think we could >> change how we freeze trunk. >> >> Currently we do a release: >> - freeze before release >> - release ahoy >> - platform maintainers get builds made >> - official announcement >> - keep trunk (mostly) frozen for ~1week to see if we need an 'a' >> version >> >> I worry that we take too much time keeping blender frozen since this >> can take approx 3 weeks and with the proposal to do better tested >> releases, this will take longer. >> >> If we need to do an 'a' release individualizer fixes could be applied >> from trunk rather then keeping trunk frozen *just in case* we need to >> do another release (could branch from the tagged rev and merge only >> the fixes from trunk). >> >> I'd like to know what others think about doing a release and >> unfreezing soon after ahoy (1-2 days). >> > > > -- > With best regards, Sergey I. Sharybin > > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] 2.6 Release Cycle Proposal
Ton Roosendaal wrote: > More-over, I prefer to stick to a serious effort to always keep trunk stable, > at any time. Only on well defined moments (branch mergers, patch applying) we > can accept a really short while of instability. Would Mango team work in separated from trunk branch? Or artists would work with stable trunk and develoeprs wouldn't be necessery? :) > What Campbell proposes - to freeze as short as possible - I rather see happen > then. This whole 'a' release tradition should go away once too. It can't be handled by developers/builder only. Even if we'll provide builds week, two week before official release it wouldn't be tested well… Remember our rc period -- nobody reported real regressions (even crash) during rc. Our old idea which isn't still implemented and which is related on "testers" team. It'll help a lot, imo. > One of the ways to solve it is by getting our release team (or the buildbut) > to make more often official builds available. All that linux builds which are building with buildbot are official. Exactly the same environment is used for building it. -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] 2.6 Release Cycle Proposal
Hi, Proposal seems good to me. Also would like to stress that I think an important change to make is not just updating the b-con levels to fit better, but really doing a time based release cycle. >From this presentation about the google chrome release cycle: https://docs.google.com/present/view?id=dg63dpc6_4d7vkk6ch&pli=1 * The pace of the schedule sets the boundaries for the amount of work that can be completed. * It's important to have specific points in the schedule to review features and cut scope. * Establish clear expectations (and engineering practice) to developers that any features not ready to ship will be disabled. On Fri, Jul 29, 2011 at 1:59 AM, Campbell Barton wrote: > If we need to do an 'a' release individualizer fixes could be applied > from trunk rather then keeping trunk frozen *just in case* we need to > do another release (could branch from the tagged rev and merge only > the fixes from trunk). > > I'd like to know what others think about doing a release and > unfreezing soon after ahoy (1-2 days). I agree, better to unfreeze trunk nearly immediate and merge critical fixes for a/b releases to a branch. Brecht. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
