Re: [gentoo-dev] Proposal: sys-pam category
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 foser wrote: On Sun, 2005-06-05 at 18:34 +0200, Jonas Geiregat wrote: I do agree with you but some package just have completely wrong place within portage, such package placements migh confuse the user. To give an example: mzscheme was placed in dev-lisp while portage had a dev-scheme directory. The current set-up isn't user-browseable anyway and hasn't been for a long time. I don't think the focus should be on correcting that in the tree, the user tools should be improved really. Then why is their a browsable Categories link on the packages site? http://packages.gentoo.org/categories/ I don't agree with Ned. Organizing the packages logically makes things less confusing for the end-user and developers alike and doesn't qualify as a cosmetic reason. It *is* valuable work, IMHO. That's not to say that the user tools shouldn't be improved where possible, of course. I don't think anyone would argue with that. Nathan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCozWL2QTTR4CNEQARAoVuAJ439WPwSg8qj0+pUWusNWMhtYMXKQCfZlTU w8wP8vkA5nTTLFoqRlWvsK4= =sbo+ -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Proposal: sys-pam category
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ned Ludd wrote: *poof* we now reshuffle, but then we can do auth with ldap. So lets move all the */ldap* related subjects under it sys-auth/... Then a month or six later comes along sys-ldap and it gets moved there. The logic will go full circle before long if we consistently keep shuffling packages around. All in all this is seriously the reason why ebuilds have a DESCRIPTION= and one of the reasons we have metadata.xml files. Well obviously there needs to be a consensus on *how* to logically organize things before anyone goes willy nilly changing stuff. Do you group by what the package is used for (email vs. game vs. web browser) or by what it is built from (PERL stuff, Gnome apps, KDE apps). It appears that currently its a mix. Is that documented anywhere? I personally think the organization should be from an end-user perspective as much as possible. Imagine for a moment that you are a Genewbie (new Gentoo user). You have a new minimal installation and you want to add some applications. How do you know what your choices are for an email client, for instance? You could find most things here: http://packages.gentoo.org/packages/?category=mail-client But that wouldn't let you know about kmail, a fairly important option. If you were to do a search, you wouldn't get much either: # emerge -s email Searching... [ Results for search key : email ] [ Applications found : 5 ] * dev-perl/Email-Find * dev-perl/Email-Valid * net-mail/archivemail * net-mail/email * net-mail/sendEmail So while the metadata.xml files do exist, I don't see how they are _currently_ very useful to the end-users. Again, I think better organization and improved tools are both worth while. Nathan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCo2cv2QTTR4CNEQARAo5tAJ0STkaF2m46JPxysx9tGGCz4wZHZQCfUElz 6RRmFZVvhp2Otr9ZA9yUVHE= =gW6X -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Proposal: sys-pam category
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nathan L. Adams wrote: Well obviously there needs to be a consensus on *how* to logically organize things before anyone goes willy nilly changing stuff. Do you group by what the package is used for (email vs. game vs. web browser) or by what it is built from (PERL stuff, Gnome apps, KDE apps). It appears that currently its a mix. Is that documented anywhere? I personally think the organization should be from an end-user perspective as much as possible. Imagine for a moment that you are a Genewbie (new Gentoo user). You have a new minimal installation and you want to add some applications. How do you know what your choices are for an email client, for instance? You could find most things here: http://packages.gentoo.org/packages/?category=mail-client But that wouldn't let you know about kmail, a fairly important option. If you were to do a search, you wouldn't get much either: # emerge -s email Searching... [ Results for search key : email ] [ Applications found : 5 ] * dev-perl/Email-Find * dev-perl/Email-Valid * net-mail/archivemail * net-mail/email * net-mail/sendEmail So while the metadata.xml files do exist, I don't see how they are _currently_ very useful to the end-users. Again, I think better organization and improved tools are both worth while. Nathan Oooops. I just realized that I did a --search instead of a --searchdesc. But I doubt most users even realize that --searchdesc even exists, so my argument there still applies. ;) Nathan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCo2iK2QTTR4CNEQARAjgtAJ0TysMfDTptn9U1v7NlquVpONevVQCZAbA6 TYcZJnMAAhsgcNwpKw6fiO4= =H/f5 -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo Enterprise deployment tools
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thierry Carrez wrote: Omkhar Arasaratnam wrote: I think most of the assumptions that you're making involve giving your user population root access. Don't ?? The assumptions I am making are clearly not involving giving a user population root access. I just point to the lack of tools to maintain semi-frozen trees and to automate software updates on a large enterprise desktop deployment, and try to see if this gathers interest. I fail to see where I need to give wheel to user. My position would rather be that workstations don't need a portage tree or an emerge command. A software deployment server could push package installation on workstations and keep track of what's installed where and with which configuration files. Would the semi-frozen tree you're looking for be embodied by GLEP 14? (I think it would for my needs.) Imagine if you could do something like this: # emerge --securityupdates world And you would get only the updates required by GLSA's that affect /your/ machine. http://www.gentoo.org/proj/en/glep/glep-0014.html This is similar to what Enterprises do with Windows installations, and I honestly think GLEP 14 could become portage's killer feature benefiting 'normal' users and enterprise users alike. The ability to push updates from a central location is, of course, a separate matter. :) Nathan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCuVgR2QTTR4CNEQARAqr3AJ9YqU09o9ZzeAVOapVCu5DnfyXCJwCgnDT6 RzGQ8mNP9qxH6RePsnIpK6M= =a99r -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] EBUILD_FORMAT support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sven Wegener wrote: On Wed, Jul 06, 2005 at 08:41:43PM -0400, Mike Frysinger wrote: On Wednesday 06 July 2005 08:20 pm, Sven Wegener wrote: We would like to introduce a new ebuild variable named EBUILD_FORMAT, seems like the name is much longer than it needs to be ... what's wrong with say 'EVER' ? It's fine too. EBUILD_FORMAT was just the name that fell in #gentoo-portage once we discussed about it. Sven EVER looks like the english word 'ever'; what does it stand for? EBUILD VERSION? If so, how about EVERSION? Since when was variable name length a problem? Go with whatever best describes the variable and is easy to figure out. Nathan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCzH772QTTR4CNEQARAlimAJ0Yh80KpXqc0yZv6Gli+KqpWaKBxQCfU6pR 2WqrKs4MfY+RCgpoFxZKD8Q= =5nzV -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Closing bugs [was: New Bugzilla HOWTO]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Duncan wrote: Well, not blocker g, but ... http://bugs.gentoo.org/show_bug.cgi?id=73181 This brings up a point that really irks me. 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/. And I don't mean to pick on Jeffrey; this seems to be a common habit among Gentoo devs. If a bug is opened and it is a valid bug, the bug should not be closed until it is actually squashed and the product ships (of course, if its a valid bug that just won't get fixed for some reason, you can always mark it WONTFIX): http://bugs.gentoo.org/page.cgi?id=fields.html#status I won't even go into the fact that the VERIFIED state* does not seemed to be used or the fact that the person ASSIGNED to the bug is allowed to close [his|her] own bugs! ;) Nathan * This would seem to be a perfect job for Team Leads, but it would need to be enforced by Bugzilla, and the ASSIGNED engineer must not be the same person as the VERIFIED(er) engineer for a particular bug. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCzmaf2QTTR4CNEQARArnwAKCSvsTZJuOGEswyResK3mNoTWlmFgCfbp2s T0h/txCaKzqjGrCdbW1pOqg= =U+ib -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 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]
-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]
-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]
-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 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-dev] Re: Closing bugs [was: New Bugzilla HOWTO]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Henrik Brix Andersen wrote: Dear Nathan, On Sat, 2005-07-09 at 12:04 -0400, Nathan L. Adams wrote: But come on guys, I'm suggesting *one* look at a bug by an independent party before marking it done. Great! Thank you for your offer to review our bugfixes. Please start right away. Are you offering me a job? ;) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC0R8t2QTTR4CNEQARAjV8AJ0QgimQUfj2PxpfC18jBB42dNirRgCfXZYt 0v6Tj6qMJU8Cmj+ZApi/Pkk= =wyyT -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 R Hill wrote: Nathan L. Adams wrote: But come on guys, I'm suggesting *one* look at a bug by an independent party before marking it done. That's reasonable, but I don't see that party being a Team Lead or even a dev. If there's a bug filed and another user can confirm it, it's Verified. That's the whole idea behind the status. I'm suggesting that the Team Lead be ultimately responsible, not that the TL has to verify each bug. The best case would be that all bugs get verified by the reporter (or another user as you suggest). The worst case is that no reporters or other users verify the bug, so *then* the TL gets the job. I don't really see much to gain by adding another step in the bug reporting process. Some projects use it, some don't. I don't think b.g.o is formal enough re. bugzilla to warrant it. I'm suggesting that making b.g.o a *little* more formal might be a Good Thing. What do you think about adding the step only to certain critical products, such as Portage or maybe Catalyst or even the Installation Docs? I do agree with the original point. Reports shouldn't be marked resolved unless the bug is fixed or permanent, or not enough info is given to verify that a bug actually exists. As Mike keeps pointing out, the NEEDINFO status covers bugs that a dev can't reproduce, etc. But my suggestion only covers bugs that a dev has provided a fix for (irreguardless of whether the dev reproduced the bug or not). Nathan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC0Sjc2QTTR4CNEQARAvCdAJ4tJaecjuA2mQRtiOZ8O9pDOt4kHQCfaMGP wtIxSh8fX218TXlYyOfBgQs= =iPoD -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 Jon Portnoy wrote: On Sun, Jul 10, 2005 at 09:49:16AM -0400, Nathan L. Adams wrote: To restate the problem: When a dev submits a fix for a bug, it should be verified and peer reviewed before the bug is marked done. That's not a problem, that's an opinion. I'm not at all convinced that not having every bug resolution reviewed every time is a problem, maybe you should start there :) Well originally I was going for any bug that a dev thinks has merit, but after reading some of the replies I'm now leaning towards any bug that a dev submits a fix for. And I've also fielded the idea that it only be mandatory for certain critical products such as Portage. Maybe as a start, the Developer's Guide can be revised to state that: Ideally any bug that a fix is submitted for should be verified and peer reviewed. It should be verified by the reporter or another user. If the reporter or another user are unable or unwilling to verify the fix, the Team Lead should take responsibility for the verification. Ideally, all bug fixes should be peer reviewed by the Team Lead and/or other team members before the bug is marked as RESOLVED. The following products have been deemed critical, and therefor must follow the above process: X Y Z Then it becomes a completely optional 'best practice' for the vast majority of bugs. Nathan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC0Tn52QTTR4CNEQARAliRAJ9CNmaI5OnHd4i1w0UKHEBq2e9XxgCgk2Hh 4Ep0I76PAIb9ItQCmD/929E= =YQOy -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 Daniel Drake wrote: Nathan L. Adams wrote: What do you think about adding the step only to certain critical products, such as Portage or maybe Catalyst or even the Installation Docs? You're now significantly altering your proposal, from something that affects almost everyone, to something that affects only some 'minority groups'. Nobody can give you a straight single answer. The whole point of this discussion is to get feedback and alter the idea as needed, not to beat everyone over the head with the Original Idea (c) until everyone sees it My Way (TM). So kindly pick the version of the idea that you like best, and base your discussion on that. ;) For portage, ask on the gentoo-portage-dev mailing list. For catalyst, ask on the catalyst mailing list. For installation docs, ask on the docs mailing list. These groups are significantly different, have their own distinctive procedures, etc. Good point. See my reply to Jon Portnoy for the latest revision of the idea that would apply to everyone as an optional 'best practice'. Nathan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC0TtM2QTTR4CNEQARAjeAAJ0bhA31Oc0Ho5mRnjkjCvg5zZZVkwCgm7Ib ehPatwEpWl9LdD59n8HJnxE= =J1U+ -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New Bugzilla HOWTO Update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris White wrote: Doc is still here: http://www.gentoo.org/doc/en/bugzilla-howto.xml After a good ammount of user input the bugzilla doc has been updated. The new version uses ggdb3 instead of g for debugging and contains a new section on testing ebuilds. Thanks goes to robbat2 for his commentary on what to improve. Thanks goes to the people who help fix my crap for grammar mistakes ;). So far it seems to be comming along nicely, I've been notified of the upgrade to bugzilla comming soon, and will update my screenshots and other information accordingly. Thanks again to everyone. Chris White This sort of thing could reduce the number of INVALID and NEEDINFO bugs. Great job! Nathan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC0TvG2QTTR4CNEQARAl3LAKCd4ODRkgSLpgf64yz1BcrGZAbnAwCeKPg+ RNBnuP0w+ISiDU2XFvqU3js= =c30Y -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 Sun, 10 Jul 2005 11:08:41 -0400 Nathan L. Adams [EMAIL PROTECTED] wrote: | Maybe as a start, the Developer's Guide can be revised to state that: | | Ideally any bug that a fix is submitted for should be verified and | peer reviewed. It should be verified by the reporter or another user. | If the reporter or another user are unable or unwilling to verify the | fix, the Team Lead should take responsibility for the verification. | Ideally, all bug fixes should be peer reviewed by the Team Lead and/or | other team members before the bug is marked as RESOLVED. Again, Gentoo is not a large corporation or Debian. I don't see how Gentoo's status (or rather lack thereof) as a corporation or Debian has anything to do with encouraging peer review. The assumption is that the majority of fixes are done correctly the first time, and this assumption is valid. I don't see how you could prove that assumption. If you can, please do so. Hence, the default behaviour is to mark bugs as RESOLVED, with reopening being an entirely legitimate and encouraged response for those occasional instances where the resolution was not sufficient. There are plenty of devs who don't share in the viewpoint that reopening bugs is legitimate and should encouraged (although I agree it is and should be). I base opinion that on some of the kicking and screaming I've seen on bugzilla in the past. ;) Nathan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC0T+c2QTTR4CNEQARAmhWAJ485c4s5MjMzQRUrCn4rR06qB/nDwCfQowx KGJfs0VkcxZO3yHOKKIPFwE= =LdlM -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 R Hill wrote: Ah, okay. You're talking about patch review. Now this makes sense. I've always considered the Verified status to be indicative that a third party has been able to reproduce the bug, not that a fix has been approved. My mistake. No problem; I appreciate your input. I think Chris White's (et. al.) recent work on the documentation is going to have a better effect on the problem you mention. Nathan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC0Z832QTTR4CNEQARAlxWAJwIkswVeLsJlSfcVmcTGcjaBGAKZACghI0b eqbYsXXyTLxJhyf8YhEH/VI= =R/2Y -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 Maurice van der Pot wrote: If the developer shortage was not as big as it is, we could probably really do something with your proposition. Then why not lay the ground work, documentation-wise, now? Then as you add on developers they have a nice reference on 'best practices' for Gentoo development. Nathan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC0aGh2QTTR4CNEQARApwyAKCIIM6lv5fgZIH/zENJ0k63WaQKLgCglnUH 0qWsK9ByqQqyKFxvPPLvtAc= =ZPnl -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Abuse by gentoo developer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The will not allow it and I will not allow someone to go fooling in an ebuild I maintain. Not trying to be an ass here but we have something called respect for others when it comes to the tree and what they maintain. Poor Jory. Respect isn't something that is owed to you; its something that is shared between two or more people. Looking down on people and being territorial (especially with something you don't actually own) doesn't help. I can't help but laugh at the idea that a dev on an F/OSS project would get mad because somebody wanted to *improve* the code. If you can't take the heat, don't join a F/OSS project... You want to curse me and tell me you think your gonna go playing in my vpopmail ebuild Wow, now its *his* vpopmail ebuild. And here I thought everything was copyrighted to the Gentoo Foundation. you can take your bullshit upstream I am black listing you on my filters so I do not need to read your bullshit Sadly, this sort of childish behavior isn't isolated to this particular dev. Its the equivalent of Cartman (Southpark) saying screw you guys, I'm going home. And it makes the speaker look just as mature. Umm look I'm just trying to help here, and I really feel like I've been treated very unfairly by this developer. I'm working hard to try to make vpopmail AND gentoo better products, I'd really appreciate not being told on things I know very well that I'm right about, and getting severe reactions like this when I prove that my statements were indeed correct and that I'm only trying to help. Most of the Gentoo devs I've dealt with are very talented and very likable people. They volunteer in a very professional manner and understand that with their developer status comes a few responsibilities (common curtesy being one of them). But there does seem to be a vocal minority of asshats who like to carve out their little fiefdoms and 'fend off invaders' at all costs. :( I really feel that this response whas wholly unjustified, and that I did nothing to warrant it. Please advise. As Mike mentioned: http://www.gentoo.org/proj/en/devrel/ Hopefully, you'll stick around and help out again in the future. Nathan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC3bVF2QTTR4CNEQARAgu9AJ0c7E5zGqC1TUTtHpC5JqTxK3RlNACfT2nZ P1Dz55PPdZ/DcqstSHPG2PY= =nlVQ -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: upgrade's and rc-scripts
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian D. Harring wrote: Vapier had suggested yanking (on unmerge, not replacement) any config_protected file that has the same md5/mtime as what it was originally merged with. As and end-user, that would be mana from heaven. :) Nathan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFC54/V2QTTR4CNEQARAlm5AJ0b9i6pwfN62FLn/rHNvrkCXDN8VACgnghT s3MyShSLliagonr06yE2M2Q= =QSzI -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Devconference archives
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Gianelloni wrote: That being said, thanks to IU for doing the webcast... now everybody gets to see what we look like... *grin* If you're like me, you have a perfect face... for email. :P -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDAqRe2QTTR4CNEQARAseAAKCjAE5e4Lu5nfw337AcKR1jiPc8/ACeNdTs ALsdqQbyiJnsaoc5a+0J3H8= =vCyM -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Bugzilla handling for maintainer-wanted things
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Fernando J. Pereda wrote: I think APPROVED doesn't reflect the idea; since nobody 'approved' the ebuild. A developer just checked it looks good and 'seems to work'. REVIEWED or CHECKED make more sense imho. I like REVIEWED; it seems to reflect the intended meaning. And I'm please that Ciaran is promoting peer review of ebuilds. Now if we can just get him off the idea that dev submitted stuff is 'correct by default' we'll be getting somewhere in terms of QA. ;) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDBSZG2QTTR4CNEQARAsYTAJ9slITUxSB8PovswA5MShV36uP1xwCfRnZB s464221vXli1LtlwKVtS+c8= =4POr -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Bugzilla handling for maintainer-wanted things
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: Oh come on, haven't you heard my rants about the state of the tree and the number of monkeys who have commit access? Yes I've read those rants, among others.. :) But with everyone screaming 'not enough manpower' the number of devs with commit access is just bound to increase. So why not focus on how to increase quality by default? Problem is, getting decent QA done once things hit the tree is in many cases very difficult So why not build peer review into the process/policy? Require that the team leads (who could deligate as they see fit) perform verification (peer review) before closing out bugs. -- the kind of people who won't accept QA feedback are usually the kind who are making the worst mistakes. The maintainer-wanted list is simply an easier target... True; being a premadonna isn't pretty or helpful to the project, but I bet alot of it is due to bad expectations. There seems to be a vocal minority of devs who equate being a dev with a God-like status. How dare you question me or my work?!? And it would make sense that the new devs would pick up on that as a way to 'fit in'. So how can we set better expectations for new devs up front? Update the dev policy docs?: - - Expect to have your work peer reviewed at all times - - Realise that peer reviews are intended to improve the code not evaluate dev performance Ideas? Nathan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDBe572QTTR4CNEQARAtYpAJ0aZ4gnfyE4lTUrbYr/DcWmIUX67ACghyvl TTCM9mWVTkuUWm33WnSeE9A= =gE1q -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Bugzilla handling for maintainer-wanted things
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: On Fri, 19 Aug 2005 10:36:43 -0400 Nathan L. Adams [EMAIL PROTECTED] wrote: | But with everyone screaming 'not enough manpower' the number of devs | with commit access is just bound to increase. So why not focus on how | to increase quality by default? I am doing. I'm doing it by trying to improve the documentation and the entry requirements for new developers. | Problem is, getting decent | QA done once things hit the tree is in many cases very difficult | | So why not build peer review into the process/policy? Require that the | team leads (who could deligate as they see fit) perform verification | (peer review) before closing out bugs. Because that won't help in the slightest. So you're saying that peer review is good, but peer reviewing things by default is bad? Explain? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDBn8e2QTTR4CNEQARAqaHAJ9erzzbR6qac8px3g+Ii4mI2nuBmQCeKW78 uVVAdNgFYoXpTaI7z5FxDsg= =iZAz -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Bugzilla handling for maintainer-wanted things
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Gianelloni wrote: *sigh* Please stay away from that bug. It is assigned to the games team, as it is a games bug, and it will be gotten to when we have the time and not before. Nathan is once again using a discussion to fuel his own personal desires and attempting to circumvent the games team. We peer review our own ebuilds against each other, so there's no need to have other developers do so, unless you're wanting to join the games team... =] In the time it took you to respond to this thread, you probably could have reviewed the ebuild in question... -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDBn/X2QTTR4CNEQARAvLkAJwP4N13cBN3yFxH5a63+SjRzKV6kACggZcw QrXnvX/Cq6vb8C5eKNtyqzs= =Hv1N -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Bugzilla handling for maintainer-wanted things
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: On Fri, 19 Aug 2005 20:53:50 -0400 Nathan L. Adams [EMAIL PROTECTED] wrote: | Because that won't help in the slightest. | | So you're saying that peer review is good, but peer reviewing things | by default is bad? Explain? No, I'm saying that having a 'team lead' throw some arbitrary stamp of approval upon bug closures is worthless. So you're problem isn't with the peer review I'm proposing but instead quality of work of the team leads? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDBzgm2QTTR4CNEQARAvaCAJwJO5BrCK+yG57+yxa4TI2gN9zT6ACdEjPP 7S5TQ9d236Oo1Lkln/9QziY= =39QI -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Bugzilla handling for maintainer-wanted things
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: On Sat, 20 Aug 2005 10:03:18 -0400 Nathan L. Adams [EMAIL PROTECTED] wrote: | Ciaran McCreesh wrote: | On Fri, 19 Aug 2005 20:53:50 -0400 Nathan L. Adams | [EMAIL PROTECTED] | wrote: | | Because that won't help in the slightest. | | | | So you're saying that peer review is good, but peer reviewing | | things by default is bad? Explain? | | No, I'm saying that having a 'team lead' throw some arbitrary stamp | of approval upon bug closures is worthless. | | So you're problem isn't with the peer review I'm proposing but instead | quality of work of the team leads? Not at all. I'm saying that a) most 'team leads' will not do proper checks because they don't have time to and b) the limited time that 'team leads' have is better spent elsewhere. I really am curious here: a) What are the team leads spending most of their time on? b) What is more important than improving the code? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDB0zS2QTTR4CNEQARAjUbAJ92tanYPNEXx6ZHyiZcFDjHpohgHQCePN0t v9BxNT1eetr9uZ8Be5PwEAw= =50IR -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Bugzilla handling for maintainer-wanted things
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Gianelloni wrote: Reviewing an ebuild has nothing to do with inclusion. For inclusion in the tree, it also needs to be tested. You don't take the slightest look at an ebuild (the code) before including it? Anyhow, whether its testing or code review, it is time better spent than cooking up conspiracy theories about me vs. the games team and posting it to the mailing list. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDB2TB2QTTR4CNEQARAo8/AJ9A2lcb/DocUJUJdMrIJEsDBwN0FgCeLAWw qWz0qr+iKO+W9zpoTtULLM8= =Maa/ -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Bugzilla handling for maintainer-wanted things
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Fernando J. Pereda wrote: On Sat, Aug 20, 2005 at 07:00:02PM -0400, Nathan L. Adams wrote: WONTFIX refers to the bug, not the attached ebuild. And it won't be 'fixed' unless the ebuild is improved, so WONTFIX is fine. As R Hill already pointed out, WONTFIX means that the *bug* will never be fixed. Fixing the *ebuild* would fix the bug, so WONTFIX isn't the right keyword. Following your logic, all bugs dealing with ebuild should be marked WONTFIX; in the ebuild's current state the bug wont be fixed. Its just not a logical argument. What Ciaran is actually doing is assigning the bug back to the person that submitted the ebuild. So ASSIGNED or something new like CONTRIB_ASSIGNED would be appropriate. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDB7tr2QTTR4CNEQARAnK8AJkB4ThPI0YmG3HUU15hvXuVmAC+bwCfT77o tNRu+Ol64fpUMoA1o33YZ7A= =Q0JO -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Bugzilla handling for maintainer-wanted things
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Duncan wrote: Not to sound harsh, but... [snip the we're just volanteers argument] All F/OSS projects (even Linux with its numerous corporate sponsors) are, at their core, volanteer projects. Yet the good ones still manage to build peer review into their development process. What I see with Gentoo is this 'cathedral' being built where only those folks who have been 'approved' or 'blessed' as being l33t enough are allowed to review the code and actually cause a positive change when some bug is found. If you believe Chris Gianelloni's argument, then only those blessed developers who are also blessed by a particular group within Gentoo are allowed. Eventually the meritocracy degrades into a popularity contest. What I want is for Gentoo to be more of a 'bazaar' where anyone with a good idea gets listened to and anyone with a good patch gets their name in the credits. Yes this is a volanteer distribution. That's a blessing, not a curse! That means that you DON'T HAVE DEADLINES. You can take the time to do it right instead of just 'code it up, test it once, and pray it really works'. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDB7/I2QTTR4CNEQARAirCAJ9V+MDjb4gAhWInpaodKeRVp6uNhQCeLfqh K4D6MJE2g0m7F4ALEoa2siY= =Nt9Z -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Bugzilla handling for maintainer-wanted things
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jon Portnoy wrote: I hate to be the bearer of bad news Somehow, I doubt that... ;) but that's because you don't realize how many devs are sitting back and giggling at this thread 8) I didn't realize you got together with other devs for giggle fests! ;) You've pretty much hijacked this thread to rant and rave about QA; we're already aware of QA problems, And yet I see scarce few ideas on how to solve the problem. The only other person who seems to have any are Ciaran, and what is his solution? He's doing *code reviews* of ebuilds. *GASP* Imagine that! the reason nobody is listening to you in this thread is not that nobody cares, it's that your ideas (well.. I guess I've mostly only seen one..) have not been practical or useful for reasons already explained. The only reason I've seen, besides I don't wanna and how dare you question my l33t code skills, is the manpower/time issue. But my work experience tells me that the sooner you find a bug, the easier/faster it is to squash. So although my little idea *will* take time up front, it has the /potential/ to save much more time later on. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDCIAX2QTTR4CNEQARAuOlAKCH97nGjDuI4VJnhIqNqeqARK9P5gCbBi5w nsTXa8Du1uQvqnlQhqTUBNo= =GZAK -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Bugzilla handling for maintainer-wanted things
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dan Meltzer wrote: This time I'll say something useful :) Nathan, you seem to be misunderstanding open source. You get the I can ask for features or suggest things part, but not that I can add features or do things part. No one is stopping you, or me, or an average joe, or George W. Bush, from peer reviewing. You can see the basic things that are commonly wrong by looking at a few resolvedwontfix bugs with ciaranm as the commenter. Most make the same mistakes. After seeing this, what is to stop you from either manually looking through the tree, or writing a script to check for you, and fixing some of the problems, submitting them as bugs when they are fixed. No, I understand what you're saying completely. I've been using F/OSS for about 10 years now, and I've been an engineer/programmer for about 5 of those. So I know a little bit about both sides of the story. And I've actually submitted an ebuild for thunderbird (although it was really just an integration job of a couple of existing versions), so I'm certainly not unwilling to get my hands dirty. I cannot imagine any developer would say no to a well written ebuild, they may wait for a version bump to switch to it, but they most likely would not ignore it all together. Hell, maybe if you do a good enough job, and show enough devotion, the gentoo guru's will even think about making you a developer in charge of fixing those things. who knows? My experience with Gentoo is that certain developers ignore user submitted ebuilds, bugs fixes, etc. and claim its a manpower/time issue. Yet they fail to court the user submitting the ebuild into becoming a developer too (thus helping relieve the manpower/time issue). And this isn't me wanting to get noticed, mind you; I'm talking about other users who regularly submit ebuilds and get ignored. So you end up with the in crowd capable of making Gentoo better and the rest forced to either fork or just go away. Chris even told Ciaran to not look at a user submitted ebuild because it was the games group's territory. Yet the games group 'FAQ' complains about how little time all of those dev's have. Wouldn't it make more sense to recruit those folks and make your team more capable of handling the load? THERE is your cathedral. And again, thats just one example and not indicative of the entire Gentoo dev team (or the entire games team for that matter). -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDCIW92QTTR4CNEQARAvPuAJwPipryDRbAo/j7IrZCfavIbUP8HQCgglUt j51c5mPa0SyDZezeGg+FJJ0= =rHOS -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Bugzilla handling for maintainer-wanted things
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Henrik Brix Andersen wrote: And - as I told you the last time you brought this issue up - you're more than welcome to start reviewing ebuilds and commits as well. I'm starting to do just that. I've even asked Ciaran to review a particular ebuild I was interested in so that I could learn from it. We have a bugzilla which is open to the public, we have an irc channel [1] (which is even monitored by CIA [2]) for tracking all commits made to the portage tree... what more do you want? That is handy, thanks. I don't see the IRC channel listed here: http://www.gentoo.org/main/en/irc.xml So I've emailed [EMAIL PROTECTED] and asked to have it added. :) If you so desperately want code review in Gentoo, why don't you do what every other open source software developer has to do to get his ideas through: put some work into it yourself? See above. I've been wondering: do your emails on this list represent the view of the IEEE organization? Of course not. But the IEEE *is* all about peer review (as all scientists have been for the last few hundred years). And here is a nice high-level article about the benefits of peer review while developing software for the non-believers :) http://www.visibleprogress.com/peer_reviews.htm -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDCItE2QTTR4CNEQARAtWfAJoDGYt/o6afKSL/7VCxFuAJNYZfHQCgp9N0 K9f5keHUSdyd5nat4rit6EM= =kXk/ -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: Most common ebuild mistakes?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Luca Barbato wrote: http://dev.gentoo.org/~plasmaroo/devmanual/ Thanks, I've been wondering where Ciaran's docs went. :) Now, there one question that I won't be able to answer for myself anytime soon: What are the most common ebuild mistakes? A script will never be a substitute for good peer review, but it can easily detect (and even correct in some cases) common syntax errors. So I'm looking for a list of things like under-quoting variables, improper spacing, etc. Thanks, Nathan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDCUJC2QTTR4CNEQARAholAKCrS2DZpMEUZH12F1agJ0/Y8nxzOQCfZctd ZMWBprkt1Nq+Zf9JaXVLhLU= =7Bbv -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Most common ebuild mistakes?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Donnie Berkholz wrote: Nathan L. Adams wrote: | What are the most common ebuild mistakes? http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2chap=3 Thanks everyone. I'll bug each of you individually if I need clarification. Nathan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDCVEa2QTTR4CNEQARApI1AJ4k5sKZN99EkEDwpPPcPQRB6ALFeQCeLmTB g3cJhP7sP0CTpM4DsTxVzgo= =3rMv -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] tentative x86 arch team glep
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kevin F. Quinn wrote: Well, it strikes me that most if not all of the organisational questions are not relevant to a tester; the only technical question that is relevant is 9 (keyword marking), and even that would be reworded for the tester perspective. The main point being that a tester can be a willing user, with no dev capabilities at all; the ebuild quiz is written for a different target group. In fact, it's useful if testers are not developers, as devs often make assumptions without realising it. I guess it comes down to what you want a tester to do. In my mind, the task of a tester is to emerge the package normally, record the use flag configuration, and exercise the application as much as possible. Possibly repeating with other use flag configurations. If you want testers to do ebuild QA, then the ebuild quiz becomes relevant, but I don't think it's a good idea.. In my professional work, the pecking order is like this: developer -- integration/test -- system design -- management Of course, some of the developers I work with may disagree. ;) But the point is that the integration/test team knows about development; it just makes sense. The integration/test team needs to know a good deal about development *and* the overall system design to be affective. So I would say have all arch-testers take both the ebuild quiz and the newer QA/testing quiz. I suppose you could be more lax about scoring if you're really worried about not getting a large enough pool of testers. And I'm not arguing that an arch tester has to become a developer first; I'm just making the point that a good tester has the ability to switch back and forth between the 'big picture' and the 'bit level'. If you want fancy terminology, the testers need to know how to test the interfaces (in this case the portage API, probably by code walk throughs), and functional threads (you gave a great example, 'emerge the package normally, record the use flag configuration, and exercise the application'). Nathan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDHF2E2QTTR4CNEQARArbJAKCEZ7K6HiTFKpVy9mEVkaTU9TFUvQCeLlLE l8v1xMYUtLLa4cvF5meZyJo= =W6Sq -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] tentative x86 arch team glep
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tom Martin wrote: I'm not sure I like this. I think it would be too slow. I'd rather have a concept of maintainer arch (the reason I still like the old keyword ordering, because there was at least *some* idea of maintainer arch. In fact, I used to fiddle the keywords every now and again when I took over a package and the maintainer arch changed). Policy, for a long time, has been that no arch team should go stable ahead of a package maintainer without his approval. This works fine. Now, some packages are going into Portage without the x86 keyword (for example, viewglob, which I recently committed. I don't have an x86 machine) and a non-x86 maintainer. All that we need is an x86 arch team to do the same jobs as other architectures: a) Test packages that aren't yet keyworded. b) Keep keywords up-to-date -- imlate. Although imlate currently compares against x86 by default, scanning x86 against a few other archs isn't a major bottleneck. c) Keep up with security bugs, with a proper security contact. Tester, I believe you're filling this role at the moment? d) Possibly arch testers. Maybe I'm seeing this all wrong, but the fact is, the number of packages that need x86 arch team lovin' are pretty small, despite the number of overall keyworded packages being large. I don't think the x86 arch team needs to be very large: I think ten developers is plenty. I just don't know what they'd be doing if there were more. Thoughts? I took Kevin's 2) to mean that the arch team *developers* wouldn't do the actual testing; the arch team testers (a sub-group of the arch team) would do the testing. Is that correct? b) You could have imlate compare against the new -maint ~maint maint keywords (or whatever gets settled on). Having the 'maint' keyword would help with the 'no arch team should go stable ahead of a package maintainer without his approval' policy. I would structure it like this: i. Package maintainers control the 'maint' keyword. ii. Arch teams control their respective 'arch' keywords, but do not go stable before 'maint'. iii. Package maintainers could optionally keyword their packages as ~arch for their 'native platform'. That should keep the responsibilities clear and things moving, correct? Rule iii would also give you the same functionality as the maintainer arch without having the cludge keyword ordering. Nathan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDHF/A2QTTR4CNEQARAkqkAJ9/zn7Sa/Bj+H5ZKuWSyVl6RNeiVwCfQa+0 oH0hUWT025XDS8aEhrc9Cvg= =bSCC -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] tentative x86 arch team glep
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kevin F. Quinn wrote: On 5/9/2005 13:41:54, Jason Stubbs ([EMAIL PROTECTED]) wrote: On Monday 05 September 2005 20:21, Simon Stelling wrote: Ciaran McCreesh wrote: If it isn't fit to be marked stable, it shouldn't be out of package.mask. ~arch means candidate for going stable after more testing, not might work. It's a bit of both. When you put a package into ~arch, it's in testing, so that says it needs further testing since there still could be a not yet discovered bug, right? Testing of the ebuild rather than of the package, though. This is the point where people sometimes get confused. That'd be me then :) So we're talking about correctness of ebuilds (correct dependencies, use flag logic etc) and not whether the package actually works in depth. The latter is what caused me to suggest drawing together a large team of user-testers managed by arch-team devs. Correctness of ebuilds takes us back to a dev role and the ebuild quiz, since it's necessary to understand ebuilds to criticise them. After a rather heated discussion a while back, I came up with this definition: - -arch :: the end-user software is/might be flakey ~arch :: the ebuild is/might be flakey but the software is good arch :: its all good :) Nathan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDHGCN2QTTR4CNEQARAiVdAJ9wVLt5CPyW//qxmuSC3GlZSOaI+QCeLqEl 78TX1Xtvbx7E4lBEdwnxMus= =T6ZT -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] local USE flag gimp for xsane
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Patrick Kursawe wrote: Hi all, I am going to add a local USE flag gimp to xsane which triggers building of xsane as a plugin for the GIMP. Bye, Patrick Or how about an xsane flag for GIMP that makes the xsane plugin a dependency. :) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDHGGb2QTTR4CNEQARAlrdAJ47eocHenP9ioHN8/uK04o6OZ2SvACfUFeB E37Fdpcs+IeNpWvk+aXXDzw= =5G+8 -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] ROX: maintainer-wanted and apps out of date
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: And as for taking it as a PISSOFF... We've had exactly one person do that so far. All the rest of the feedback we receive -- which is a heck of a lot -- is of the thanks for the pointers, please could someone check this updated ebuild? and occasionally could you clarify $blah for me please? variety. My first inclination is to take WONTFIX as PISSOFF, and I even read the previous thread in question. :) I humbly suggest adding a REVIEWED and/or NEEDSWORK keyword and leaving the bug in the OPEN or ASSIGNED state. But adding the comments (with pointers to more in-depth explanations) is a great idea, especially if you present them in a cordial way: Thanks for helping Gentoo! The ebuild you submitted isn't quite ready, so here is what one needs to do to get it in the tree: link1 link2 Thanks again! Which is probably what you're doing already. :) As for missing/AWOL developers, and for developer/user problem resolution, I *think* devrel handles that: http://www.gentoo.org/proj/en/devrel/ Nathan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDJhs02QTTR4CNEQARApZsAJ9+KRCAsawb5/fVD8FFpTO0d2TitACgmqH2 OI1jP3uv+/Ll7qHOawzqowo= =VPCh -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo Council meeting, Thursday 15th, 1900 UTC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Frysinger wrote: right ... once a GLEP has been hammered out and approved, there isnt really anything left for managers/council to do ... it's then up to whoever to get it done ;) They *could* do some 'creative re-org' a.k.a. remove some folks from their current roles if they are willfully breaking the rules... -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDJltI2QTTR4CNEQARAlYeAJ4sPX/5chqU+OQ+6mRR3ttcg2KVjwCfb4Ip RPvewdjAs7v5EjyC9GeOZGY= =J86n -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo Council meeting, Thursday 15th, 1900 UTC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Frysinger wrote: if you read this whole thread you'll find that it is a grey area with different devrel people saying/thinking different things in terms of what devrel's responsibilities are It sounds like somebody needs to take a look at all of the existing documentation for this topic, write a GLEP that clarifies the matter, and present it to the council for a vote. - - who should enforce Gentoo policy (technical or otherwise)? - - what are the procedures for getting the enforcement done? - - what checks and balances are in place (and are more/clarification needed)? - - etc. Nathan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDJ4k22QTTR4CNEQARAvbbAJwNtqXM9L9ycyCqmQoJrelYeNnE0wCgoRit 4mUsp/yONu4TfTAV5GVxSKk= =Mflu -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo Council meeting, Thursday 15th, 1900 UTC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Frysinger wrote: GLEP's are developed after the details are ironed out in public developer forums ... their purpose isnt to fast track changes through the Gentoo council to kill long threads not saying that is what you meant, just making sure everyone is on the same track ;) I wasn't suggesting fast tracking or killing long threads; but I think it would be easier for you dev types to iron out the details if you had a draft GLEP to target your flames... er... 'discussion' at. ;) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDJ4yV2QTTR4CNEQARAnpbAJ4s4P38g40LliScob4ovFs+DphBYwCfRzbE Tz1G1kRKPr73KpChE96ZvIQ= =IVUR -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo Council meeting, Thursday 15th, 1900 UTC
Jon Portnoy wrote: Sounds to me more like people who aren't familiar with the internal structure of Gentoo don't need to be the peanut gallery when it comes to internal structural issues, but that's just me 8) It sounds to me like those 'more familiar with the internal structure Gentoo' haven't done so well on this issue. Maybe a little *more* peanut gallery would do some good. 8) Seriously, don't knock an idea simply because it doesn't come from somebody in your chosen circle, or because it comes from somebody you don't like personally... As far as devrel goes, call me a traditionalist but I think while infra should be able to do emergency deactivations (and afaik nobody's ever said they shouldn't) devrel should continue to be responsible for disciplinary issues including repeated QA violations reported by the QA team What about giving QA temporary revoke powers just like infra (Curtis Napier's idea), traditionalist? Fixing devrel's resolutions policies and Curtis' idea don't have to be mutually-exclusive. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo alt-projects meeting 9/26 1900 UTC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kito wrote: Greetings, On behalf of the g/fbsd and macos teams, I'd like to call a meeting for all members of the gentoo-alt projects (and anyone else who would like to attend) on Monday September 26 at 19:00 UTC. Items on the Agenda so far: * Naming and categorization of alt-arch system packages * Merging patches in the main tree * Additional Repoman checks (cp -[a,d], /bin/false, etc.) * Project page content (tech notes, tasks data, active devs, etc) * Portage rewrite - alternate prefix installs(!), moving/adding platform dependent code to loadable modules * Alt-project roadmap I'm writing a tool, called esyntaxer, that finds certain common ebuild errors and automagically corrects them if possible. Yes, I'm aware of the overlaps with repoman, and no this isn't a duplication of work. Anyhow, I would be very keen on any ideas you may have for checks that can be added to esyntaxer that would make ebuilds more agreeable on 'alternate' platforms. Any suggestions, feedback, etc are greatly appreciated. Thanks, Nathan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDKgoo2QTTR4CNEQARAtqxAJ0VFFq6m7vn0Z1VF88pUHZqc4SkzgCeIyxG uralm8EaACd5FLYiMxo5Tr4= =1oix -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo alt-projects meeting 9/26 1900 UTC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Diego 'Flameeyes' Pettenò wrote: I don't trust automatic correction, false positives can always happen, currently my way to proceed with such problems is opening a big bug and poking maintainers to fix them :) The esyntaxer tool will warn and/OR autocorrect; user's choice. The warnings are intended to teach (by pointing to documentation) rather than just moaning and groaning. And while I'll agree that there are always edge cases and autocorrection will never be 100%, I must say that the kinds of errors I'm correcting aren't that hard. Besides, esyntaxer isn't something your run and forget; it is *not* a replacement for peer review by good ole' humans. :) Nathan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDK1b12QTTR4CNEQARAmMkAJ0QSZ+p1SoImPQEIRzM3iq5BwaxtACgghKH ReLKbUMlgPNGIch77olSWvQ= =2OgF -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Getting Important Updates To Users
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Gianelloni wrote: On Mon, 2005-10-31 at 01:42 +, Stuart Herbert wrote: There is *only one time* we can guarantee that we'll have a user's attention. That's right after the message that tells a user how many CONFIG_PROTECT files they need to fix by running etc-update. I definitely like the --news idea. Some of those who hold the keys to those places have actively resisted this in the past. Personally, I don't think the front page or gentoo-announce will reach many more users than the Forums et al already do. Well, I think that if users knew that information would be on these places, they might actually check them. Currently, little to no information ever makes it to either of these locations, so users never bother to check them. If we were to change that, I'm sure users would eventually pick up on the fact. How about http://errata.gentoo.org/ for all technical announcements. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDZr902QTTR4CNEQARAuTgAKCbNlY5EN3JQ1AY49Zsri9W+tOKGgCcCQNO 9mPnHCY7CNlbL1uA7Gh8cN0= =ptIr -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP ??: Critical News Reporting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: [a reply] 1. Store the actual guides as GuideXML at a central place such as http://errata.gentoo.org/ 2. Write a simple 'publishing' tool that extracts a summary and a link. This is what gets pumped into portage and shown during an # emerge --news 3. Rejoice. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDahaE2QTTR4CNEQARAmzbAJ9G3UdKnSJ1ze+KMD4jMnr7I91fMwCgm29P 1prgiQtmdk6F6qSgngCyfWY= =P03X -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP ??: Critical News Reporting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: On Thu, 03 Nov 2005 08:49:42 -0500 Nathan L. Adams [EMAIL PROTECTED] wrote: | 6. Ciaran is completely biased against XML (or anything that isn't | stored as a simple flat file) ;) It's not bias. I give XML exactly what it deserves. SGML is a giant fire breathing stomping monster useful for crushing Tokyo. XML is the spawn of said giant fire breathing stomping monster that's had its claws and teeth removed, its jaws glued shut, its legs chained together and its tail nailed to the ground. And we're not trying to destroy any large cities here... rant You're just missing the fact that a flat file (or whatever it is you're clinging to; for the purpose of this rant, I shall refer to your simple data format as flat file) has trade-offs, just like XML's trade off is parsing overhead. XML was designed to solve certain problems; portability of data, separation and portability of presentation from the data, etc. Complexity in the parser is the trade-off. Flat files can be great in certain situations. Flat files do indeed make the parsing trivial. However SIMPLE CODE ISN'T ALWAYS THE MOST IMPORTANT REQUIREMENT. In the case of this GLEP, the most important requirement is getting the proper migration info to the users in the best possible way. So what are the trade-offs of the 'flat file'? If you store a migration guide as a 'flat file', its not going to be very readable. I would certainly rather read info in GuideXML than some garbage output by einfo or the like (and I'm talking about the same exact data, just a different presentation). You're being daft if you say that your average terminal output is easier to read and understand than the same data in proper GuideXML format. OK, you say, you have a point there. But, you say, my flat file allows me to write a 'presentation' proggy in relatively few lines of trivial code. Yes, but now you have to write a new presentation program for every type of presentation you want to do. Or worse you would imbed the presentation in the data itself and make a new copy of the data every time you want to present it differently. But, you say, don't you have to do that with XML (i.e. a new style sheet definition for each presentation)? Sure, but I don't have to re-write firefox in the process... So the point is that, yes, XML has a down side. But plain text, CSV files, whatever have their downsides too. And the point of this GLEP shouldn't be to push any XML-bashing agenda, it should be to present the user with the migration guide in the best possible way. GuideXML is the standard for Gentoo docs for some damn good reasons! /rant Nathan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDaqt52QTTR4CNEQARAoQ1AJ42ItHkJ37eFUY8rSoGpN/dVoKIFACeJi7b KW6/pzn8VEKi3hO0Gqomsms= =cSQh -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP ??: Critical News Reporting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: On Tue, 1 Nov 2005 14:32:47 +0100 Jakub Moc [EMAIL PROTECTED] wrote: | What do you mean they aren't tied to ebuilds? I don't really | understand what this feature should do then, it seems. Once again, | what's wrong with reusing emerge --changelog mechanism for displaying | this kind of information? We make changes that have scope other than ebuilds. | I'm not particularly happy with idea of emerge as a newsreader | really, IMHO we should display relevant, vital upgrading information | *when relevant*, not to inform users about upgrades that they are not | interested in in the least. Which is what my proposed GLEP does, at least as far as we can determine automatically. Yes, occasionally this will mean giving, say, mysql 4.1 upgrade instructions to people who plan to use only mysql 4.0, but then, if we didn't give them the news, most of them wouldn't know that they don't want to upgrade. And it doesn't turn emerge into a news reader. All portage does is deliver the news. How said news is read is a different issue. | And please, keep the thing simple so that I can be done in reasonable | amount of time and does not follow the destiny of einfo/ewarn logging | (3 years and counting). Of course. Hence why I'm proposing something easy and workable, and not suggesting some magic new framework that will solve all existing problems (including world peace). Just keep in mind that portage is supposed to be non-interactive and most users like it that way. (Although the countdown when cleaning out old packages kinda breaks that idea, but I digress.) So just make sure that the scheme doesn't involve forcing the user to notice anything during a 'normal' non-interactive emerge in order for it to be effective. Thats why I keep pushing having a nice GuideXML version in a central location like http://errata.g.o/ and just having emerge output a summary and a link (however/at what point/with what mechanism you decide to actually have portage output it). -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDaq8U2QTTR4CNEQARAm6kAJ948WBp0elnZvxoHLMXvNfaBZvxsgCdEdAO gO6VPobgKHfqcKpjAQ1II6U= =iNoA -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP ??: Critical News Reporting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Gianelloni wrote: On Tue, 2005-11-01 at 12:26 +, Ciaran McCreesh wrote: On Tue, 01 Nov 2005 13:16:03 +0100 Thierry Carrez [EMAIL PROTECTED] wrote: | For them to know about it, they need to be warned when they do their | emerge -p world or emerge -a mysql that the upgrade is not as easy | as it seems. People using a cron job to sync are probably a | significant part of our user base... Have Portage give a red flashy before emerge if there're unread news items? Or have it die unless they have I_LIKE_A_BROKEN_SYSTEM_PLEASE_IGNORE_NEWS=yes in make.conf ;] Although, a better solution for users who cron sync would be to have said cron mail them all the relevant news files... We don't have control over what they do in cron, we do have control over portage itself. The cron thing is a *really* good idea. Its so good that its an example in the Gentoo Cron How-to. A few developers actively debugging the sync process might enjoy watching the output of a sync scroll by, but normal/sane people have better things to do. (Note: I'm not bashing Chris's statement here; I honestly don't know what point he was trying to make). So don't implement the --news thing in such a way that in the future a developer might be tempted to tell a complaining user whats the matter with you? don't you read the output when you sync? no? what a loser; no wonder your system is b0rked. (or something to that effect) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDarFQ2QTTR4CNEQARAgWDAJ0cW1xpOKCy+jjaYCoGBbfOOXSGwwCgojNk flBm0MnXXXRLsBGC3XXcYts= =1Ls9 -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP ??: Critical News Reporting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: On Thu, 03 Nov 2005 19:29:45 -0500 Nathan L. Adams [EMAIL PROTECTED] wrote: | Flat files can be great in certain situations. Flat files do indeed | make the parsing trivial. However SIMPLE CODE ISN'T ALWAYS THE MOST | IMPORTANT REQUIREMENT. In the case of this GLEP, the most important | requirement is getting the proper migration info to the users in the | best possible way. Read the list of requirements in the GLEP. The plain text solution meets all of them. XML fails on several. If readability isn't a requirement, your list is wrong. And, incidentally, I came up with the requirements list *before* dismissing XML. Given your past public statement about XML; I highly doubt that. Whether you were concious of it or not, I suspect that XML bashing was always in the mix. | So what are the trade-offs of the 'flat file'? If you store a | migration guide as a 'flat file', its not going to be very readable. Who said anything about storing a migration guide as a flat file? Read the GLEP. No, *you* need to read my previous response. I was using 'flat file' to mean whatever it is you're calling your less-than-GuideXML scheme. | GuideXML is the standard for Gentoo docs for some damn good reasons! No, it's the standard because Daniel said so. And the reasons behind which web publishing setup we use have little relation to good reasons for a news delivery system. Why do you think we still send email in plain text? Why do you think news is sent as an RSS feed? Answer: Because it has proven to be the best way! *shrug* Anyway, if you want to come up with an alternate GLEP based around XML, bittorrent, Java and CORBA, go right ahead. I never mentioned bittorrent, Java, or CORBA. If you don't have a valid arguement, please don't try to distract everyone by putting words into the mouths of those you're arguing with. The GLEP system is quite happy with handling multiple competing proposals for a given topic, and at the end of it we can select the best proposal, reject all the proposals or go and come up with a new proposal with bits from both. So if you didn't want people to actually review and comment on *your* GLEP, why did you write: The attached GLEP is a draft proposal for the emerge --news thing that's been under discussion. There are still some TODO items. These are calls for people to weigh in with suggestions. Of course, suggestions on other items are good too... -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDarNC2QTTR4CNEQARAkvgAJ91X9MQyPVLE20VPYhAVq5O36jV3gCeI/nY swzdhW0+/C84vVN9UQ8aes4= =DiXn -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP ??: Critical News Reporting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: On Thu, 03 Nov 2005 19:45:08 -0500 Nathan L. Adams [EMAIL PROTECTED] wrote: | Just keep in mind that portage is supposed to be non-interactive and | most users like it that way. (Although the countdown when cleaning out | old packages kinda breaks that idea, but I digress.) You really should give the GLEP a read. It's quite nice, you know... Your explanations hint at interacting with portage during an emerge. Specifically you floated the idea of having emerge print a red flashy message before doing the emerge. *That* is what I was commenting on. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDarPp2QTTR4CNEQARAkkbAKCn8yDt7D17Ls+/huZkg4TkKjmXVwCgntbs BrrWIziJCF2M8RckaINyMNA= =Ytle -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42 (Was: Getting Important Updates To Users)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stuart Herbert wrote: On Tue, 2005-11-01 at 14:51 -0500, Chris Gianelloni wrote: Did you specifically ask them if it is because we have different news in different locations? Somehow I think you're obscuring some facts to make your own argument. That seems an unpleasant accusation to make :( The answer is that I didn't ask them if it was because we have different news in different locations. The question didn't occur to me. The only problem that we have now with our multiple mediums is that not all news is on all mediums. We should have the same information going to all of these and let the user choose which method they like for getting news. The critical difference between improving our existing mediums, and the emerge --news approach that I've proposed, is that emerge --news is the only approach that actively pushes news out to *all* users, and puts it in a place that is as guaranteed as anything else available to catch their attention. All the other approaches rely on the user going somewhere to get news, whether it's signing up to a mailing list, reading www.g.o, reading the forums, or whatever. Inevitably, this is only going to reach a smaller subsection of our user community. What I care about is that we've taken the right steps to put important information in front of *all* of our users (and our devs!). Even (especially?) the ones who are unable to keep up with the news as it is currently delivered. Making sure our users are well-informed improves the level and quality of service that we provide; it can only enhance our reputation; and it should also cut down on the amount of developer time that goes into post-upgrade support (leaving more time for package maintenance). One source: http://errata.gentoo.org/ Push that out to as many alternate sources as you like (RSS feeds, summaries in emerge --news, forums post, etc.), but make it known that the website is *the* source (your alternate sources should point back to it). -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDarUL2QTTR4CNEQARAh0pAKCi7BJpBOkRRT4iiaXUjajwbrjseACfahPV R2MVvKhkLfnid1/ADRUZAxk= =Oou4 -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP ??: Critical News Reporting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: On Thu, 03 Nov 2005 20:02:58 -0500 Nathan L. Adams [EMAIL PROTECTED] wrote: | So if you didn't want people to actually review and comment on *your* | GLEP, why did you write: | | The attached GLEP is a draft proposal for the emerge --news thing | that's been under discussion. There are still some TODO items. These | are calls for people to weigh in with suggestions. Of course, | suggestions on other items are good too... I want people to review and comment on it after they've actually read the thing. I have read it, and I find it lacking; thus the comments. Or are you claiming that the idea of having a central website like errata.g.o with GuideXML-ized migrations guides is in your GLEP? Its not. I'm proposing adding that as the definative source of the errata, and feeding it to other places (emerge --news, mailing lists, forums, GWN) as desired. I'm also commenting on the part that *wrongly* states It is not reasonable to expect all users to have an MTA, *web browser*, email client, cron daemon or text processing suite available on their system. In particular, this means that any markup to be parsed must be in a very simple format. *ALL* of the official docs are GuideXML; Gentoo *expects* users to have a web browser by default. Otherwise a vast majority of users would never get Gentoo installed in the first place. The lightweight requirement appears to just be your way of subverting the current documentation standards (because of your XML hatred). The news directory shouldn't the main source of the migration guides; the website should be (one central page that can feed other sources). -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDarhL2QTTR4CNEQARAr+KAJ9v5iy+i5tvqNx9woib/cJUZI+eMwCgohIo acuUUmVYcI1TsBDX0dg/K0s= =bWEF -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP ??: Critical News Reporting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: On Thu, 03 Nov 2005 20:05:45 -0500 Nathan L. Adams [EMAIL PROTECTED] wrote: | Ciaran McCreesh wrote: | On Thu, 03 Nov 2005 19:45:08 -0500 Nathan L. Adams | [EMAIL PROTECTED] | wrote: | | Just keep in mind that portage is supposed to be non-interactive | | and most users like it that way. (Although the countdown when | | cleaning out old packages kinda breaks that idea, but I digress.) | | You really should give the GLEP a read. It's quite nice, you know... | | | Your explanations hint at interacting with portage during an emerge. | Specifically you floated the idea of having emerge print a red flashy | message before doing the emerge. *That* is what I was commenting on. Ever noticed any of the other red flashies that emerge gives? For example, if you try emerge -C glibc? Doesn't break the non-interactive requirement, it's just yet another way of shoving something in the user's face if they somehow ignore all the normal warnings. Yes, I've noticed them. My point is that you need to be careful that the red-flashy doesn't the primary way of delivering the message. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDarid2QTTR4CNEQARAq+gAKCZ0e1kZHeuYvQcjqxKwTZ+XsbXRACgh2ef gSZ1q0Of1t6SA6u5oMQkp5c= =oKCA -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP ??: Critical News Reporting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: On Thu, 03 Nov 2005 20:24:27 -0500 Nathan L. Adams [EMAIL PROTECTED] wrote: | I'm also commenting on the part that *wrongly* states It is not | reasonable to expect all users to have an MTA, *web browser*, email | client, cron daemon or text processing suite available on their | system. In particular, this means that any markup to be parsed must | be in a very simple format. | | *ALL* of the official docs are GuideXML; Gentoo *expects* users to | have a web browser by default. Otherwise a vast majority of users | would never get Gentoo installed in the first place. The | lightweight requirement appears to just be your way of subverting | the current documentation standards (because of your XML hatred). I don't have a web browser installed on my server. Do you? So you installed your server without reading *any* documenation? (Don't lie). And you expect that the average user installs a Gentoo server without at least referencing the documentation? Pa-leaze. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDarsD2QTTR4CNEQARAuZhAJ49FHBjVbDQbC6+nyBIw6wRjLZE+QCeO/yW dPY2A20OJcwJ/NTOwZqg434= =SPIh -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP ??: Critical News Reporting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian Harring wrote: Not necessarily the website imo, some central store where it's pushed out to all of the locations though (which I suspect you're getting at). I forgot to clarify one point. I'm saying that http://errata.g.o/ should be the *official* source where users go to find the info, not neccessarity the place where the raw data is stored and pushed to other places (although it certainly could be). -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDarzS2QTTR4CNEQARAlB7AJsHfqCVL160KApWZU7iuqNtCb9SWwCcCtRR D2e1H1U208kQQNzLDo9CpGk= =kiyo -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP ??: Critical News Reporting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephen P. Becker wrote: *ALL* of the official docs are GuideXML; Gentoo *expects* users to have a web browser by default. Otherwise a vast majority of users would never get Gentoo installed in the first place. The lightweight requirement appears to just be your way of subverting the current documentation standards (because of your XML hatred). How about getting some facts straight before running your mouth? Gentoo most certainly does not expect users to have a web browser to install. The last time I actually installed on x86 (which was some time ago admittedly), there was a .txt version of the install guide on the livecd. Even then, the web browser you are speaking of runs directly off the livecd. So, what happens when there is critical news to be read during the install phase inside the chroot, but no web browser is yet installed? Are you suggesting we bloat stage1 and stage2 with some sort of XML parser so that the user can read news without having to kill the emerge and read the news outside the chroot? I think you would have a seriously hard time convincing the release folks this is a good idea. Furthermore, it is not possible to include any sort of XML parser with installers for certain arches which use very minimal netboots for the default installation method. So really, your complaints about the lightweight requirement appears to just be a way of subverting attention away from the real reasons it is a good idea, and towards maintaining a flamewar with ciaran that you will surely lose. Let me say it one more time. I'm not saying you have to have a web browser installed on the system that you are updating or installing. I'm saying that the GuideXML docs are the standard, official source of documentation and the same should hold true for the migration guides. I'm also saying that feedback from users said they want ONE official place to find this stuff. Therefor any plan that doesn't take both of those things into account is silly. And having the GuideXML-ized guides on a central website marked as the 'official-one-stop-for-errata' does not in any way shape or form preclude anyone from mirroring that info in a text file, forum post, emerge --news, mailing list, etc. etc. ad nauseum. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDar7y2QTTR4CNEQARAkK2AJ9W+uofXxiuNc86gzsfHISvD7XkPgCeMeue kDgucVFWYYLAb74WbcLQWpM= =6A4p -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP ??: Critical News Reporting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephen P. Becker wrote: So you installed your server without reading *any* documenation? (Don't lie). And you expect that the average user installs a Gentoo server without at least referencing the documentation? Pa-leaze. Funny, I've done three fresh installs on my various mips machines in the past couple of weeks, and I didn't read even a word of documentation to do it. Besides, if somebody is installing gentoo on a server, do you really think that would be their only box? Surely they have a workstation of some sort, since a proper server certainly would not be also used as a desktop. And therefore they would have a access to a web browser. Thank you for helping to explain my point. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDar8m2QTTR4CNEQARAvlAAJ9cXIqGHzojBSkz6XEACuXefbBE1ACaAsE2 p2wxad72pF3iHPAf+LU2x7s= =z0nr -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP ??: Critical News Reporting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: On Thu, 03 Nov 2005 20:36:03 -0500 Nathan L. Adams [EMAIL PROTECTED] wrote: | So you installed your server without reading *any* documenation? Actually, yes, I did. I can quite easily do installs without the documentation, as can most other people who really know how Gentoo works. And as a long time developer, I'm sure you represent the typical user... | (Don't lie). And you expect that the average user installs a Gentoo | server without at least referencing the documentation? Pa-leaze. I bet there're lots of people who don't read the documentation using the machine on which they're installing. See above. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDar+G2QTTR4CNEQARAqTdAJ9LT4bx+nrPJpdwpttZaKFoOCVTSgCfYbvy ozqoUGfbXM57FLxBMYp9UWg= =Alrz -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP ??: Critical News Reporting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lance Albertson wrote: Nathan L. Adams wrote: *ALL* of the official docs are GuideXML; Gentoo *expects* users to have a web browser by default. Otherwise a vast majority of users would never get Gentoo installed in the first place. The lightweight requirement appears to just be your way of subverting the current documentation standards (because of your XML hatred). Since when did GuideXML become the standard for all our websites? Currently, the only website that uses it is www. Nothing else uses it. If any solution to the errata site idea is going to come out, it doesn't need to be guidexml, it can be anything. http://www.gentoo.org/proj/en/gdp/doc/doc-policy.xml#doc_chap3 However, when the document is finished, it should be transformed into GuideXML and made available on the Gentoo CVS infrastructure. It must also be registered in the metadoc.xml file if applicable. I never said all [Gentoo] website; just documentation. Errata is documentation. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDavH02QTTR4CNEQARAryaAJkB4DCRYSxwrskI20hzqkC7nmcmggCgpkUu TaEAOVda9tjLj1CQZK1YIkg= =FO5/ -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP ??: Critical News Reporting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Grant Goodyear wrote: Nathan L. Adams wrote: [Thu Nov 03 2005, 07:02:58PM CST] -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: Read the list of requirements in the GLEP. The plain text solution meets all of them. XML fails on several. If readability isn't a requirement, your list is wrong. I would argue that reading raw xml is a lot less fun than reading minimally marked-up plain text (such as an e-mail). Oh good grief! Nobody is arguing that the user should have to read raw XML. | So what are the trade-offs of the 'flat file'? If you store a | migration guide as a 'flat file', its not going to be very readable. Who said anything about storing a migration guide as a flat file? Read the GLEP. No, *you* need to read my previous response. I was using 'flat file' to mean whatever it is you're calling your less-than-GuideXML scheme. *Sigh* I think you might be misinterpreting the GLEP. The news items are likely to be fairly short, such as the YourSQL example that's in the GLEP. The news item would then point to a migration guide that resides elsewhere, if needed. No, I happen to understand the that point. Emerge outputting a short summary is great. But the GLEP should cover the hey mr. end user, the central repository for errata/full fledged migration guides is here: [insert url] as well. The point behind having the news pulled by portage is that the headless server, for example, would only report news items that are relevant to that machine. The server's admin could then fire up a web browser on a desktop machine to read any necessary additional info. Great; I'm not against that. Now where does that admin point her web browser? Mailing list archive? GWN archive? The Forums? The stated feedback is that users what a central place for the errata (whether the errata be large or small). | GuideXML is the standard for Gentoo docs for some damn good reasons! True, but at the same time there's a reason that GLEPs can be written in restructured text as well as guidexml. I doubt that it's accidental that almost all GLEPs have been submitted in restructured text rather than guidexml. (Incidentally, I like our guidexml. I think that it renders quite well for what we want. I'm not so fond of writing it, however.) That's really beside the point, though. The real point is that plain text news items are going to be the easiest to create and the easiest to read on a console screen. As for having an errata page, it wouldn't be difficult to write a program to automatically convert news items to guidexml. I suspect that ciaranm could even be talked into writing it, if such a page were to become reality. I happen to think that the assumption that the errata are going to be small is a bad one. I think if errata is neccessary in the first place then its going to be something larger than a screen's worth of console output and worth the supposed trouble of GuideXML. So why not approach it from the GuideXML end first, and extract the summary from that? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDavVI2QTTR4CNEQARAnMnAKCAir22mvnCgoKXc8xPDIYaQMmReACdELKr aa1l8avqCC7nIvV/VypyJj8= =LxgP -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP ??: Critical News Reporting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul de Vrieze wrote: What is worse is that some users might not update for a prolongued time (6 months). At that time they will not find the information in the erata list anymore. But they will get the RELEVANT news delivered by emerge/enews. Why would a SomeSQL 1.0 to 1.1 guide ever need to dissappear? Surely errata.g.o would have archiving/searching. But I do see your point about emerge filtering out the unwanted stuff. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDa2RQ2QTTR4CNEQARAv0fAKCFOH6RedaYBSG069nX+aAtmQ/YWgCgjVlE RAF3N34PDvrtY88ks3QwRhc= =b+7v -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP ??: Critical News Reporting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thierry Carrez wrote: Paul de Vrieze wrote: Oh god help. This also points to another reason why this is not such a good idea. Writing guideXML is a lot more work than writing an e-mail format file (ciaran's proposed format for those who didn't recognize it). Also having double files containing the same information is broken by design. By the way, we're talking about 1 source file being translated into multiple formats (email for the mailing list, news blurb for GWN, etc), and the idea is far from broken. OK so there is two options : 1- every news requires a GuideXML/RST/whatever errata at a central web location [snip] 2- every news requires just a short text-based item, extra doc is optional Pros: [snip] We can have the best of both worlds if we find a way to reduce the work overhead to 0 (using some kind of news2errataXml translator ?). If we can't, I tend to favor the second solution... This is a wonderful comprimise. And one might even sucker me into helping write the tool. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDa2ZE2QTTR4CNEQARAvNVAJ4+q94QFV+fik4FRCywX1N1Yh1s9QCfab7m trmF40e9e33usGS7EbpMjoQ= =tPJE -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP ??: Critical News Reporting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Gianelloni wrote: On Thu, 2005-11-03 at 20:24 -0500, Nathan L. Adams wrote: *ALL* of the official docs are GuideXML; Gentoo *expects* users to have a web browser by default. Otherwise a vast majority of users would never get Gentoo installed in the first place. The lightweight requirement appears to just be your way of subverting the current documentation standards (because of your XML hatred). *sigh* Then I guess we're wasting our time getting the Handbook converted to plain text for *every* release. It's on the CD itself, have a look. No need for a web browser of any kind. You really need to check your facts before posting. I've done several Gentoo installs and never knew the plain text versions existed. I think you might want to check the assumption that just because they exists they are widely known (and if they aren't known to exist, they don't do squat for the end user). Surely we're not going to delve into an arguement over whether the web is the best way to distribute information... -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDa4U92QTTR4CNEQARAjkzAJ0YS2F/6zWLZeLQ0tbvIYNIqoe1PQCfcV53 bLnhNPoCJDNGrHuIw3pxEEA= =rSj8 -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP ??: Critical News Reporting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Gianelloni wrote: On Thu, 2005-11-03 at 20:36 -0500, Nathan L. Adams wrote: So you installed your server without reading *any* documenation? (Don't lie). And you expect that the average user installs a Gentoo server without at least referencing the documentation? Pa-leaze. less /mnt/cdrom/docs/handbook/txt/install.txt No web browser, so can you please quit beating this dead horse. It isn't even funny anymore. That's a great and wonderful alternative, but the policy is to publish documentation in GuideXML: http://www.gentoo.org/proj/en/gdp/doc/doc-policy.xml#doc_chap3 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDa4a42QTTR4CNEQARAqGnAJ4gfJLCMmK5/tU5lmnszaR1fW1MSQCfTyYK wh/HaL69456P9eOqc7sabDc= =D8T6 -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP ??: Critical News Reporting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Gianelloni wrote: On Fri, 2005-11-04 at 10:58 -0500, Nathan L. Adams wrote: I've done several Gentoo installs and never knew the plain text versions existed. I think you might want to check the assumption that just because they exists they are widely known (and if they aren't known to exist, they don't do squat for the end user). Surely we're not going to delve into an arguement over whether the web is the best way to distribute information... Ehh... It is listed in the MOTD on the installation media. I'm not making any assumptions on this. It's really not our fault when the user base doesn't read what is sitting in front of them, plainly on the screen. Thank you for proving my point. And what point would that be exactly? Console messages are ineffective? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDa5Ls2QTTR4CNEQARAm5NAKCiOQEkK07nz4KFfSY+5uzeUNMN2wCfUe1Q LSTG+k4lWKo6v6Wl1AR+424= =Ar9r -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP ??: Critical News Reporting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Gianelloni wrote: Yeah, see, this is a case where not understanding the structure of Gentoo gives you the wrong impression. The GDP's policy applies to the GDP. That is not a global developer policy of any kind. It is a policy by a project, for that project. If I were, for example, to write up a nice guide for something on the games team and do it all in ASCII art, that policy has no bearing on what I do. If I were to write something for the GDP, then it would. At any rate, that has *zero* bearing on whether or not our update information needs to be written in GuideXML, so there's no point in arguing it with you. So you're saying that Gentoo consists of projects that are completely 'silo'd up' and have no bearing whatsoever on each other. Then the DevRel project only has bearing on those who actually join DevRel. Neat, a group formed for the sole purpose of coordinating itself. Security need only concern itself with securing its members (from who knows what!), and infra can just ignore the needs of everyone else (different project!). I wonder how any of the other projects *ever* made it onto the website... The errata.g.o (not the summaries w/ link that emerge would output) would obviously be documentation, would obviously be governed by the Doc rules, and it would be irrelevant which staff member happened to publish a particular guide. If Gentoo really is as balkanized as you state, then it is a sad state of affairs indeed. Maybe the 'full fledged' versions should be GuideXML-lite or something, I'm not sure, but your argument is just silly. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDa5WH2QTTR4CNEQARAlERAKCeVue4ATD4fXBgLGdRAWt4Gi7vWgCcCs7R w/Pvjk9vv2C00HmrTkhBnHU= =Eiba -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP ??: Critical News Reporting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Grobian wrote: Danny van Dyk wrote: IMHO a text based file has a big advantage in this proposed application over fileformats which use XML: Any administrator can read it with his editor of choice, right from the console. This is an important aspect for sure, but why can't such file be generated from a marked up one? Because the same message will be put in multiple forms (ideally) it is best to have a version with all the required meta-data to generate all the other formats, because if you have to add such meta-data it's usually much worse (= manual or conditional human work). Some people like reading console messages, others plain text mail messages, others want html marked up mail messages, other others like reading an rss-feed, and of course there are people that like to read the full fledged funky marked up with all hyperlinks possible html version on the web. I think the only real importance is that all representations can easily be generated from the original source, be that XML, reStructuredText or any other format. With regard to being it hard to write or not, I think these kind of messages are very well suited for templates, so it is just a matter of filling in the message, which should make the underlying format not so important. Just my €0.02 on the XML vs. plain text discussion. A very good point. You could even offer a web form for those who don't even want to edit the template by hand. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDa5YF2QTTR4CNEQARAly+AKCjnT+yONZPAmTO+cccByWeQcaVsQCfQ4Vb K8Cwc/QQNKxAe/Q0VknIOiU= =2Dow -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
