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 11-21-2007, 04:11 PM
Christopher Blizzard
 
Default Fedora Board Recap 2007-NOV-13

On Nov 21, 2007, at 12:02 PM, Jeroen van Meeuwen wrote:

Keeping old systems around doesn't sound very efficient -one goal
that I guess is attempted to be achieved by the "keeping-only-so-
many-copies of the sources re-generating the SRPM on demand" idea.


If it's cheaper than converting the data and it's not in active use,
then it's fine. Also if the new system has to figure out how to use
the old system's data it can often add unattractive constraints.
Anyway, it's just an option. Just putting it out there.


--Chris

_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
 
Old 11-21-2007, 04:27 PM
"Jeff Spaleta"
 
Default Fedora Board Recap 2007-NOV-13

On Nov 21, 2007 8:02 AM, Jeroen van Meeuwen <kanarip@kanarip.com> wrote:
> Keeping old systems around doesn't sound very efficient -one goal that I
> guess is attempted to be achieved by the "keeping-only-so-many-copies of
> the sources re-generating the SRPM on demand" idea.

There several issues that need to be addressed and i think the
regenerated of srpms on demand makes headway on all of them without
speaking to the GPL licensing issue directly.

1) We as a project are producing live-cds, and encouraging people to
physically hand this out. But we are not providing source in a way
that these people can easily meet the requirements of GPLv2 if someone
receiving a physical livecd requests the corresponding sourcecode.
How do we as a project expect this to be handled currently by
ambassadors or the free media project.. or even a sitting board
member? When I hand out a f7/f8 live cd and someone asks me for the
corresponding source what do I say as a Fedora Board member?

Are these people who are giving out physical media acting as this
project's agents or acting on their own? If the are acting as our
agents does this project have a legal responsibility to make sure they
can meet the source code distribution requirements? If they are not
acting as our agents in a legal sense, do we have an ethical
obligation to make it reasonable easy for people handing out fedora
media to meet the source distribution requirements?

Both Jesse's idea of hardlinked archive and the srpm generation on
demand will help here. But the hardlinked archive isn't going to scale
out.

2) Koji is space constrained. We are going to need to flush things
from koji quite frequently. I'm not sure we can rely on koji to be the
point at which we archive anything even srpms. Nor do I think we have
the resources to scale jesse's big pile of archived srpms. His idea
may scale just fine right now, but what happens a year from now when
there are 12 different active spin SIGS, each producing monthly
re-spins? The space needed to house a hardlinked dump of all possible
'released' srpms is still an unbounded constraint. The cvs and
lookaside space on the other hand are consuming much smaller amounts
of space currently and we can most certainly set a limit on the size
limit for the re-generated srpms cache.

3)re-generation of srpms on the fly lets us provide more than the
absolute minimum in required service. We should be aiming to provide
source distribution for everything we've built through koji and has
been in a publicly facing repository.. including rawhide. The big
ball of hardlinked srpms certainly can't give us source distribution
coverage that also includes everything seen in the public rawhide
tree.

-jef

_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
 
Old 11-21-2007, 04:28 PM
Jeroen van Meeuwen
 
Default Fedora Board Recap 2007-NOV-13

Jesse Keating wrote:

Yes, because then we can prune more efficiently. As each binary
distribution is pruned, we can prune that specific reference to a
source package. If no more binary distributions exist with references
to the source package, then the actual file on the file system goes
away. There may be many interim updates that don't ever get included
in any binary distribution (other than our updates directory) and would
be pruned out automatically when the update is superseded.



On the other hand you rely on downstream to tell you when it is OK for
them to have you purge the binary (as well as the sources) all and all
not making it very manageable or even sustainable in the long run.
Committing to provide the sources for a given period of time however
let's you crontab a 'find -exec', leaving any "real responsibility" to
downstream; far more efficient and way more manageable for us, good
enough for anyone else.


BTW, these interim updates, builds or even CVS commits are not released
effectively -like you said they are never included in any binary
distribution. I'm thinking these got included in the bigger picture
somehow, while I was just talking about released updates (possibly
including updates-testing) -nothing more, not even development/.


Kind regards,

Jeroen van Meeuwen
-kanarip

_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
 
Old 11-21-2007, 04:40 PM
Jesse Keating
 
Default Fedora Board Recap 2007-NOV-13

On Wed, 21 Nov 2007 08:27:56 -0900
"Jeff Spaleta" <jspaleta@gmail.com> wrote:

> Both Jesse's idea of hardlinked archive and the srpm generation on
> demand will help here. But the hardlinked archive isn't going to scale
> out.
>
> 2) Koji is space constrained. We are going to need to flush things
> from koji quite frequently. I'm not sure we can rely on koji to be the
> point at which we archive anything even srpms. Nor do I think we have
> the resources to scale jesse's big pile of archived srpms. His idea
> may scale just fine right now, but what happens a year from now when
> there are 12 different active spin SIGS, each producing monthly
> re-spins? The space needed to house a hardlinked dump of all possible
> 'released' srpms is still an unbounded constraint. The cvs and
> lookaside space on the other hand are consuming much smaller amounts
> of space currently and we can most certainly set a limit on the size
> limit for the re-generated srpms cache.
>
> 3)re-generation of srpms on the fly lets us provide more than the
> absolute minimum in required service. We should be aiming to provide
> source distribution for everything we've built through koji and has
> been in a publicly facing repository.. including rawhide. The big
> ball of hardlinked srpms certainly can't give us source distribution
> coverage that also includes everything seen in the public rawhide
> tree.

I think the two efforts can go in tandem, however I would rely upon the
hardlinked tree as v2 3a distribution means, and not rely upon on the
fly generation to fulfill v2 3b/c. Please avoid 3b/c at all costs.

--
Jesse Keating
Fedora -- All my bits are free, are yours?
_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
 
Old 11-21-2007, 04:46 PM
Jesse Keating
 
Default Fedora Board Recap 2007-NOV-13

On Wed, 21 Nov 2007 18:28:52 +0100
Jeroen van Meeuwen <kanarip@kanarip.com> wrote:

> On the other hand you rely on downstream to tell you when it is OK
> for them to have you purge the binary (as well as the sources) all
> and all not making it very manageable or even sustainable in the long
> run. Committing to provide the sources for a given period of time
> however let's you crontab a 'find -exec', leaving any "real
> responsibility" to downstream; far more efficient and way more
> manageable for us, good enough for anyone else.

No, I rely on the downstream to either purge their release themselves,
either by replacing it with a newer one, or having it autopurged at a
time agreed upon when accepting the donated hosting. The key is tying
the removal of the binary release with the removal of the source
release.

I suppose we could be less helpful and just say we're going to host the
source you used for $bla time, after that you're SOL, but I'm trying to
be a bit more helpful.

>
> BTW, these interim updates, builds or even CVS commits are not
> released effectively -like you said they are never included in any
> binary distribution. I'm thinking these got included in the bigger
> picture somehow, while I was just talking about released updates
> (possibly including updates-testing) -nothing more, not even
> development/.

I was talking about released (or -testing) updates that were never
included in any respin. They went out as an update, then later was
replaced by a newer update, without any respin coming along and using
them.

--
Jesse Keating
Fedora -- All my bits are free, are yours?
_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
 
Old 11-21-2007, 04:48 PM
"Jeff Spaleta"
 
Default Fedora Board Recap 2007-NOV-13

On Nov 21, 2007 8:40 AM, Jesse Keating <jkeating@redhat.com> wrote:
> I think the two efforts can go in tandem, however I would rely upon the
> hardlinked tree as v2 3a distribution means, and not rely upon on the
> fly generation to fulfill v2 3b/c. Please avoid 3b/c at all costs.

When I hand out an F7 or F8 livecd in my capacity as a Fedora Board
member right now, am I engaging in conduct which necesitates the use
of the written offer for source code clause?

-jef

_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
 
Old 11-21-2007, 04:51 PM
Jeroen van Meeuwen
 
Default Fedora Board Recap 2007-NOV-13

Jesse Keating wrote:

I think the two efforts can go in tandem, however I would rely upon the
hardlinked tree as v2 3a distribution means, and not rely upon on the
fly generation to fulfill v2 3b/c. Please avoid 3b/c at all costs.



What's this? Should I now say: "Please do 3b/c because it's money better
spent then trying to avoid it at all costs" ??


Kind regards,

Jeroen van Meeuwen
-kanarip

_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
 
Old 11-21-2007, 05:14 PM
Jesse Keating
 
Default Fedora Board Recap 2007-NOV-13

On Wed, 21 Nov 2007 08:48:11 -0900
"Jeff Spaleta" <jspaleta@gmail.com> wrote:

> When I hand out an F7 or F8 livecd in my capacity as a Fedora Board
> member right now, am I engaging in conduct which necesitates the use
> of the written offer for source code clause?

Yes. That hasn't changed. I'd really like to see us instead make a
limited number of source isos to match the live image(s) so that they
can be offered in tandum. If the recepient doesn't take the source,
well that's just too bad. But once we stop offering the binary, then
we can stop offering the source too. No need for a written offer. At
least that's my non-lawyer interpretation that I have yet to validate
with a lawyer.

--
Jesse Keating
Fedora -- All my bits are free, are yours?
_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
 
Old 11-21-2007, 05:15 PM
Jeroen van Meeuwen
 
Default Fedora Board Recap 2007-NOV-13

Jesse Keating wrote:

On Wed, 21 Nov 2007 18:28:52 +0100
Jeroen van Meeuwen <kanarip@kanarip.com> wrote:


On the other hand you rely on downstream to tell you when it is OK
for them to have you purge the binary (as well as the sources) all
and all not making it very manageable or even sustainable in the long
run. Committing to provide the sources for a given period of time
however let's you crontab a 'find -exec', leaving any "real
responsibility" to downstream; far more efficient and way more
manageable for us, good enough for anyone else.


No, I rely on the downstream to either purge their release themselves,
either by replacing it with a newer one, or having it autopurged at a
time agreed upon when accepting the donated hosting. The key is tying
the removal of the binary release with the removal of the source
release.



I see what you mean but this also means that FP is going to function as
an umbrella in a way that someone down the line is not going to be able
to do whatever it is he does just because someone within the FP doesn't
feel like it, doesn't accept it, or, has "zero confidence" in that
person (or his spin, code, you name it I may have misunderstood it).



I suppose we could be less helpful and just say we're going to host the
source you used for $bla time, after that you're SOL, but I'm trying to
be a bit more helpful.



Again this option doesn't give anyone the freedom to "go at it", as it
needs FP to intervene and create some hard links. It's improvement, it
sure is, but it isn't what I've been looking for all along.



BTW, these interim updates, builds or even CVS commits are not
released effectively -like you said they are never included in any
binary distribution. I'm thinking these got included in the bigger
picture somehow, while I was just talking about released updates
(possibly including updates-testing) -nothing more, not even
development/.


I was talking about released (or -testing) updates that were never
included in any respin. They went out as an update, then later was
replaced by a newer update, without any respin coming along and using
them.



To optimize with such granularity... Isn't that way too much overkill?

Nevermind, withdrawn.

This branch in the discussion isn't my beef and I should stick to my
point; giving anyone enough freedom to do whatever it is they want to do
with Fedora, based on Fedora or rebranded FUbuntu for all I care,
without the legal responsibilities of having to host or distribute the
sources or creating any other type of overhead. No-one (individuals and
small projects in particular) should care about GPL-compliance knowing
that someone else has that area covered.


If that means you wish to communicate with every individual or (small)
project that does foo with Fedora, or else you'll purge what they are
required have available when distributing their spin, in the granular
matter that you are going to hard-link each file into some published
directory dedicated to that one custom spin or downstream project... I
don't know whether to say "Thank you" or "Good luck".


Kind regards,

Jeroen van Meeuwen
-kanarip

_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
 
Old 11-21-2007, 05:16 PM
Jesse Keating
 
Default Fedora Board Recap 2007-NOV-13

On Wed, 21 Nov 2007 18:51:40 +0100
Jeroen van Meeuwen <kanarip@kanarip.com> wrote:

> What's this? Should I now say: "Please do 3b/c because it's money
> better spent then trying to avoid it at all costs" ??

I have no idea how to parse that.

In my opinion, targetting 3b/c is very dangerous for Fedora as an
upstream, as it is entirely too vague and could easily land us in a
trap where every single source ever to pass through our build system
must be always available in the same location from now until
eternity. /That/ is what I'd like to avoid.

--
Jesse Keating
Fedora -- All my bits are free, are yours?
_______________________________________________
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 05:56 AM.

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