Mozilla.org Publishing Workflows
 Share
The version of the browser you are using is no longer supported. Please upgrade to a supported browser.Dismiss

View only
 
ABCDEFGHIJKLMNOPQRSTUVWX
1
stakeholderteamtype (experimental)titlesvn repopublishes topublish frequencycontent publishedworkflow detailscontent item sampleother notesbug
2
akeyblRelease Teamrelease supportNew Release Noteshttp://viewvc.svn.mozilla.org/vc/projects/mozilla.com/trunk/en-US/firefox/https://www.mozilla.org/en-US/{firefox,mobile}/19.0/releasenotes/ (example)Every FF releaseIncludes first run (displayed upon installation), system requirements, what's new (displayed upon update for non-Mozilla, like Linux, installs), as well as release notes.add some rows to sqllite notes; generates release note content; copies over system requirements, firstrun, whatnew; edits requirements as necessary in place; pushes it onto trunk; reviews; svn copy to stage/prod; check it again; modify .htaccess (aurora/.../notes points to the most recent versions, etc.) - https://wiki.mozilla.org/Release_Management/Release_Notes_and_Product_Detailshttps://www.mozilla.org/en-US/firefox/20.0.1/releasenotes/ there's a sqlite database (in dropbox) of releases, versions, features, bugs (found in version, fixed in version) that is used for automated generation of this content (using jinja); but these pages are also tweaked by hand now and then. sqlite data goes back to FF10 (early 2012); it shouldn't be used to regenerate existing content in a new system since existing content may have been hand modified after generation. in other words, PHP is not needed. the ESR pages are maintained by hand. they would welcome any changes that made this dynamic: i.e. their database changes would land on a website. the process doesn't change much. there's no need for this content to be protected/confidential prior to release. they are eager to have a better system/process
3
akeyblRelease Teamrelease supportRelease notes archivehttps://www.mozilla.org/en-US/firefox/releases/Statically linking to all available desktop release notes
4
akeyblRelease Teamrelease supportFirefox download buttonshttps://www.mozilla.org/en-US/firefox/new/, https://www.mozilla.org/en-US/firefox/beta/,https://www.mozilla.org/en-US/firefox/channel/update product-details, svn propedit svn:externals tags/{stage,production}/includes (mozilla china as well), push, restart bedrock/apache?new links to new binaries at https://www.mozilla.org/en-US/firefox/fx/#desktop and on https://www.mozilla.org/en-US/firefox/all/
5
akeyblRelease Teamrelease supportFirefox Nightlieshttp://www.mozilla.org/projects/firefox/prerelease.htmlRedirected (or in-client) first run page for Nightlies.We're going to build a new nightly first run page per https://bugzilla.mozilla.org/show_bug.cgi?id=964919
6
Al BillingsSecuritysecurity announcementsSecurity Advisories
http://www.mozilla.org/security/announce/Every FF releaseNew lines on several index pages; new pages for each new lineA new security vulnerability is discovered. A security team member copies the HTML/CSS from an existing advisory and changes the content to reflect the circumstances of the new advisory. The advisory is emailed to various parties for review and correction. When the new version of FF is made available, the advisory is committed to SVN and automatically published to the live site.http://www.mozilla.org/security/announce/2013/mfsa2013-28.htmlExtremely important that draft advisories not be public.
7
Gervdata-driven listsCreditshttp://viewvc.svn.mozilla.org/vc/projects/mozilla.org/trunk/credits/http://www.mozilla.org/credits/One checkin per name, done in batches every so often.New names in long list of names.Gerv opens his email folder of stored credits requests. For each one, he formulates a "credit" line: Name <email>: "Citation", and passes it to a Perl script. The script formats the name, checks for duplicates, inserts it in the correctly-ordered place in the list and fires off a checkin. (This used to be a time-consuming and error-prone manual process.)"Justin Crawford, " in the file itself, and the email address and citation of what they did appear in the checkin log (which is itself part of the historical record).Accessible in-product via a special URL, but that shows the web copy, not a shipped copy; the SVN history is valuable in this repo in particular.https://bugzilla.mozilla.org/show_bug.cgi?id=801909
8
Gervpage contentCredits FAQhttp://viewvc.svn.mozilla.org/vc/projects/mozilla.org/trunk/credits/faqhttp://www.mozilla.org/credits/faq/RarelyNew FAQs.Edit HTML and publish.
9
Gervdata-driven listsForumshttp://viewvc.svn.mozilla.org/vc/projects/mozilla.org/trunk/about/forums/http://www.mozilla.org/about/forums/RandomNew line itemsA new forum for communication is requested by someone filing a bug. When it's approved, Gerv adds the name and description to a data files, and then runs a perl script that converts the data to HTML (read line, split on whitespace, generate urls, sort, wrap in markup, output), inserts the HTML into the middle of the containing file and commits changes to SVN.mozilla.airmozilla
For discussions related to Mozilla's video distribution site, Air Mozilla. (Moderated)
10
Gervpolicy (page content)MPL License Policy/MPL/license-policy.htmlRarelyOnce changes are discussed and approved, edit HTML and publish.In a thread in May 2013, discussed just using static pages in a repo for this since a publishing solution doesn't add much value for one-off HTML pages. Justin suggests: create generic MPL bedrock template, child templates that contain content, move anything possible to someplace other than www, take changes via PR from Gerv.https://bugzilla.mozilla.org/show_bug.cgi?id=987852
11
Gervpolicy (page content)Commit Access Policyhttps://www.mozilla.org/hacking/commit-access-policy/index.htmlRarelyChanges to policy, as and when necessaryOnce changes are approved, edit HTML (and .odt and generate a PDF) and publish.Important that this item be not randomly modifiable by others
12
Gervpolicy (page content)IDN TLD Policy listhttp://viewvc.svn.mozilla.org/vc/projects/mozilla.org/trunk/projects/security/tld-idn-policy-list.htmlwww.mozilla.org/projects/security/tld-idn-policy-list.htmlInfrequentlyNew additions to IDN TLD whitelistThis list is going away when we implement the new algorithm, so it's included as an item here merely for completeness.
13
Gervpolicy (page content)Hacking (policies & procedures for writing code on Mozilla projects)/hacking/*
14
standard8release supportThunderbird Release Noteshttp://viewvc.svn.mozilla.org/vc/projects/mozilla.org/trunk/thunderbird/en-US/thunderbird/17.0.4esr/releasenotes/http://www.mozilla.org/en-US/thunderbird/17.0.4/releasenotes/ (example)Every Thunderbird releaseNew release notes directory containing bugslist.html and index.html. A new download button?
15
dboswell and cmoredata-driven listsSite directoryhttp://www.mozilla.org/community/directory.htmlcmore runs a batch script that creates this output, which he checks into svnNote: moving to Bedrock as static pagehttps://bugzilla.mozilla.org/show_bug.cgi?id=885797
16
Kathleen Wilsonpolicy (page content)http://www.mozilla.org/projects/security/certs/policy/
17
Kathleen Wilsondata-driven listshttp://www.mozilla.org/projects/security/certs/pending/
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
Loading...