Summary/Minutes from today's FESCO meeting (2011-12-12 at 1800 UTC)

[Thomas Spura]

On Tue, Dec 13, 2011 at 9:53 PM, J. Bruce Fields <bfields at redhat.com> wrote:
> On Tue, Dec 13, 2011 at 02:12:30PM -0500, Stephen Gallagher wrote:
>> On Tue, 2011-12-13 at 14:06 -0500, J. Bruce Fields wrote:
>> > On Mon, Dec 12, 2011 at 01:22:06PM -0800, Toshio Kuratomi wrote:
>> > > To some extent I agree with both sgallagh's sentiment and the logical
>> > > conclusion you're drawing.  However, I think the lookaside cache is
>> > > a necessary optimization/compromise to the ideal of putting everything into
>> > > version control, though.  Current technology would make it prohibitive in
>> > > terms of packager time (and for some packages, space on developer's
>> > > machines) to put tarballs into git as the cloned repository would then
>> > > contain every single new tarball the package ever had.
>> >
>> > I'd be curious to know how expensive that actually was.
>> >
>> > I'd think delta-compression could make it quite reasonable for the
>> > typical project.  (Exceptions including things like games with lots of
>> > binary data in each release.)
>>
>> Nearly all packages are released as a compressed tarball. So any change
>> in the package is likely to result in a delta of the binary image that
>> is close enough to 100% as makes no difference.
>
> You'd want to uncompress before checking in.  Or even expand before
> checking in--"git diff" and "git grep" would then be a lot more useful.
>
> You'd no longer have a copy of exactly what you downloaded, but someone
> with a copy of the download could mechanically verify that you'd
> imported the same content.
>
> You could still keep the .tar.gz in the lookaside cache, but you
> wouldn't normally need to go look at it.

What's the benefit of all the overhead (=growing size of the repos and
doing this as an extra step, not just uploading the tarball)?

Adding a VCS key [1] to the spec, so you can look at the uncompressed
source, which all of "vcs diff/grep", makes more sense to me. (This
only assumes upstreams repo will stay reachable.)
Unpackaging the tarball and adding a lot of data to the git repository
only makes it bigger and bigger and you can't really compare that git
repo to the upstream one (Maybe sharing some patches, but I guess no
pull etc will work).

Greetings,
   Tom

[1] http://fedoraproject.org/wiki/User:Walters/Packaging_VCS_key_proposal