> >> Because every snapshot for every architecture is done on a different
> >> tree, and some are even done 5-6 times a day.  So this would require,
> >> if I can guess this right, 2.6GB per day.  Supplied over a T1.
> >
> > Obviously a full tarball isn't the answer, but how about enough
> > information to reproduce the source code used to make the snapshot?
> 
> Sure, it does not look like it's a lot of work.
> 
> Now imagine what happens in reality.
> 
> Architecture A is 10% in the build.
> Architecture B is 30% in the build.
> Architecture C is 75% in the build.
> All three from the same, NFS mounted, source tree.
> 
> A spiffy userland diff arrives, which will be put in the snapshot. It
> affects src/bin/foo, src/usr.bin/bar and src/usr.sbin/baz.
> 
> After the diff is applied, it is probably too late for architecture C,
> which will have these changes in its next snapshot, and all of it or
> part of it will be in the A and B snapshots.
> 
> If you want "enough information to reproduce" the snapshot, this means
> that every time a diff is added to the common source tree, or every
> time a partial cvs update is made in this common source tree, one has
> to check all the currently running snapshots to see how far they are and
> what part of the update will really end up in the tarballs.
> 
> This is not something you can do with scripts only.
> 
> The only way to access your request is to change the process used in
> making snapshots.
> 
> Guess what? This will not happen, because we are satisfied with the
> current process.
> 
> This can be frustrating to end users, but given that unpublished diffs
> don't stay long in snapshots (they either get dropped or commited soon),
> this is something we developers thing you can live with.
> 
> >                         It is well known in the free software community
> > that the more eyeballs look at source code, the more bugs get found and
> > fixed.
> 
> BTW, this is one of the most successfull lies in the free software
> community.

In summary:

        if you don't understand what we do and how we do it., and don't even
        TRY to understand it, don't bother critiqueing it -- or you will be
        recognized for exactly what kind of slime you are.

Reply via email to