Index: head/en_US.ISO8859-1/htdocs/cgi/monthly.cgi =================================================================== --- head/en_US.ISO8859-1/htdocs/cgi/monthly.cgi (revision 52305) +++ head/en_US.ISO8859-1/htdocs/cgi/monthly.cgi (nonexistent) @@ -1,275 +0,0 @@ -#!/usr/bin/perl -w -# $FreeBSD$ - -require "./cgi-style.pl"; - -use CGI qw(:all); -use strict; - -my $Submit = param("Submit"); -my $debug = param("debug") || ""; - -my $NumDevelopers = 3; -my $NumLinks = 4; -my $NumSponsors = 2; -my $NumTasks = 5; - -my @messages; - -# -# Routine to format some xml nicely -# -sub xml -{ - my($Indent, $TagEtc, @Text) = @_; - - my($Tag, $Etc) = split(' ', $TagEtc, 2); - - my $Spaces = " " x ($Indent*2); - if (!@Text) - { - # No text in the tag - return ("$Spaces<$TagEtc />\n"); - } - elsif (@Text == 1) - { - # Bottom level tag - output on one line - return ("$Spaces<$TagEtc>@Text\n"); - } - else - { - # This is not a bottom level tag - output a new line after - # starting tag - return ("$Spaces<$TagEtc>\n", - @Text, - "$Spaces\n"); - } -} - -# -# As above to format indented text but no tag -# -sub xmltext -{ - my($Indent, @Text) = @_; - - my $Spaces = " " x ($Indent*2); - - return map { "$Spaces$_\n" } @Text; -} - -if ($Submit) -{ - my $errors = 0; - - my @hidden; - - my $Project = param("Project") || ""; - my $Category = param("Category") || "misc"; - push(@hidden, hidden("Project")); - - my @contacts; - foreach my $Num (1..$NumDevelopers) - { - my $fname = param("FirstName$Num") || ""; - my $lname = param("LastName$Num") || ""; - my $email = param("Email$Num") || ""; - - push(@hidden, hidden("FirstName$Num")); - push(@hidden, hidden("LastName$Num")); - push(@hidden, hidden("Email$Num")); - - next unless $fname || $lname || $email; - - my @name; - push(@name, xml(4, 'given', $fname)) if $fname; - push(@name, xml(4, 'common', $lname)) if $lname; - - my @person; - push(@person, xml(3, 'name', "", @name)) if @name; - push(@person, xml(3, 'email', $email)) if $email; - - push(@contacts, xml(2, 'person', "", @person)); - } - - if (!@contacts) - { - ++$errors; - push(@messages, b("Please specify at least one contact")); - } - - my @links; - foreach my $Num (1..$NumLinks) - { - my $url = param("Url$Num") || ""; - my $desc = param("Desc$Num") || ""; - - push(@hidden, hidden("Url$Num")); - push(@hidden, hidden("Desc$Num")); - - next unless $url; - my @link; - if ($desc) - { - push(@links, xml(2, "url href=\"$url\"", $desc)); - } - else - { - push(@links, xml(2, "url href=\"$url\"")); - } - } - - my @sponsors; - foreach my $Num (1..$NumSponsors) - { - my $sponsor = param("Sponsor$Num") || ""; - push(@hidden, hidden("Sponsor$Num")); - - next unless $sponsor; - push(@sponsors, xml(1, "sponsor", "", xmltext(2, $sponsor))); - } - - if (@sponsors) - { - push(@sponsors, "\n"); - } - - my @tasks; - foreach my $Num (1..$NumTasks) - { - my $desc = param("Task$Num") || ""; - $desc =~ s/\r//g; - my @desc = split("\n", $desc); - - push(@hidden, hidden("Task$Num")); - - next unless $desc; - push(@tasks, xml(2, "task", "",xmltext(3, @desc))); - } - - my $info = param("SubmittedInfo") || ""; - push(@hidden, hidden("SubmittedInfo")); - - $info =~ s/\r//g; - my @info = split("\n", $info); - - my $title = "FreeBSD project submission output"; - - my @contents = xml(0, "project cat=\'$Category\'", - xml(1, "title", $Project), - "\n", - xml(1, "contact", "", @contacts), - "\n", - xml(1, "links", "", @links), - "\n", - xml(1, "body", - xml(2, "p", "", xmltext(3, @info))), - "\n", - @sponsors, - xml(1, "help", "", @tasks), - ); - my $contents = join('', @contents); - - $contents = "\n$contents"; - - if (!$errors) - { - print "Content-Type: text/plain\n\n"; - print $contents; - exit; - } -} - -my @DeveloperTable; -foreach my $Num (1..$NumDevelopers) -{ - push(@DeveloperTable, - TR(td(textfield(-name => "FirstName$Num", -size => 20)), - td(textfield(-name => "LastName$Num", -size => 20)), - td(textfield(-name => "Email$Num", -size => 32)))); -} - -my @LinksTable; -foreach my $Num (1..$NumLinks) -{ - push(@LinksTable, - TR(td(textfield(-name => "Url$Num", -size => 55)), - td(textfield(-name => "Desc$Num", -size => 20)))); -} - -my @SponsorTable; -foreach my $Num (1..$NumSponsors) -{ - push(@SponsorTable, - TR(td(textarea(-name => "Sponsor$Num", -rows => 1, -cols => 60)))); -} - -my @TaskTable; -foreach my $Num (1..$NumTasks) -{ - push(@TaskTable, - TR(td(textarea(-name => "Task$Num", -rows => 3, -cols => 60)))); -} - -print - (html_header("Submitting a FreeBSD Project Status Report"), - hr, - join("
\n", @messages, ""), - p("To submit status information about a FreeBSD project, fill out the", - " following:"), - start_form(), - - h3("Project:"), - textfield(-name => "Project", -size => "32"), - - h3("Category:"), - popup_menu(-name => "Category", - -values => ['proj', 'doc', 'kern', 'bin', 'arch', 'ports', 'vendor', - 'misc', 'soc', 'team'], -default => 'proj'), - - h3("Developers:"), - blockquote(table({"BORDER" => 0, - "COLS" => 3, - "NOSAVE" => 1}, - TR(td("First Name"), - td("Family Name"), - td("Email address")), - @DeveloperTable)), - - h3("Links:"), - blockquote(table({"BORDER" => 0, - "COLS" => 2, - "NOSAVE" => 1}, - TR(td("Url"), - td("Description")), - @LinksTable)), - - h3("Present status:"), - p("You can use "simple" HTML tags (e.g. <p>, ", - "<em>, <strong> and <a href=... >) to format."), - blockquote(textarea(-name => "SubmittedInfo", - -rows => 7, - -cols => 60)), - - h3("Sponsors (optional):"), - blockquote(table({"BORDER" => 0, - "COLS" => 1, - "NOSAVE" => 1}, - TR(td("Name")), - @SponsorTable)), - - h3("Open tasks (optional):"), - blockquote(table({"BORDER" => 0, - "COLS" => 5, - "NOSAVE" => 1}, - TR(td("Description")), - @TaskTable)), - - - submit(-name => "Submit", -label => "Download XML"), - reset(-value => "Reset"), - br, - end_form(), - html_footer()); - -__END__ Property changes on: head/en_US.ISO8859-1/htdocs/cgi/monthly.cgi ___________________________________________________________________ Deleted: svn:executable ## -1 +0,0 ## -* \ No newline at end of property Deleted: svn:keywords ## -1 +0,0 ## -FreeBSD=%H \ No newline at end of property Index: head/en_US.ISO8859-1/htdocs/cgi/Makefile =================================================================== --- head/en_US.ISO8859-1/htdocs/cgi/Makefile (revision 52305) +++ head/en_US.ISO8859-1/htdocs/cgi/Makefile (revision 52306) @@ -1,29 +1,28 @@ # $FreeBSD$ .if exists(../Makefile.conf) .include "../Makefile.conf" .endif .if exists(../Makefile.inc) .include "../Makefile.inc" .endif DATA= DATA+= cgi-lib.pl DATA+= cgi-style.pl CGI= CGI+= fingerprints.cgi CGI+= getmsg.cgi CGI+= mailindex.cgi CGI+= man.cgi CGI+= mid.cgi CGI+= mirror.cgi -CGI+= monthly.cgi CGI+= ports.cgi .SUFFIXES: .C .cgi .C.cgi: ${CXX} ${CFLAGS} -o ${.TARGET} ${.IMPSRC} .include "${DOC_PREFIX}/share/mk/web.site.mk" Index: head/en_US.ISO8859-1/htdocs/news/status/README =================================================================== --- head/en_US.ISO8859-1/htdocs/news/status/README (revision 52305) +++ head/en_US.ISO8859-1/htdocs/news/status/README (revision 52306) @@ -1,178 +1,177 @@ Compiling status reports - best practices 0) Timeline (relative to submission deadline) -1 month First call for reports -2 weeks Reminder -1 week Reminder, and follow up with teams and individuals we expect to submit reports deadline Follow up on missing reports Continue editing individual reports Continue adding new (late) reports as they arrive +1 week Edit overall report and write introduction +10 days Publish report 1) Call for reports - Are usually sent to freebsd-hackers@ CC freebsd-current@ as the lists with the most usual suspects for submitting reports. Forward to developers@ as well. Also ping individuals which are known to have something cooking. - The xml-template is at: - https://www.freebsd.org/news/status/report-sample.xml and the generator - CGI at: https://www.freebsd.org/cgi/monthly.cgi at the time of this - writing. Make sure to keep them up to date with regard to categories + https://www.freebsd.org/news/status/report-sample.xml at the time of this + writing. Make sure to keep it up to date with regard to categories to pick from and place them prominently in the CFR - otherwise people submit plain text reports and you have to format them yourself. - Reporting howto is at: https://www.freebsd.org/news/status/howto.html. It contains a great deal of useful hints for the submitters on how to write good reports. But it also helps to forward all the completed reports to developers for reference, and point to the latest report in the CFR. - It may also be worth making a call for reports on the forums as was done here: https://forums.freebsd.org/threads/call-for-freebsd-2014q4-october-december-status-reports.49812/ 2) In the past we usually had to extend the deadline by a week in order to get everybody to report. Starting early with kind reminders seems to help ;) Ideally, reminders should be sent at least one month before the deadline. But it is worthwhile the keep sending reminders two weeks before the deadline and on the day of the deadline. 3) The following groups should be definitely approached for a report on their recent activities: - core@, portmgr@, doceng@, secteam@, re@, postmaster@, clusteradm@, devsummit@ (team reports). - FreeBSD Foundation (emaste@), participants of Foundation-sponsored projects, deb@ (Deb Goodkin) can also do a report for the Foundation itself. - Various conference organizers, depending on the season: - BSDCan (info@bsdcan.org) May (April-June) - EuroBSDcon (foundation@eurobsdcon.org) Sept-Oct (October-December) - AsiaBSDCon (secretary@asiabsdcon.org) March (January-March) - Google Summer of Code students and their mentors (soc-students@ and soc-mentors@, April-June, July-September). - All submitters for the previous quarterly status report (they may have updates or further improvements). Our readers seem to value these reports, so we should try to get them in if at all possible. 4) Building the report: - Fold the reports into a work-in-progress draft as they are coming in (see point 5) for putting the report together). Commit the result and hook the draft into the build, so you can (almost) immediately provide the submitters a preview of their entries. This is also a good excuse to do a acknowledgement on the receipt. - While the report draft is kept updated, other doc-committers (wblock, pluknet, and bjk, for example) may review the individual entries and propose fixes. - As mentioned above, the received reports should be in a single .xml file, where tidy(1) may be used to get them well-formatted. Usually s without a description are missing the closing "/>" which is the cause for most of the errors you will encounter. Sometimes other closing tags are missing. - Invoking tidy with the following options seems to cause the fewest problems: tidy -xml -i -wrap 74 -latin1 -preserve - Some special characters still break with that - noticed when sos@ submits a report. - Remove empty "" sections, they cause a strange looking newline. - The part usually needs a hand to make it proper html. Use here, not . - Lists come out best if you close the

before and start a new one after, like: ... blabla:

  • some item

Some more blabla ... 5) Wrapping the whole thing in a report template: - Use a filename of yyyy-mm-yyyy-mm.xml for the new report, where the first mm is the starting month and the second mm is the ending month. - Create the new report by copying report-template.xml and replacing the variables in it with actual values. Or 'svn cp' a previous report and make sure the new file has the svn:mime-type set to text/xml with 'svn propget svn:mime-type'. - Add the new file to the XMLDOCS entries in the Makefile. - Categories are subject to change obviously. They come out in the order as stated in the report. After another round of tidy(1) try to balance the categories. Put things where they belong best, retire categories that do not fill up, etc. Adding it to your local build and looking at the html helps. Make sure you have an up-to-date doc tree. - theraven may be poked for composing a nice introduction for the reports. But should be usually the last step in the process; a good introduction can be only written once the report is considered finished. - wblock suggests that we ask different people to write introductions to add variety. Different people will bring different viewpoints and help keep it fresh. 6) Committing it: - Files to edit and commit: In doc/en_US.ISO8859-1/htdocs/news/status/ : The quarterly report itself: report-yyyy-mm-yyyy-mm.xml Update the next due date on the status report page and add a link to the new report below that: status.xml In doc/share/xml/ : The news entry for the main website page: news.xml Sample: June-October 2006 Status Report

The June to October 2006 Status Report is now available with 49 entries.

- Extract a text version with the command /usr/local/bin/lynx -dump -nolist ./report-yyyy-mm-yyyy-mm.html \ | /usr/bin/iconv -f ISO-8859-1 -t UTF-8 \ | sed -e 's%Napieral/a%Napierała%g' > report.txt and prettify it. lynx defaults to a width of 80 and will forcibly wrap URLs to fit within that size. The prettification process includes undoing that wrapping of URLS, and also fixing any cases where the name and email for a contact person have been placed onto different lines. In some cases lynx will refuse to output certain Unicode characters (such as the U+0142 LATIN SMALL LETTER L WITH STROKE found in trasz's surname), instead using an ASCII transliteration; these should be returned to the UTF-8 form. For the Links sections, put the title on one line, and the URL: on the following line, indented by an additional space than the title. Change the "Introduction" heading to read "FreeBSD Project Quarterly Status Report - Quarter " - Send out To: announce@ Subject: FreeBSD Quarterly Status Report - Quarter This one must be approved, so find someone (mail postmaster) who can do that before starting. Send a separate mail: To: hackers CC: current, stable BCC: developers 7) Repeat. Index: head/en_US.ISO8859-1/htdocs/news/status/howto.xml =================================================================== --- head/en_US.ISO8859-1/htdocs/news/status/howto.xml (revision 52305) +++ head/en_US.ISO8859-1/htdocs/news/status/howto.xml (revision 52306) @@ -1,117 +1,117 @@ ]> &title; $FreeBSD$

&os; status reports are published quarterly and provide the general public with a view of what is going on in the Project, and they are often augmented by special reports from Developer Summits. As they are one of our most visible forms of communication, they are very important. This page will provide some advice on writing status report entries from David Chisnall, experienced in technical writing.

Do not worry if you are not a native English speaker. The team - handling status reports, monthly@FreeBSD.org, will check + handling status reports, quarterly@FreeBSD.org, will check your entries for spelling and grammar, and fix it for you.

Introduce Your Work

Do not assume that the person reading the report knows about your project.

The status reports have a wide distribution. They are often one of the top news items on the &os; web site and are one of the first things that people will read if they want to know a bit about what &os; is. Consider this example:

abc(4) support was added, including frobnicator compatibility.

Someone reading this, if they are familiar with UNIX man pages, will know that abc(4) is some kind of device. But why should the reader care? What kind of device is it? Compare with this version:

A new driver, abc(4), was added to the tree, bringing support for
 Yoyodyne's range Frobnicator of network interfaces.

Now the reader knows that abc is a network interface driver. Even if they do not use any Yoyodyne products, you have communicated that &os;'s support for network devices is improving.

Show the Importance of Your Work

Status reports are not just about telling everyone that things were done, they also need to explain why they were done.

Carry on with the previous example. Why is it interesting that we now support Yoyodyne Frobnicator cards? Are they widespread? Are they used in a specific popular device? Are they used in a particular niche where &os; has (or would like to have) a presence? Are they the fastest network cards on the planet? Status reports often say things like this:

We imported Cyberdyne Systems T800 into the tree.

And then they stop. Maybe the reader is an avid Cyberdyne fan and knows what exciting new features the T800 brings. This is unlikely. It is far more likely that they have vaguely heard of whatever you have imported (especially into the ports tree: remember that there are over 20,000 other things there too...). List some of the new features, or bug fixes. Tell them why it is a good thing that we have the new version.

Tell Us Something New

Do not recycle the same status report items.

Bear in mind that status reports are not just reports on the status of the project, they are reports on the change of status of the project. If there is an ongoing project, spend a couple of sentences introducing it, but then spend the rest of the report talking about the new work. What progress have been made since the last report? What is left to do? When is it likely to be finished (or, if finished does not really apply, when is it likely to be ready for wider use, for testing, for deployment in production, and so on)?

Sponsorship

Do not forget about your sponsors.

If you or your project has received sponsorship, a scholarship from somebody or you have been already working as a contractor or an employee for a company, please include it. Sponsors always certainly appreciate if you thank them for their funding, but it is also beneficial for them to show that they are actively supporting the Project this way. Last, but not least, this helps &os; to learn more about its important consumers.

Open Items

If help is needed, make this explicit!

Is there any help needed with something? Are there tasks other people can do? There are two ways in which you can use the open items part of the status report: to solicit help, or to give a quick overview of the amount of work left. If there is already enough people working on the project, or it is in a state where adding more people would not speed it up, then the latter is better. Give some big work items that are in progress, and maybe indicate who is focussing on each one.

List tasks, with enough detail that people know if they are likely to be able to do them, and invite people to get in contact.

Back to the main page

Index: head/en_US.ISO8859-1/htdocs/news/status/status.xml =================================================================== --- head/en_US.ISO8859-1/htdocs/news/status/status.xml (revision 52305) +++ head/en_US.ISO8859-1/htdocs/news/status/status.xml (revision 52306) @@ -1,279 +1,278 @@ ]> &title; $FreeBSD$ -

Next Quarterly Status Report submissions (July – - September) due: January 14th, 2018

+

Next Quarterly Status Report submissions (October, 2017 – + September, 2018) due: October 31th, 2018

-

Use the xml - generator or download and edit the - xml-template. Submissions should be submitted by e-mail to - monthly@FreeBSD.org.

- +

Submit your entries as Pull Requests from your fork of + FreeBSD + Quarterly Status Reports GitHub repo or submit them via e-mail to + quarterly@FreeBSD.org.

One of the benefits of the FreeBSD development model is a focus on centralized design and implementation, in which the operating system is maintained in a central repository, and discussed on centrally maintained lists. This allows for a high level of coordination between authors of various components of the system, and allows policies to be enforced over the entire system, covering issues ranging from architecture to style. However, as the FreeBSD developer community has grown, and the rate of both mailing list traffic and tree modifications has increased, making it difficult even for the most dedicated developer to remain on top of all the work going on in the tree.

The &os; Development Status Report attempts to address this problem by providing a vehicle that allows developers to make the broader community aware of their on-going work on FreeBSD, both in and out of the central source repository. For each project and sub-project, a one paragraph summary is included, indicating progress since the last summary. If it is a new project, or if a project has not submitted any prior status reports, a short description may precede the status information.

For more exact guidelines on how to write good status reports, please consult our recommendations.

Periodically, special status reports are prepared and published. One of those are the developer summit reports. Developer summits are places where developers meet in person to discuss issues related to the project. They are definitely worth attending if one is interested in making significant contributions to the Project and they are open to anybody!

These status reports may be reproduced in whole or in part, as long as the source is clearly identified and appropriate credit given.

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

Index: head/en_US.ISO8859-1/htdocs/robots.txt =================================================================== --- head/en_US.ISO8859-1/htdocs/robots.txt (revision 52305) +++ head/en_US.ISO8859-1/htdocs/robots.txt (revision 52306) @@ -1,20 +1,19 @@ # $FreeBSD$ User-agent: * #Crawl-delay: 10 Disallow: /cgi/confirm-code.cgi Disallow: /cgi/cvsweb.cgi Disallow: /cgi/dosendpr.cgi Disallow: /cgi/getmsg.cgi Disallow: /cgi/mailindex.cgi #Disallow: /cgi/man.cgi Disallow: /cgi/mid.cgi Disallow: /cgi/mirror.cgi Disallow: /cgi/missing_handler.cgi -Disallow: /cgi/monthly.cgi Disallow: /cgi/ports.cgi Disallow: /cgi/query-pr-summary.cgi Disallow: /cgi/query-pr.cgi Disallow: /cgi/search.cgi Disallow: /cgi/url.cgi Disallow: /statistic