1 |
On Sunday 16 October 2005 14:20, Zac Medico wrote: |
2 |
> I am very impressed with the number of bugs closed in preparation for the |
3 |
> 2.0.53 release (dependencies of bug 108082) and it seems like it is in |
4 |
> everyone's best interest to keep up this pace so that all the easy bugs are |
5 |
> closed ASAP. There is already a large list of *open* dependencies for the |
6 |
> 2.0.54 (bug 108262) that will hopefully be closed and released soon. :) |
7 |
|
8 |
It will likely be that some of the bugs marked against 108262 won't be fixed |
9 |
in time. Perhaps it would have been better to just open a metabug when the |
10 |
branch is opened and mark bugs against it as they are fixed. |
11 |
|
12 |
> It should be possible to integrate some refactorings+features without too |
13 |
> much slowdown of the easy bugfix release pace (call it the EBRP for now). |
14 |
> IMO the timing of such merges should be limited to times that everyone |
15 |
> (people with commit access) agrees will have a minimal impact on the EBRP. |
16 |
|
17 |
Stabalizing 2.0.53 took 2 weeks - assuming all the regressions are now worked |
18 |
out. Perhaps something like a 6 week cycle would be good? 2 weeks for any |
19 |
change, 2 weeks for small changes only, 2 weeks stabalizing... |
20 |
|
21 |
On Saturday 15 October 2005 14:16, Brian Harring wrote: |
22 |
> Really not much for 2.1 (existing ebd based) being brought up as a |
23 |
> release line N months down the line, since 2 branches of development |
24 |
> is a pita enough, let alone 3 with fairly radical differences between |
25 |
> each branch. Not saying the path can't be tweaked as we're |
26 |
> proceeding, but would *really* like to know that as a group/community, |
27 |
> this is what we're going towards rather then in N different |
28 |
> directions. |
29 |
|
30 |
I don't really like the idea of trunk being stabalized either. Too much work |
31 |
to bring forward all the changes in stable as well as fixing its own bugs. |
32 |
|
33 |
On Saturday 15 October 2005 13:59, Brian Harring wrote: |
34 |
> On Sat, Oct 15, 2005 at 01:45:42PM +0900, Jason Stubbs wrote: |
35 |
> > So, there's pretty much three ways we can go: |
36 |
> > |
37 |
> > 1) Backport refactorings+features and release. |
38 |
> > 2) Fix more bugs, backport refactorings+features and release. |
39 |
> > 3) Fix more bugs, release, backport refactorings+features and release. |
40 |
> |
41 |
> Aside from the 2.1 name being already slightly abused, prefer option |
42 |
> 4, bug/release work, integrating chunks in as they're ready and |
43 |
> releasing when things are stable. Basically... when the chunks are |
44 |
> ready to be integrated, they've been tested (ala cache patch + some |
45 |
> more time), yank the suckers in, and continue with stabilising towards |
46 |
> a release. |
47 |
|
48 |
To clarify: Treat backports as regular bugs and go through cycles of open the |
49 |
2.0 branch for fixes for a while followed by stabalizing for a while? |
50 |
|
51 |
> On the subject of versions, which ever version the chunks get included |
52 |
> under, they're going to need integration testing, so versioning isn't |
53 |
> as much an issue to me as time. |
54 |
> |
55 |
> The delta between 2.1 and 2.0, last time I generated it was half a |
56 |
> meg; pulling chunks from 2.1 into 2.0 requires rewriting a chunk of |
57 |
> glue, so minimizing the time/delta is something of a concern- eg, |
58 |
> doing 2.0.* for a while, then a 2.1 I'm not totally much for. |
59 |
|
60 |
The thing I'm concerned about is the backports and bigger bugs that will |
61 |
require a longer stabalizing period. That and the fact that a few of them are |
62 |
also quite major in terms of what the user sees. It makes sense to me to |
63 |
group these together, bump the version to 2.1 and finally make the version |
64 |
numbers meaningful. |
65 |
|
66 |
-- |
67 |
Jason Stubbs |
68 |
-- |
69 |
gentoo-portage-dev@g.o mailing list |