FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Advisory Board

 
 
LinkBack Thread Tools
 
Old 01-15-2008, 03:41 PM
seth vidal
 
Default Flush end of lifed binaries from master mirror

On Tue, 2008-01-15 at 11:42 -0500, Jesse Keating wrote:
> It was brought up during FUDCon that we could help our mirrors out a
> lot if we flushed our outdated binary content. Old test releases,
> released earlier than FC6. Just the binaries for now, the sources can
> stay around (well except for the test releases, those can go).
>
> Does anybody have any objections to doing this? I'll make sure the
> binaries are sufficiently archived somewhere before flushing them.

None, nuke them from orbit. It's the only way to be sure.

-sv


_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
 
Old 01-15-2008, 07:30 PM
"Stephen John Smoogen"
 
Default Flush end of lifed binaries from master mirror

On Jan 15, 2008 9:42 AM, Jesse Keating <jkeating@redhat.com> wrote:
> It was brought up during FUDCon that we could help our mirrors out a
> lot if we flushed our outdated binary content. Old test releases,
> released earlier than FC6. Just the binaries for now, the sources can
> stay around (well except for the test releases, those can go).
>
> Does anybody have any objections to doing this? I'll make sure the
> binaries are sufficiently archived somewhere before flushing them.
>

Well as long as the archives don't flush the data because it got
flushed from master mirror . 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.



--
Stephen J Smoogen. -- CSIRT/Linux System Administrator
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"

_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
 
Old 01-15-2008, 07:44 PM
Matt Domsch
 
Default Flush end of lifed binaries from master mirror

On Tue, Jan 15, 2008 at 01:30:55PM -0700, Stephen John Smoogen wrote:
> Well as long as the archives don't flush the data because it got
> flushed from master mirror . 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.

We distribute GPLv2 code under paragraph 3a, source posted concurrent
with binaries. Therefore we can remove both concurrently, or just
remove the binaries (Jesse's proposal) at will.

We can be nice and leave the source there for longer than the binaries
if we wish.

Thanks,
Matt





_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
 
Old 01-15-2008, 07:56 PM
"Jeff Spaleta"
 
Default Flush end of lifed binaries from master mirror

On Jan 15, 2008 11:30 AM, Stephen John Smoogen <smooge@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

_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
 
Old 01-18-2008, 01:33 AM
"Stephen John Smoogen"
 
Default Flush end of lifed binaries from master mirror

On Jan 15, 2008 1:44 PM, Matt Domsch <matt@domsch.com> wrote:
> On Tue, Jan 15, 2008 at 01:30:55PM -0700, Stephen John Smoogen wrote:
> > Well as long as the archives don't flush the data because it got
> > flushed from master mirror . 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.
>
> We distribute GPLv2 code under paragraph 3a, source posted concurrent
> with binaries. Therefore we can remove both concurrently, or just
> remove the binaries (Jesse's proposal) at will.
>
> We can be nice and leave the source there for longer than the binaries
> if we wish.
>
> Thanks,
> Matt

Thanks. I get confused with 3a and 3b since I remember mostly serving
data via physical media versus just downloads.

--
Stephen J Smoogen. -- CSIRT/Linux System Administrator
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"

_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
 

Thread Tools




All times are GMT. The time now is 07:07 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org