On Thu, 2006-06-08 at 13:42 +0100, Chris Bainbridge wrote: > On 08/06/06, Matteo Azzali <[EMAIL PROTECTED]> wrote: > > Hum, maybe my little english is not good to explain my thoughts..... > > > > I already have a /usr/local/portage overlay bigger than 500Kb. > > I can beat that, try 23MB :-/ > > Anyway, back to your point - yes, there are lots of bugs with patches > attached that aren't being added to the main tree. And there are lots > of bugs where the ebuild or fix is ending up in an overlay rather than > the main tree. It's getting complicated to keep track - all I can > really advise is that if you'd like to see fixes and ebuilds being > added to the main tree, then become a developer and start doing it > (although it is complex for something like gcc compile fixes which are > spread across packages owned by multiple developers who will get upset > if you touch their package).
Actually, this isn't exactly true. In the case of a compile fix, such as this, the developer is aware of the issue, and gcc-porting@ is on the bug, too, as CC, usually. If someone from gcc-porting were to go around committing patches to my ebuilds, I know I wouldn't mind. It would reduce my workload greatly, especially as they're the experts on what is and isn't allowed in gcc 4.1, versus myself, who is a gcc 4.1 amateur. ;] The truth is that there's tens of thousands of possible patch-providers (users) and only ~300 people with commit rights. Even fewer when you consider that the package in question may have a single maintainer, or only a small team. Most of the packages that are blocking that bug are games. We're working on them, but there's a small group of us and a very large number of packages, many of which are very poorly coded and require a lot of work and testing. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux
signature.asc
Description: This is a digitally signed message part
