On Thu, 6 Nov 2008 22:51:20 -0800
Donnie Berkholz <dberkholz@g.o> wrote:

> > What's the motivation behind this?  I can think of several reasons
> > why a package maintainer would need to touch a stable ebuild.
> 
> Could you provide a few examples? It's impossible for anyone else to 
> come up with solutions to problems that haven't been described.
> 
> Once it's stable, it should be static. If they need to make changes, 
> they should make them in a new revision & stabilize it. That may
> require a slight change in our workflow to reduce stabilization
> periods in these cases. But I think it's a superior approach to an
> ever-changing single revision, as long as portage handles revisions
> of filenames instead of revisions of git.

Well, if we could get rid of the 30 day wait to get anything done in
stable-land then, yeah, that makes a lot of sense.  Pretty much all the
examples I have in mind hinge on that.   Nothing aggravates me more
than having a broken package in stable and having to wait a month to
fix it.

What about things that don't require a revbump though, like build
fixes?  If the stable version of a package doesn't build with GCC 4.3,
and the current unstable can't go stable any time soon (say it breaks
ABI or is generally crap), then I have two choices.  I can do an
unstable revbump consisting of the stable version + a backported patch,
or I can just backport the patch directly to the stable version.  I
currently do the latter, not just because I don't have the time and
patience to track these packages for 30 days, file the stabilization
bugs, try to get vapier to stabilize s390 and m86k, discover vapier
stabilized them a month ago and didn't tell anyone, and generally
follow them through to the end -- I did exactly this for GCC 4.1 and it
took _over a year_ to sort out -- but also because I don't believe in
forcing a rebuild on people for no good reason.

If a stable package has an ewarn at the end telling the user they must
run "mypackage-updater", and that util is later renamed, do we really
need to do a revbump?  What about homepage moves?  What about stable
ebuilds that have a dependency on a package that is then moved to
another category?  Or USE flag renames?  I don't think any of these
things should require a rebuild.

On the other hand, I see where you're coming from.  If changes were
made to the process, namely doing away with the arbitrary time limit for
trivial changes, then I think I could agree.

One other thing I was thinking of - would package maintainers still
have write access to the stable tree?  If not, who cleans out old
ebuilds?


-- 
gcc-porting,                                      by design, by neglect
treecleaner,                              for a fact or just for effect
wxwidgets @ gentoo     EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662