On Sun, Nov 06, 2005 at 11:54:11AM +0900, Jason Stubbs wrote: > On Sunday 06 November 2005 06:09, Brian Harring wrote: > > We've pretty much ignored the minor, and abused the micro for both bug > > fixing and feature inclusion. Thoughts on using micro for _strictly_ > > bug fixes, and macro for features? > > I suggested this before, but it didn't go down too well...
Something I ixnayed/argued against? If so ignore me- I'm a dumb ass (this you should know already) ;-) As stated below, the dead 2.1 release screws with things a bit- which is about my only concern with fiddling with minor these days. > > Yes we'll run aground of the dead 2.1 release (not incredibly happy > > about that), but I'd like to see if we can get bug fixes out a bit > > quicker, with some semblence of a gurantee we're not tagging in stuff > > an admin isn't going to care about. > > What sort of bug fixes are you looking to get out quicker? While the EAPI > stuff drew out .53 a little longer than originally expected it was still only > 30 days from first rc to final (assuming _rc7 is final). I can't really see > the necessity for getting non-regression fixes out "quicker". At the moment, > a lot of fixes go out all at once rather than in lots of small bumps. I doubt > the overall speed would change very much. Question is how will it scale for non-bugfixes, disruptive changes like cache backport, elog backporting, confcache, etc? What I'm concerned about is what's going to occur with .5x when large changes start sliding into it (or into a minor)- basically the territory we're wandering into right now with cache/exec refactoring for .54. ~harring
pgp2lzUGfOaEs.pgp
Description: PGP signature
