> > So things going into the next "minor" bump (2.0.51 -> 2.0.52) can go > > into portage_2_0 and we can make the 2_0_51_branch just regression > > fixes. Then when portage_2_0 is ready for testing/feature-freeze, we > > branch it off to 2_0_52 branch and portage_2_0 becomes what will be in > > 2.0.53... > Down the line, branching head from stable (when it's actually stable) makes > sense... > won't happen with the next branch since there's already around 450kb+ worth > of changes in head, and that changeset > will grow :)
Yeah, but I'm saying we should have 3 branches instead of the current 2. regression-fix-only (portage_2_0_51-branch) stable (portage_2_0 which will become portage_2_0_52-branch) development (HEAD which will become portage_2_1-branch) > An ancillary issue, possibly worthy of it's own thread is mandating stable, > be just that- stable. Only bug fixes, > and regression fixes. > The result of the ebuild digest going from generating a complete digest (all > src_uri), to a partial digest > (src_uri after USE flag filterring) fex, should not ever change within a > stable release (as it did at .51-r3, and > subsequently reverted recently). Granted, I would make an exception here and > there- the locking changes to > portage_db_flat now in cvs- in that case, it's an improvement of existing > code, changes are minor, and the gains from > it are noticable- roughly 13% normal usage, in rare/screwed up systems, > dropping metadata transfer from 20m to 3m. > That said, still not much for anything but reversion/bug fixes in stable :) Hence why I think 3 branches works better =)
signature.asc
Description: This is a digitally signed message part
