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