Re: [gentoo-dev] GLEP ??: Critical News Reporting

2005-11-04 Thread Nathan L. Adams
-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

2005-11-04 Thread Nathan L. Adams
-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

2005-11-04 Thread Nathan L. Adams
-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

2005-11-04 Thread Nathan L. Adams
-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

2005-11-04 Thread Nathan L. Adams
-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

2005-11-04 Thread Nathan L. Adams
-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

2005-11-04 Thread Nathan L. Adams
-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

2005-11-03 Thread Nathan L. Adams
-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

2005-11-03 Thread Nathan L. Adams
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ciaran McCreesh wrote:
 On Thu, 03 Nov 2005 08:49:42 -0500 Nathan L. Adams [EMAIL PROTECTED]
 wrote:
 | 6. Ciaran is completely biased against XML (or anything that isn't
 | stored as a simple flat file) ;)
 
 It's not bias. I give XML exactly what it deserves. SGML is a giant
 fire breathing stomping monster useful for crushing Tokyo. XML is the
 spawn of said giant fire breathing stomping monster that's had its
 claws and teeth removed, its jaws glued shut, its legs chained together
 and its tail nailed to the ground. And we're not trying to destroy any
 large cities here...
 

rant
You're just missing the fact that a flat file (or whatever it is you're
clinging to; for the purpose of this rant, I shall refer to your simple
data format as flat file) has trade-offs, just like XML's trade off is
parsing overhead. XML was designed to solve certain problems;
portability of data, separation and portability of presentation from the
data, etc. Complexity in the parser is the trade-off.

Flat files can be great in certain situations. Flat files do indeed make
the parsing trivial. However SIMPLE CODE ISN'T ALWAYS THE MOST IMPORTANT
REQUIREMENT. In the case of this GLEP, the most important requirement is
getting the proper migration info to the users in the best possible way.

So what are the trade-offs of the 'flat file'? If you store a migration
guide as a 'flat file', its not going to be very readable. I would
certainly rather read info in GuideXML than some garbage output by einfo
or the like (and I'm talking about the same exact data, just a different
presentation). You're being daft if you say that your average terminal
output is easier to read and understand than the same data in proper
GuideXML format. OK, you say, you have a point there. But, you say, my
flat file allows me to write a 'presentation' proggy in relatively few
lines of trivial code. Yes, but now you have to write a new presentation
program for every type of presentation you want to do. Or worse you
would imbed the presentation in the data itself and make a new copy of
the data every time you want to present it differently. But, you say,
don't you have to do that with XML (i.e. a new style sheet definition
for each presentation)? Sure, but I don't have to re-write firefox in
the process...

So the point is that, yes, XML has a down side. But plain text, CSV
files, whatever have their downsides too. And the point of this GLEP
shouldn't be to push any XML-bashing agenda, it should be to present the
user with the migration guide in the best possible way. GuideXML is the
standard for Gentoo docs for some damn good reasons!
/rant

Nathan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDaqt52QTTR4CNEQARAoQ1AJ42ItHkJ37eFUY8rSoGpN/dVoKIFACeJi7b
KW6/pzn8VEKi3hO0Gqomsms=
=cSQh
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] GLEP ??: Critical News Reporting

2005-11-03 Thread Nathan L. Adams
-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

2005-11-03 Thread Nathan L. Adams
-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

2005-11-03 Thread Nathan L. Adams
-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

2005-11-03 Thread Nathan L. Adams
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ciaran McCreesh wrote:
 On Thu, 03 Nov 2005 19:45:08 -0500 Nathan L. Adams [EMAIL PROTECTED]
 wrote:
 | Just keep in mind that portage is supposed to be non-interactive and
 | most users like it that way. (Although the countdown when cleaning out
 | old packages kinda breaks that idea, but I digress.)
 
 You really should give the GLEP a read. It's quite nice, you know...
 

Your explanations hint at interacting with portage during an emerge.
Specifically you floated the idea of having emerge print a red flashy
message before doing the emerge. *That* is what I was commenting on.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDarPp2QTTR4CNEQARAkkbAKCn8yDt7D17Ls+/huZkg4TkKjmXVwCgntbs
BrrWIziJCF2M8RckaINyMNA=
=Ytle
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: GLEP 42 (Was: Getting Important Updates To Users)

2005-11-03 Thread Nathan L. Adams
-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

2005-11-03 Thread Nathan L. Adams
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ciaran McCreesh wrote:
 On Thu, 03 Nov 2005 20:02:58 -0500 Nathan L. Adams [EMAIL PROTECTED]
 wrote:
 | So if you didn't want people to actually review and comment on *your*
 | GLEP, why did you write:
 | 
 | The attached GLEP is a draft proposal for the emerge --news thing
 | that's been under discussion. There are still some TODO items. These
 | are calls for people to weigh in with suggestions. Of course,
 | suggestions on other items are good too...
 
 I want people to review and comment on it after they've actually read
 the thing.
 

I have read it, and I find it lacking; thus the comments. Or are you
claiming that the idea of having a central website like errata.g.o with
GuideXML-ized migrations guides is in your GLEP? Its not. I'm proposing
adding that as the definative source of the errata, and feeding it to
other places (emerge --news, mailing lists, forums, GWN) as desired.

I'm also commenting on the part that *wrongly* states It is not
reasonable to expect all users to have an MTA, *web browser*, email
client, cron daemon or text processing suite available on their system.
In particular, this means that any markup to be parsed must be in a very
simple format.

*ALL* of the official docs are GuideXML; Gentoo *expects* users to have
a web browser by default. Otherwise a vast majority of users would never
get Gentoo installed in the first place. The lightweight requirement
appears to just be your way of subverting the current documentation
standards (because of your XML hatred).

The news directory shouldn't the main source of the migration guides;
the website should be (one central page that can feed other sources).
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDarhL2QTTR4CNEQARAr+KAJ9v5iy+i5tvqNx9woib/cJUZI+eMwCgohIo
acuUUmVYcI1TsBDX0dg/K0s=
=bWEF
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] GLEP ??: Critical News Reporting

2005-11-03 Thread Nathan L. Adams
-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

2005-11-03 Thread Nathan L. Adams
-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

2005-11-03 Thread Nathan L. Adams
-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

2005-11-03 Thread Nathan L. Adams
-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

2005-11-03 Thread Nathan L. Adams
-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

2005-11-03 Thread Nathan L. Adams
-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

2005-11-03 Thread Nathan L. Adams
-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

2005-11-03 Thread Nathan L. Adams
-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] Getting Important Updates To Users

2005-10-31 Thread Nathan L. Adams
-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

2005-09-16 Thread Nathan L. Adams
-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

2005-09-15 Thread Nathan L. Adams
-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

2005-09-14 Thread Nathan L. Adams
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

2005-09-13 Thread Nathan L. Adams
-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

2005-09-13 Thread Nathan L. Adams
-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] ROX: maintainer-wanted and apps out of date

2005-09-12 Thread Nathan L. Adams
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ciaran McCreesh wrote:
 And as for taking it as a PISSOFF... We've had exactly one person do
 that so far. All the rest of the feedback we receive -- which is a heck
 of a lot -- is of the thanks for the pointers, please could someone
 check this updated ebuild? and occasionally could you clarify $blah
 for me please? variety.

My first inclination is to take WONTFIX as PISSOFF, and I even read
the previous thread in question. :)

I humbly suggest adding a REVIEWED and/or NEEDSWORK keyword and
leaving the bug in the OPEN or ASSIGNED state.

But adding the comments (with pointers to more in-depth explanations) is
a great idea, especially if you present them in a cordial way:

Thanks for helping Gentoo! The ebuild you submitted isn't quite
ready, so here is what one needs to do to get it in the tree:

link1
link2

Thanks again!

Which is probably what you're doing already. :)

As for missing/AWOL developers, and for developer/user problem
resolution, I *think* devrel handles that:

http://www.gentoo.org/proj/en/devrel/

Nathan

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDJhs02QTTR4CNEQARApZsAJ9+KRCAsawb5/fVD8FFpTO0d2TitACgmqH2
OI1jP3uv+/Ll7qHOawzqowo=
=VPCh
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Gentoo Council meeting, Thursday 15th, 1900 UTC

2005-09-12 Thread Nathan L. Adams
-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] tentative x86 arch team glep

2005-09-05 Thread Nathan L. Adams
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Kevin F. Quinn wrote:
 Well, it strikes me that most if not all of the organisational questions
 are not relevant to a tester; the only technical question that is
 relevant is 9 (keyword marking), and even that would be reworded for the
 tester perspective.  The main point being that a tester can be a willing
 user, with no dev capabilities at all; the ebuild quiz is written for a
 different target group.  In fact, it's useful if testers are not developers,
 as devs often make assumptions without realising it.
 
 I guess it comes down to what you want a tester to do. In my mind, the
 task of a tester is to emerge the package normally, record the use flag
 configuration, and exercise the application as much as possible.  Possibly
 repeating with other use flag configurations.  If you want testers to do
 ebuild QA, then the ebuild quiz becomes relevant, but I don't think it's
 a good idea..

In my professional work, the pecking order is like this:

developer -- integration/test -- system design -- management

Of course, some of the developers I work with may disagree. ;)

But the point is that the integration/test team knows about development;
it just makes sense. The integration/test team needs to know a good deal
about development *and* the overall system design to be affective.

So I would say have all arch-testers take both the ebuild quiz and the
newer QA/testing quiz. I suppose you could be more lax about scoring if
you're really worried about not getting a large enough pool of testers.
And I'm not arguing that an arch tester has to become a developer first;
I'm just making the point that a good tester has the ability to switch
back and forth between the 'big picture' and the 'bit level'.

If you want fancy terminology, the testers need to know how to test the
interfaces (in this case the portage API, probably by code walk
throughs), and functional threads (you gave a great example, 'emerge the
package normally, record the use flag configuration, and exercise the
application').

Nathan

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDHF2E2QTTR4CNEQARArbJAKCEZ7K6HiTFKpVy9mEVkaTU9TFUvQCeLlLE
l8v1xMYUtLLa4cvF5meZyJo=
=W6Sq
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] tentative x86 arch team glep

2005-09-05 Thread Nathan L. Adams
-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

2005-09-05 Thread Nathan L. Adams
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Kevin F. Quinn wrote:
 On 5/9/2005 13:41:54, Jason Stubbs ([EMAIL PROTECTED]) wrote:
 
On Monday 05 September 2005 20:21, Simon Stelling wrote:

Ciaran McCreesh wrote:

If it isn't fit to be marked stable, it shouldn't be out of
package.mask. ~arch means candidate for going stable after more
testing, not might work.

It's a bit of both. When you put a package into ~arch, it's in 
testing, so that says it needs further testing since there still 
could be a not yet discovered bug, right?

Testing of the ebuild rather than of the package, though. This is the 
point  where people sometimes get confused.
 
 
 That'd be me then :)
 
 So we're talking about correctness of ebuilds (correct dependencies,
 use flag logic etc) and not whether the package actually works in depth.
 The latter is what caused me to suggest drawing together a large team of
 user-testers managed by arch-team devs.  Correctness of ebuilds takes
 us back to a dev role and the ebuild quiz, since it's necessary to
 understand ebuilds to criticise them.
 

After a rather heated discussion a while back, I came up with this
definition:

- -arch :: the end-user software is/might be flakey
~arch :: the ebuild is/might be flakey but the software is good
 arch :: its all good :)

Nathan

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDHGCN2QTTR4CNEQARAiVdAJ9wVLt5CPyW//qxmuSC3GlZSOaI+QCeLqEl
78TX1Xtvbx7E4lBEdwnxMus=
=T6ZT
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] local USE flag gimp for xsane

2005-09-05 Thread Nathan L. Adams
-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] Re: Bugzilla handling for maintainer-wanted things

2005-08-21 Thread Nathan L. Adams
-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

2005-08-21 Thread Nathan L. Adams
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dan Meltzer wrote:
 This time I'll say something useful :)
 
 Nathan, you seem to be misunderstanding open source.  You get the I
 can ask for features or suggest things part, but not that I can add
 features or do things part.  No one is stopping you, or me, or an
 average joe, or George W. Bush, from peer reviewing.  You can see
 the basic things that are commonly wrong by looking at a few
 resolvedwontfix bugs with ciaranm as the commenter.  Most make the
 same mistakes.  After seeing this, what is to stop you from either
 manually looking through the tree, or writing a script to check for
 you, and fixing some of the problems, submitting them as bugs when
 they are fixed.

No, I understand what you're saying completely. I've been using F/OSS
for about 10 years now, and I've been an engineer/programmer for about 5
of those. So I know a little bit about both sides of the story. And I've
actually submitted an ebuild for thunderbird (although it was really
just an integration job of a couple of existing versions), so I'm
certainly not unwilling to get my hands dirty.

 I cannot imagine any developer would say no to a
 well written ebuild, they may wait for a version bump to switch to it,
 but they most likely would not ignore it all together.

 Hell, maybe if you do a good enough job, and show enough devotion, the
 gentoo guru's will even think about making you a developer in charge
 of fixing those things. who knows?


My experience with Gentoo is that certain developers ignore user
submitted ebuilds, bugs fixes, etc. and claim its a manpower/time issue.
Yet they fail to court the user submitting the ebuild into becoming a
developer too (thus helping relieve the manpower/time issue). And this
isn't me wanting to get noticed, mind you; I'm talking about other users
who regularly submit ebuilds and get ignored. So you end up with the in
crowd capable of making Gentoo better and the rest forced to either
fork or just go away. Chris even told Ciaran to not look at a user
submitted ebuild because it was the games group's territory. Yet the
games group 'FAQ' complains about how little time all of those dev's
have. Wouldn't it make more sense to recruit those folks and make your
team more capable of handling the load? THERE is your cathedral.

And again, thats just one example and not indicative of the entire
Gentoo dev team (or the entire games team for that matter).



-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDCIW92QTTR4CNEQARAvPuAJwPipryDRbAo/j7IrZCfavIbUP8HQCgglUt
j51c5mPa0SyDZezeGg+FJJ0=
=rHOS
-END PGP SIGNATURE-
-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] Re: Bugzilla handling for maintainer-wanted things

2005-08-21 Thread Nathan L. Adams
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Henrik Brix Andersen wrote:
 And - as I told you the last time you brought this issue up - you're
 more than welcome to start reviewing ebuilds and commits as well.

I'm starting to do just that. I've even asked Ciaran to review a
particular ebuild I was interested in so that I could learn from it.

 We have a bugzilla which is open to the public, we have an irc channel
 [1] (which is even monitored by CIA [2]) for tracking all commits made
 to the portage tree... what more do you want?

That is handy, thanks. I don't see the IRC channel listed here:

http://www.gentoo.org/main/en/irc.xml

So I've emailed [EMAIL PROTECTED] and asked to have it added. :)

 If you so desperately want code review in Gentoo, why don't you do what
 every other open source software developer has to do to get his ideas
 through: put some work into it yourself?

See above.

 I've been wondering: do your emails on this list represent the view of
 the IEEE organization?

Of course not. But the IEEE *is* all about peer review (as all
scientists have been for the last few hundred years). And here is a nice
high-level article about the benefits of peer review while developing
software for the non-believers :)

http://www.visibleprogress.com/peer_reviews.htm
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDCItE2QTTR4CNEQARAtWfAJoDGYt/o6afKSL/7VCxFuAJNYZfHQCgp9N0
K9f5keHUSdyd5nat4rit6EM=
=kXk/
-END PGP SIGNATURE-
-- 
[EMAIL PROTECTED] mailing list



[gentoo-dev] Re: Most common ebuild mistakes?

2005-08-21 Thread Nathan L. Adams
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Luca Barbato wrote:
 http://dev.gentoo.org/~plasmaroo/devmanual/

Thanks, I've been wondering where Ciaran's docs went. :)

Now, there one question that I won't be able to answer for myself
anytime soon:

What are the most common ebuild mistakes?

A script will never be a substitute for good peer review, but it can
easily detect (and even correct in some cases) common syntax errors. So
I'm looking for a list of things like under-quoting variables, improper
spacing, etc.

Thanks,

Nathan

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDCUJC2QTTR4CNEQARAholAKCrS2DZpMEUZH12F1agJ0/Y8nxzOQCfZctd
ZMWBprkt1Nq+Zf9JaXVLhLU=
=7Bbv
-END PGP SIGNATURE-
-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] Re: Most common ebuild mistakes?

2005-08-21 Thread Nathan L. Adams
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Donnie Berkholz wrote:
 Nathan L. Adams wrote:
 | What are the most common ebuild mistakes?
 
 http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2chap=3

Thanks everyone. I'll bug each of you individually if I need clarification.

Nathan

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDCVEa2QTTR4CNEQARApI1AJ4k5sKZN99EkEDwpPPcPQRB6ALFeQCeLmTB
g3cJhP7sP0CTpM4DsTxVzgo=
=3rMv
-END PGP SIGNATURE-
-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] Bugzilla handling for maintainer-wanted things

2005-08-20 Thread Nathan L. Adams
-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

2005-08-20 Thread Nathan L. Adams
-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

2005-08-20 Thread Nathan L. Adams
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Chris Gianelloni wrote:
 Reviewing an ebuild has nothing to do with inclusion.  For inclusion  in
 the tree, it also needs to be tested.

You don't take the slightest look at an ebuild (the code) before
including it? Anyhow, whether its testing or code review, it is time
better spent than cooking up conspiracy theories about me vs. the games
team and posting it to the mailing list.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDB2TB2QTTR4CNEQARAo8/AJ9A2lcb/DocUJUJdMrIJEsDBwN0FgCeLAWw
qWz0qr+iKO+W9zpoTtULLM8=
=Maa/
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: Bugzilla handling for maintainer-wanted things

2005-08-20 Thread Nathan L. Adams
-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] Re: Bugzilla handling for maintainer-wanted things

2005-08-20 Thread Nathan L. Adams
-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

2005-08-20 Thread Nathan L. Adams
-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] Bugzilla handling for maintainer-wanted things

2005-08-19 Thread Nathan L. Adams
-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

2005-08-19 Thread Nathan L. Adams
-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

2005-08-19 Thread Nathan L. Adams
-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

2005-08-18 Thread Nathan L. Adams
-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

2005-08-16 Thread Nathan L. Adams
-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

2005-07-27 Thread Nathan L. Adams
-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

2005-07-19 Thread Nathan L. Adams
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

 The will not allow it and I will not allow someone to go fooling in 
 an ebuild I maintain. Not trying to be an ass here but we have 
 something called respect for others when it comes to the tree and 
 what they maintain.

Poor Jory. Respect isn't something that is owed to you; its something
that is shared between two or more people. Looking down on people and
being territorial (especially with something you don't actually own)
doesn't help.

I can't help but laugh at the idea that a dev on an F/OSS project would
get mad because somebody wanted to *improve* the code. If you can't take
the heat, don't join a F/OSS project...

 You want to curse me and tell me you think your gonna go playing in 
 my vpopmail ebuild

Wow, now its *his* vpopmail ebuild. And here I thought everything was
copyrighted to the Gentoo Foundation.

 you can take your bullshit upstream I am black 
 listing you on my filters so I do not need to read your bullshit

Sadly, this sort of childish behavior isn't isolated to this particular
dev. Its the equivalent of Cartman (Southpark) saying screw you guys,
I'm going home. And it makes the speaker look just as mature.

 Umm look I'm just trying to help here, and I really feel like I've 
 been treated very unfairly by this developer.  I'm working hard to 
 try to make vpopmail AND gentoo better products, I'd really 
 appreciate not being told on things I know very well that I'm right 
 about, and getting severe reactions like this when I prove that my 
 statements were indeed correct and that I'm only trying to help.

Most of the Gentoo devs I've dealt with are very talented and very
likable people. They volunteer in a very professional manner and
understand that with their developer status comes a few responsibilities
(common curtesy being one of them).

But there does seem to be a vocal minority of asshats who like to carve
out their little fiefdoms and 'fend off invaders' at all costs. :(

 I really feel that this response whas wholly unjustified, and that I 
 did nothing to warrant it.  Please advise.

As Mike mentioned: http://www.gentoo.org/proj/en/devrel/

Hopefully, you'll stick around and help out again in the future.

Nathan

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFC3bVF2QTTR4CNEQARAgu9AJ0c7E5zGqC1TUTtHpC5JqTxK3RlNACfT2nZ
P1Dz55PPdZ/DcqstSHPG2PY=
=nlVQ
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: Closing bugs [was: New Bugzilla HOWTO]

2005-07-10 Thread Nathan L. Adams
-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]

2005-07-10 Thread Nathan L. Adams
-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]

2005-07-10 Thread Nathan L. Adams
-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]

2005-07-10 Thread Nathan L. Adams
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Daniel Drake wrote:
 Nathan L. Adams wrote:
 
What do you think about adding the step only to certain critical
products, such as Portage or maybe Catalyst or even the Installation Docs?
 
 You're now significantly altering your proposal, from something that affects
 almost everyone, to something that affects only some 'minority groups'. Nobody
 can give you a straight single answer.

The whole point of this discussion is to get feedback and alter the idea
as needed, not to beat everyone over the head with the Original Idea (c)
until everyone sees it My Way (TM). So kindly pick the version of the
idea that you like best, and base your discussion on that. ;)

 For portage, ask on the gentoo-portage-dev mailing list. For catalyst, ask on
 the catalyst mailing list. For installation docs, ask on the docs mailing
 list. These groups are significantly different, have their own distinctive
 procedures, etc.

Good point. See my reply to Jon Portnoy for the latest revision of the
idea that would apply to everyone as an optional 'best practice'.

Nathan

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFC0TtM2QTTR4CNEQARAjeAAJ0bhA31Oc0Ho5mRnjkjCvg5zZZVkwCgm7Ib
ehPatwEpWl9LdD59n8HJnxE=
=J1U+
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] New Bugzilla HOWTO Update

2005-07-10 Thread Nathan L. Adams
-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]

2005-07-10 Thread Nathan L. Adams
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ciaran McCreesh wrote:
 On Sun, 10 Jul 2005 11:08:41 -0400 Nathan L. Adams [EMAIL PROTECTED]
 wrote:
 | Maybe as a start, the Developer's Guide can be revised to state that:
 | 
 | Ideally any bug that a fix is submitted for should be verified and
 | peer reviewed. It should be verified by the reporter or another user.
 | If the reporter or another user are unable or unwilling to verify the
 | fix, the Team Lead should take responsibility for the verification.
 | Ideally, all bug fixes should be peer reviewed by the Team Lead and/or
 | other team members before the bug is marked as RESOLVED.
 
 Again, Gentoo is not a large corporation or Debian.


I don't see how Gentoo's status (or rather lack thereof) as a
corporation or Debian has anything to do with encouraging peer review.

 The assumption is
 that the majority of fixes are done correctly the first time, and this
 assumption is valid.

I don't see how you could prove that assumption. If you can, please do so.

 Hence, the default behaviour is to mark bugs as
 RESOLVED, with reopening being an entirely legitimate and encouraged
 response for those occasional instances where the resolution was not
 sufficient.
 

There are plenty of devs who don't share in the viewpoint that reopening
bugs is legitimate and should encouraged (although I agree it is and
should be). I base opinion that on some of the kicking and screaming
I've seen on bugzilla in the past. ;)

Nathan

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFC0T+c2QTTR4CNEQARAmhWAJ485c4s5MjMzQRUrCn4rR06qB/nDwCfQowx
KGJfs0VkcxZO3yHOKKIPFwE=
=LdlM
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: Closing bugs [was: New Bugzilla HOWTO]

2005-07-10 Thread Nathan L. Adams
-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]

2005-07-10 Thread Nathan L. Adams
-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]

2005-07-09 Thread Nathan L. Adams
-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]

2005-07-09 Thread Nathan L. Adams
-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]

2005-07-09 Thread Nathan L. Adams
-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]

2005-07-09 Thread Nathan L. Adams
-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]

2005-07-09 Thread Nathan L. Adams
-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]

2005-07-09 Thread Nathan L. Adams
-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]

2005-07-09 Thread Nathan L. Adams
-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]

2005-07-09 Thread Nathan L. Adams
-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]

2005-07-09 Thread Nathan L. Adams
-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



[gentoo-dev] Closing bugs [was: New Bugzilla HOWTO]

2005-07-08 Thread Nathan L. Adams
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Duncan wrote:
 
 Well, not blocker g, but ...
 http://bugs.gentoo.org/show_bug.cgi?id=73181
 

This brings up a point that really irks me. In the bug, I believe the
dev implies that the reported bug has merit /yet he closes the bug
before actually doing something about it/. And I don't mean to pick on
Jeffrey; this seems to be a common habit among Gentoo devs.

If a bug is opened and it is a valid bug, the bug should not be closed
until it is actually squashed and the product ships (of course, if its a
valid bug that just won't get fixed for some reason, you can always mark
it WONTFIX):

http://bugs.gentoo.org/page.cgi?id=fields.html#status

I won't even go into the fact that the VERIFIED state* does not seemed
to be used or the fact that the person ASSIGNED to the bug is allowed to
close [his|her] own bugs! ;)

Nathan

* This would seem to be a perfect job for Team Leads, but it would need
to be enforced by Bugzilla, and the ASSIGNED engineer must not be the
same person as the VERIFIED(er) engineer for a particular bug.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCzmaf2QTTR4CNEQARArnwAKCSvsTZJuOGEswyResK3mNoTWlmFgCfbp2s
T0h/txCaKzqjGrCdbW1pOqg=
=U+ib
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] EBUILD_FORMAT support

2005-07-06 Thread Nathan L. Adams
-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

2005-06-22 Thread Nathan L. Adams
-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] Proposal: sys-pam category

2005-06-05 Thread Nathan L. Adams
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

foser wrote:
 On Sun, 2005-06-05 at 18:34 +0200, Jonas Geiregat wrote:
 
I do agree with you but some package just have completely wrong place
within portage, such package placements migh confuse the user.
To give an example: mzscheme was placed in dev-lisp while portage had a
dev-scheme directory.
 
 The current set-up isn't user-browseable anyway and hasn't been for a
 long time. I don't think the focus should be on correcting that in the
 tree, the user tools should be improved really.
 

Then why is their a browsable Categories link on the packages site?

http://packages.gentoo.org/categories/

I don't agree with Ned. Organizing the packages logically makes things
less confusing for the end-user and developers alike and doesn't qualify
as a cosmetic reason. It *is* valuable work, IMHO.

That's not to say that the user tools shouldn't be improved where
possible, of course. I don't think anyone would argue with that.

Nathan

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCozWL2QTTR4CNEQARAoVuAJ439WPwSg8qj0+pUWusNWMhtYMXKQCfZlTU
w8wP8vkA5nTTLFoqRlWvsK4=
=sbo+
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Proposal: sys-pam category

2005-06-05 Thread Nathan L. Adams
-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

2005-06-05 Thread Nathan L. Adams
-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