Jonathan Nieder <jrnie...@gmail.com> writes:
> Goswin von Brederlow wrote:
>
>> 1) Think about doing this for linux-2.6, XOrg or OOo and what it would
>> mean for the source size or usability.
>
> Indeed, the history is pretty large. A rough estimate (for something
> less rough, one should use a well packed bundle with only the objects
> of interest):
>
> $ pwd
> /home/jrn/src/linux-2.6
> $ git status -u
> # On branch next
> nothing to commit (working directory clean)
> $ du -sk .git
> 440664 .git
> $ du -sk --exclude=.git .
> 450920 .
> $ du -sk ../linux-2.6.33-rc7.tar.bz2
> 64648 ../linux-2.6.33-rc7.tar.bz2
>
> The source package would become about 7 times as large.
>
> For usability: I imagine what is typically needed is the set of Vcs-Git
> fields somewhere conveniently machine-readable, so one could just go
>
> apt-get source --git whatever
>
> and get a checkout of its packaging repository.
>
> That would be the 90% solution. What it doesnât do is help people with
> poor connectivity to hack on a package like linux-2.6. Given the high
> quality of commit messages and the sparsity of comments on the
> implementation, it is really much easier to work with the history in
> hand.
Then create CD/DVDs of git.d.o.
> So it would be nice (though hard) to find some method that allows the
> git history to be widely mirrored, included on distributed DVDs, and
> so on. Iâm sure the admins of kernel.org would appreciate it as
> well.
Show the demand and I'm sure mirroring will follow.
>> Uploading a new source could then be sending a signed ref to the
>> maintainers git or sending a signed bundle or even just pushing and
>> setting a tag.
>
> I imagine that would be very nice for people with large packages.
> Maybe something similar could be accomplished for existing
> tarball+changes packages by providing a "proxy" git server that runs
> dpkg-source -b server side.
For non-upstream updates the upload is usualy small. Just the diff.gz or
debian.tar.gz file. But yeah, for most upstream changes a pristine-tar
upload is much smaller than the full orig.tar.gz. But is that really the
problem?
> Selfishly, I guess if someone implements the 90% solution above, I
> would stop caring so much about what source format the buildds use.
> Others might be more principled, though. ;-)
>
> Regards,
> Jonathan
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
