| Message ID | 1445032823-22040-2-git-send-email-stephen.finucane@intel.com |
|---|---|
| State | Accepted |
| Headers | show |
Hi Stephen, You asked for review, and there are a few pieces I'm qualified to comment on :) On Fri, Oct 16, 2015 at 11:00:22PM +0100, Stephen Finucane wrote: > The CHANGELOG document should describe the high level changes of the > project. This will provide a human-readable way for people to evaluate > the changes in each release. This file is based on the templates and > general changelog "ethos" provided by 'Keep a CHANGELOG': > > http://keepachangelog.com/ > > The UPGRADING document provide instruction for system admininstrators > managing patchwork deployments. At the moment, this document is a > rename and minor reformatting of the existing 'docs/NEWS' document, but > going forward documentation will be added for each new release. > > Signed-off-by: Stephen Finucane <stephen.finucane@intel.com> > --- > CHANGELOG.md | 57 ++++++++++++++++++++++++++++++++++++++++++++++ > UPGRADING.md | 74 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > docs/NEWS | 67 ------------------------------------------------------ > 3 files changed, 131 insertions(+), 67 deletions(-) > create mode 100644 CHANGELOG.md > create mode 100644 UPGRADING.md > delete mode 100644 docs/NEWS > > diff --git a/CHANGELOG.md b/CHANGELOG.md > new file mode 100644 > index 0000000..f28a7b5 > --- /dev/null > +++ b/CHANGELOG.md > @@ -0,0 +1,57 @@ > +# Change Log > + > +All notable changes to this project will be documented in this file. Please > +refer to the release notes for more detailed information, e.g. how to upgrade. > + > +This project adheres to [Semantic Versioning](http://semver.org/). > + > +## [Unreleased] > + > +... > + > +## [1.0.0] - 2015-10-16 > + > +### Added > + > +- Patch tag infrastructure feature. This provide a quick summary of patch > + 'tags' (e.g. `Acked-by`, `Reviewed-by`, ...) found in a patch and its replies > +- Support for Django 1.7 and Django 1.8 > +- Support for Django Migrations. This will be the chosen method of making > + database changes going forward. See below for more information > +- Support for tox > +- Django management commands, which replace the existing patchwork cron scripts > + > +### Changed > + > +- Static files are now gather and served using the `django.contrib.staticfiles` > + module, per Django best practices > +- Restructured directory per modern Django standards. The `apps` directory no > + longer exists and patchwork source has instead been moved to the top level > + directory > +- Rewrote documentation to reflect changes in development and deployment best > + practices over the past few years > +- Reworked `requirements.txt` and `settings.py` files > + > +### Removed > + > +- Support for Django 1.5 > +- Defunct Python 2.5 code > +- Numerous dead files/code > +- `bin/patchwork-cron` script, in favor of `cron` management command > + > +### Deprecated > + > +- Django 1.6 support will be removed in the next release > +- Django 1.7 supports Django Migrations and Django 1.8 requires them. This > + negates the need for handwritten SQL migration scripts. Future releases will > + no longer include these scripts and they will eventually be removed > + > +## [0.9.0] - 2015-03-22 > + > +**NOTE:** 1.0.0 was the first release of patchwork adopting semantic versioning. > +For information on *"0.9.0"* and before, please refer to Git logs. > + > +[Unreleased]: https://github.com/getpatchwork/patchwork/compare/v1.0.0...HEAD > +[1.0.0]: https://github.com/getpatchwork/patchwork/compare/v0.9.0...v1.0.0 > +[0.9.0]: https://github.com/getpatchwork/patchwork/compare/c561ebe...v0.9.0 What markdown are you using? These URLs don't get matched up to their headers with mine; you need to include an ID on the header label for my copy, from [1]. e.g.: ## [0.9.0][0.9.0] - 2015-03-22 Also, there are no tags uploaded to github, so the URLs don't work. > + Brian [1] http://daringfireball.net/projects/markdown/
> Hi Stephen, > > You asked for review, and there are a few pieces I'm qualified to > comment on :) Thanks Brian - appreciate it :) > On Fri, Oct 16, 2015 at 11:00:22PM +0100, Stephen Finucane wrote: > > The CHANGELOG document should describe the high level changes of the > > project. This will provide a human-readable way for people to evaluate > > the changes in each release. This file is based on the templates and > > general changelog "ethos" provided by 'Keep a CHANGELOG': > > > > http://keepachangelog.com/ > > > > The UPGRADING document provide instruction for system admininstrators > > managing patchwork deployments. At the moment, this document is a > > rename and minor reformatting of the existing 'docs/NEWS' document, but > > going forward documentation will be added for each new release. > > > > Signed-off-by: Stephen Finucane <stephen.finucane@intel.com> > > --- > > CHANGELOG.md | 57 ++++++++++++++++++++++++++++++++++++++++++++++ > > UPGRADING.md | 74 > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > docs/NEWS | 67 ------------------------------------------------------ > > 3 files changed, 131 insertions(+), 67 deletions(-) > > create mode 100644 CHANGELOG.md > > create mode 100644 UPGRADING.md > > delete mode 100644 docs/NEWS > > > > diff --git a/CHANGELOG.md b/CHANGELOG.md > > new file mode 100644 > > index 0000000..f28a7b5 > > --- /dev/null > > +++ b/CHANGELOG.md > > @@ -0,0 +1,57 @@ > > +# Change Log > > + > > +All notable changes to this project will be documented in this file. > Please > > +refer to the release notes for more detailed information, e.g. how to > upgrade. > > + > > +This project adheres to [Semantic Versioning](http://semver.org/). > > + > > +## [Unreleased] > > + > > +... > > + > > +## [1.0.0] - 2015-10-16 > > + > > +### Added > > + > > +- Patch tag infrastructure feature. This provide a quick summary of > patch > > + 'tags' (e.g. `Acked-by`, `Reviewed-by`, ...) found in a patch and its > replies > > +- Support for Django 1.7 and Django 1.8 > > +- Support for Django Migrations. This will be the chosen method of > making > > + database changes going forward. See below for more information > > +- Support for tox > > +- Django management commands, which replace the existing patchwork cron > scripts > > + > > +### Changed > > + > > +- Static files are now gather and served using the > `django.contrib.staticfiles` > > + module, per Django best practices > > +- Restructured directory per modern Django standards. The `apps` > directory no > > + longer exists and patchwork source has instead been moved to the top > level > > + directory > > +- Rewrote documentation to reflect changes in development and deployment > best > > + practices over the past few years > > +- Reworked `requirements.txt` and `settings.py` files > > + > > +### Removed > > + > > +- Support for Django 1.5 > > +- Defunct Python 2.5 code > > +- Numerous dead files/code > > +- `bin/patchwork-cron` script, in favor of `cron` management command > > + > > +### Deprecated > > + > > +- Django 1.6 support will be removed in the next release > > +- Django 1.7 supports Django Migrations and Django 1.8 requires them. > This > > + negates the need for handwritten SQL migration scripts. Future > releases will > > + no longer include these scripts and they will eventually be removed > > + > > +## [0.9.0] - 2015-03-22 > > + > > +**NOTE:** 1.0.0 was the first release of patchwork adopting semantic > versioning. > > +For information on *"0.9.0"* and before, please refer to Git logs. > > + > > +[Unreleased]: > https://github.com/getpatchwork/patchwork/compare/v1.0.0...HEAD > > +[1.0.0]: > https://github.com/getpatchwork/patchwork/compare/v0.9.0...v1.0.0 > > +[0.9.0]: > https://github.com/getpatchwork/patchwork/compare/c561ebe...v0.9.0 > > What markdown are you using? These URLs don't get matched up to their > headers with mine; you need to include an ID on the header label for my > copy, from [1]. e.g.: They do work on GitHub alright. I duplicated the style used on http://keepachangelog.com/. They're using GitHub flavored Markdown, which is essentially the same as CommonMark and the Markdown supported by sites like Bitbucket, StackOverflow, GitLab and readthedocs. What version did you use? :D > ## [0.9.0][0.9.0] - 2015-03-22 > > Also, there are no tags uploaded to github, so the URLs don't work. I wanted to see if anyone had any dire complaints about adopting some form of versioning before I created tags. I'll probably create them this weeked. Stephen > > + > > Brian > > [1] http://daringfireball.net/projects/markdown/
On Tue, Oct 20, 2015 at 11:39:02PM +0000, Finucane, Stephen wrote: > > On Fri, Oct 16, 2015 at 11:00:22PM +0100, Stephen Finucane wrote: [...] > > > +[Unreleased]: > > https://github.com/getpatchwork/patchwork/compare/v1.0.0...HEAD > > > +[1.0.0]: > > https://github.com/getpatchwork/patchwork/compare/v0.9.0...v1.0.0 > > > +[0.9.0]: > > https://github.com/getpatchwork/patchwork/compare/c561ebe...v0.9.0 > > > > What markdown are you using? These URLs don't get matched up to their > > headers with mine; you need to include an ID on the header label for my > > copy, from [1]. e.g.: > > They do work on GitHub alright. I duplicated the style used on > http://keepachangelog.com/. They're using GitHub flavored Markdown, > which is essentially the same as CommonMark and the Markdown supported > by sites like Bitbucket, StackOverflow, GitLab and readthedocs. OK. Unfortunately Markdown is a very loose standard :( > What > version did you use? :D I linked to it in my earlier email. I'm actually using the markdown in my distro, which claims it is v1.0.1 from daringfireball.net: $ markdown --version This is Markdown, version 1.0.1. Copyright 2004 John Gruber http://daringfireball.net/projects/markdown/ But no matter, as long as you have some sort of standard you're working against. > > ## [0.9.0][0.9.0] - 2015-03-22 > > > > Also, there are no tags uploaded to github, so the URLs don't work. > > I wanted to see if anyone had any dire complaints about adopting some form of > versioning before I created tags. I'll probably create them this weeked. No complaint here. Versioning doesn't impose much on those who just want to pull the latest from git, and it helps when determining why (for instance) kernel.org behaves differently than ozlabs.org. Brian > Stephen > > > > + > > > > Brian > > > > [1] http://daringfireball.net/projects/markdown/
> On Tue, Oct 20, 2015 at 11:39:02PM +0000, Finucane, Stephen wrote: > > > On Fri, Oct 16, 2015 at 11:00:22PM +0100, Stephen Finucane wrote: > [...] > > > > +[Unreleased]: > > > https://github.com/getpatchwork/patchwork/compare/v1.0.0...HEAD > > > > +[1.0.0]: > > > https://github.com/getpatchwork/patchwork/compare/v0.9.0...v1.0.0 > > > > +[0.9.0]: > > > https://github.com/getpatchwork/patchwork/compare/c561ebe...v0.9.0 > > > > > > What markdown are you using? These URLs don't get matched up to their > > > headers with mine; you need to include an ID on the header label for my > > > copy, from [1]. e.g.: > > > > They do work on GitHub alright. I duplicated the style used on > > http://keepachangelog.com/. They're using GitHub flavored Markdown, > > which is essentially the same as CommonMark and the Markdown supported > > by sites like Bitbucket, StackOverflow, GitLab and readthedocs. > > OK. Unfortunately Markdown is a very loose standard :( It sure is. Hopefully CommonMark should solve that. There's an article here on the whole situation, if you were interested: http://arstechnica.com/information-technology/2014/10/markdown-throwdown-what-happens-when-foss-software-gets-corporate-backing/2/ > > What > > version did you use? :D > > I linked to it in my earlier email. I'm actually using the markdown in > my distro, which claims it is v1.0.1 from daringfireball.net: > > $ markdown --version > > This is Markdown, version 1.0.1. > Copyright 2004 John Gruber > http://daringfireball.net/projects/markdown/ > > But no matter, as long as you have some sort of standard you're working > against. > > > > ## [0.9.0][0.9.0] - 2015-03-22 > > > > > > Also, there are no tags uploaded to github, so the URLs don't work. > > > > I wanted to see if anyone had any dire complaints about adopting some > form of > > versioning before I created tags. I'll probably create them this weeked. > > No complaint here. Versioning doesn't impose much on those who just want to > pull the latest from git, and it helps when determining why (for > instance) kernel.org behaves differently than ozlabs.org. My thoughts exactly: git for developers and versioned tarballs or similar for deployers. We should probably make the version visible through the Web UI/API at a later date. Thanks for the review, Brian. Appreciated. Stephen > Brian > > > Stephen > > > > > > + > > > > > > Brian > > > > > > [1] http://daringfireball.net/projects/markdown/
> The CHANGELOG document should describe the high level changes of the > project. This will provide a human-readable way for people to evaluate > the changes in each release. This file is based on the templates and > general changelog "ethos" provided by 'Keep a CHANGELOG': > > http://keepachangelog.com/ > > The UPGRADING document provide instruction for system admininstrators > managing patchwork deployments. At the moment, this document is a > rename and minor reformatting of the existing 'docs/NEWS' document, but > going forward documentation will be added for each new release. > > Signed-off-by: Stephen Finucane <stephen.finucane@intel.com> Merged (and tags added). Stephen
diff --git a/CHANGELOG.md b/CHANGELOG.md new file mode 100644 index 0000000..f28a7b5 --- /dev/null +++ b/CHANGELOG.md @@ -0,0 +1,57 @@ +# Change Log + +All notable changes to this project will be documented in this file. Please +refer to the release notes for more detailed information, e.g. how to upgrade. + +This project adheres to [Semantic Versioning](http://semver.org/). + +## [Unreleased] + +... + +## [1.0.0] - 2015-10-16 + +### Added + +- Patch tag infrastructure feature. This provide a quick summary of patch + 'tags' (e.g. `Acked-by`, `Reviewed-by`, ...) found in a patch and its replies +- Support for Django 1.7 and Django 1.8 +- Support for Django Migrations. This will be the chosen method of making + database changes going forward. See below for more information +- Support for tox +- Django management commands, which replace the existing patchwork cron scripts + +### Changed + +- Static files are now gather and served using the `django.contrib.staticfiles` + module, per Django best practices +- Restructured directory per modern Django standards. The `apps` directory no + longer exists and patchwork source has instead been moved to the top level + directory +- Rewrote documentation to reflect changes in development and deployment best + practices over the past few years +- Reworked `requirements.txt` and `settings.py` files + +### Removed + +- Support for Django 1.5 +- Defunct Python 2.5 code +- Numerous dead files/code +- `bin/patchwork-cron` script, in favor of `cron` management command + +### Deprecated + +- Django 1.6 support will be removed in the next release +- Django 1.7 supports Django Migrations and Django 1.8 requires them. This + negates the need for handwritten SQL migration scripts. Future releases will + no longer include these scripts and they will eventually be removed + +## [0.9.0] - 2015-03-22 + +**NOTE:** 1.0.0 was the first release of patchwork adopting semantic versioning. +For information on *"0.9.0"* and before, please refer to Git logs. + +[Unreleased]: https://github.com/getpatchwork/patchwork/compare/v1.0.0...HEAD +[1.0.0]: https://github.com/getpatchwork/patchwork/compare/v0.9.0...v1.0.0 +[0.9.0]: https://github.com/getpatchwork/patchwork/compare/c561ebe...v0.9.0 + diff --git a/UPGRADING.md b/UPGRADING.md new file mode 100644 index 0000000..3cf69d4 --- /dev/null +++ b/UPGRADING.md @@ -0,0 +1,74 @@ +# Patchwork Upgrade Guide + +## 0.9.0 to 1.0.0 + +Version 1.0.0 changes a few admin-visible components of patchwork so +upgrading involves a few steps. + +### Database Migrations + +Update the database schema, by running the `015-add-patch-tags.sql` script, +and re-run the grants script. For example, on postgres: + + psql -f lib/sql/migration/015-add-patch-tags.sql patchwork + psql -f lib/sql/grant-all.postgres.sql patchwork + +### Update to the new settings infrastructure + +By default, settings are read from `patchwork/settings/production.py`. To +migrate, use the template: + + cp patchwork/settings/production{.example,}.py + +Merge your previous settings (from `apps/local_settings.py`) into this file. + +### Fixup external references to `apps/` + +The `apps/` directory is gone; the patchwork module is now in the top-level +directory. If you have scripts that run anything from `apps/` (e.g. incoming +mail parsers that call `parsemail.sh`, and cron scripts), then remove the +`apps/` directory from those: + + apps/patchwork/ -> patchwork/ + +Alternatively, you can create a symlink - `apps/ -> .` + +If you have been running scripts (eg, from cron) that set the +`DJANGO_SETTINGS_MODULE` environment variable, you'll need to update that to +the new settings system. Typically: + + DJANGO_SETTINGS_MODULE=patchwork.settings.production + +The `manage.py` script has been moved from apps/ into the top-level directory +too. + +### Migrate to the `staticfiles` module + +Static content should now be located in the folder indicated by `STATIC_ROOT`. +This should point somewhere sensible (e.g. the absolute path of `htdocs/static` +in the patchwork tree). + +You'll need to set the `STATIC_ROOT` setting in your settings file. + +Once settings are configured, run the 'collectstatic' management command: + + ./manage.py collectstatic + +You also need to update your Apache configuration to use the new static +content. Since static content is now in all under `STATIC_ROOT`, the +configuration should be simpler than in previous releases. The core config +will be: + + DocumentRoot /srv/patchwork/htdocs/ + Alias /static/ /srv/patchwork/htdocs/static/ + WSGIScriptAlias / /srv/pathchwork/lib/apache2/patchwork.wsgi + WSGIPassAuthorization On + +### Use new management console + +The patchwork cron script (`bin/patchwork-cron.py`) has been moved to a +`manage.py` command. Instead of running `patchwork-cron.py`, you should now +run: + + ./manage.py cron + diff --git a/docs/NEWS b/docs/NEWS deleted file mode 100644 index d1342b1..0000000 --- a/docs/NEWS +++ /dev/null @@ -1,67 +0,0 @@ -== Cron script changes == - -The patchwork cron script has been moved to a manage.py command. Instead -of running patchwork-cron.py, run: - - ./manage.py cron - -== Upgrading to 3b8a61c == - -Recent commits have changed a few admin-visible components of patchwork, so -upgrading to post-commit 3b8a61c involves a few steps: - -- Update the database schema, by running the 015-add-patch-tags.sql script, - and re-run the grants script. - - For example, on postgres: - - psql -f lib/sql/migration/015-add-patch-tags.sql patchwork - psql -f lib/sql/grant-all.postgres.sql patchwork - -- Update to the new settings infrastructure. By default, settings are read - from patchwork/settings/production.py. To migrate, use the template: - - cp patchwork/settings/production{.example,}.py - - and merge your previous settings (from apps/local_settings.py) into - this file - -- Fixup external references to apps/ - - The apps/ directory is gone; the patchwork module is now in the top-level - directory. If you have scripts that run anything from apps/ (eg, incoming - mail parsers that call parsemail.sh, and cron scripts), then remove the apps/ - directory from those. - - apps/patchwork/ -> patchwork/ - - (or you can create a symlink - apps/ -> .) - -- Update any external scripts to use the new settings module - - If you have been running scripts (eg, from cron) that set the - DJANGO_SETTINGS_MODULE environment variable, you'll need to update that - to the new settings system. Typically: - - DJANGO_SETTINGS_MODULE=patchwork.settings.production - - The manage.py script has been moved from apps/ into the top-level directory - too. - -- Run the 'collectstatic' management command: - - ./manage.py collectstatic - - Ensure that the STATIC_ROOT setting points somewhere sensible (eg, the - absolute path of htdocs/static in the patchwork tree). - -- Update apache to use the new static content. - - Static content is now in all under STATIC_ROOT, the apache configuration - should be simpler now. The core config will be: - - DocumentRoot /srv/patchwork/htdocs/ - Alias /static/ /srv/patchwork/htdocs/static/ - WSGIScriptAlias / /srv/pathchwork/lib/apache2/patchwork.wsgi - WSGIPassAuthorization On -
The CHANGELOG document should describe the high level changes of the project. This will provide a human-readable way for people to evaluate the changes in each release. This file is based on the templates and general changelog "ethos" provided by 'Keep a CHANGELOG': http://keepachangelog.com/ The UPGRADING document provide instruction for system admininstrators managing patchwork deployments. At the moment, this document is a rename and minor reformatting of the existing 'docs/NEWS' document, but going forward documentation will be added for each new release. Signed-off-by: Stephen Finucane <stephen.finucane@intel.com> --- CHANGELOG.md | 57 ++++++++++++++++++++++++++++++++++++++++++++++ UPGRADING.md | 74 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ docs/NEWS | 67 ------------------------------------------------------ 3 files changed, 131 insertions(+), 67 deletions(-) create mode 100644 CHANGELOG.md create mode 100644 UPGRADING.md delete mode 100644 docs/NEWS