Re: [gentoo-dev] Re: RFC: reduce conflicts, separate keywording from ebuilds
On Mon, 2007-02-19 at 15:37 +0100, Stefan Schweizer wrote: > moving keywording only in the arch teams responsibility is the way to go > imo because I hate having keywording bugs assigned to my herd where I > can do nothing about it. Uhh... so why *don't* you assign these to the arch teams? Here's a good example... games. We get keyword requests all the time. Sometimes, one of us has the time to test it right there, so we do and we resolve the bug. EVERY other time, we defer it to the arch team, almost immediately. If we're also members of that arch team, we might come back later and do it ourselves, but it's really a job for the arch team, and up to them to either do the work, or decide not to add KEYWORDS and close the bug. > > I am not sure how a) is going to work at all in > > this respect. Are we going to get tons of ebuilds just sitting there never > > made visible to any arch now (since even x86 would have a large backlog)? > > it can be automated to do this from the maintainer arch if the arch team > wants it. When will people get rid of this concept of "maintainer arch" ? Not all maintainers only use one architecture. Not all ebuild maintainers use the same architecture all the time. When I do a commit, it could be from one of any of *eight* architectures. The number of people using only one architecture is growing smaller. This is especially true for the "top 10%" who do most of the commits. Go back and look at who those people are, they're the same people that work on *multiple* architectures. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: RFC: reduce conflicts, separate keywording from ebuilds
George Shapovalov schrieb: a) move all the keywording into profiles (that is remove all KEYWORDS fields from all the ebuild) and disallow package maintainers and other devs (other than arch teams) to touch keywords or b) leave ebuilds with simple ~arch/arch/-arch (literally) keywords and move granular per-arch settings to profiles the first one + maintainer arch is what I like to have. Other arches can then go up to maintainer arch automatically(with a bot) for ~arch and manually for arch or define their own policies like they want. or something else? Even then I am not sure how either of these is going to work, especially this: The arch team can then decide themselves which ebuild they want to mark ~arch and they can take care of possible new dependencies themselves. normally new versions/packages go directly into ~arch unless they are transiently masked by developer (waiting for release, etc) or are permanently masked live-cvs/svn ones. The particular case is about having new depends in new versions. For example in ghostscript-esp-8.15.3-r1 there is a new dependency on app-text/djvu and mips, arm, s390 and sh do not keyword it. See bug 148945 too. moving keywording only in the arch teams responsibility is the way to go imo because I hate having keywording bugs assigned to my herd where I can do nothing about it. I am not sure how a) is going to work at all in this respect. Are we going to get tons of ebuilds just sitting there never made visible to any arch now (since even x86 would have a large backlog)? it can be automated to do this from the maintainer arch if the arch team wants it. -Stefan -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: RFC: reduce conflicts, separate keywording from ebuilds
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
Re: [gentoo-dev] Re: RFC: reduce conflicts, separate keywording from ebuilds
On Mon, Feb 19, 2007 at 03:16:06PM +0100, Stefan Schweizer wrote: > Alexander Færøy schrieb: > >It was discussed at the last council meeting... Proposed by jokey. > > Thanks. Sorry I did not know about it because there was no summary for > the last council meeting. From the log that I read now I cannot clearly > define an outcome. > The (very clear imho) outcome was that it wasn't going to save any bandwidth at all and would increase used diskspace quite a bit. Bandwidth reduction was jokeys primary goal iirc. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: RFC: reduce conflicts, separate keywording from ebuilds
Alexander Færøy schrieb: It was discussed at the last council meeting... Proposed by jokey. Thanks. Sorry I did not know about it because there was no summary for the last council meeting. From the log that I read now I cannot clearly define an outcome. I would appreciate to see summaries again for the council. - Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: RFC: reduce conflicts, separate keywording from ebuilds
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. 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. 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. [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 :( We can for example also offer x86-only sync trees without all the ebuilds that are only relevant to the other arches. Best regards, Stefan -- gentoo-dev@gentoo.org mailing list
