On Mon, Feb 19, 2007 at 03:13:00PM +0100, Stefan Schweizer wrote: > Bryan Østergaard wrote: > >A. ~arch keywords are supposed to be carried over to new versions unless > >we're talking about big rewrites or similar (so old versions doesn't > >have to linger around in portage tree at all). > right, we all agree :) > > >B. If we're complaining about MIPS team not being able to ~mips kde-meta > >on time we need to remove all the arch teams that falls behind from > >time. I think that leaves us with maybe x86, amd64, sparc as *the only* > >arch teams allowed to keyword kde-meta which is completely insane and an > >insult to our users. > every arch team is allowed to keyword kde-meta, just they should not > complain about their keywords not being on bumps when they are late. Of course they should complain about dropped keywords. Policy says to keep ~arch keywords when doing bumps unless there's a very good reason not to (like a complete rewrite or whatever).
> > Keyword<->ebuild separation allows to clearly show the arch teams that > they are responsible and allows the developers not to get into conflict > here. It clearly would have avoided the recent conflict. Arch teams already know what they're responsible for - moving metadata about isn't going to change that at all and it most certainly wouldn't fix flameeyes complaint about having an extra 300 ebuilds in the tree because some arch team are late regarding keywording. The ebuilds would *still* need to be in the tree no matter where we store keyword information so it wouldn't solve it at all. > > The problem is with ebuild developers like me having no means to get > arch teams to keyword stuff yet we are responsible if something fails > and we get bugs assigned. Many arch team members have repeatedly stated that ebuild maintainers are free to reassign bugs about old versions to them if you've given the arch team reasonable time to keyword a newer version first so I don't think that argument has much merit to it at all. > > >[remove kde-meta talk] > > > >Besides that splitting keywords out from ebuilds doesn't solve > >*anything* at all related to this as the ebuilds *still* have to stay > >around as long as they have keywords. Just like current policy says. > >Moving metadata to another place doesn't change that at all. > > yeah. A script for removing all ebuilds that are allowed to be removed > by policy would be cool. Sadly I don't have one currently :( > I'm all for removing old junk from the tree but I don't think that can be entirely automated - there's lots of reasons that we might want to keep an older package around even when a newer package is keyworded on all archs. Sometimes we need to test against the older version and sometimes we need to allow people a transition period for config changes for example. So I think a tool listing versions that could possibly be removed would be much better than an automated tool just removing it all without further concerns. > We can for example also offer x86-only sync trees without all the > ebuilds that are only relevant to the other arches. > As an arch team member I think that's a horrible idea tbh. I don't want to waste any time on keeping all the changes from various arch trees in sync with my own arch tree. And from an ebuild maintainers point of view I'd like to know that when I fix a bug it's fixed on all archs. Both things would be broken if we seperate the tree imo and we would also drastically increase the space requirements for rsync mirrors which is quite bad. Having to keep 12 (or however many archs we support) portage trees instead of just one on rsync servers doesn't sound like a good idea imo. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
