Ehrm, I'm already becomed developer (some days) *, I'm already the author of lots of patches/comment in those reports, and as you pointed out I must follow rules and can't "jump" maintainers (who surely have better understanding of the issue involved than me).
That's the cause of the question,my (little?) brain asked me "Why there are so much version of a package in portage, and why following bugs for version that aren't the latest stable and the latest unstable (for any arch) instead of ensuring that those 2/3 versions work fine?" , I mean, because in some cases a revision bump is necessary to let unstable work fine, (and these will be necessary however when gcc-4.x will become stable) why delaying trying to fix bugs specific of older versions, probably resolved upstream with new ones? (I know, my brain is nasty and doesn't works as others may expect). Other than this, 23MB of overlay? But you "clean" it or you keep stored every line of code you wrote? If you regularly clean your overlay (keeping no more than 2-3 ebuilds for package), then it's really huge and impressive! [EMAIL PROTECTED] * (I'm not sending mails through gentoo.org account cause http://www.gentoo.org/proj/en/infrastructure/dev-email.xml asks me to not use it to send mails "unless absolutely necessary." , and I have others mean of sending emails....) 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). -- [email protected] mailing list
