Re: Introducing dgit - git integration with the Debian archive
On 25 August 2013 17:31, Steve Langasek <vorlon@debian.org> wrote:
> On Sun, Aug 25, 2013 at 12:51:31PM +0100, Dmitrijs Ledkovs wrote:
>> I have maintenance access to UDD & have filed a few bugs about it, and
>> all I can say is that dgit so far is getting a lot of things right:
>
> <snip>
>
>> 2) removing automatic importer
>> forcing all the checks on the developer side & forcing VCS commit to
>> match the src upload is a massive win. It means that one can actually
>> trust the archive & VCS commits. And they will always match. (Well one
>> can even verify that by unpacking the .dsc and comparing it to the
>> Dgit: commit id) After all the archive will always be authoritative,
>> as that's that gets GPG signature, is mirrored and gets deployed to
>> the users.
>
> I don't think "removing the automatic importer" is an improvement at all.
> If we want VCS branches for the whole of Debian that we can rely on,
> something / someone needs to update them automatically when a package is
> uploaded.
>
Under dgit: push = (git push + dput *.changes). Thus the failure mode
is much sooner and in general it's more strict.
For uploads done without using dgit, it can synthesise "upload
granulaty" commits with reproducible / stable commit ids.
Thus the branches are maintained up to date, without the need to rely
on automatic importer.
One can trivially add automatic importer for uploads done without dgit.
> The problems with the UDD automatic importer have all been around its
> failing to cope with any kind of manual changes to the bzr branch. I.e.,
> if even once the importer sees an upload before it sees the corresponding
> commit on the bzr branch - because a maintainer did a bzr push --overwrite,
> or because of a race between the upload and the branch propagation, or
> because of a bug on the server - then that package is forever after in
> "manual" import mode until someone with admin privileges can kick the
> machine. This is a pretty bad failure mode; but it's a failure because the
> importer can't cope with changes to the branch, not because automatic
> importing was being done.
>
>> And one is free to push pristine-tar (if makes sense/easy to
>> generate), and/or any other branches into the repository (git-dpm,
>> git-quilt, etc)
>
> I would have expected dgit to support pristine-tar
> directly/automatically/unconditionally. Any system that requires me to
> download the same information (== the upstream source) both from a VCS
> repository and the archive in order to get a fully-formed source package for
> upload is a non-starter.
>
if pristine-tar can recreate the tarball, without size penalties.
Since it's just a git repository, one can do $ pristine-tar commit and
push that into the dgit repository.
At the moment it's not a requirement.
>> I am exited about dgit, as for the first time it will be possible for
>> derivatives to centrally share history with Debian.
>
> I am as well!
>
>> In practice one doesn't actually care how far back the history goes,
>> as the history that is interesting is where developers get to do
>> intermediate commits between the two uploads to granulise the
>> changes....
>
> I don't agree with this at all. I have regularly made use of the UDD
> branches to examine the history of packages (and not just the Ubuntu
> history, but also the Debian history). Being upload-level granularity makes
> it less useful than if it were at the granularity of a VCS branch being
> committed to natively by the developer, but it's still *very* useful for
> understanding the uploader's thought process at the time a change was made.
>
> The fact that git will allow us to graft the developer's own VCS on to these
> dgit repositories in a way that UDD never did is an important improvement,
> but as this is *optional*, not importing the package history from the
> archive would make dgit much less useful for the common case than UDD is
> today.
>
Ok. Given that we have snapshots.debian.org & graft points we can
create "import level" history in retrospect.
But I find merging existing history more interesting: either upstream,
or existing git/svn packaging repositories.
For new packages with dgit, I start my repository on top of upstream
git reposity, which gives full history of the project in the dgit
repository.
Imho shared history with upstream projects is more interesting than
debian packaging upload history. Ideally one would have both =)
Regards,
Dmitrijs.
Reply to: