Re: [gentoo-dev] GLEP ??: Critical News Reporting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lance Albertson wrote: > Nathan L. Adams wrote: > > >>>>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? > > > That you haven't completely read documentation that was right on your > screen. I mean *read*, not glanced. I've finally read through ciaranm's > GLEP and I get the impression you only skimmed through it. I suggest you > stick with exact wording from the GLEP for discussion on this thread > rather than assumptions made on arguments. > > Cheers- > Actually, Lance, I have read it. Where does it say anything about a central web repository for the docs in question? Where does it specify the format of those? It doesn't. It assumes that all Gentoo officially cares about is the emerge --news output. Any external docs can live anywhere in any format. Users have asked for a central location for these documents and the transient nature of your current local portage tree doesn't give that. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDa5cY2QTTR4CNEQARAhBcAJ4oT9Wwf5ohK4prQgDSQNGCKoE3WwCeNCct C16jLYYC4zKemRdzcJFNrr4= =IQ1Y -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
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 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 Xavier Neys wrote: > 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. >> >> >> >> OK so there is two options : >> >> 1- every "news" requires a GuideXML/RST/whatever errata at a central web >> location >> Pros: >> - non-portage user can easily browse errata >> - consistency in documentation >> Cons: >> - work overhead for errata-writing dev >> >> 2- every "news" requires just a short text-based item, extra doc is >> optional >> Pros: >> - flexibility: short news don't require writing extra doc >> - external doc reuse: the documentation referenced in the news item can >> be some upstream upgrade doc when sufficient >> Cons: >> - lack of consistency and difficulty for non-portage users to browse >> >> 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... > > > Both can be done. > Posting news items on our front page can be done today, publishing > upgrade notes can be done today, grouping all upgrade documents in an > upgrade category on the main doc index (docs.gentoo.org) can be done > today, having upgrade.gentoo.org point to it can be done one hour later. > All of the above does not require a single line of code. > > I suppose the news snippets could also be integrated in > packages.gentoo.org, hopefully without requiring too much work. > Great, then I hope that the scope of the GLEP gets expanded to include: - - central website (ugrade.g.o or errata.g.o or whatever) - - external docs follow existing doc policy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDa4d82QTTR4CNEQARApNQAJ9RzRxl1y/KRd/5xhVh0gQuwU4OEQCdFofK pC5D+BbzmgOcSDdW3IookUs= =J44D -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 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 Paul de Vrieze wrote: > On Friday 04 November 2005 14:38, Nathan L. Adams wrote: > >>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. > > > It would be hidden in the forrest. Even if I did a search on SomeSQL, it > might return a number of news items on SomeSQL. That is besides the fact > that I have 737 packages installed. I'm not going to search news on all > of them. Archiving would of course be provided, but searching is not > usefull for updating. You update all 737 packages with each emerge? I don't see any validity in your point; a nice http://errata.g.o/ site with archived guides and search wouldn't preclude 'emerge --news' in any way. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDa4R12QTTR4CNEQARApTFAKCL3rZ88STZtuu1EZUw/iSFf8NJMACfXtHu UyKLcgsYF4+nC+ezKSC4Of8= =a4Ki -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 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 Dan Meltzer wrote: > erm, and how exactly do you propose that the user who > doesn't-read-the-site-because-it-has-no-useful-information-currently > will learn about errata.g.o? If all of the other replicated sources (forums, mailing lists, GWN, etc) and 'emerge --news' link back to errata.g.o, they'll figure it out. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDa2N82QTTR4CNEQARAquRAJ9mKsu0QOubuK/IdSB1eyJakHgl+QCeJQqE qhBjRtcR6zxebGOr1IjNAp4= =LtIp -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 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 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 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 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 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 Brian Harring wrote: > On Thu, Nov 03, 2005 at 08:24:27PM -0500, Nathan L. Adams 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). > > > We actually have links in the base profile iirc, either way, the > example of where this breaks down is headless servers... Actually, a headless server would be administered from a workstation that would actually have a head. (Unless you like the idea of installing things by typing blindly on a keyboard ;)) And as I mentioned in my last reply to Ciaran, I doubt anyone installing a server doesn't have access to the web (another computer for example). And having the GuideXML as the main source does NOT preclude having the other sources (such as emerge --news) for people sitting in the dark. >>The news directory shouldn't the main source of the migration guides; >>the website should be (one central page that can feed other sources). > > 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). If I understand his position correctly, Ciaran doesn't want the GuideXML version at all, which is a supremely stupid idea IMHO. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDarxP2QTTR4CNEQARAvnNAJ4gJb41KcQuE2lsSDoTY4Se9wg+8wCfQKqQ TMwatb4SkjOLfuUJyv7xTf0= =f/nj -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 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: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] 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 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] 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 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 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 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... > 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! 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: > [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 Tue, 1 Nov 2005 17:22:29 +0100 Jan Kundrát <[EMAIL PROTECTED]> wrote: > | What's wrong with XML format similar to the one that is used for our > | GLSAs? > > 1. Portage does not handle XML. Portage will not handle XML in the > near future. > > 2. Many users do not have an XML parser installed. > > 3. The standard Unix tools cannot be used on XML files. > > 4. Bloat. > > 5. XML is merely adding another problem to the one we have already. > 6. Ciaran is completely biased against XML (or anything that isn't stored as a simple flat file) ;) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDahV22QTTR4CNEQARArcBAJ9OKq5xfST4dCq0aUCLYw4DxUXdbQCbBPmD b02OM9czrkinjosTw4zCC5I= =Fr/5 -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Getting Important Updates To Users
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Duncan wrote: > Stuart Herbert posted <[EMAIL PROTECTED]>, > excerpted below, on Mon, 31 Oct 2005 19:05:33 +: > >>The original problem is that GWN, forums, planet.g.o, gentoo-dev - even >>together, we've seen that they just don't reach enough of our user base. >>Aren't we just going to reach the same people by putting more news in >>the same old place? How is that going to reach the people we're not >>reaching today? > > > There is /one/ way to reach /everyone/ doing an upgrade (well, those that > do emerge -a or -p, anyway, and those that don't, well... they apparently > /like/ being left in the dark, and doing perhaps risky upgrades without > knowing what's going on, so let's not disturb their "enjoyment" ). > > That ONE way: Push a "null" portage -rX upgrade to both stable and ~ > versions, the sole purpose of which is to print the *VITALLY* *IMPORTANT* > *ANNOUNCEMENT* as an einfo both after the "upgrade", and as part of the > "portage will stop merging at this point and recalculate" message one gets > with a -p or -a. (For double-sure effect, make the first emerge action > after the upgrade /only/ print the message, doing nothing else. Further > emerges would then go back to normal behavior.) > Cramming this info in portage is stupid, because portage is supposed to be NON-interactive. Does anyone really expect users to sit and stare at the output of a compile (openoffice takes HOURS to compile) waiting for an einfo to pass by? Perhaps printing out an URI after portage is done would be useful: http://errata.g.o/apache-migration.xml Publishing the info on a webpage also allows you to view the info from another computer if you seriously b0rk something during an upgrade. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDahOq2QTTR4CNEQARAg/mAJ9/Lbfpq0McjxI3isOopxLo60q1ugCdH5Ux ++iU1lMgWKCaxgybqQzUdIs= =B+rI -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 Tue, 2005-11-01 at 12:11 +0900, pclouds wrote: > >>Just curious how other distros deliver important news to their users? > > > Red Hat has you subscribe to RHN, which sends you errata based on your > installed configuration. When you add packages via up2date, Red Hat > knows. > > Others just use mailing lists, as far as I know, though I have limited > experience with other distributions. (Slackware, LFS, and RH are it) > Almost all of them publish 'errata'. That is why I suggest a single place for all technical info such as the recent apache upgrade: http://errata.gentoo.org/ i.e. Upgrade/migration stuff would go there as opposed to 'fresh install' stuff (which belongs in the normal docs area). I forget who it was, but one of the folks involved in that said that the users overwhelmingly want a *single* place to look for this type of info. You can repost the summaries elsewhere (via a RSS feed to GWN or the mailing list(s) for example), but there should be one place to get all of the info. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDahHd2QTTR4CNEQARAjDnAJ4zdr9K1OyCq1mcJlzp7G8+dB3c1QCgoERR sYquQPGP2IISj+dW7l9jOy4= =t9oR -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] 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] 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 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 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
-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: > 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] GLEP 41: Making Arch Testers official Gentoo Staff
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephen P. Becker wrote: >> My understanding is that this GLEP is supposed to make AT as good as >> being a dev, but with a different role, one that doesn't need commit >> access. > > > My point exactly! Why have another category? Because their role is *not* to develop, its to *test*. >> If the people involved decide they want to become committing >> devs, it also make it easier to make that transition. If they don't >> want to commit, they can stay as an AT. > > Then shall we reclassify all the developers that currently don't have > commit access to the portage tree? No, *their* role is to be develop, not test. To have or not to have commit access is not the question. To develop or to test (and get recognized for it as well) is the question. Nathan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDJiGw2QTTR4CNEQARAhZuAJ9BRRr+9baj3kAcEU1LrUr8AyjZPwCfbEt6 EzqISNCg69GwNNew2jJoYdM= =kGey -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] 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] 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] 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: > 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] 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=2&chap=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
[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: Bugzilla handling for maintainer-wanted things
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: > On Sun, 21 Aug 2005 17:37:52 +0200 Henrik Brix Andersen > <[EMAIL PROTECTED]> wrote: > | On Sun, 2005-08-21 at 16:26 +0100, Ciaran McCreesh wrote: > | > That's, uh, not really the best documentation around... The > | > devmanual's a slightly better bet if one wishes to learn how things > | > should really be done. > | > | Have you submitted a set of patches against our official documentation > | to address the issues, you think should be corrected? > > I did. After those patches were sat on, ignored and butchered, I took > the sane way out and started my own set of developer documentation > instead. > Which I started to read (and found to be excellent), but then they seemed to have disappeared. Could you please post a valid link? :) Thanks, Nathan p.s. The tool I intend to write will only cover the most obvious/common syntax error. There is no substitute for good peer review! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDCUDH2QTTR4CNEQARAs26AJ0XPdcG3GKaYe6cJ2EUo/ji/MKnTQCeItrM El0QpQBS988tQSyJE7L3Pt8= =/5D/ -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: > On Sun, 2005-08-21 at 10:10 -0400, Nathan L. Adams wrote: > >>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. > > That's still not *you* doing the actual work - that's you requesting > someone else to review your work - which is good, but a totally > different topic which doesn't really belong in this thread, imho. Its a chicken and egg situation. I need to have a certain level of expertise with ebuild syntax and conventions to do the job. So I've asked for some help from an expert. Also, I learn things quicker and easier by first seeing examples and then seeing the documentation; that's just me. Once I've learned a bit, I can start doing things on my own. By the way, I didn't create the ebuild. Peer review isn't when you review your own work. Its when somebody else, knowlegdable in the subject, reviews your work. >>>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. > > > See above what? The part about you requesting someone to review your > ebuild? See above, again. >>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 :) > > I'm confident that most Gentoo developers agree that peer review is a > nice concept Peer review is *not* a 'nice concept'. Peer review (as a part of the broader scientific method) is how humans have progressed from horses and buggies to the level of technology we have today. > - but... I think you need to sit down and participate in an > open source project to fully understand how it works. You can't just > step forward and say "this is good, you need to do this" as a bystander > - that's not how the open source spirit works. This isn't my first F/OSS project. I was active with Fr**Craft before it was (wrongly) shut down. > If you on the other hand step forward and say something like "I've spent > the last x months reviewing your code and developed a small set of > utilities for doing so, would you be interested in a wider use of > these?" I think you'd get a much better welcome. *THAT* is a great idea. I am proficient in several scripting languages. I am willing to write the tools if someone more knowledgable is willing to help me with what the 'best practices' are for ebuilds. Its a 'you help me and we'll both help Gentoo' situation. > In the open source community this is also known as "show me the code" as > in: if you want something done, you'd better be ready to back it up with > code and/or actions. Basically, you'll need to put more than words into > this, if you want to see it happen. Agreed. Nathan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDCJpN2QTTR4CNEQARAi1lAKCWbAC/0Zf/crUQNlVkPe1zqnwsnQCeNUQY v9N1FPnAx5Bc6431eqTK7m8= =2qFM -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
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 > "resolved""wontfix" 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 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 Luca Barbato wrote: > Nathan L. Adams wrote: > Given every dev is complaining about how long is getting this thread and > how pointless is. > > PLEASE AVOID REFRAINING SUCH NONSENSE > > point taken, working on it, don't impair our productivity more than that. > > thank you The only devs I've seen complain are yourself and Jon Portnoy. Nobody is forcing you to read the thread... -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDB8B42QTTR4CNEQARAp7GAKCZ+aMdroeuwyxQaS0fmwRhYyL5WQCfWoXo A5s9+NzN7F8NNWep6vxkW/w= =o5B7 -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 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 Donnie Berkholz wrote: > Ciaran McCreesh wrote: > | | WONTFIX doesn't seem the right tool for the job: > | | > | |WONTFIX > | | The problem described is a bug which will never be fixed. > | > | And the ebuild attached will never be 'fixed' in the state it is in. > > I might use NEEDINFO instead, but it all depends on the people looking > at the bug. WONTFIX refers to the bug, not the attached ebuild. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDB7Xy2QTTR4CNEQARAjS0AJ40CySjXd7/w4ty2JNZTdZ+fl7AygCfdt/B Iqqj0IAiDX3nO5Mfd1QvMGo= =rIn6 -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] 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 Mike Frysinger wrote: > On Friday 19 August 2005 08:56 pm, Nathan L. Adams wrote: > >>In the time it took you to respond to this thread, you probably could >>have reviewed the ebuild in question... > > thank you for wasting our time with a pointless e-mail > -mike Thank Chris. I asked Ciaran to review an ebuild I was interested in so that I could learn a little by example of what he thinks coding standards in ebuilds should be. This is the development mailing list, correct? Where development stuff is discuss, correct? Chris responded with (paraphrasing of course) "this my territory, go away", "Nathan is part of a conspiracy against the game team", and "don't critique our stuff, this is our territory". The territorial stuff... stupid but whatever. The attack on me... not acceptable behaviour. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDBzpN2QTTR4CNEQARAhA9AJ4uIZAS9l/9kYK7tcaU60QRsd5DCACfV+Ef FKb5jFgXTo7Xps8gtEp1vqM= =Ybo/ -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 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 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 Ciaran McCreesh wrote: > I've been going through the EBUILD list at random and providing lists of > things that need to be fixed before the ebuild can be considered for > inclusion. The WONTFIX resolution along with a comment asking for the > submitter to reopen with a fixed ebuild is used when problems are found. If you have time, could you please review the ebuild attached to this bug: http://bugs.gentoo.org/show_bug.cgi?id=94764 Thanks, Nathan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDBe8e2QTTR4CNEQARAv0cAJ9lKCHbPpiHgJO5KfKi8qrlB2gTKACdGVTw NDOmC0UYBLEwF6Zo9U8cLA8= =oP5s -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 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] 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] 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] 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] Kudzu and Kudzu-Knoppix
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Gianelloni wrote: > These packages infuriate me, and quite frankly, I have no need for them > for release building. Basically, I don't want to maintain them any > more. I plan on adding a "libkudzu" ebuild, which will fulfill the > dependency for hwsetup, and drop kudzu and kudzu-knoppix from the tree > completely, unless some brave soul steps up to maintain these. I figure > I'll be removing them around August 1st, so speak up if you want them, > otherwise, they are history. > Why do they infuriate you? Nathan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC1GzD2QTTR4CNEQARAqpyAKCfLip8QDJrzmojN5ZbAnOP+T7A0gCfZMGZ WSMfv5H457XQHiz7bUf7oK0= =0pH6 -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] 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 Ciaran McCreesh wrote: > On Sun, 10 Jul 2005 11:32:44 -0400 "Nathan L. Adams" <[EMAIL PROTECTED]> > wrote: > | > 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. > > You're taking methods from a "how your typical oversized software > engineering bloatware project works" situation and trying to apply them > outside of their domain. The Linux kernel has a mult-tiered sign-off/peer review method[1]. I guess they're just your typical oversized software engineering bloatware project then, right? > | > 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. > > Experience. I receive bug mail for a heck of a lot of bugs. I see how > many of them are indeed correctly resolved when they are marked as such. Ah ha! So you've been peer reviewing bug fixes!!! Wouldn't it be nice if all developers did that sort of thing and gained that kind of experience? > | > 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. ;) > > No, that kicking and screaming is reserved for when bugs are reopened > inappropriately. Let's not reopen old wounds. ;) [1] http://www.groklaw.net/article.php?story=20050529095918381 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC0Z6n2QTTR4CNEQARAg/vAJ0d74aHyB1123sAmIMMxuSgxX4bKQCglP6a ihY16+oc5BTRLudHW6PtZ3s= =Me/f -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] 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 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] 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 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 R Hill wrote: > a) what would be the point of the reporter also being the verifier as > far as confirming that the bug is real and not a PEBKAC error? Sometimes devs do clever things to their systems that end-users aren't aware of, or they test the fix logged into their machine with special priviledges, etc. So having the reporter verify would test the fix with those things out of the loop. > b) what would be the point of requiring that verification be done by a > third party if the dev the PR is assigned to can reproduce the bug > themselves? I'm assuming that this would only apply to cases where the dev has provided a fix (in most cases I assume they would have reproduced the problem). The reporter's test would have the benefits mentioned above, and if the Team Lead tested, they could review the fix for technical correctness, etc. > c) how do you propose the assignee fix the bug if they cannot reproduce > it? this may be possible in some cases, but not anywhere near the > majority. My suggestion doesn't even cover that; it assumes that the dev has provided a fix. > d) team leads lead the team, not attempt to reproduce bugs for every PR > that falls under their umbrella. to be blunt, they have much better > things to do. Is it out of the scope of the Team Lead to check that [his|her] devs are fixing things in a technically correct manner? From the "Gentoo Developer Handbook": "Team leads are responsible for organizing the developer in their team and coordinating releases and also resolving issues within the team, as well as improving products on the basis of feedback from the community." http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=1&chap=5 I think a bug report qualifies as feedback from the community and verifying that a bug fix actually works would qualify as improving products. > Dear Nathan, > > In your spare time, could you please begin testing every new problem > report filed as of now for validity and tag them appropriately? This > small, incremental move should greatly improve our QA process. Thanks boo. Again, my suggestion attempts to improve the process farther down stream; the problem of validating new bugs and tagging them appropriately is a separate matter. Also, suggesting that I do all the work is silly. It suggests, to me at least, that you can't find anything wrong with what I'm suggesting, but for some reason or another you're unwilling to change your working habits. So you throw up the "if its such a good idea, you do it... ALL of it!" nonsense. Obviously, no process (including the current Gentoo bugzilla process being used daily) will work without participation from most of the people involved. There will *always* be people who disagree, and there will *always* be people who skirt the system in some way. That's just life. > Note: I am not denying there could be a (small) policy problem, I'm just > pointing out that the proposed solution is unworkable. Great! Can you think of any ways to make my idea workable? What about a completely different solution? 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. Nathan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC0Sdc2QTTR4CNEQARAsh+AJ93PRmC0JLJlBNV3kSbFlKR2vOkOgCdEpvq 2SVJFg/G2B0sb8CXTstOGEY= =CAPL -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 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 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 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 Stephen P. Becker wrote: > Clearly, you either chose to blatantly ignore, or completely > misunderstood what avenj was saying. What he *meant* was we don't have > the time or manpower to have developers take significant portions of > their valuable time to do what you suggest without paying somebody to do it. > No, I didn't blatantly ignore or misunderstand Jon. The ;) was meant to imply humor, but I am the first to admit that email isn't the best medium for that sort of thing. But as far as the manpower thing goes, it is obviously a good and valid point. Please read my last response to Ciaran on that topic. Nathan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCz/lM2QTTR4CNEQARAkoIAJ9EnB8nzHNSOIfJ5OW42bgNftvs0gCfbOkv bcYnd7C9s0np/5SmY+iwzQE= =i6xI -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 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 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 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 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 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 Mike Frysinger wrote: >>>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. > > > that's because we got tired of asking for more info/whatever and never > getting > anything back ... so we close the bug, get it off our 'todo' lists, and wait > for the user to get back to us (not all do) > > this is the biggest reason NEEDINFO was created Having the reporter be the verifier is a great idea (probably ideal), but again, you could assign the verification to the Team Lead. If the Team Lead can get the user to respond, great, otherwise they could do the QA themselves. >>Also note that the bug is NOT "closed", only /resolved/. There /is/ a >>not insignificant technical difference, altho it /does/ seem Gentoo >>doesn't seem to actually close bugs that often. Ah, my bad. For some reason I thought it had been closed. But I know that if you looked (not too hard) you could find bugs that were closed by the person assigned to resolve it and/or that were closed before the 'fix' was marked stable. > > thats because very few (if any) think or care about the difference You could make bugzilla try to enforce the process; that would get dev's thinking and caring! Just think: The Great QA Rebellion of 2005 ;) Anyway, this stuff is important to me 1) because I do systems integration for a living and deal with this sort of stuff daily 2) good QA is an 'enterprise characteristic' if you will, and 3) good QA benefits everyone (although it annoys some developers to no end). Nathan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCz0ij2QTTR4CNEQARAitWAKCXfs0tTNRo3eOPvuZ+VJYUG13GKACgkalh 7eRv7Aj61BNfMnFSN/I76oI= =N7XG -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 , 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] 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
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] where goes Gentoo?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Aron Griffis wrote: > In my humble opinion, Gentoo is missing too many points to be an > enterprise Linux. We commit to a live tree. We don't have true QA, > testing or tinderbox. We don't have paid staff, alpha/beta/rc cycles. > We don't really have product lifecycles, since we don't generally > backport fixes to older versions, requiring instead for people to > update to a more recent release. We don't have, and probably will > never be able to offer, support contracts. We support as wide a range > of hardware as the upstream kernel, plus hardware that requires > external drivers; we don't have access to a great deal of the hardware > for which we provide drivers. We understand when real life gets in > the way of bug-fixing, because all our developers are volunteers. Using your list there would be two types of enterprise 'requirements': process requirements and support requirements. Improving and working towards the process requirements (sane commits, better QA, etc.) doesn't mean that Gentoo would have to be any less fun. And just because the Gentoo Foundation isn't in a position to provide the support requirements (paid staff, support contracts, etc.) doesn't mean that someone else couldn't provide those (or that Gentoo would make it particularly hard to do so). > Also I find it amusing when people say that Gentoo exists for the > users. I think that is wrong. Gentoo exists for the *developers*. > It's our playground, and it's the reason we use a live tree rather > than switching to an actually sane approach. The users are cool > because they point out bugs, help solve problems on bugzilla, suggest > enhancements, provide patches, and notify us of package updates. > Sometimes they become developers. But the truth is that Gentoo sees > improvement and maintenance in the areas that appeal to the > developers. And that is why Gentoo exists for the developers first, > the users second. I would suggest that: 1) this is a pretty common belief in any software developement project, commercial, community led, or otherwise 2) its a bit wrong headed for various reasons, IMHO (see below) and 3) I personally find it amusing. ;) What developers seem to forget, is that they too are end-users. For instance, a particular developer's responsibilities may be Baselayout, Epm, Gentoo/Alpha, Gentoo/IA64, Keychain, Mozilla, Mutt, Vim, and such. That makes him/her an end-user for everything else thats installed on their system. In other words, developers are just a subset of the user base. Secondly, polishing things for developer's sake doesn't preclude polishing things for user's sake, and visa-versa. So if it were up to me, it would be users first , which would encompass everyone, including the developers! Nathan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCp2bZ2QTTR4CNEQARAqTcAKCOa/cBOlWV7z7f7UOB6lr5uCVpbACglB3/ 4Fm35UBwetXvSY7jFy8276I= =w0yb -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] 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 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
