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 Development

 
 
LinkBack Thread Tools
 
Old 03-11-2010, 05:36 PM
Jesse Keating
 
Default Stable Release Updates types proposal (was Fedora Board Meeting Recap 2010-03-11)

On Thu, 2010-03-11 at 12:21 -0600, Matt Domsch wrote:
> Paul: Jesse Keating provided a draft policy for what updates should be
> done. Board will take this into consideration, if necessary, in
> another round of discussions (not this meeting).

https://fedoraproject.org/wiki/Stable_Release_Updates_Proposal

Here is the link. I'm going to start a new thread here.

Feedback welcome.

--
Jesse Keating
Fedora -- Freedom˛ is a feature!
identi.ca: http://identi.ca/jkeating
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-11-2010, 05:52 PM
Paul Wouters
 
Default Stable Release Updates types proposal (was Fedora Board Meeting Recap 2010-03-11)

On Thu, 11 Mar 2010, Jesse Keating wrote:

> https://fedoraproject.org/wiki/Stable_Release_Updates_Proposal
>
> Here is the link. I'm going to start a new thread here.

# Stable releases should not be used for tracking upstream
version closely when this is likely to change the user experience
beyond fixing bugs and security issues.
# Close tracking of upstream should be done in the Rawhide repo
wherever possible, and we should strive to move our patches upstream.

That might be harsh for some soname updates. Six months is a long time
to wait on new functionality after upstream released it. Even for users
running only full Fedora releases. Though I see various phrasing around
this that would allow exceptions, which is good.

Example: SHA256 support added to bind 9.6.2 less then a week ago (from
9.6.1). Bind 9.6.x is in F-12, and arpa. will be signed with SHA256 in
4 days. This leaves quite the window until F-13 is released (where users
are on bind-9.7.x that contains SHA25 already). In this case, F-12 should
really upgrade from 9.6.1 to 9.6.2.

I understand this when thinking about large sets (KDA, Gnome) or common
libraries that has too many in and out of tree dependancies (openssl 0.9x vs
openssl 1.x), but it might not always be valid.

Paul
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-11-2010, 06:02 PM
Seth Vidal
 
Default Stable Release Updates types proposal (was Fedora Board Meeting Recap 2010-03-11)

On Thu, 11 Mar 2010, Paul Wouters wrote:

>
> That might be harsh for some soname updates. Six months is a long time
> to wait on new functionality after upstream released it. Even for users
> running only full Fedora releases. Though I see various phrasing around
> this that would allow exceptions, which is good.
>
> Example: SHA256 support added to bind 9.6.2 less then a week ago (from
> 9.6.1). Bind 9.6.x is in F-12, and arpa. will be signed with SHA256 in
> 4 days. This leaves quite the window until F-13 is released (where users
> are on bind-9.7.x that contains SHA25 already). In this case, F-12 should
> really upgrade from 9.6.1 to 9.6.2.

And it will be impossible for users running the non-sha256 bind to
communicate with the sha256 supporting arpa?

I guess I don't understand what do the users of the existing bind LOSE?

Is ARPA expecting everyone to upgrade to a sha256 supporting bind
immediately? There's no migration window?

-sv

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-11-2010, 06:11 PM
Matthew Garrett
 
Default Stable Release Updates types proposal (was Fedora Board Meeting Recap 2010-03-11)

On Thu, Mar 11, 2010 at 01:52:06PM -0500, Paul Wouters wrote:

> That might be harsh for some soname updates.

If a user has built an application against a library, it's not
especially reasonable to then break that application by bumping a soname
in a stable release.

--
Matthew Garrett | mjg59@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-11-2010, 06:12 PM
Chris Adams
 
Default Stable Release Updates types proposal (was Fedora Board Meeting Recap 2010-03-11)

Once upon a time, Paul Wouters <paul@xelerance.com> said:
> That might be harsh for some soname updates. Six months is a long time
> to wait on new functionality after upstream released it.

People keep tossing out "six months". How often is it that a new Fedora
release comes out right before a new upstream, and that upstream is not
already in testing in Fedora?

Why not handle those cases similar to how GNOME and Firefox (and IIRC
OpenOffice.org?) have been handled in the past, where a test/RC release
was in Fedora leading up to the Fedora release, and the "final" upstream
release is pushed as an update (if/when needed)? Going from test/RC to
final usuaully isn't going to involve major changes (soname bumps, UI
changes, etc.) and so should be an acceptable update to everybody.

You'd be looking at a typical peak of around 5 months between upstream
release and Fedora release, with an average of more like 2-3 months,
which is a lot different from the 6 months that keeps being repeated as
the waiting time for something new.

For example (just an example - please don't take this as picking on
KDE!), KDE 4.4.0 was released on February 9, and F13 is scheduled for
May 11. That's a 3 month gap, not 6 months. In my opinion, I don't
think it is entirely unreasonable to wait 3 months for a major new
release.

--
Chris Adams <cmadams@hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-11-2010, 08:22 PM
Paul Wouters
 
Default Stable Release Updates types proposal (was Fedora Board Meeting Recap 2010-03-11)

On Thu, 11 Mar 2010, Seth Vidal wrote:

> And it will be impossible for users running the non-sha256 bind to
> communicate with the sha256 supporting arpa?
>
> I guess I don't understand what do the users of the existing bind LOSE?
>
> Is ARPA expecting everyone to upgrade to a sha256 supporting bind
> immediately? There's no migration window?

If someone has dnssec enabled in bind including DLV, then the key will be
found and its use will be attempted. I am not sure what happens on an older
bind 9.6.1 when that happens. One will hope it will just continue to be
treated as "insecure" and not as "bogus" (aka servfail). I have not tested
this.

But I understand your generic point. It's a feature so put it in rawhide/next
release.

Paul
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-11-2010, 08:46 PM
Jesse Keating
 
Default Stable Release Updates types proposal (was Fedora Board Meeting Recap 2010-03-11)

On Thu, 2010-03-11 at 16:22 -0500, Paul Wouters wrote:
> On Thu, 11 Mar 2010, Seth Vidal wrote:
>
> > And it will be impossible for users running the non-sha256 bind to
> > communicate with the sha256 supporting arpa?
> >
> > I guess I don't understand what do the users of the existing bind LOSE?
> >
> > Is ARPA expecting everyone to upgrade to a sha256 supporting bind
> > immediately? There's no migration window?
>
> If someone has dnssec enabled in bind including DLV, then the key will be
> found and its use will be attempted. I am not sure what happens on an older
> bind 9.6.1 when that happens. One will hope it will just continue to be
> treated as "insecure" and not as "bogus" (aka servfail). I have not tested
> this.
>
> But I understand your generic point. It's a feature so put it in rawhide/next
> release.
>
> Paul

If the case was that it would stop working badly, that falls under the
type of update I listed that depends on external data providers. That
type of update is allowed.

--
Jesse Keating
Fedora -- Freedom˛ is a feature!
identi.ca: http://identi.ca/jkeating
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-11-2010, 09:45 PM
Kevin Kofler
 
Default Stable Release Updates types proposal (was Fedora Board Meeting Recap 2010-03-11)

Chris Adams wrote:

> Once upon a time, Paul Wouters <paul@xelerance.com> said:
>> That might be harsh for some soname updates. Six months is a long time
>> to wait on new functionality after upstream released it.
>
> People keep tossing out "six months". How often is it that a new Fedora
> release comes out right before a new upstream, and that upstream is not
> already in testing in Fedora?

The average is 3 months which is just as unreasonable.

> For example (just an example - please don't take this as picking on
> KDE!), KDE 4.4.0 was released on February 9, and F13 is scheduled for
> May 11. That's a 3 month gap, not 6 months. In my opinion, I don't
> think it is entirely unreasonable to wait 3 months for a major new
> release.

I disagree. Sorry.

Kevin Kofler

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-11-2010, 09:47 PM
Kevin Kofler
 
Default Stable Release Updates types proposal (was Fedora Board Meeting Recap 2010-03-11)

Matthew Garrett wrote:

> On Thu, Mar 11, 2010 at 01:52:06PM -0500, Paul Wouters wrote:
>
>> That might be harsh for some soname updates.
>
> If a user has built an application against a library, it's not
> especially reasonable to then break that application by bumping a soname
> in a stable release.

If the application is in Fedora as all applications eventually ought to be,
we will take care of rebuilding it. Otherwise, whoever built it (some third-
party repository or the user him/herself) is responsible for rebuilding it.
This has always worked fine, I don't see the problem.

Kevin Kofler

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-11-2010, 10:13 PM
Kevin Kofler
 
Default Stable Release Updates types proposal (was Fedora Board Meeting Recap 2010-03-11)

Jesse Keating wrote:
> I had thought about these things, but they didn't strike me as a high
> level update type. And for the leaf node packages, when they do break
> it's not as less disruptive as you might think. Leaf node packages
> exist for a reason, they are likely very important to somebody, and if
> that breaks, that's going to be a very big issue for that somebody.

But if they're outdated, that can also be a big issue. Some leaf packages
are under heavy development, so users don't want to run old versions, nor do
upstream developers want them to.

Kevin Kofler

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 02:59 AM.

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