Closed
Bug 243369
Opened 21 years ago
Closed 21 years ago
Set up RSS feed for good first bugs list
Categories
(www.mozilla.org :: General, defect)
www.mozilla.org
General
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: fantasai.bugs, Assigned: fantasai.bugs)
References
()
Details
Attachments
(5 files, 10 obsolete files)
|
735 bytes,
text/plain
|
Details | |
|
867 bytes,
text/plain
|
Details | |
|
3.43 KB,
text/plain
|
Details | |
|
901 bytes,
patch
|
Details | Diff | Splinter Review | |
|
7.79 KB,
patch
|
Details | Diff | Splinter Review |
Like the summary says, set up RSS feed for good first bugs list.
I have the Perl script and TT template for this; I'll attach them shortly.
They should be put in the website build tools directory.
Attachment #148267 -
Attachment is obsolete: true
|
||
Comment 4•21 years ago
|
||
Does that handle a <dt> with a linebreak in it, btw?
|
|
||
Comment 6•21 years ago
|
||
Well, either we fix the script or we fix the changes I checked into the bug page
today. Either way. The page should probably document any such restrictions on
the HTML.
Fixed.
The HTML restrictions are documented at the top of the script. Perhaps a note
referring there and suggesting copy/paste would do.
Attachment #148275 -
Attachment is obsolete: true
|
|
||
Comment 8•21 years ago
|
||
I know they're in the script, but people will be editing the page, not the
script. I fully expect no one to ever look at the script after we check it in,
in fact...
I suppose a note pointing to the script would do, but would be more work for
people (go to edit page, get told to go read something else first).
|
||
Comment 9•21 years ago
|
||
Wouldn't the fix for bug 82878 coupled with a queryable keyword be a better
solution for this?
|
|
||
Comment 10•21 years ago
|
||
Unfortunately, no. The keyword would likely be set by all sorts of people who
don't know what they're talking about; I had to manually filter the list of bugs
that have "good first bug" set to generate this list. Further, this list
provides a contact address to ask for advice/help; I don't see how a buglist
would handle that.
|
|
||
Comment 11•21 years ago
|
||
Comment on attachment 148286 [details]
bug-feed.pl
>#!/usr/bin/perl
>
># HTML Requirements:
Ok, so this is better as a script and some source than as a Bugzilla keyword,
but why HTML source? Seems like it would be much simpler and more robust to
keep the source in an XML format and use XSLT stylesheets to transform it into
HTML and RSS. Since RSS is XML, you might even be able to keep the source in
RSS and have a single stylesheet to transform it into HTML.
In any case, I strongly recommend you use RSS 1 instead of RSS 2. RSS 1 is
backwards compatible with RSS 0.9x and forwards compatible with RSS 2 for the
majority of RSS 0.9x/2 parsers, which means it enjoys support from the widest
number of parsers. It's also better architected and has the brightest future
of the RSS variants (although Atom's future is arguably brighter than any RSS
variant).
>my $filetree = '../html/'; # top of file tree
>my $webtree = 'http://www.mozilla.org/'; # top of web tree
>my $filedir = 'contribute/hacking/first-bugs/'; # directory holding "index.html" to process
>
>open (FIXLIST, "$filetree${filedir}index.html") || die "Could not open Bug Feed file: $!";
In my experience it's better to leave off trailing slashes in filesystem paths.
It makes them more flexible, since it's easier to add a slash to a string than
remove one, and it also makes a composite path easier to read, f.e. by making
the path above be "$filetree/${filedir}/index.html". A third benefit is that
you no longer need the curly braces around filedir, since Perl sees the slash
as a word separator character, so the path can become
"$filetree/$filedir/index.html".
>$meta{'date'} = &datetime;
The use of an ampersand to call a function in Perl is out of fashion these
days.
>$_ = <FIXLIST> until (/<head>/);
Note that you rarely need parentheses around conditions in side-effect
notation, i.e. you can say just:
$_ = <FIXLIST> until /<head>/;
> elsif (/(\s*)<dd>(.*)(?:<\/dd>)?/ && $summary) {
> $description = $1 . $2 . "\n";
This (and similar lines) might be more simply written using string
interpolation, i.e. "$1$2\n";
> push @items, {'summary' => escapeHTML($summary),
> 'link' => $link,
> 'category' => escapeHTML($category),
> 'description' => escapeHTML($description)};
Don't escape these now, do it later in the template using one of the following
two syntaxes (the latter being shorthand for the former):
[% item.summary FILTER html %]
[% item.summary | html %]
>my %outvars = ('items' => \@items, 'meta' => \%meta);
Slightly more intuitive as:
my $outvars = {'items' => \@items, 'meta' => \%meta};
>$template->process("rss2.tmpl", \%outvars, "$filetree${filedir}rss2.xml") || die "Template process failed: ", $template->error(), "\n";
Per common practice and for readability (especially for long lines), die on the
next line, i.e.:
$template->process("rss2.tmpl", \%outvars, "$filetree${filedir}rss2.xml")
|| die "Template process failed: ", $template->error(), "\n";
>sub datetime {
> my ($sec,$min,$hour,$mday,$mon,$year, $wday,$yday,$isdst) = gmtime time;
> my $month = qw(Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec)[$mon];
> return sprintf("%02d %s %d %02d:%02d GMT", $mday, $month, $year + 1900, $hour, $min);
>}
This is easier with POSIX::strftime:
http://search.cpan.org/~nwclark/perl-5.8.4/ext/POSIX/POSIX.pod#strftime
For example:
use POSIX qw(strftime);
$now_string = strftime "%a %b %e %H:%M:%S %Y", gmtime;
|
Assignee | |
Comment 12•21 years ago
|
||
> Ok, so this is better as a script and some source than as a Bugzilla keyword,
> but why HTML source? Seems like it would be much simpler and more robust to
> keep the source in an XML format and use XSLT stylesheets to transform it
into
> HTML and RSS.
HTML source because I don't want to include the whole intro into the feed, and
I'm too lazy to define my own XML format and design an XSLT tranformation.
> In any case, I strongly recommend you use RSS 1 instead of RSS 2.
I'll do both, then. RSS 2 seems the most appropriate. RSS1 and Atom are imo too
picky for this kind of thing.
> In my experience it's better to leave off trailing slashes in filesystem
> paths. It makes them more flexible, since it's easier to add a slash to a
> string than remove one.
The problem is, what do you do if everything's in one directory? Like you said,
it's hard to get rid of slashes. I'll change it if you insist, though.
> Slightly more intuitive as: my $outvars = { ...
I disagree. Keeping outvars as a hash rather than a reference emphasizes it's
hash-ness. That it's passed as a reference is a characteristic of the function
call. I'll change it if you insist.
All other noted problems fixed.
Attachment #148286 -
Attachment is obsolete: true
|
|
Assignee | |
Comment 13•21 years ago
|
||
Attachment #148268 -
Attachment is obsolete: true
|
|
Assignee | |
Comment 14•21 years ago
|
||
|
|
Assignee | |
Comment 15•21 years ago
|
||
moved processing code into a subroutine
Attachment #149018 -
Attachment is obsolete: true
|
|
||
Comment 16•21 years ago
|
||
> The problem is, what do you do if everything's in one directory? Like you said,
> it's hard to get rid of slashes. I'll change it if you insist, though.
No, that wasn't a requirement. Multiple slashes get interpreted as single
slashes by filesystems, though, so that wouldn't be a problem.
>I'll change it if you insist.
No need to change it; it was a nit.
I still think this is better as an XSLT stylesheet transforming an RSS source,
but I guess something is better than nothing. r=myk if you:
1. Make the RSS 1 resource identifiers be the original URLs rather than links to
anchors in the HTML. Some feed readers use those instead of the contents of the
"link" tag, but it's the original URL we want to point people to; there's
nothing at the anchors that can't be found in the feed itself.
2. Make the RSS 2 file be valid XML with the appropriate leading xml declaration.
3. Give the files more specific names like first-bugs-feed.pl,
first-bugs-rss1.tmpl, and first-bugs-rss2.tmpl.
|
||
Comment 17•21 years ago
|
||
I think you meant well-formed XML, right? Also note that the PI is optional, not
required.
|
|
Assignee | |
Comment 18•21 years ago
|
||
Attachment #149122 -
Attachment is obsolete: true
|
|
Assignee | |
Comment 19•21 years ago
|
||
rss2.tmpl hasn't changed (I haven't seen any RSS2 feeds with XML PIs). You can
just call it bug-feed-rss2.tmpl when you save it to disk before checkin.
Attachment #149020 -
Attachment is obsolete: true
|
|
||
Comment 20•21 years ago
|
||
> rss2.tmpl hasn't changed (I haven't seen any RSS2 feeds with XML PIs). You can
> just call it bug-feed-rss2.tmpl when you save it to disk before checkin.
r=myk; is there some reason why I need to check this in instead of you, and how
is the rebuild going to get triggered?
|
|
||
Updated•21 years ago
|
Assignee: myk → fantasai.bugs
QA Contact: stolenclover → myk
|
|
Assignee | |
Comment 21•21 years ago
|
||
The rebuild needs a cron job (which doesn't need to be as frequent as the
website) or I need to write changes to something else to make the normal build
process build it. You get to pick. :) I can't check it in because I don't have
access to the tools directory.
|
|
||
Comment 22•21 years ago
|
||
If I get to pick, then make it be changes to the build scripts. That's how we
do other similar things (like generating news.html).
|
|
Assignee | |
Comment 23•21 years ago
|
||
Attachment #149356 -
Attachment is obsolete: true
|
|
Assignee | |
Comment 24•21 years ago
|
||
To fix this:
- apply patch
- add files to /tools:
- bug-feed.pl
- bug-feed-rss1.tmpl
- bug-feed-rss2.tmpl (rss2.tmpl on the attachment list)
|
|
Assignee | |
Comment 25•21 years ago
|
||
David, could you check this in, please?
Putting it in the else of the initialization code doesn't make sense. It
belongs in main.
|
|
Assignee | |
Comment 27•21 years ago
|
||
Attachment #151300 -
Attachment is obsolete: true
Sorry I didn't get to this for so long.
So, um, what good is printing out "perl bug-feed.pl"?
Also, when I said "in main", I meant "in the function main".
Oh, right, backquotes. So you're printing out its output. That seems a
roundabout way of doing things. But I probably shouldn't be trying to review
code at 1am.
But invoking perl by name really isn't a good idea, since it doesn't allow
people to use a perl other than the first in their path. I'll change this to
use require before checking in.
And I'm also not that happy of tainting the source directory. Scripts should
put things into output.
So this is a complete patch with the changes I mention, and also making the
error handling a bit less fatal.
However, I don't have template toolkit on my machine and I don't want to mess
with perl modules right now, so I haven't tested this at all. And, for that
matter, I'm not sure the web server does either...
|
|
Assignee | |
Comment 33•21 years ago
|
||
I can test it for you.
If we didn't have the TT modules installed, I expect Myk would have said
something by now.
The more serious issue is that this adds an additional requirement to anybody
testing changes to the website.
That said, if we can just not build those files if TT isn't installed, that
would probably be fine.
|
|
||
Comment 36•21 years ago
|
||
There is a little error in attachment 149357 [details] :
We must prefixe the resource attribute.
This is a working version of the previous patch, although it gives:
Use of uninitialized value in pattern match (m//) at tools/bug-feed.pl line 50,
<VARIABLES> line 164 (#1)
(W uninitialized) An undefined value was used as if it were already
defined. It was interpreted as a "" or a 0, but maybe it was a mistake.
To suppress this warning assign a defined value to your variables.
To help you figure out what was undefined, perl tells you what operation
you used the undefined value in. Note, however, that perl optimizes your
program and the operation displayed in the warning may not necessarily
appear literally in your program. For example, "that $foo" is
usually optimized into "that " . $foo, and the warning will refer to
the concatenation (.) operator, even though there is no . in your
program.
Attachment #154268 -
Attachment is obsolete: true
(In reply to comment #11)
> >$_ = <FIXLIST> until (/<head>/);
>
> Note that you rarely need parentheses around conditions in side-effect
> notation, i.e. you can say just:
>
> $_ = <FIXLIST> until /<head>/;
I undid this change since it caused the warning in comment 37.
I'm going to check in the attachment 159263 [details] [diff] [review] with that one change shortly.
Checked in. Should appear at
http://www.mozilla.org/contribute/hacking/first-bugs/rss1 and
http://www.mozilla.org/contribute/hacking/first-bugs/rss2 within the next 20
minutes.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
|
|
||
Comment 40•21 years ago
|
||
The first bugs page, <http://www.mozilla.org/contribute/hacking/first-bugs/>,
should have two '<link rel="alternate">' to point to the feeds.
Now we see why '<link rel="alternate" type="application/xml" title="RSS"
href="http://www.mozilla.org/news.rdf">' shouldn't be added to every file...
|
||
Comment 41•21 years ago
|
||
I've been getting the following email from rheet every 5 minutes since
approximately 4:30pm on the 17th:
Date: Mon, 20 Sep 2004 01:04:23 -0700
From: root@rheet.mozilla.org (Cron Daemon)
To: root@rheet.mozilla.org
Subject: Cron <root@rheet> /usr/local/bin/dostage
X-Cron-Env: <SHELL=/bin/sh>
X-Cron-Env: <HOME=/root>
X-Cron-Env: <PATH=/usr/bin:/bin>
X-Cron-Env: <LOGNAME=root>
Use of uninitialized value in pattern match (m//) at tools/bug-feed.pl line 50,
<VARIABLES> line 1803262 (#1)
(W uninitialized) An undefined value was used as if it were already
defined. It was interpreted as a "" or a 0, but maybe it was a mistake.
To suppress this warning assign a defined value to your variables.
To help you figure out what was undefined, perl tells you what operation
you used the undefined value in. Note, however, that perl optimizes your
program and the operation displayed in the warning may not necessarily
appear literally in your program. For example, "that $foo" is
usually optimized into "that " . $foo, and the warning will refer to
the concatenation (.) operator, even though there is no . in your
program.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Warning should be fixed now (as should dependencies, which are what confused me
before).
Status: REOPENED → RESOLVED
Closed: 21 years ago → 21 years ago
Resolution: --- → FIXED
|
||
Updated•17 years ago
|
Product: mozilla.org → Websites
|
|
||
Updated•13 years ago
|
Component: www.mozilla.org → General
Product: Websites → www.mozilla.org
You need to log in
before you can comment on or make changes to this bug.
Description
•