Process for handlng fakesyncs

[Emmet Hikory]

    There was some dissension about the best way to handle a fakesync
in #ubuntu-motu today, and a few of us talked about why we might
fakesync, and what should happen to the package after fakesync.  It
appears that the term "fakesync" is currently used in a couple of
different contexts, and that there are several different practices in
place on how to best perform a fakesync, which results in some
confusion when someone asks about them, and requires more intervention
in later review of the package than is strictly necessary.  We came to
a consensus of a model that should reduce confusion in the future, and
I present it below for consideration.

    Historical references to "fakesync" have included uploads to
Ubuntu with Debian packaging and Ubuntu tarballs in cases where the
tarballs differ, pulls from Debian VCS in advance of Debian uploads,
and potentially other cases not clearly identified in the sparse
reference on the wiki.  To avoid future confusion, the term "fakesync"
should be restricted exclusively to the case where we wish to sync a
package available in some Debian repository at the time of the
fakesync but cannot because of differing tarballs, and where the
tarballs do not differ sufficiently to require any changes in
packaging to handle the differences.

    Some people seem to upload fakesyncs with a revision of the form
"-XbuildY" and others with a revision of the form "-XubuntuY".  Both
of these are less than ideal.  "-XbuildY" implies that a sync should
succeed with the next Debian upload, but this wil not be the case if a
new Debian revision (but not a new upstream) is uploaded for a
non-native package.  "-XubuntuY" implies that there exists some Ubuntu
modification that needs a manual merge, but this will not be the case
if a new Debian upload occurs with a new upstream version.  In order
to provide appropriate hints to the various tools, the use of a
revision of the form "-Xfakesync"  This form requires no 'Y'
component, as there should only ever be one revision for each Debian
revision.  With this semantic addition, the tools can be adjusted to
handle "-Xfakesync" in a manner similar to "-XbuildY" in cases where a
new upstream version is available, and in a manner similar to
"-XubuntuY" in cases where a new Debian upload happens with the same
upstream version.  Additionally, a `fakesync` tool could be added to
ubuntu-dev-tools that could automate the construction of a "correct"
fakesync candidate package.

    To reduce the size of the autogenerated patches, and the effort
required to review a potential merge in the future, it seems
appropriate to agree to drop all previous Ubuntu-local entries from
the changelog when preparing a fakesync.  The history of construction
of the unmatching tarball is available in launchpad for those
interested, and if the contents of the tarballs are essentially
identical, we shouldn't care who created the unmatching tarball, when,
or specifically why, as the code itself matches that in Debian.

    On a related subject, we were unable to come to a conclusion about
the application of the DebianMaintainerField guidelines to rebuilds
and fakesyncs.  Some documentation seems to imply that this is not
required for changelog-only uploads, but the original specification
suggests it applies for all classes of Ubuntu change.  Some discussion
and clarification on this matter would help reduce confusion in this
area (and appropriate tools could be adjusted to check each of
"-XbuildY", "-XubuntuY", and "-Xfakesync" to encourage compliance.

    In summary, the proposal is as follows:

1) The term "fakesync" is only to be used when applying Debian
packaging to an Ubuntu tarball when a sync would fail and adding a
single changelog entry

2) A fakesync should use a revision of "-Xfakesync", and appropriate
tools should understand the semantics of this revision to perform sync
or merge correctly

3) Prior Ubuntu changelog entries should be dropped when performing a fakesync

4) There needs to be some review and clarification on the use of
source-maintainer-mangling for fakesyncs and rebuilds

    Your comments, thoughts, or determination to adopt this as your
preferred practice are appreciated.

-- 
Emmet HIKORY