Process for handlng fakesyncs

[Benjamin Drung]

Am Sonntag, den 14.02.2010, 02:54 +0900 schrieb 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

We should use a revision of "-XfakesyncY" starting with "-Xfakesync1".
When we need to do a rebuild, the revision will be increased to
"-Xfakesync2".

> 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.

-- 
Benjamin Drung
Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20100213/349db26c/attachment.pgp