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-12-2010, 04:16 PM
Andy Green
 
Default Stable Release Updates types proposal (was Fedora Board Meeting Recap 2010-03-11)

On 03/12/10 14:01, Somebody in the thread at some point said:
> On Fri, Mar 12, 2010 at 12:23:58PM +0000, Andy Green wrote:
>
>> However I agree this isn't a real issue, the packages with the homegrown
>> apps should choke the yum update because they see the lib versions they
>> depend on would go away, so nothing breaks.
>
> Only if they're using the packaging system. While in an ideal world
> everything would be packaged in Fedora, the reality is that there's
> plenty of code that isn't, and users do do things like download stuff

Then that's the person's problem who is using a packaged OS outside the
packaging system: he can expect nothing but headaches being in stealth mode.

It seems we all agree though that it's true the update action will choke
if there are packages around that need the old libs and that's OK for
that scenario.

> and run ./configure; make; make install. The ones who are least likely
> to know how to generate packages are the ones who are most likely to be
> confused by applications suddenly breaking because of a soname bump, and
> they're the ones who are going to be wary of running *any* updates
> because they tend to break stuff for them.

That is what will happen when they upgrade to fc(n+1) anyway. And these
guys have to know enough usually to yum in a load of -devel pieces.

All that guy has to do is re-run make ; make install after the update
and he's away again. That does not sound very onerous. If there's a
big gain to be had in terms of solving impossible backport situations
then it sounds like a tradeoff that's at the least reasonable to argue.

-Andy

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

On Fri, 12 Mar 2010 17:19:45 +0000
Andy Green <andy@warmcat.com> wrote:

> On 03/12/10 15:11, Somebody in the thread at some point said:
> > Andy Green wrote:
> >
> >> On 03/12/10 00:45, Somebody in the thread at some point said:
> >>
> >>> If you are the user, then you should not be compiling
> >>> software. :-) You should be using some repository and that
> >>> repository is responsible for rebuilding the package.
> >>
> >> I tend to agree with what you have been writing but this seems
> >> wrong.
> >>
> >> I don't think I'm the only person who is using Fedora as a basis
> >> for homegrown apps, if what I want isn't in Fedora (because I am
> >> creating it locally) then I certainly will "compile software" as a
> >> Fedora user and the case must be considered.
> >
> > Uh, please read the context of my statement!
> >
> > I wrote:
> >> Huh? I have to compile the stuff I am developing very often anyway.
> >> Having to rebuild it once is not going to be the end of the world.
> >
> > Simo Sorce replied:
> >> It is if you are not the developer but the user.
> >
> > And I replied:
> >> If you are the user, then you should not be compiling software. :-)
> >
> > In this context, if you're writing homegrown apps, you're a
> > "developer", not a "user", so the above sentence obviously does not
> > apply. Instead, my original point does (you'll be compiling your
> > own software very often anyway).
>
> It's a bit of a false dichotomy because I may be developing my stuff
> and using someone else's, but I take your point.

You can call it a straw man, no problem calling things as they are.

I love people quoting other people slightly out of context and putting
their spin on it to make a point ...

Simo.

--
Simo Sorce * Red Hat, Inc * New York
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-12-2010, 05:14 PM
Peter Jones
 
Default Stable Release Updates types proposal (was Fedora Board Meeting Recap 2010-03-11)

On 03/12/2010 12:56 PM, Al Dunsmuir wrote:
> Friday, March 12, 2010, 10:52:35 AM, spot you wrote:
>
>> On 03/12/2010 10:47 AM, Eric Sandeen wrote:
>
>>> I really think this is not the approach, unless Fedora is just for rich people
>>> in (theoretically) rich countries. I doubt that's what we want.
>
>> Or we could just make Fedora print money.
>> ~spot
>> P.S. Please don't try this.
>
> Could you please add RFEs for World Peace, Curing the common cold,
> Turning back the ravages of time, and "Should have run when I met my
> ex" to that?
>

http://www.scientificamerican.com/blog/post.cfm?id=another-reason-vitamin-d-is-importa-2010-03-07

YMMV.

--
Peter

THE MAGIC WORDS ARE SQUEAMISH OSSIFRAGE
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-12-2010, 05:25 PM
Peter Jones
 
Default Stable Release Updates types proposal (was Fedora Board Meeting Recap 2010-03-11)

On 03/11/2010 07:18 PM, Kevin Kofler wrote:

> Once 4.n+1.0 is out, 4.n.x is no longer updated, there are no further bugfix
> releases, any bugs in it will stay unfixed. And there are also nice new
> features in the new version.

So this all boils down to you, the package maintainer, being unwilling or
unable to actually fix bugs? Is that what you're saying?

--
Peter

THE MAGIC WORDS ARE SQUEAMISH OSSIFRAGE
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-12-2010, 07:04 PM
Kevin Kofler
 
Default Stable Release Updates types proposal (was Fedora Board Meeting Recap 2010-03-11)

Peter Jones wrote:
> So this all boils down to you, the package maintainer, being unwilling or
> unable to actually fix bugs? Is that what you're saying?

KDE upstream fixes hundreds of bugs each month. It is just plain impossible
to backport all their bugfixes with the manpower we, or any other existing
distro, have (and no, our GNOME maintainers don't have that kind of manpower
either, so please don't bring up that argument), and even if we miraculously
managed to do it anyway, it would lead to us shipping something completely
untested outside of Fedora, so it'd potentially be much more broken than the
newer stable release series.

Kevin Kofler

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

Peter Jones wrote:
> It also implies that we're okay shipping updates of whole dep chains for
> any bug whatsoever in a stable release. This is a gigantic problem! Many
> people have complained about this - it uses much more bandwidth and
> storage, even with deltas (in fact, significantly more storage with
> deltas), and for very little appreciable benefit.

Without upgrading whole dep chains, important updates such as libmtp updates
adding new hardware support would be impossible. These always come as
grouped updates with rebuilds of Amarok and a couple other things. But the
maintainers do try to coordinate to reduce the amount of grouped updates,
e.g. libmtp and other such libraries such as libnjb often get updated
together, and they frequently come together with some new version of Amarok
as well.

Kevin Kofler

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

On Fri, 12 Mar 2010 18:59:30 +0000
Andy Green <andy@warmcat.com> wrote:

> On 03/12/10 18:06, Somebody in the thread at some point said:
>
> >>> In this context, if you're writing homegrown apps, you're a
> >>> "developer", not a "user", so the above sentence obviously does
> >>> not apply. Instead, my original point does (you'll be compiling
> >>> your own software very often anyway).
> >>
> >> It's a bit of a false dichotomy because I may be developing my
> >> stuff and using someone else's, but I take your point.
> >
> > You can call it a straw man, no problem calling things as they are.
> >
> > I love people quoting other people slightly out of context and
> > putting their spin on it to make a point ...
>
> My dear Simo your IFF is malfunctioning. "I take your point" is me
> agreeing that I took his words out of context when I went back and
> read what he clearly quoted. Having understood his larger point, I
> don't think splitting people into "developers" and "users" is a
> worthwhile distinction because all developers are users of something
> else.

I think we misunderstood each other on how we are referring to what.
Given the matter is completely knotted I give up commenting and
preemptively apologize to anyone that feel I said something wrong or
wrongly attributed something.

> At the company I am working for this whole subject has been a matter
> of great debate these last days about the best way to update our own
> stable packages for our own repo on top of a Fedora basis, by focus
> on backport or elevating our equivalent of rawhide into stable after
> thorough testing.

In general I think that point releases are a mean to provide users with
something usable somewhat consistent and that doesn't change too much,
so they can stick with it.
The others can adventure into rawhide.

If everything turns into rawhide why are we even doing point releases
at all ? Just have rawhide and push to ""stable"" stuff once enough
karma accumulates and have a constantly rolling release with no numbers
or anything.
Needless to say I don't think a constantly rolling release helps our
users. Even developers need to have something that doesn't move too
much under your feet. Developers are users too and need a distro they
can use for most of their tasks or the will move and develop elsewhere.

Although *some* developers need bleeding edge, they are normally a
minority, and they don't need bleeding edge everything, they can easily
pick from testing or rawhide what they need, or just rebuild from sprm
themselves.

> AFAICS the best way through it is a mixture depending on the exact
> situation of each package and the divergence in the sources and libs.
> If a fix we would like to have in stable is dependent on new APIs in
> uplevelled libs, backporting becomes Hell given the need to retain
> the old APIs for packages that don't get updated while integrating
> new ones for the fix.

I agree with you. It is not a clear cut ban this, approve that.
But it is more a matter of tendency. The unstable repositories should
tend to upgrade often, the released stable repos shouldn't and
sometimes you have to just let a bug there and tell people to use the
newer release rather than breaking more stuff in a "stable" release to
cram in an update to fix a minor bug.

Security releases are more delicate and if necessary exceptions can be
made there, that's where rel-eng comes in.

> It pushes me towards thinking a solution by bringing in the new libs
> and accepting the damage in terms of uplevelling and retesting the
> users of the library can often be the right way. And that seems to
> be Kevin's POV which is why I was surprised to misread what I misread.

I am not sure what's Kevin POV anymore, probably he has some sort of
view of what is the target user base and which packages should be fast
movers, but I can't make it up from his emails anymore.

If the position is that the status quo is fine, I have to disagree, we
have way too many updates in F-12, so from my POV something should
change to slow down the pace a bit. Whether that should be only done
for CRITPATH first and exclude some category of software that is not
installed by default I don't know; we can discuss that.
But the current status is not good IMO.

Simo.

--
Simo Sorce * Red Hat, Inc * New York
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-12-2010, 08:06 PM
Kevin Kofler
 
Default Stable Release Updates types proposal (was Fedora Board Meeting Recap 2010-03-11)

Simo Sorce wrote:
> I am not sure what's Kevin POV anymore, probably he has some sort of
> view of what is the target user base and which packages should be fast
> movers, but I can't make it up from his emails anymore.

I think that new versions should, as a general rule, be pushed, unless there
is a good reason NOT to push a particular new version (feature regressions,
known unfixed new bugs as found during testing, requires manual
intervention, breaks compatibility with existing user data etc.). (And of
course, if there are such reasons, the update MUST NOT be pushed. That's
what distinguishes the updates from Rawhide, and it's an important
distinction, because it defines stability from the user's point of view.)

> If the position is that the status quo is fine, I have to disagree, we
> have way too many updates in F-12, so from my POV something should
> change to slow down the pace a bit. Whether that should be only done
> for CRITPATH first and exclude some category of software that is not
> installed by default I don't know; we can discuss that.
> But the current status is not good IMO.

And indeed, I do think the status quo is mostly fine! If anything, it is
sometimes too conservative (e.g. GNOME, Firefox).

Kevin Kofler

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

On 03/11/2010 07:26 PM, Kevin Kofler wrote:
> Upstream cannot go back in time and magically fix a bug in an old release.

As an upstream maintainer, I wind up doing exactly this *constantly*.

--
Peter

I number the Linux folks among my personal heroes.
-- Donald Knuth
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-12-2010, 09:23 PM
Kevin Kofler
 
Default Stable Release Updates types proposal (was Fedora Board Meeting Recap 2010-03-11)

Peter Jones wrote:

> On 03/11/2010 07:26 PM, Kevin Kofler wrote:
>> Upstream cannot go back in time and magically fix a bug in an old
>> release.
>
> As an upstream maintainer, I wind up doing exactly this *constantly*.

No you don't. (I don't believe you invented time travel, sorry. ;-) ) You
can only release a NEW release with this fixed. Which by a strict enough
update policy (e.g. Debian stable's) already counts as a "new upstream
release", even if you only made that one particular change.

And in addition, many upstreams don't work that way. Sure, they will release
a new release with this fixed, but it will come from the current trunk which
also has many other changes. Many upstream projects do not use branches, all
releases come from the trunk, and it is totally impractical to make a fixed
version of every past release ever made. Not to mention that they will also
see no reason to do that: in fact, they will expect the packager to also
ship those other changes, as they are all there for a reason, e.g. because
they fix other bugs.

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 07:06 AM.

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