Process for handlng fakesyncs

[Colin Watson]

On Sun, Feb 14, 2010 at 02:54:47AM +0900, Emmet Hikory wrote:
>     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.

Yes.

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

It seems to me that if we're changing sync-source.py anyway (which is
the only tool that really needs to know the difference here), then we
could simply change it to detect the fact that the Debian and Ubuntu
orig tarballs differ, and not perform a sync in that case, but in such a
way as to avoid breaking 'sync-source.py -a'.  After all, it has access
to the Launchpad database.  With that change, this would be equivalent
to the -XfakesyncY proposal.

My vote (not veto) is that we should not make process changes which need
manual attention when a change to a script would suffice.

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

Yes.

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

I would cast a vote for "doesn't matter" - we could happily allow
either.  No point in encouraging compliance with something that doesn't
really matter.

(My personal practice is not to change the Maintainer field here, and I
note that the tools will not raise a fatal error if you don't, unlike
for -XubuntuY uploads at least for certain values of $DEBEMAIL.)

-- 
Colin Watson                                       [cjwatson at ubuntu.com]