| 1 |
On Monday 17 October 2005 08:25, Zac Medico wrote: |
| 2 |
> Jason Stubbs wrote: |
| 3 |
> > It will likely be that some of the bugs marked against 108262 won't be |
| 4 |
> > fixed in time. Perhaps it would have been better to just open a metabug |
| 5 |
> > when the branch is opened and mark bugs against it as they are fixed. |
| 6 |
> |
| 7 |
> It's nice to have a list of open bugs against the release where everyone |
| 8 |
> can see it. I suppose this mailing list can serve that purpose though. |
| 9 |
|
| 10 |
That's the thing though.. Most of the bugs we should be looking at fixing are |
| 11 |
15 minute jobs - maybe an hour on the "big" ones. If bugs are marked as |
| 12 |
blocking as patches are made and committed and then marked as fixed when a |
| 13 |
release is made, it should still be as easy to follow the progress. |
| 14 |
|
| 15 |
Looking closer at some of the bugs I've marked as possible targets for .54, a |
| 16 |
few will likely have to be deferred. That just means more junk mail from |
| 17 |
apache@×××××××××××.org and broken hopes for those that had activity on their |
| 18 |
bugs. |
| 19 |
|
| 20 |
> >>It should be possible to integrate some refactorings+features without too |
| 21 |
> >>much slowdown of the easy bugfix release pace (call it the EBRP for now). |
| 22 |
> >>IMO the timing of such merges should be limited to times that everyone |
| 23 |
> >>(people with commit access) agrees will have a minimal impact on the |
| 24 |
> >> EBRP. |
| 25 |
> > |
| 26 |
> > Stabalizing 2.0.53 took 2 weeks - assuming all the regressions are now |
| 27 |
> > worked out. Perhaps something like a 6 week cycle would be good? 2 weeks |
| 28 |
> > for any change, 2 weeks for small changes only, 2 weeks stabalizing... |
| 29 |
> |
| 30 |
> I'm not so sure about the "2 weeks for *any* change" part. We need to be |
| 31 |
> very selective about the larger changes. |
| 32 |
|
| 33 |
After thinking about it, incremental "feature creep" does seem like the best |
| 34 |
way to go at this late stage in 2.0's life. The problem is how to guage what |
| 35 |
is and what is not more trouble than worth. Perhaps adhering to the kernel's |
| 36 |
rule of "Separate each logical change into its own patch" would help to ease |
| 37 |
the possible impact of larger changes? |
| 38 |
|
| 39 |
> > To clarify: Treat backports as regular bugs and go through cycles of open |
| 40 |
> > the 2.0 branch for fixes for a while followed by stabalizing for a while? |
| 41 |
|
| 42 |
So where shall we head next? 2.0.53_rc6 is tagged and a tarball is making it's |
| 43 |
way to the mirrors. I'm pretty confident that this is the last - that is to |
| 44 |
say, 2.0.53 will essentially just be a renamed tarball - so time's pretty |
| 45 |
much up for deciding on the above. I know I'm itching to start knocking of |
| 46 |
some bugs again... |
| 47 |
|
| 48 |
Speaking of which, if something does crop up with 2.0.53 while the arch guys |
| 49 |
are deciding if it's stable, how should that be dealt with in subversion? |
| 50 |
Continue development under branches/2.0 and, should an issue crop up, `svn cp |
| 51 |
tags/2.0.53_rc6 tags/2.0.53_rc7` and make any required change directly under |
| 52 |
the tag? |
| 53 |
|
| 54 |
Another "by the way", `svn -v log > ChangeLog` for 2.0.53_rc6. I'm open to |
| 55 |
anything better if anybody has a good format for autogeneration. The quality |
| 56 |
of the commit messages themselves isn't really useful though without knowing |
| 57 |
their context, so this might be a bit of a catch 22.. For 2.0.54, viewsvn |
| 58 |
should be available so it might be better to just use the tracker bug to |
| 59 |
manually create a summary of notable changes. |
| 60 |
|
| 61 |
-- |
| 62 |
Jason Stubbs |
| 63 |
-- |
| 64 |
gentoo-portage-dev@g.o mailing list |
Archives