Re: [gentoo-dev] splitting build deps out from depends
On Tuesday 05 July 2005 18:39, Martin Schlemmer wrote: On another note .. how do you guys plan to handle this BDEPEND .. just for x-compile, or global? If global, any ideas how to solve the circular issues ??? Global. There's no real difference between building a package for the local machine or for another machine as far as deps go. If not global, there are circular issues involved anyway. Most of them are easy to overcome - just not easy to hack into the current implementation. If you've got concerns about a specific case, outline them please. Regards, jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] splitting build deps out from depends
On Saturday 02 July 2005 02:49, Mike Frysinger wrote: On Friday 01 July 2005 12:25 pm, Brian D. Harring wrote: Currently, we pretty much leave out the big dogs of build depends from ebuilds- basically we rely on the profile to require a suitable toolchain. Couple of issues with this though- 1) Deps aren't complete for an ebuild. 2) Merging a php or python lib that doesn't require compilation doesn't require a full toolchain, distutils/pear or make mainly. So autoassuming a c/c++ toolchain is required isn't accurate. 3) For automatically handling x-compile deps, without this info bound to an ebuild, portage will _never_ be able to know what dependencies are x-compile targets, and what deps must be natively merged. so what you're proposing is that we add binutils/gcc/glibc to every package that compiles something, make to every package that uses make, sed/grep/bash/coreutils to every package which runs configure, and tar/gzip/bzip2 to every package which has a gzipped/bzipped tarball in SRC_URI ? I'd agree with this as far as the compiling only. For the rest, they should really be RDEPENDs from portage (or whatever it is that provides econf, emake and unpack) itself. econf, emake and unpack are parts of the ebuild environment that every ebuild is guaranteed to have available. However, if an ebuild chooses to run make directly for some unknown reason or use some specific tool to unpack an unsupported file format, the package should really be explicit about its dependency. Regards, Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] splitting build deps out from depends
On Thursday 07 July 2005 02:08, Brian D. Harring wrote: Basically, I was attempting to get feedback on issues where this wouldn't be quiet enough, an example of which is ncurses. (my understanding of this, thanks to flameeyes for clueing me in) ncurses built/installed in chost==ctarget, BDEPEND= ncurses built/installed in chost!=ctarget, BDEPEND=ncurses I didn't read this in the thread. How does this work? Regards, Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] splitting build deps out from depends
On Tuesday 05 July 2005 19:48, Martin Schlemmer wrote: This is all well and dandy, but try to add coreutils as a dependency of itself, or gcc of itself, or sed ... or grep ... etc, and then try to do a stage1 install (probably stage2/3 as well, but I never do those, so rather wont comment). The point that Mike and I make, is that portage cannot handle this (and probably wont be able to in future without a _lot_ of black magic), and this is why we need the system profile which have just the right amount of DEPEND magic to make it work, and then everything else depends automagically on the system profile (and everything in it). Making the adding of system packages to non system packages really redundant. Portage can handle this because it doesn't look at BDEPEND. Black magic is not required. Black magic is what we have now that is causing so many problems. Regards, Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] splitting build deps out from depends
On Saturday 09 July 2005 11:28, Jason Stubbs wrote: I didn't read this in the thread. How does this work? ncurses needs to run a given binary (that I don't remember now, sorry), during the compilation stage. The build system try to build it bug if $CC != $BUILD_CC (literally) it considers it cross-compiling and doesn't try to run it (thinking that's a binary for another platform). In this case it *needs* the same binary already installed in the system. That means that when you're crosscompiling ncurses it requires a local copy of ncurses installed. To install the local copy, it doesn't need another local copy. -- Diego Flameeyes Pettenò Gentoo Developer - http://dev.gentoo.org/~flameeyes/ (Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM) pgpHxmC3VDTrU.pgp Description: PGP signature
Re: [gentoo-dev] splitting build deps out from depends
On Sat, 2005-07-09 at 18:28 +0900, Jason Stubbs wrote: On Tuesday 05 July 2005 19:48, Martin Schlemmer wrote: This is all well and dandy, but try to add coreutils as a dependency of itself, or gcc of itself, or sed ... or grep ... etc, and then try to do a stage1 install (probably stage2/3 as well, but I never do those, so rather wont comment). The point that Mike and I make, is that portage cannot handle this (and probably wont be able to in future without a _lot_ of black magic), and this is why we need the system profile which have just the right amount of DEPEND magic to make it work, and then everything else depends automagically on the system profile (and everything in it). Making the adding of system packages to non system packages really redundant. Portage can handle this because it doesn't look at BDEPEND. Black magic is not required. Black magic is what we have now that is causing so many problems. Ok, sorry, so maybe I went a bit overboard :) The point I tried to make is that with the current depend resolver this will not work, and we cannot just start to add packages in the system profile to DEPEND all over the place. -- Martin Schlemmer Gentoo Linux Developer, Desktop/System Team Developer Cape Town, South Africa signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] splitting build deps out from depends
On Sat, 2005-07-09 at 11:47 +0200, Diego 'Flameeyes' Pettenò wrote: On Saturday 09 July 2005 11:28, Jason Stubbs wrote: However, if an ebuild chooses to run make directly for some unknown reason or use some specific tool to unpack an unsupported file format, the package should really be explicit about its dependency. And this let me think: we'll be able sooner or later to specify 'gmake' instead of make to avoid having aliases magic on G/FBSD systems? :) I still this this is a bsd issue, so some or other solution which do not include having gmake (and then later lots of other symlinks/whatever) should be installed system wide for only a very small portion of our user segment on all systems. If its portage side only, fine. If I am missing something, my apologies - I am just making my stance clear. Thanks, -- Martin Schlemmer Gentoo Linux Developer, Desktop/System Team Developer Cape Town, South Africa signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] splitting build deps out from depends
On Saturday 09 July 2005 12:20, Martin Schlemmer wrote: I still this this is a bsd issue, so some or other solution which do not include having gmake (and then later lots of other symlinks/whatever) should be installed system wide for only a very small portion of our user segment on all systems. If its portage side only, fine. Trying to clear this: gmake is installed in Linux systems with make and gmake names. This is true not only for Gentoo but also for most of the linux distributions I know. A lot of scripts checks gmake support before 'make' and uses that if they found it. Most of the autotools stuff works fine on both gmake and bsdish make. There are a few cases in which we *really really really* need to use gmake (and a few we *really really really* need to use bsdmake). What I'd like to see if 'make' used when every kind of make is supported (gnu, bsd, whatever will come) and 'gmake' or 'bsdmake' when they are strictly required. -- Diego Flameeyes Pettenò Gentoo Developer - http://dev.gentoo.org/~flameeyes/ (Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM) pgpxhihSKntB4.pgp Description: PGP signature
Re: [gentoo-dev] splitting build deps out from depends
On Sat, 9 Jul 2005 14:08:24 +0200 Diego 'Flameeyes' Pettenò [EMAIL PROTECTED] wrote: On Saturday 09 July 2005 14:01, Martin Schlemmer wrote: And this is exactly what one of the issue for me is. Now devs on the linux sides, need to learn bsd make peculiarities as well (to start with, but it will expand if this gets in as 'policy' or whatever), and hope to guess right when to use make/gmake. BSD problem, BSD fixes it them self (ie some sane way that do not require global ebuild scouring, or BSD devs sweep the tree themselfs). The solution is: use gmake, which is GNU for sure, in case we need to use bsdmake, we'll take care of it. Alternatively, and less work for the ebuild devs, if most stuff works with either then use `make` by default (as has always been done), and if things don't work with the system's make we can change it around when we come to keyword things. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] splitting build deps out from depends
On Sat, 2005-07-09 at 15:11 +0200, Diego 'Flameeyes' Pettenò wrote: On Saturday 09 July 2005 15:05, Martin Schlemmer wrote: Ditto - point being, is that if you want the agony of per-ebuild hacks, be my guest, but do not expect the rest to hold your hand. It's not a matter of per-ebuild hack. Let me explain for example: for a bit of time we had make - gmake alias on g/fbsd profiles, but emake still called plain make (bsdmake). That was fine for most of the cases, gawk was the first one failing because it uess $(RM) which on gmake is an internal but it's not in other makes. The good solution was to fix the configure.in (or .ac i don't remember) to make sure that RM variable was set. That was discarded and we needed to let emake call gmake. The problem of make/gmake is minimal, just a few corner cases, but I don't really like have to use alias make='gmake' in profiles. Could do a make wrapper similar to the emake one, that just stips /usr/$(get_libdir)/portage/bin from PATH, and then run $MAKE. Then bsd will only need to add MAKE=gmake to its profile, and change it to MAKE=make or whatever for the bsd only stuff ? (as I assume you already have to do that for emake ...) Anyhow, just a suggestion. -- Martin Schlemmer Gentoo Linux Developer, Desktop/System Team Developer Cape Town, South Africa signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Closing bugs [was: New Bugzilla HOWTO]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Schlemmer wrote: Problem is many of us have sometimes already too many bugs to care about users reporting something, and then never coming back, not even talking about keeping to poke the reporter to come back and say the fix works fine, and close it. Thus the fix it, test it, resolve the bug as Fixed, and if the user do not reopen it, your work is done. Again, that's why I suggest that the verification be assigned to the Team Lead. Its not like you have to 'poke the reporter' 1000 times before the Team Lead does the verification [him|her]self. I mean the Team Lead is supposed to help the team members along with a little peer review, right? This process would just encourage more peer review, right? And one of the biggest strengths of F/OSS is PEER REVIEW!! Nathan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCz+U22QTTR4CNEQARAjDIAJwPDBcOjeuYFGSjwTznUGsg4RkgywCgnDYS ZFQJDE+sjAzo/jROHnukoRU= =y/cP -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Closing bugs [was: New Bugzilla HOWTO]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jory A. Pratt wrote: I have sat here and read you all rant on and on about these issues, Jory, I take issue with that. I am not ranting. I am proposing a way to *improve* QA. but you still are not taking into account that when a bug is marked worksforme or needmoreinfo that we are unable to replicate the error. We are not saying that the bug does not exist we are saying that of all the QA that we can do for you the user are unable to replicate the error. I do software development, systems integration, and bug squashing for a living. I know this fact: Sometimes the developer doesn't realise what the actual problem is. Sometimes its because the end-user didn't communicate well. Sometimes its because the developer is being an ass (we've all been guilty of this). *That* is why verification should be done not by the person writing the fix. It should be by an independent party; Team Lead, reporter, etc. If you can point out a number of bugs that violate my points please say so ... If you can not I believe you need to step back re-evalute the your thoughts and possibly send an apoligy to the DEV's. You forget we do not get paid for our time and/or work that we put into your DISTRO. Dear Developers Who Take Constructive Critizism as Insults, Please grow thicker skin. No one is out to get you. Believe it or not, the people trying to improve the process are on your side, and they're not trying to insult you. No one is saying that because the process could be better that your work is somehow diminished. Sincerely, Nathan p.s. End-users aren't paid to report bugs on 'your DISTRO' either. Sincely Jory P.S. I am not looking for a flame war Well you severly missed the mark on that one... I am looking for you all to step back and think before you say that no QA is being completed. Maybe you should stop assuming that a critique of a process is a personal insult. And I never said that 'no QA is being completed'. I'm suggesting a way to improve QA. Nathan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCz+kV2QTTR4CNEQARAjrTAJ0a3xa6Tao/+u5P7UGXjK6xonzLogCfexzQ BN9PNjeOoQO3e12Dz4taKZA= =S0om -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Closing bugs [was: New Bugzilla HOWTO]
On Sat, 09 Jul 2005 11:11:17 -0400 Nathan L. Adams [EMAIL PROTECTED] wrote: | I do software development, systems integration, and bug squashing for | a living. Gentoo's 'moving target' development model is not the development model used by your typical 'stable release once or twice per year' large software development project. HTH, -- Ciaran McCreesh -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Closing bugs [was: New Bugzilla HOWTO]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jon Portnoy wrote: On Sat, Jul 09, 2005 at 10:54:46AM -0400, Nathan L. Adams wrote: So when can we discuss the salaries you're going to pay the team leads to waste fairly significant quantities of time staring over everybody's shoulder? 8) Ha! If you don't like people staring over your shoulder, or if you expect payment for your time, go work for Microsoft. ;) I mean seriously, since when is someone else looking at your work a Bad Thing in F/OSS?? I really can't get my brain around that one. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCz/Sy2QTTR4CNEQARAjZQAJ92xrrbvfn3LZAY4UJCq9jDKtJTxgCgjSSN NxEldX9wWQLIJozIIJRqXbw= =gnDc -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Closing bugs [was: New Bugzilla HOWTO]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gregorio Guidi wrote: Any proposal that implies an enourmous increase of our human resources is really useless for us. Please accept the fact that we cannot change our resources at will, and adapt any suggestion to this simple principle. Now *that* is a reasonable argument. But come on guys, I'm suggesting *one* look at a bug by an independent party before marking it done. Nathan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCz/WW2QTTR4CNEQARAo8hAKCLfYZxHliZ1ChAgiuRZ6sNPwO8rwCgqCm6 SczzEoiUpUxklhRZ7muBl2o= =/HL1 -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Closing bugs [was: New Bugzilla HOWTO]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: On Sat, 09 Jul 2005 11:11:17 -0400 Nathan L. Adams [EMAIL PROTECTED] wrote: | I do software development, systems integration, and bug squashing for | a living. Gentoo's 'moving target' development model is not the development model used by your typical 'stable release once or twice per year' large software development project. That is absolutely true. But what I'm suggesting is by no means as strict as what you will find in those environments. I just think a small, incremental move in that direction could significantly improve Gentoo's QA process. Nathan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCz/Wm2QTTR4CNEQARAscBAJ9dBE+wWl1Tq0sZcMxC19ZQeNRYCACgh0HG QrB00IUUp3AI9ojffFEvYQo= =H6iQ -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Closing bugs [was: New Bugzilla HOWTO]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: On Sat, 09 Jul 2005 11:11:17 -0400 Nathan L. Adams [EMAIL PROTECTED] wrote: | I do software development, systems integration, and bug squashing for | a living. Gentoo's 'moving target' development model is not the development model used by your typical 'stable release once or twice per year' large software development project. Ah, how about this: Most of Gentoo's developers are concerned with Ebuilds (packaging if you will). A small subset of developers are concerned with Portage itself. Would have a *slightly* improved QA process on Portage development be such a bad thing/impossible. As I posted earlier, all I'm suggesting is *one* verification check by the Team Lead or the reporter before marking a bug as done. And Portage is arguably more stable and less fluid than the entirety of the ebuild tree. Nathan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCz/aK2QTTR4CNEQARApI1AKCH+XUcl4FR7xjZIK4V+GQPUFXoLACeJc5W M00736E0mlNtN7IqEqDh6wA= =Y9+n -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Closing bugs [was: New Bugzilla HOWTO]
Nathan L. Adams wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jon Portnoy wrote: On Sat, Jul 09, 2005 at 10:54:46AM -0400, Nathan L. Adams wrote: So when can we discuss the salaries you're going to pay the team leads to waste fairly significant quantities of time staring over everybody's shoulder? 8) Ha! If you don't like people staring over your shoulder, or if you expect payment for your time, go work for Microsoft. ;) I mean seriously, since when is someone else looking at your work a Bad Thing in F/OSS?? I really can't get my brain around that one. Clearly, you either chose to blatantly ignore, or completely misunderstood what avenj was saying. What he *meant* was we don't have the time or manpower to have developers take significant portions of their valuable time to do what you suggest without paying somebody to do it. -Steve -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] splitting build deps out from depends
I'll even top post this one :P Take it back to the thread flameeyes started about this originally pretty please, with sugar on top. On Jul 9, 2005, at 9:10 AM, Martin Schlemmer wrote: On Sat, 2005-07-09 at 15:11 +0200, Diego 'Flameeyes' Pettenò wrote: On Saturday 09 July 2005 15:05, Martin Schlemmer wrote: Ditto - point being, is that if you want the agony of per-ebuild hacks, be my guest, but do not expect the rest to hold your hand. It's not a matter of per-ebuild hack. Let me explain for example: for a bit of time we had make - gmake alias on g/fbsd profiles, but emake still called plain make (bsdmake). That was fine for most of the cases, gawk was the first one failing because it uess $(RM) which on gmake is an internal but it's not in other makes. The good solution was to fix the configure.in (or .ac i don't remember) to make sure that RM variable was set. That was discarded and we needed to let emake call gmake. The problem of make/gmake is minimal, just a few corner cases, but I don't really like have to use alias make='gmake' in profiles. Could do a make wrapper similar to the emake one, that just stips /usr/$(get_libdir)/portage/bin from PATH, and then run $MAKE. Then bsd will only need to add MAKE=gmake to its profile, and change it to MAKE=make or whatever for the bsd only stuff ? (as I assume you already have to do that for emake ...) Anyhow, just a suggestion. -- Martin Schlemmer Gentoo Linux Developer, Desktop/System Team Developer Cape Town, South Africa -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Closing bugs [was: New Bugzilla HOWTO]
Nathan L. Adams wrote: Jory, I take issue with that. I am not ranting. I am proposing a way to *improve* QA. Some thoughts from a humble user: Any improvement must neither excessively waste developer nor user time, it is the most scarce resource. To optimize this, the common case must be made fast, and the common case is that the bug has been truly fixed when it has been closed. The person reporting the bug can reopen the bug, as he/she is in a perfect position to test the fix. You can't have the people (developers) who are already the busiest spend significant time recreating bugs and testing the fix, just to find out that, yes indeed, it has been fixed. Sincerely, Marco -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Closing bugs [was: New Bugzilla HOWTO]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Marco Matthies wrote: Nathan L. Adams wrote: Jory, I take issue with that. I am not ranting. I am proposing a way to *improve* QA. Some thoughts from a humble user: Any improvement must neither excessively waste developer nor user time, it is the most scarce resource. To optimize this, the common case must be made fast, and the common case is that the bug has been truly fixed when it has been closed. The person reporting the bug can reopen the bug, as he/she is in a perfect position to test the fix. You can't have the people (developers) who are already the busiest spend significant time recreating bugs and testing the fix, just to find out that, yes indeed, it has been fixed. Sincerely, Marco I don't think any of the devs would suggest that *any* fix should be accepted without first testing it (under the current process). If you don't believe me, submit it an ebuild and keyword it as stable on a platform that you have not tested it on. The change I'm suggesting is having either the reporter or the Team Lead verify that the 'fix' actually works. Also, in the case were the 'fix' doesn't actually fix the bug, you waste alot more development time by letting it slip through and having to 'fix' it again later. So you can justify the time cost now, with time saved later. But then again, developer time *is* a very scarce resource. That's why I fielded the idea that the verification process only be required on things like Portage. Good development takes time. Nathan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC0Cvw2QTTR4CNEQARAg7MAJ912/60YTVVPBm3AQGFy4gMweYSsgCfTfym 3sQwbgylKR1GD6LllzKQDl4= =E0DJ -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Closing bugs [was: New Bugzilla HOWTO]
On Sat, 09 Jul 2005 15:56:32 -0400 Nathan L. Adams [EMAIL PROTECTED] wrote: | I don't think any of the devs would suggest that *any* fix should be | accepted without first testing it (under the current process). If you | don't believe me, submit it an ebuild and keyword it as stable on a | platform that you have not tested it on. The change I'm suggesting is | having either the reporter or the Team Lead verify that the 'fix' | actually works. Oh absolutely, I agree entirely that it is a vital part of the QA process that the team lead verifies that an arch developer has correctly managed to use ekeyword. -- Ciaran McCreesh -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Closing bugs [was: New Bugzilla HOWTO]
On Sat, Jul 09, 2005 at 12:00:50PM -0400, Nathan L. Adams wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jon Portnoy wrote: On Sat, Jul 09, 2005 at 10:54:46AM -0400, Nathan L. Adams wrote: So when can we discuss the salaries you're going to pay the team leads to waste fairly significant quantities of time staring over everybody's shoulder? 8) Ha! If you don't like people staring over your shoulder, or if you expect payment for your time, go work for Microsoft. ;) I mean seriously, since when is someone else looking at your work a Bad Thing in F/OSS?? I really can't get my brain around that one. I didn't say that. I'm saying that (a) team leads do not want to waste their time in such a way just to give you warm fuzzies (b) devs do not particularly want their team lead reviewing every single action they take, it sends the message that devs don't know wtf they're doing and need their hands held -- Jon Portnoy avenj/irc.freenode.net -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Closing bugs [was: New Bugzilla HOWTO]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jon Portnoy wrote: I didn't say that. I'm saying that (a) team leads do not want to waste their time in such a way just to give you warm fuzzies (b) devs do not particularly want their team lead reviewing every single action they take, it sends the message that devs don't know wtf they're doing and need their hands held (a) Its not a waste of time, and it is a FACT that peer review improves quality. (b) That's just a little prima donna... -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC0HSj2QTTR4CNEQARAncMAJ9d4k5ATKQQGTEeba+Dx9GoFjklFwCgjEww 3YzpdaKhz0wr4zibNcRzTOk= =lCjU -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Closing bugs [was: New Bugzilla HOWTO]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nathan L. Adams wrote: Jon Portnoy wrote: I didn't say that. I'm saying that (a) team leads do not want to waste their time in such a way just to give you warm fuzzies (b) devs do not particularly want their team lead reviewing every single action they take, it sends the message that devs don't know wtf they're doing and need their hands held (a) Its not a waste of time, and it is a FACT that peer review improves quality. (b) That's just a little prima donna... Nathan you have this misconception that just cause a bug apears on one system it is gonna apear on multiple systems. Most compilation bugs that I have seen are usually due to user not maintaining their configurations properly. You also still fail to understand that most of us maintain more packages than just one and it is impossible for us to take and drop what we are working on to help test and confirm that a bug does exist and is not user error. As far as team leads go they make sure the project stay on task and packages and bugs are handled in a timely manner. I would like to know do you want us to have 15 devs test for a particular bug if a team lead is not avaliable or would you like us to have just 2 people test? This has gotten way out of control with time and how issues are delt with, personally I think that you have a vendictive against a few devs that have closed bugs on you that they have not been able to replicate and/or find invalid. I can not say either way all I know is you in FACT have a misconception of how much time goes into testing before a package is moved to stable. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC0IW9GDfjNg8unQIRAvhNAJ9gXX7KNauZuYTvR4exeHUR7t6zdgCgk8yH LKl2nGSz2dLjmGrPb5gJAa4= =BzWw -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Closing bugs [was: New Bugzilla HOWTO]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jory A. Pratt wrote: Nathan you have this misconception that just cause a bug apears on one system it is gonna apear on multiple systems. What are you talking about? This whole discussion was framed with the situation where the *developer* determines that the bug report has merit. From my original post: In the bug, I believe the dev implies that the reported bug has merit /yet he closes the bug before actually doing something about it/. Most compilation bugs that I have seen are usually due to user not maintaining their configurations properly. Then that wouldn't be something that a dev would submit a fix for, now would it? You also still fail to understand that most of us maintain more packages than just one and it is impossible for us to take and drop what we are working on to help test and confirm that a bug does exist and is not user error. Again, you are confusing what I am suggesting with a completely different situation. NEVER have I suggested that user configuration problems should have some elaborate verification process. As far as team leads go they make sure the project stay on task and packages and bugs are handled in a timely manner. Great! My hat's off to them! I would like to know do you want us to have 15 devs test for a particular bug if a team lead is not avaliable or would you like us to have just 2 people test? OK, now you're rambling. If a team lead isn't available they should have a designated sub. That has nothing to do with the bug closer process; that is a Gentoo organization issue. This has gotten way out of control with time and how issues are delt with, personally I think that you have a vendictive against a few devs that have closed bugs on you that they have not been able to replicate and/or find invalid. Yes, that tinfoil hat is paying off nicely for you. ;) Seriously, my suggestion has nothing to with bugs that are found to be invalid. Please read the thread carefully and that should become apparent. Furthermore, I don't hold grudges against people who disagree with me. And lastly, what bugs have I filed that were marked invalid that would lead me to start this great conspiracy against some devs? Please enlighten me: http://bugs.gentoo.org/query.cgi?format=advanced I can not say either way all I know is you in FACT have a misconception of how much time goes into testing before a package is moved to stable. Now you're a mind reader too. Please tell me what else I have a misconception about. I'm sure my life will be greatly enriched by your sage wisdom in the matter! ;) If you want to continue the flamewar, I suggest we take it off this mailing list; other subscribers might not find it as entertaining as I do... Nathan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC0JSk2QTTR4CNEQARAhTmAJ96wIR/fPFm9xTK+K+tOzmcztm3dQCgmxWr +Zf5AtXi5Nux+eWK/Gfcbcg= =moyc -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Proposal: pre-emerge advisories
On Friday 08 July 2005 16:40, Craig Lawson wrote: What I'd like to see *before* I upgrade is a list of advisories about what trouble I'm in for. By the time most people upgrade a package, someone's been there before and felt the pain. The answers, or at least the warnings, are in the Forums. Yet searching the forums before upgrading each package is not practical. Similarly, the build logs are 99% stuff I don't care to read and 1% that I really do. How to find it? Better yet, I'd like to see it *before* I build. How about the ChangeLog? You're on the wrong list for this. The thread should be on [EMAIL PROTECTED] Regards, Jason Stubbs -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Proposal: pre-emerge advisories
Jason Stubbs [EMAIL PROTECTED] wrote: On Friday 08 July 2005 16:40, Craig Lawson wrote: What I'd like to see *before* I upgrade is a list of advisories about what trouble I'm in for. How about the ChangeLog? That would be a great answer. I look for trips and traps by doing an `emerge --pretend --verbose --changelog` every time I sync. Unfortunately, changes are often made with no entry in the log. When some change has significant effects, it is rare that even a passing mention is made regarding the precautions and prerequisites. I'm not suggesting yelling-at-the-user style *** DANGER WILL ROBINSON *** messages, but the terse kind suggested in Mr. Lawson's first message would be dandy. You're on the wrong list for this. The thread should be on [EMAIL PROTECTED] What he was requesting, additional capability for Portage, probably belonged here. On the other hand, a discussion on how to convince devs to make use of the existing capabilities would probably be welcome on gentoo-dev or, perhaps, gentoo-qa. -- Batou: Hey, Major... You ever hear of human rights? Kusanagi: I understand the concept, but I've never seen it in action. -- Ghost in the Shell, Shirow Masamune pgpNFh4y7ms45.pgp Description: PGP signature
