| 1 |
Brian Harring wrote: |
| 2 |
> On Sat, Oct 15, 2005 at 01:45:42PM +0900, Jason Stubbs wrote: |
| 3 |
>> |
| 4 |
>>Which leaves us with 2.0 and a set of refactorings and features. I think it's |
| 5 |
>>pretty much decided that these will be backported to 2.0. The only question |
| 6 |
>>at this stage is when. The only complicating factor here is the current 225 |
| 7 |
>>open bug reports. That and what to call 2.0+refactorings+features. |
| 8 |
>> |
| 9 |
>>So, there's pretty much three ways we can go: |
| 10 |
>> |
| 11 |
>>1) Backport refactorings+features and release. |
| 12 |
>>2) Fix more bugs, backport refactorings+features and release. |
| 13 |
>>3) Fix more bugs, release, backport refactorings+features and release. |
| 14 |
>> |
| 15 |
>>There's still a lot of bugs that can be fixed without too much work, so I'd |
| 16 |
>>like to go with 2) or 3). I was thinking to go with 3) with the backported |
| 17 |
>>stuff being named 2.1.0, which is how we arrived at this thread. |
| 18 |
> |
| 19 |
|
| 20 |
I am very impressed with the number of bugs closed in preparation for the 2.0.53 release (dependencies of bug 108082) and it seems like it is in everyone's best interest to keep up this pace so that all the easy bugs are closed ASAP. There is already a large list of *open* dependencies for the 2.0.54 (bug 108262) that will hopefully be closed and released soon. :) |
| 21 |
|
| 22 |
> |
| 23 |
> Aside from the 2.1 name being already slightly abused, prefer option |
| 24 |
> 4, bug/release work, integrating chunks in as they're ready and |
| 25 |
> releasing when things are stable. Basically... when the chunks are |
| 26 |
> ready to be integrated, they've been tested (ala cache patch + some |
| 27 |
> more time), yank the suckers in, and continue with stabilising towards |
| 28 |
> a release. |
| 29 |
> |
| 30 |
|
| 31 |
It should be possible to integrate some refactorings+features without too much slowdown of the easy bugfix release pace (call it the EBRP for now). IMO the timing of such merges should be limited to times that everyone (people with commit access) agrees will have a minimal impact on the EBRP. |
| 32 |
|
| 33 |
Brian's cache rewrite backport seems like an example of something that can be merged relatively soon. The modularity of the existing cache makes it relatively easy to replace without causing regressions. In addition, the cache backport almost falls into the category of an "easy bugfix" considering problems with the existing cache code (bug 108412 for example). |
| 34 |
|
| 35 |
Zac |
| 36 |
-- |
| 37 |
gentoo-portage-dev@g.o mailing list |
Archives