We have gerrit-dash-creator and https://tiny.cc/ReleaseInbox, but both
require manual steps to be taken by someone each time the status of a
series changes. Since we already capture series status data in a format
that is easily parsable, let's just add a sphinx directive to make this
automatic.
Change-Id: I05b2a65b52809d249bfb299164d624f6de5bff02
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
Clarify language used in the page.
Only list teams with active deliverables (current or still
under maintenance) in the Teams section. This allows to stop
mentioning long-gone teams like Astara or Cue or Fuel.
Change-Id: Ic41020606febf69769825f904255c915784791a1
Cycle-trailing deliverables are regular cycle-following deliverables,
using RCs or not not using RCs -- they just have a different deadline.
Rather than using a release model, those deadline variants are better
described using deliverable types, in much the same way 'library'
deliverables have a specific deadline too.
This simplifies the list of models significantly, and allows to have
proposer validation of trailing deliverables that use RCs or not use
RCs.
For compatibility in old branches, setting 'cycle-trailing' is still
supported, it will just overload the type to 'trailing' if specified.
Change-Id: Ifce88ef3e5dd406f45f25214699f16e736ad5377
Team pages on releases.o.o sort 'Independent' releases between
'Juno' and 'Icehouse', which is pretty confusing. List independent
releases last, if any.
Change-Id: If702f3b1d3fb4a2583172ce0946450b89a14d168
The highlights extension attempted to be helpful by pulling in team
details from governance into the generated highlights output. This did
not account for the possiblity that teams may actually leave official
OpenStack governance, and therefore may not have these details present
in the governance output.
This adds handling to fail gracefully in this scenario by just not
trying to include the information that is no longer there.
Change-Id: Iee97b9547a2044acd86864f788f7ba1294afbf0a
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
This makes sphinx-build use the number of cores available to make the
docs build parallel. On my 16 core system, this cut the time by ~50%. We
don't have as many cores available in the gate, but it should provide a
slight improvement in overall job time.
Change-Id: I7ad4d87a3dba10475a0fcf797a9aa2d4b1ad0eb5
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
In releases.o.o we display signature links for all deliverables,
if the series is > Ocata or independent. Since some "independent"
deliverables predate the signature generation tooling, that results
in a number of "independent" deliverables displaying broken signature
links, which makes us look bad.
This adds a flag (skipped-sig) that can be set for independent
deliverables that did not have any signature generated (pre-Ocata), and
skips the signature link display if the flag is set.
As a practical example, this fixes broken links for PBR<2. Tony signed
up to automatically generate the others.
Change-Id: I44a49e3f08010a85c64673d2292528139eabcc99
This updates our sphinx extension to show abandoned deliverables
as EOL, in a separate section at the bottom of the independent
deliverables page. It adds an 'EOL' mention to such deliverables
on team pages.
Change-Id: I56b9fbad9314c523e2f18765371746d21a71ed88
We have been filtering whether to include pgp links for deliverables if
the series was >= 'O', which resulted in filtering out any independent
deliverables.
This updates the check to account for independent deliverables. It also
makes the table format consistent for pre- and post-Ocata, just leaving
the column blank for series where we did not generate signatures.
Change-Id: I0c9f97cb12a429d2e54d94df2b3e110156278bc1
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
Our docs job has a lot of output that is not generally very useful.
Rather than bloating our log files, this switches some log calls over to
debug level so they are only emitted if needed.
Change-Id: Id0440ef506d0bc896d6dd4ba30473f430a6606dd
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
We want these tags in git for developers and those working directly with
the source code, but we do not want to have these listed on the releases
site. Consumers of the site are just looking for actual official
releases they can use, so we should avoid confusion by not including
these "internal" tags.
Change-Id: I6a3fcc11efed6254ea6fb95579eafe5288508661
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
After observing errors from importing our iCal into Outlook, I found
there were a few issues with our generated output according to [0].
This adds an overall VERSION to the iCal and sets per event timestamps
and UIDs.
This also updates YAML loading to use safe_load to get rid of a
deprecation warning noticed while testing.
[0] https://icalendar.org/validator.html?url=https://releases.openstack.org/schedule.ics
Change-Id: I3803a432da2538af4de163b77c192130366ddadf
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
Adding liaisons to deliverables where there is a liasion listed here:
https://wiki.openstack.org/wiki/CrossProjectLiaisons#Release_management
Also creates a data dir to put the non deliverable files that were in the
deliverables dir elsewhere and updates filepaths to reflect the change.
Story: 2005702
Task: 31024
Change-Id: Idc5f4b29dd375465b21d678fa8503cbd8d6d3eb6
With a large number of deliverables and different deliverable types, the
documentation output for a release series can get very long and it's not
always obvious that there are different groups of types if you scroll
all the way down.
This updates our deliverable extension to include a table of contents at
the top of the output to add convenient links to the different groups of
deliverables.
Change-Id: I3c55057320661f7167d44138941a07fd38c3c81f
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
In Ib5d35169e68cd92b666a35705d8e36942bd28b89 (Use a template to generate
the 'whereto' testing data) I did the simple copy'n'paste instead of
factoring the common code into a helper function.
Fix that
Change-Id: I3f0b93dd57db4811ed5c04a5a01a7ecca7ff539c
Once we have the nest series in series_status.yaml we can add
redirections for those constraints too. This allows us, should we want
to, to have branches refer to the series by name, instead of 'master'.
Change-Id: I0035190d11bf0c0bb43119fde18b5dc22d2cc1a0
As we add more branches and tags we don't want to manually add tests for
them (and we'd need to or the docs build will fail with an 'Untested
Rule'.
Use the redirections data that we use to generate the htaccess file to
also generate the tests.
Also I removed the debug output as it it's assertion is incorrect we can
actually get the .htaccess file from the docs job \o/
Change-Id: Ib5d35169e68cd92b666a35705d8e36942bd28b89
Instead of statically listing the redirections move to a dynamic model.
We move the existing _extras/.htaccess to _templates/htaccess so we have
some control and safety of what goes in there. Connect 'build-finished'
from _exts.deliverables.py to trigger generating the redirects. Doing
so here avoids re-reading the data as deliverables.py ahas already done
that for us.
Change-Id: If6bd59fd478593a84ebcedc3a50af3720d620d3c
We have static URLs redirecting /constraints/upper/series to the
appropriate git interface. In the next change in this series we move to
a data-driven model so let's supply the data :)
Even though we have tag history that goes back to Folsom only import
Juno and later because that's when we first added constraints support
This means as the create and delete branches for requirements, like
other projects, we have a central source of truth (other than git) from
which to update the htaccess redirects.
I had update deliverables.py to account for the fact most of the
requirements branches don't have a release. This does make the table
look a little funny (as the earliest release is the series eol tag :()
but I'm not sure how we can do better there.
Change-Id: Ie8e60dc865ab301539c0bb085a52dd25f3f62edf
Remove the governance code in this repository and use the new
openstack_governance library instead.
Depends-On: https://review.openstack.org/614605
Change-Id: Ia7ffff3945462f4b568b55287dfdf45fe73a35d9
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
We had sphinx extensions in multiple locations. This centralized them
under the doc/source tree.
Change-Id: Ieda73fb4b51ed78409423c41eaddacda199abddc
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
Use the sphinx wrapper around logging instead of app.info().
Add a -v option to sphinx-build to see the output.
Change-Id: Ia698929c252a2a19da812e399011341a41976540
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
Remove line breaks within a paragraph to allow calendar software to
handle the text formatting.
Change-Id: Ic4c335b9bff7f0213f22c821059d9e0a842b859b
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
In addition to each series-specific calendar, prepare a single global
ICS file with all calendar events in it.
Change-Id: I3b66a343d1d0eac19c212c26957cc98ecbc062de
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
Put the titles of the cross-project events in the summary of the
calendar event so they show up in the main calendar view.
Add the full descriptions of the cross-project events to the calendar
event description so any extra notes (such as specific dates for
deadlines) or details about the event are visible to calendar users.
Change-Id: I6eebcdd827241f008522065a40b765b2089e2856
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
