GStreamer 0.8.10

[Loïc Minier]

--OwLcNYc0lM97+oe1
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Jun 12, 2005, Lo=EFc Minier wrote:
>  My generic "new-upstream-release" notes are attached, and I'll check
>  for file/directories disparities and interdiff the Debian diffs prior
>  to declaring this suitable for upload.

 Sorry, here they are.

--=20
Lo=EFc Minier <lool@dooz.org>
"Neutral President: I have no strong feelings one way or the other."

--OwLcNYc0lM97+oe1
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename=package-new-upstream-release


Procedure from Brian Nelson <pyro@debian.org> to package a new upstream
release:

1. Read the upstream changelog, NEWS, and whatever other documentation
   they may have released with the new version.

2. Do a 'diff -urN' between the old and new upstream sources to try to
   get a feel for the scope of the changes, where work is actively being
   done (and thus where new bugs may appear), and also keep an eye out
   for anything suspicious.

3. Port the old Debian packaging to the new version.  This basically
   involves applying the diff.gz from the old package to the new one and
   incrementing the debian/changelog.  Tools like uupdate help automate
   this for you.  Personally I keep all of my packages in a subversion
   repository and thus do an svn merge.

4. If the patch/merge did not apply cleanly, inspect the situation to
   determine what failed (clues are left in .rej files).  Most often the
   problem is that a patch you applied to the source was integrated
   upstream, and thus the patch is no longer relevant.

5. If any changes were made to the build system (hopefully you'd know
   from steps 1 and 2) and update the debian/rules and debian/control
   build dependencies if necessary.

6. Build the new package.  Personally I always build in a pbuilder
   chroot since I use some 3rd party packages on my system and I don't
   want those interfering.

7. Verify that the new package builds correctly.

8. Run lintian to catch any obvious policy violations.

9. Run 'debdiff old-package.change new-package.change'.  Verify that no
   files have been unintentionally misplaced or removed, and no other
   inadvertent changes were made.  Also works with 'debdiff 1.dsc 2.dsc'.

10. Verify the contents with 'debc new-package.changes'.  Ensure no files
    are zero-length that should not be.
       debc netspeed_0.12.1-1_i386.changes |
           grep -v ^d |
           awk '{ print $3}' |
           grep ^0$

11. Install the new package.  Verify it installs/upgrades correctly.
    Verify that it works normally.  If the package makes use of
    non-trivial pre/post/inst/rm scipts, be sure to test the upgrade
    paths of those.

12. Check to see if any bugs have been fixed that are currently open in
    the BTS.  If they have been, close them in the debian/changelog.

13. Check the sanity of the diff.gz file.  Run 'interdiff -z -p1
    old-package.diff.gz new-package.diff.gz' and verify any
    modifications changes are intentional and no junk files have crept
    in.

14. Check the contents of the .changes file to make sure you are
    uploading to the correct distribution, the proper bugs closures are
    listed in the Closes: field, the Maintainer: and Changed-By: fields
    match, the file is GPG-signed, etc.

15. If any changes were made to correct anything in the packaging along
    the way, repeat steps 6-13 until satisfied.  If your upload needs to
    be sponsored, be sure to note any special options required when
    building the package (like 'dpkg-buildpackage -sa -v ...') and be
    sure to inform your sponsor so he or she builds it correctly.


Tips by Antti-Juhani Kaijanaho <ajk@debian.org>:

 - Use a -1 Debian revision number for the new upstream release.

 - Preserve old changelog entries (sounds obvious, but there have been
   incidents...)

 - Add an entry "New upstream release" to the changelog.

 - Upgrades to the new version should preferably be silent and
   nonintrusive (existing users should not notice the upgrade except by
   discovering that old bugs have been fixed and there perhaps are new
   features)

 - When an upgrade is necessarily intrusive (eg. it will break existing
   usage), the upgrade must be noisy (a note in README.Debian or other
   documentation is generally not enough; NEWS.Debian note may become
   okay once apt-listchanges with NEWS.Debian support becomes standard
   operating practice)

 - Existing Debian changes need to be reevaluated; throw away stuff that
   upstream has incorporated (in one form or another) and remember to
   keep stuff that hasn't been incorporated by upstream, unless there is
   compelling reason not to.


Additional note from Steve Langasek <vorlon@debian.org>:

... and please note that "New upstream release" is not a change that closes
bugs other than wishlist requests *for* the new upstream release; if there
are changes *in* the new upstream release that fix reported bugs, please
enumerate those changes before closing the bugs in the changelog.


--OwLcNYc0lM97+oe1--