Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Fedora Advisory Board (http://www.linux-archive.org/fedora-advisory-board/)
-   -   Fedora Board Recap 2007-NOV-13 (http://www.linux-archive.org/fedora-advisory-board/1868-fedora-board-recap-2007-nov-13-a.html)

John Poelstra 11-21-2007 04:07 AM

Fedora Board Recap 2007-NOV-13
 
http://fedoraproject.org/wiki/Board/Meetings/2007-11-13

Attendees: Chris Aillon, Max Spevack, Seth Vidal, John Poelstra, Steve
Dickson, Jef Spaleta, Matt Domsch, Bill Nottingham, Karsten Wade, and
Dennis Gilmore, and Chris Blizzard



== Fedora 9 Planning ==

=== Source Code ===
* Long term storage and availability of source code
* ability to match source code to any released package--store for four
years

* create source on the fly so that space is not a concern
* One approach would be to change the way we tag things or to disable
forced tagging

* Area of interest for Matt, Jef, Chris A

=== Wevisor ===
* Written in TurboGears
* A web-based version of system-config-kickstart
* kickstart stored online
* Make sure it can import anaconda
* What is needed to resurect it?
* Development of this tool and providing it as a service are separate
problems to solve

* Area of interest for Max

=== Fedora Store SIG ===
* Looking to make Fedora store process better
* First meeting on IRC 1800 UTC Wednesday

=== Presto ===
* Infrastructure evaluation needs to be done by Release Engineering
* Must be integrated with Koji before anything else can happen

== FUDCon ==
* January 11 to 13, 2008
* Location: TBD
* Deadline for decision is 2007-11-20 (next week's meeting)

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

Jesse Keating 11-21-2007 12:16 PM

Fedora Board Recap 2007-NOV-13
 
On Tue, 20 Nov 2007 21:07:09 -0800
John Poelstra <poelstra@redhat.com> wrote:

> === Source Code ===
> * Long term storage and availability of source code
> * ability to match source code to any released package--store for
> four years
> * create source on the fly so that space is not a concern
> * One approach would be to change the way we tag things or to
> disable forced tagging
> * Area of interest for Matt, Jef, Chris A

I have to say that I'm still pretty against any strategy that has us or
any of our downstreams relying upon us for a GPLv2 3b or 3c
distribution method. I feel that the methods described are entirely
too vague and too easily misinterpreted and could easily drive Fedora
into a "trap" of never being able to retire sources at all.

Instead I'd far rather investigate methods to make it easier and
lighter weight for us and downstreams to continue using 3a methods and
offering the source along side the binary, so that when we retire the
binary we can retire the source. Making clever use of hardlinks,
offering more things like spins.fp.o for not just Fedora branded spins
but for any branded Fedora based spin, adding source gathering
capabilities to the likes of our live image creators so that a limited
number of source isos can be used at events where binary isos are
given, etc... I strongly feel we can make it easy enough to use 3a
that we don't have to fall into a trap with 3b/c.

--
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

Jeroen van Meeuwen 11-21-2007 01:02 PM

Fedora Board Recap 2007-NOV-13
 
Jesse Keating wrote:

On Tue, 20 Nov 2007 21:07:09 -0800
John Poelstra <poelstra@redhat.com> wrote:


=== Source Code ===
* Long term storage and availability of source code
* ability to match source code to any released package--store for
four years
* create source on the fly so that space is not a concern
* One approach would be to change the way we tag things or to
disable forced tagging
* Area of interest for Matt, Jef, Chris A


I have to say that I'm still pretty against any strategy that has us or
any of our downstreams relying upon us for a GPLv2 3b or 3c
distribution method. I feel that the methods described are entirely
too vague and too easily misinterpreted and could easily drive Fedora
into a "trap" of never being able to retire sources at all.



Personally I am opposed to trying to find clever ways to not needing to
host the source (rpms). Finding ways to do anything different from *just
making the sources available online* for a period of time is asking for
trouble; It should work, but what if it doesn't -or fails half-way? How
does investing in a couple of discs weigh (each release?) against the
potential legal liability of losing anything because in the past you
thought you needed some 'clever way' to make sources available.


I can't really understand though how anyone could be opposed to the
Fedora Project releasing under 3b.


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

Jesse Keating 11-21-2007 01:07 PM

Fedora Board Recap 2007-NOV-13
 
On Wed, 21 Nov 2007 15:02:40 +0100
Jeroen van Meeuwen <kanarip@kanarip.com> wrote:

> Personally I am opposed to trying to find clever ways to not needing
> to host the source (rpms). Finding ways to do anything different from
> *just making the sources available online* for a period of time is
> asking for trouble; It should work, but what if it doesn't -or fails
> half-way? How does investing in a couple of discs weigh (each
> release?) against the potential legal liability of losing anything
> because in the past you thought you needed some 'clever way' to make
> sources available.
>
> I can't really understand though how anyone could be opposed to the
> Fedora Project releasing under 3b.

Forgive my use of "clever". I meant making use of hardlinks so that
keeping the sources for each available binary release online less of a
problem. I also want to avoid the "clever" idea of regenerating srpms
on the fly. I just want them available, but I want them available just
for the period of time the binary release is available, so that when
the binary release is retired, so can any sources associated with it,
that aren't used by a different binary release. I'm more than happy
with the Fedora project taking on that resource, but I want it done in
a way that has a reasonable end in sight, not an infinite trap.

--
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

seth vidal 11-21-2007 01:15 PM

Fedora Board Recap 2007-NOV-13
 
On Wed, 2007-11-21 at 09:07 -0500, Jesse Keating wrote:
> On Wed, 21 Nov 2007 15:02:40 +0100
> Jeroen van Meeuwen <kanarip@kanarip.com> wrote:
>
> > Personally I am opposed to trying to find clever ways to not needing
> > to host the source (rpms). Finding ways to do anything different from
> > *just making the sources available online* for a period of time is
> > asking for trouble; It should work, but what if it doesn't -or fails
> > half-way? How does investing in a couple of discs weigh (each
> > release?) against the potential legal liability of losing anything
> > because in the past you thought you needed some 'clever way' to make
> > sources available.
> >
> > I can't really understand though how anyone could be opposed to the
> > Fedora Project releasing under 3b.
>
> Forgive my use of "clever". I meant making use of hardlinks so that
> keeping the sources for each available binary release online less of a
> problem. I also want to avoid the "clever" idea of regenerating srpms
> on the fly. I just want them available, but I want them available just
> for the period of time the binary release is available, so that when
> the binary release is retired, so can any sources associated with it,
> that aren't used by a different binary release. I'm more than happy
> with the Fedora project taking on that resource, but I want it done in
> a way that has a reasonable end in sight, not an infinite trap.
>

3 years is a long time for keeping the sources around if we generate
them that way. It seems like we're better off in terms of space and in
terms of being able to provide sources for the longer run if we can
generate srpms on the fly out of cvs.

-sv


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

Jesse Keating 11-21-2007 01:25 PM

Fedora Board Recap 2007-NOV-13
 
On Wed, 21 Nov 2007 09:15:30 -0500
seth vidal <skvidal@fedoraproject.org> wrote:

> 3 years is a long time for keeping the sources around if we generate
> them that way. It seems like we're better off in terms of space and in
> terms of being able to provide sources for the longer run if we can
> generate srpms on the fly out of cvs.

3 years only comes into play if you use 3b/c. If you use 3a, you only
have to keep the source as long as you keep the binary. In the case of
respins, you only have to keep the sources associated with the respin
for as long as that respin binary is hosted. This is the real concern,
the updates sources used in respins.

--
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

Jeroen van Meeuwen 11-21-2007 01:30 PM

Fedora Board Recap 2007-NOV-13
 
seth vidal wrote:

3 years is a long time for keeping the sources around if we generate
them that way. It seems like we're better off in terms of space and in
terms of being able to provide sources for the longer run if we can
generate srpms on the fly out of cvs.



However once you choose to generate srpms on the fly out of cvs, you are
also committing to using cvs for the same amount of time. Migrating the
cvs component to anything else might show to have a huge tail and might
just not work in the sense that the new vcs might not give you srpms
with the same checksum, or <insert-favorite-unforeseen-hurdle-here>.


Besides that, generating spins off of on-the-fly generated srpms without
some repository being generated might prove to be a challenge as well
-remember downstream /can/ use 3c if FP does 3b, it can also use 3a if
they want to.


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

seth vidal 11-21-2007 01:30 PM

Fedora Board Recap 2007-NOV-13
 
On Wed, 2007-11-21 at 09:25 -0500, Jesse Keating wrote:
> On Wed, 21 Nov 2007 09:15:30 -0500
> seth vidal <skvidal@fedoraproject.org> wrote:
>
> > 3 years is a long time for keeping the sources around if we generate
> > them that way. It seems like we're better off in terms of space and in
> > terms of being able to provide sources for the longer run if we can
> > generate srpms on the fly out of cvs.
>
> 3 years only comes into play if you use 3b/c. If you use 3a, you only
> have to keep the source as long as you keep the binary. In the case of
> respins, you only have to keep the sources associated with the respin
> for as long as that respin binary is hosted. This is the real concern,
> the updates sources used in respins.
>

But if we have the source tarball and spec file + patches in cvs - which
we do right now, anyway, why not generate them on demand and not even
need to host the srpms until they're desired?

We save space even in the short run.

-sv


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

Jesse Keating 11-21-2007 01:38 PM

Fedora Board Recap 2007-NOV-13
 
On Wed, 21 Nov 2007 09:30:39 -0500
seth vidal <skvidal@fedoraproject.org> wrote:

> But if we have the source tarball and spec file + patches in cvs -
> which we do right now, anyway, why not generate them on demand and
> not even need to host the srpms until they're desired?
>
> We save space even in the short run.

Because that will overtime potentially generate something that is
different than the original srpm, unless we plan on freezing the
machines that do the srpm production and never update rpm on them. It
also feels very "hacky" when we can go a far more simplistic route of
just hosting the files and using hardlinks to reduce the actual space
overhead.

--
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

seth vidal 11-21-2007 01:44 PM

Fedora Board Recap 2007-NOV-13
 
On Wed, 2007-11-21 at 15:30 +0100, Jeroen van Meeuwen wrote:
> seth vidal wrote:
> > 3 years is a long time for keeping the sources around if we generate
> > them that way. It seems like we're better off in terms of space and in
> > terms of being able to provide sources for the longer run if we can
> > generate srpms on the fly out of cvs.
> >
>
> However once you choose to generate srpms on the fly out of cvs, you are
> also committing to using cvs for the same amount of time. Migrating the
> cvs component to anything else might show to have a huge tail and might
> just not work in the sense that the new vcs might not give you srpms
> with the same checksum, or <insert-favorite-unforeseen-hurdle-here>.
>

No we aren't committing to using cvs. We're committing to the tool
which generates the srpms being able to talk to whatever we're using in
the future.

-sv


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


All times are GMT. The time now is 08:48 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.