Re: [gentoo-dev] Shouldn't gcc-4.1-related bugs have some kind of priority as gcc-4.1 is now unmasked?
On Thursday 08 June 2006 15:34, Chris Gianelloni wrote: 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. Perhaps we should do something about this problem. There are still many committers. Take myself for example, I have (of course) my own overlay, and sometimes I must confess that I just fix these kinds of bugs for myself, add it to my overlay and forget about it. Perhaps if it were easier to fix these things in tree, it would be better for gentoo. I do not mean to say that it should become a free-for-all, but fixing these kinds of issues is beneficial. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpOFJtLRX1uN.pgp Description: PGP signature
Re: [gentoo-dev] Shouldn't gcc-4.1-related bugs have some kind of priority as gcc-4.1 is now unmasked?
On Thu, 2006-06-15 at 22:36 +0200, Paul de Vrieze wrote: On Thursday 08 June 2006 15:34, Chris Gianelloni wrote: 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. Perhaps we should do something about this problem. There are still many committers. Take myself for example, I have (of course) my own overlay, and sometimes I must confess that I just fix these kinds of bugs for myself, add it to my overlay and forget about it. Perhaps if it were easier to fix these things in tree, it would be better for gentoo. I do not mean to say that it should become a free-for-all, but fixing these kinds of issues is beneficial. If *any* developer came to us with a patch for GCC 4.1.1 and one of our games and asks if they can fix it, I know for a fact that I will definitely say yes. I'm pretty sure none of the other guys would object to it, either. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Shouldn't gcc-4.1-related bugs have some kind of priority as gcc-4.1 is now unmasked?
On Thu, Jun 08, 2006 at 07:00:33PM -0700, Drake Wyrm wrote: I just took a look at that. It's asking that you don't relay mail through dev.gentoo.org unless you can't send mail through your usual means of sending mail. For example, if your ISP blocks mail if the From: header indicates something other @myisp.com, then you need to relay through dev.gentoo.org. In any case, it's not telling you to avoid using your @gentoo.org account. Yupp. Of course, somebody flame me if I'm wrong. No flames from me - i send my from: [EMAIL PROTECTED] mails via my university's gateway as well. ;-) cheers, Wernfried -- Wernfried Haas (amne) - amne at gentoo dot org Gentoo Forums: http://forums.gentoo.org IRC: #gentoo-forums on freenode - email: forum-mods at gentoo dot org pgpesZDuc2ulD.pgp Description: PGP signature
[gentoo-dev] Shouldn't gcc-4.1-related bugs have some kind of priority as gcc-4.1 is now unmasked?
This is just a mine question, but it seems that since gcc-4.1 got it's way into portage (~branch) things are getting slower. Lots of the bugs blocking bug #117482 - http://bugs.gentoo.org/show_bug.cgi?id=117482 - have a patch in the report or an ebuild for revision bump, tested working. They just don't get committed (or, sometimes, closed). IMHO these bugs should get some kind of priority, cause actually any unstable system having one of these blocking ebuilds in world tree will have issue emerging,for sure. ( for who didn't noticed: gcc-4.1 is actually in portage testing , no more unmasked). thanks for your time and for listening my 2 cents. mattepiu -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Shouldn't gcc-4.1-related bugs have some kind of priority as gcc-4.1 is now unmasked?
Matteo Azzali wrote: This is just a mine question, but it seems that since gcc-4.1 got it's way into portage (~branch) things are getting slower. Lots of the bugs blocking bug #117482 - http://bugs.gentoo.org/show_bug.cgi?id=117482 - have a patch in the report or an ebuild for revision bump, tested working. They just don't get committed (or, sometimes, closed). IMHO these bugs should get some kind of priority, cause actually any unstable system having one of these blocking ebuilds in world tree will have issue emerging,for sure. ( for who didn't noticed: gcc-4.1 is actually in portage testing , no more unmasked). Sometimes people get busy, I know I haven't looked at my bugs all week, been busy at work 12 hours a day. As such if it's a big problem you can always gcc-config some-other-compiler-version and then compile any problem packages. I know that breaks the whole 'my whole system is compiled w/gcc-4.1' deal, but if it's that big of a blocker, take action. Or hell, patch the ebuild yourself. I think this distro was (or is?) about giving users the ability to do what they needed. If something is masked, you can unmask it, if it's not keyworded you can keyword it, if it's not patched, you can patch it thanks for your time and for listening my 2 cents. mattepiu -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Shouldn't gcc-4.1-related bugs have some kind of priority as gcc-4.1 is now unmasked?
Hum, maybe my little english is not good to explain my thoughts. I already have a /usr/local/portage overlay bigger than 500Kb. What I was asking is if it's a normal behaviour that emerge stops for unstable branch users. I asked myself this after looking some ebuilds that have more than 4 versions in portage but still none of these (neither unstable or masked) works with gcc-4.1.x (for example fox, 11 different versions in portage and the gcc-4.1.x ebuild (stabled upstream) still floating in bugreport #132407 of 5-apr-2006 and bug #128917 of 5-may-2006 , but fox is just an example, and there could be causes I don't know...) No meant to harm anyone, sorry if you get mad, still completely my personal opinion and nothing more. mattepiu Alec Warner wrote: Matteo Azzali wrote: This is just a mine question, but it seems that since gcc-4.1 got it's way into portage (~branch) things are getting slower. Lots of the bugs blocking bug #117482 - http://bugs.gentoo.org/show_bug.cgi?id=117482 - have a patch in the report or an ebuild for revision bump, tested working. They just don't get committed (or, sometimes, closed). IMHO these bugs should get some kind of priority, cause actually any unstable system having one of these blocking ebuilds in world tree will have issue emerging,for sure. ( for who didn't noticed: gcc-4.1 is actually in portage testing , no more unmasked). Sometimes people get busy, I know I haven't looked at my bugs all week, been busy at work 12 hours a day. As such if it's a big problem you can always gcc-config some-other-compiler-version and then compile any problem packages. I know that breaks the whole 'my whole system is compiled w/gcc-4.1' deal, but if it's that big of a blocker, take action. Or hell, patch the ebuild yourself. I think this distro was (or is?) about giving users the ability to do what they needed. If something is masked, you can unmask it, if it's not keyworded you can keyword it, if it's not patched, you can patch it thanks for your time and for listening my 2 cents. mattepiu -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Shouldn't gcc-4.1-related bugs have some kind of priority as gcc-4.1 is now unmasked?
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). -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Shouldn't gcc-4.1-related bugs have some kind of priority as gcc-4.1 is now unmasked?
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
Re: [gentoo-dev] Shouldn't gcc-4.1-related bugs have some kind of priority as gcc-4.1 is now unmasked?
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). -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Shouldn't gcc-4.1-related bugs have some kind of priority as gcc-4.1 is now unmasked?
[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) You should always use it on official gentoo mailing lists. -Steve -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Shouldn't gcc-4.1-related bugs have some kind of priority as gcc-4.1 is now unmasked?
Matteo Azzali [EMAIL PROTECTED] wrote: [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) I just took a look at that. It's asking that you don't relay mail through dev.gentoo.org unless you can't send mail through your usual means of sending mail. For example, if your ISP blocks mail if the From: header indicates something other @myisp.com, then you need to relay through dev.gentoo.org. In any case, it's not telling you to avoid using your @gentoo.org account. Of course, somebody flame me if I'm wrong. -- my other signature is witty pgpdkdniUrIZu.pgp Description: PGP signature
