Changes between Version 12 and Version 13 of SecurityVulnerabilityProcess

Timestamp:

Mar 5, 2013, 3:59:23 AM (11 years ago)

Author:

datallah

Comment:

Update developer process to include private repo usage instructions

SecurityVulnerabilityProcess

@@ -36 +36 @@
 }}}
    b. If the bug has already been announced publicly (on devel mailing list, IRC, or Jabber conference), send all information about the bug to security@pidgin.im
- 2. Developers on the security email list should determine an appropriate fix and create a patch.  Do not share it publicly, but do get it reviewed and tested by other developers.
- 2. Once an agreed upon patch has been created, an email based on this template should be sent to the packagers mailing list with the diff attached:
+ 1. Developers on the security email list should determine an appropriate fix and create a patch.  Do not share it publicly, but do get it reviewed and tested by other developers.
+ 1. Once an agreed upon patch has been created, an email based on this template should be sent to the packagers mailing list with the diff attached:
 {{{
 A security vulnerability has been discovered in [Pidgin|Finch|libpurple|other]
@@ -46 +46 @@
 Embargo date: [Either "none" or the agreed upon date]
 }}}
- 2. As the embargo date approaches, a developer should be chosen to commit the fix to their repository.  Do not push yet, but go through the normal release process and prepare the ChangeLog, NEWS, etc.  This developer should also create (but not upload) tarballs.  It's often nice to provide the tarball to packagers prior to the embargo date.
- 2. On the day of the embargo, push the changes to the repository and update http://pidgin.im/news/security/
+ 1. Commit the agreed upon patch to the `private/main` repo:
+   a. If you don't already have a clone of the  the `private/main` repo, make one (you can clone from a local repo if you like)
+      * `hg clone ssh://hg.pidgin.im/private/main /path/to/myprivatemain`
+      * '''NOTE:''' If you clone from a local repo, you'll need to edit the `.hg/hgrc` file and make sure that the `default` path points to `ssh://hg.pidgin.im/private/main` to avoid pushing changes to the wrong repo!
+   a. Propagate all changes from the `pidgin/main` repo into `private/main`
+      * `cd /path/to/myprivatemain`
+      * `hg pull`
+      * `hg pull https://hg.pidgin.im/pidgin/main`
+      * `hg push`
+      * NOTE: You may need to merge if there have already been commits to the private repo.
+   a. Apply the patch to the correct branch and commit it as usual
+   a. Push the changeset to the server.
+      * '''NOTE:''' it's a great idea to make sure that the `default` path in your `.hg/hgrc` points to `ssh://hg.pidgin.im/private/main` before doing this.
+ 1. Prior to the normal release process, the changes from `pidgin/main` should be propagated to `private/main` as mentioned above (merging any heads as necessary).  The release can then be performed as normal but out of the `private/main` repo instead of the normal repo.  It's often nice to provide the tarball to packagers prior to the embargo date.
+ 1. On the day of the embargo, push the changes to the `pidgin/main` repository (`hg push ssh://hg.pidgin.im/private/main -r $release_tag`), and update http://pidgin.im/news/security/
 
 = Information for Distributors =