On Wed, 13 Aug 2008 23:33:04 +0300 Petteri Räty <[EMAIL PROTECTED]> wrote:
As a distribution we should strive to make as many packages available with as many features as possible on as many architectures (or indeed operating systems) as possible.[1] Not communicating important changes in ebuilds to arch teams, even making decisions on their behalf, we risk having to mend increasingly complex systems of profiles and flags. > I have been instructing people to adjust the files themselves. The > changes affect only the package in question and as such it falls > under the responsibility of the maintainer of the package. Sadly, I've been adding capitalised boilerplate pleas to the heads (and sometimes the tails) of hppa profile files requesting bug reports instead of adding silently to the ancient cruft that's there already. That doesn't mean that either you or I are wrong, but it does clearly show that we should put this all down in writing[2] when we find agreement. :) > > I personally think no, individual ebuild devs shouldn't touch > > arch-profiles. They should simply drop the (broken) keywords and > > file a keywordreq bug for those arches. Then the arch-teams can > > test and eventually decide whether to keyword the package or mask > > the use-flag. There should be no problem committing the ebuild with dropped keywords, then filing a KEYWORDREQ bug report describing the problem and the solution, and CC'ing the stricken arch teams. > The arch teams don't have that much staff so not adding to their work > load is the best way to go imho. Cleaning up *use.mask is annoying work and removing a flag from *use.mask could affect many users (emerge --newuse world). We should therefore reluctantly mask USE flags and let profile maintainers decide what is useable and practical to have on their OS/arch. When in doubt whether to mask a USE flag or drop a keyword, a package maintainer should commit the ebuild, drop the keyword and file a bug to have the arch team decide. Important note: leaving the keyword dropped is no option for active, security supported arches[3]. Kind regards, JeR [1] That's my interpretation of much of what http://www.gentoo.org/main/en/philosophy.xml says. [2] The end result should probably trickle down into the devmanual (and/or the Developer Handbook?) at some point. I feel like writing a section or two about arch workflows and keywording processes that could be included in http://devmanual.gentoo.org/keywording/index.html . [3] When an arch team cannot handle the workload any longer, the support level should be dropped to ~arch anyway. I would really hate to see people do what amounts to crippling packages (removing features), just to decrease some arch team's workload. In the mean time, do pile up the work regardless of staffing problems - somebody new may just volunteer to help an arch team out when the going gets tough.