Flush end of lifed binaries from master mirror

[Jeff Spaleta]

On Jan 15, 2008 11:30 AM, Stephen John Smoogen <smooge at gmail.com> wrote:
> The other issue is how long does the
> source code need to be available from the primary source for GNU GPL
> or other licenses requirements? Both of these are probably moot
> questions... but I will play mr ignoramus.


As of right now.. we don't have to keep source any longer than we keep
binaries because we distribute under 3a of the GPL.  When you get
binaries from servers we control, you pretty much have to decide
whether or not you want the source then.  If you redistribute what you
got from us, the onus is on you to provide source for anyone who takes
binaries from you.

That's how it stands right now.   Soon, like F9 soon, I'd really like
to be able to see us extend access to source for 'long enough' so that
downstream distributors can rely on us and point people back to us for
source for a specific period of time..after which they are again
responsible for providing source to people if they choose to continue
distributing.

I think after fudcon a lot of the stakeholders agree that we can do
something along these lines, cover our asses legally speaking, and
more important not be assholes about source access.  They aren't the
same thing, necessarily.

I'm hoping we can solve the tagging issues with cvs so we can generate
srpm from an archive of our cvs and lookaside caches and know with
reasonable assurance that the result is the desired srpm that koji
used.  To do that we might break some contributors' work flow
associated with using forced retagging.. and I'd like to avoid doing
that. But being responsible about access to sources is a very
important thing.  From a legal perspective i think we have our asses
covered by just giving someone a full archive of our cvs and look
aside cache (using archive.org for example) and letting them dig
through it. But I don't want to just do the minimum here and be an
ass. I want to try to make sure that we have a source distribution
that is easy enough to use, but isn't continuing to burden our
infrastructure by having to cache srpms when we don't have to.

Give me a cvs tag namespace that maintainers don't need to forcibly
retag that maps to releasable binary builds and we have a simple way
to regenerate srpm's on the fly just from the cvs archive. And the cvs
archive is not a bottleneck in terms of space. We simply cannot rely
on koji's cache for any time scale of merit. Koji takes up way more
space that what is actually in cvs and the lookaside, and its naive to
think we can get away with trying to historically cache at the koji
level. CVS where we deal with source material, and that is where we
need to re-generate historic srpms when asked for.  if we move to some
other source control system, then we make sure we have a similar
ability.. but how we deal with source distribution requirements as it
impacts downstream distributors (like our ambassadors who hand out
binaries at tradeshows) needs to be enhanced sooner rather than later.
It's not going to wait for cvs to be replaced.

-jef