| May | JUN | Jul |
| 11 | ||
| 2017 | 2018 | 2019 |
COLLECTED BY
Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
History is littered with hundreds of conflicts over the future of a community, group, location or business that were "resolved" when one of the parties stepped ahead and destroyed what was there. With the original point of contention destroyed, the debates would fall to the wayside. Archive Team believes that by duplicated condemned data, the conversation and debate can continue, as well as the richness and insight gained by keeping the materials. Our projects have ranged in size from a single volunteer downloading the data to a small-but-critical site, to over 100 volunteers stepping forward to acquire terabytes of user-created data to save for future generations.
The main site for Archive Team is at archiveteam.org and contains up to the date information on various projects, manifestos, plans and walkthroughs.
This collection contains the output of many Archive Team projects, both ongoing and completed. Thanks to the generous providing of disk space by the Internet Archive, multi-terabyte datasets can be made available, as well as in use by the Wayback Machine, providing a path back to lost websites and work.
Our collection has grown to the point of having sub-collections for the type of data we acquire. If you are seeking to browse the contents of these collections, the Wayback Machine is the best first stop. Otherwise, you are free to dig into the stacks to see what you may find.
The Archive Team Panic Downloads are full pulldowns of currently extant websites, meant to serve as emergency backups for needed sites that are in danger of closing, or which will be missed dearly if suddenly lost due to hard drive crashes or server failures.
Collection: Archive Team: The Github Hitrub
Fetching latest commit…
Cannot retrieve the latest commit at this time.
setup.cfg.
Release requests are filed as patches to deliverables files in
the openstack/releases repository, see the README there for more
details.
Before beginning this process, you need to set up gpg with a valid
key, and authorize launchpad to run the release tools
commands. Authorizing launchpad can be tricky on a system that only
provides a terminal-based browser, since the launchpad site does not
work well with the default configuration of lynx (cookies and
referrer headers need to be enabled for the launchpad site). Newer
versions of launchpadlib also rely on keyring, which may require a
password for every command being run if you are not in a graphical
environment with a better interactive key manager. Talk with dhellmann
if you start a release and run into trouble with launchpad auth.
When a release request is ready to be approved, follow these steps:
The release team member taking responsibility for the
release should approve the change in openstack/releases.
Release requests should not be approved until we are actually ready
to cut the release.
After the release request merges, check out or update a local copy
of openstack/releases to get the new version of the file under
the deliverables directory. Make sure you check out the
releases repository to the commit with the new release request you
want to process, in case multiple requests merge around the same
time. The release tools only look at the most recent commit to
detect which deliverable files have changed.
Check out or update a local copy of
openstack-infra/project-config repository, which contains the
tools for tagging a release.
Change directories to
project-config/jenkins/scripts/release-tools.
Create or update a virtualenv and install all of the dependencies
for the release tools using
openstack-infra/project-config/jenkins/scripts/release-tools/requirements.txt
as the basis.
For example:
$ virtualenv .venv $ source .venv/bin/activate $ pip install -U -r requirements.txtRun
release_from_yaml.sh, giving the path to the
openstack/releases repository.
For example:
$ ./release_from_yaml.sh ~/repos/openstack/releasesAs the release script runs, it will prompt you for your GPG key passphrase before adding the tag. This gives you a last chance to review the proposed tag before proceeding. After the tag is created locally and pushed up to the remote server, the script will push comments to closed Launchpad bugs since the previous tag. Announce the release. (一)Milestones are manually announced once all projects are done (usually at the closing of the milestone window), using an email recapitulating all projects that did a milestone tag and pointing to milestone tarballs. The process to follow for announcements of releases will be added here soon. (二)Library and tool releases are announced via one of the OpenStack mailing lists. See the instructions for running announce.sh below.
requirements.txt.
Each shell script should try to create a Python virtualenv to install
the packages before running any of the commands written in Python. If
you start seeing import errors after updating your sandbox, it is
likely that a new dependency was added. Try removing .tox/venv and
running the command again.
openstack-infra/project-config/jenkins/scripts/release-tools.
./rccut.sh 7432f32d838ab346c liberty novaCreate a series/liberty branch for Nova at commit 7432f32d838ab346c, and mark FixCommitted bugs FixReleased, while targeting them to the juno-rc1 milestone.
./rccut.sh 3472368b3a546d liberty neutron-fwaas neutronCreate a series/liberty branch for neutron-fwaas at commit 3472368b3a546d.
./rcdelivery.sh kilo rc1 cinderPush 2015.1.0rc1 tag to current cinder stable/kilo branch HEAD, wait for the tarball build, and upload the resulting tarball to Launchpad (while marking it released).
./rcdelivery kilo final neutron-fwaas neutronPush 2015.1.0 final tag to current neutron-fwaas stable/kilo branch HEAD (which should be the last RC), wait for the tarball build, and upload the resulting tarball to the "neutron" Launchpad page.
Bugs:",
extracts the URL following the colon, and includes that information in
the output.
The bugs URL is converted to a launchpad project URL and combined with
the final version number to produce a milestone URL.
The script uses python setup.py to determine the project name and
the one-line description to include in the output text.
Examples:
release-notes ~/repos/openstack/oslo.config 1.7.0 1.8.0Print the release notes between versions 1.7.0 and 1.8.0 for the project in the
~/repos/openstack/oslo.config directory.
release-notes --show-dates --changes-only ~/repos/openstack/oslo.config 1.8.0 HEADPrint the list of changes after 1.8.0 for the project in the
~/repos/openstack/oslo.config directory, including the date of
the change but leaving out the email message boilerplate. This mode
is useful for examining the list of unreleased changes in a project
to decide if a release is warranted and to pick a version number.
$ check_library_constraints.sh /path/to/requirements-repository stable/mitaka
$ milestone-checkup ~/repos/openstack/releases newton 2 training-labs (Documentation) did not find /home/dhellmann/repos/openstack/releases/deliverables/newton/training-labs.yaml aodh (Telemetry) did not find /home/dhellmann/repos/openstack/releases/deliverables/newton/aodh.yaml ceilometer (Telemetry) did not find /home/dhellmann/repos/openstack/releases/deliverables/newton/ceilometer.yaml astara (astara) ...
milestone-close oslotest 1.8.0
milestone-rename oslo.rootwrap next-juno 1.3.0Rename oslo.rootwrap next-juno milestone to 1.3.0.
./ms2version.py nova kilo-3Returns 2015.1.0b3 (after checking that the kilo-3 milestone exists in Nova)
./ms2version.py swift 2.1.0 --onlycheckExists successfully if there is a 2.1.0 milestone in Swift.
./repo_tarball_diff.sh nova masterCheck the difference between Nova master branch contant and a tarball that would be generated from it.
./compare_tarball_diff.sh openstack/nova 13.0.0
./validate_tarballs.sh ~/repos/openstack/releases mitaka
./pre_expire_bugs.py neutron --days 180Prepare for expiration neutron bugs with no activity not updated in the last 180 days.
./pre_expire_bugs.py glance --days 365 --testTest prepare for expiration on Launchpad Staging servers.
./pre_expire_bugs.py glance --days 365 --dry-runPrepare for expiration dry-run: print actions without executing them.
DAYS_SINCE_CREATED). It ignores bug reports which:
* have a special comment (see constant STILL_VALID_FLAG).
* have the status In Progress
* have the importance Wishlist
By default it uses a dry-run to not accidentally close bug reports. You
have to use a flag to make it a real execution.
Closed bug reports will have:
* status = Won't Fix
* assignee = None
* importance = Undecided
* a comment which explains why this was done.
Examples:
./expire_old_bug_reports.py nova --verboseShow which bug reports of Nova would be expired (a dry-run is the default).
./expire_old_bug_reports.py nova --no-dry-runActually expire old bug reports of Nova.
./expire_old_bug_reports.py nova --no-dry-run --credentials-file cred.txtUse a credentials file to expire bug reports (see launchpad-login).
export LP_CREDS_FILE=path/to/my/lp/credentials/files/cred.txt ./expire_old_bug_reports.py nova --no-dry-runUse an environment variable to access the credentials file instead of the
--credentials-file flag.
./process_bugs.py nova --settarget=grizzly-3 --fixreleaseSets the target for all Nova FixCommitted bugs to grizzly-3 and mark them 'Fix Released'.
./process_bugs.py glance --settarget=grizzly-2 --status='Fix Released' --testTest setting the target for all untargeted Glance FixReleased bugs to grizzly-2 on Launchpad Staging servers.
./process_bugs.py neutron --milestone juno-3 --settarget juno-rc1Move all juno-3 open bugs from juno-3 to juno-rc1 milestone.
./wait_for_tarball.py cinder --mpsha=59089e56f674f5f94f67c5986e9a616bb669d846Looks for a cinder-branch-tarball job matching SHA 59089e... which would produce a milestone-proposed.tar.gz tarball, and waits for completion
./wait_for_tarball.py cinder --tag=2013.1.1Looks for a cinder-tarball job for tag "2013.1.1" and waits for completion.
./upload_release.py nova 2015.1.0 --milestone=kilo-3Uploads Nova's nova-2015.1.0b3.tar.gz to the kilo-3 milestone page.
./upload_release.py glance 2015.1.0 --testUploads Glance's glance-2015.1.0.tar.gz to the final "2015.1.0" milestone as glance-2015.1.0.tar.gz, on Launchpad staging server
./upload_release.py cinder 2012.2.3 --tarball=stable-folsomUploads Cinder's current cinder-stable-folsom.tar.gz to the 2012.2.3 milestone as cinder-2012.2.3.tar.gz
./consolidate_release_page.py cinder kilo 2015.1.0Moves Cinder blueprints and bugs from intermediary kilo milestones to the final 2015.1 milestone page.
./consolidate_release_page.py --test swift grizzly 1.8.0Moves Swift 1.8.0-rc* blueprints and bugs to the final 1.8.0 page, on Launchpad staging server
./consolidate_release_page.py --copytask glance kilo 2015.1.0Moves Glance blueprints from intermediary kilo milestones to the final 2015.1.0 milestone page. Creates kilo series task for all grizzly bugs and sets the milestone for those to 2015.1.0.
milestones-create havana.yaml
milestone-ensure oslo.config liberty next-liberty
./spec2bp.py glance super-spec --milestone=juno-2 --priority=MediumGlance's super-spec.rst was approved and you want to add it to juno-2, with Medium priority. This will do it all for you.
./spec2bp.py nova --specpath=specs/kilo/approved/my-awesome-spec.rst --in-review --milestone=juno-2Nova's my-awesome-spec.rst is still under review, but you would like to add the my-awesome-spec blueprint to juno-2 (marked Blocked). Since it's located in a non-standard path, we specify it using --specpath parameter.
./spec2bp.py nova my-awesome-spec --priority=Highmy-awesome-spec is now approved. You want to flip all the approval bits, but also change its priority to High. There is no need to pass --specpath again, spec2bp will infer it from the blueprint URL field.
./stable_freeze.py -r 2014.1.4 queryView open reviews for stable/icehouse 2014.1.4.
./stable_freeze.py -r 2014.1.4 -o ~/openstack/2014.1.4-freeze.txtFreeze all open reviews proposed to stable/icehouse. 2014.1.4-freeze.txt will contain all frozen reviews and this can be used to thaw later on.
./stable_freeze -r 2014.1.4 -i ~/openstack/2014.1.4-freeze.txt thawThaw all reviews previously frozen and stored in 2014.1.4-freeze.txt.
./stable_freeze -r 2014.1.4 -i ~/openstack/2014.1.4-freeze.txt \ -c 123777 -c 123778 freezeFreeze individual changes that have been proposed after the stable freeze period started. References to these reviews will be appended to 2014.1.4-freeze.txt to be unfrozen later on.
./autokick.py nova kilo
./translation-cleanup.sh kilo nova
./adjust_blueprints.py nova liberty-1Displays proposed adjustments around Nova liberty-1 blueprints.
./adjust_blueprints.py nova liberty-1 --target --cleanTargets missing implemented blueprints and cleans incomplete ones for Nova in liberty-1.
add-comment --subject='Winner' --content='You won!' 1000000 2000000Add a 'You won!' comment (with subject line 'Winner') to Launchpad bugs #1000000 and #2000000
update_reviews oslo.configThe tool looks for all of the changes in the project that you have a -2 vote on and changes your vote to 0, with the message "This project is now open for new features."
./bugs-fixed-since.py -r ../neutron --start=8.0.0Use
--stop option to list bugs mentioned in stable branch messages stopping
from a specified commit.
Example:
./bugs-fixed-since.py -B -r ../neutron --start=8.0.0 --stop=origin/stable/mitakaUse
-B option to ignore patches that were already backported into all
stable branches.
Example:
./bugs-fixed-since.py -B -r ../neutron --start=8.0.0Use
-e option to ignore patches that don't apply cleanly to one of stable
branches.
Example:
./bugs-fixed-since.py -e -r ../neutron --start=8.0.0Use
-sb option to also include StoryBoard bugs
Example:
./bugs-fixed-since.py -sb -r ../octavia --start=1.0.0
./bugs-fixed-since.py [...] --start=8.0.0 | \ ./lp-filter-bugs-by-importance.py neutronList bugs that are fixed in master since 8.0.0 that are not of Wishlist importance. Example:
./bugs-fixed-since.py --start=8.0.0 | \ ./lp-filter-bugs-by-importance.py neutron | \ ./lp-filter-bugs-by-importance.py neutron --importance LowList bugs that are fixed in master since 8.0.0 that are not of Wishlist or Low importance.
./bugs-fixed-since.py [...] --start=8.0.0 | \ ./lp-filter-bugs-by-tag.py neutron --tag in-stable-mitakaList bugs that are fixed in master since 8.0.0 that don't have relevant fixes merged in stable/mitaka.
./bugs-fixed-since.py [...] --start=8.0.0 | ./annotate-lp-bugs.py neutronPull in detailed description for bugs that are fixed in master since 8.0.0.
./lp-reset-backport-potential.py neutron python-neutronclient
./bugs-fixed-since.py [...] --start=8.0.0 | ./lp-tag.py foo-tagThis command will add the 'foo-tag' tag to all bugs fixed since 8.0.0.
./bugs-fixed-since.py [...] -sb --start=1.0.0 | \ ./sb-filter-stories-by-tag.py in-stable-pikeList stories fixed in master since 1.0.0 that do not have relevant fixes merged in stable/pike.
./bugs-fixed-since.py [...] -sb --start=1.0.0 | \ ./sb-tag.py foo-tagThis command will add the 'foo-tag' tag to all stories fixed since 1.0.0.
eol_branch.sh script is provided to end-of-life branches. It
will abandon any changes on the to-be-removed branch, create a
branch-eol tag at the current branch HEAD and then remove the
branch.
To run the script, ensure you are either in the "Release Managers"
group or a gerrit admin. add yourself to "Project Bootstrappers"
temporarily in review.openstack.org (note: this is a gerrit
limitation with branch deletion permissions. This may not be required
in the future). Be careful and remember to remove yourself at the end
to avoid accidental changes.
Usually the release team will have provided the branches to remove
grouped by project in an easy to use format. The command goes
something like:
eol_branch.sh -- stable/oldbranch oldbranch-eol openstack/project1 openstack/python-project1It's usually best to run under
screen and save the log file in
case of unintended consequences.
gpg is setup correctly for password
caching or you will have to type your password a lot. gpg2 has
better support for gpg-agent, so git config --global gpg.program
gpg2 will probably just "do the right thing" (note if you're
migrating from gpg, you may need to import your keys with
gpg2 --import < ~/.gnupg/secreing.gpg).
●© 2018 GitHub, Inc.
●Terms
●Privacy
●Security
●Status
●Help
●Contact GitHub
●API
●Training
●Shop
●Blog
●About
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session.
You signed out in another tab or window. Reload to refresh your session.