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 11-12-2008, 05:00 PM
Les Mikesell
 
Default Proposal: Rolling Release

Jeff Spaleta wrote:

On Wed, Nov 12, 2008 at 8:37 AM, Les Mikesell <lesmikesell@gmail.com> wrote:

It might if I knew when and how to use it. Would that be obvious if some
3rd party or local program(s) no longer worked some time after an update?


How does anyone with a niche need know about the existence of any
capability in our software collection that is not installed by
default? That's a deep question. Far deeper than I think you are
prepared to discuss.


That's the wrong question. The real question is, what interface did you
just break in an update? You don't need to know anything about anyone
else's software. You just need to provide working interfaces. Or, when
you whimsically break them in updates, give a hint about how to get a
working version back.


--
Les Mikesell
lesmikesell@gmail.com



--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-12-2008, 07:33 PM
"Jeff Spaleta"
 
Default Proposal: Rolling Release

On Wed, Nov 12, 2008 at 9:00 AM, Les Mikesell <lesmikesell@gmail.com> wrote:
> That's the wrong question. The real question is, what interface did you
> just break in an update? You don't need to know anything about anyone else's
> software. You just need to provide working interfaces. Or, when you
> whimsically break them in updates, give a hint about how to get a working
> version back.

Are you suggesting that we should never provide an unstable interface
in any of the libraries or scripting modules that we package? And
that we only provide technologies that upstream has committed to API
stability between subsequent releases? Surely you aren't suggesting
that. You can't really expect us to hold an API stable when upstream
isn't...that's just silly.

At best you could maybe hope for a subset of available technologies to
be identified as upstream interface stable, and get a subset of
maintainers to pledge to keep interfaces stable inside a release
timeframe in conjunction with those upstream projects. There is no
coherent initiative towards what could be generously termed a 'Fedora
SDK'. I've seen no interest from a group of active
maintainers..ever..to take on that problem space and commit to seeing
it happen. Something like this would require a community member to
step forward and be a strong, active, persuasive leader on the effort.

I very much doubt that you are the right person to lead such an
effort, even if you did decide this is the issue that would finally
get you off the fence and working on something constructively. So my
advice to you is, dial back the rhetoric and see if you can get other
people talking about this and identify the person you think can lead
this initiative.

-jef"if I only had a beowulf cluster of XO's"spaleta

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-12-2008, 08:44 PM
Les Mikesell
 
Default Proposal: Rolling Release

Jeff Spaleta wrote:



That's the wrong question. The real question is, what interface did you
just break in an update? You don't need to know anything about anyone else's
software. You just need to provide working interfaces. Or, when you
whimsically break them in updates, give a hint about how to get a working
version back.


Are you suggesting that we should never provide an unstable interface
in any of the libraries or scripting modules that we package?


No, I'm saying that necessary changes should be planned, and to the
extent possible, batched at version releases. And where that isn't
possible, interface and command line changes to expect should be
published before the update so users and 3rd parties know how to work
around the breakage.



And
that we only provide technologies that upstream has committed to API
stability between subsequent releases?


I'd like that very much but given what you have to work with, I'll agree
it is impossible. However, like any other QA aspect, I'm suggesting
that you do the best you can not to break local or 3rd party programs
built on the platform you just shipped.



Surely you aren't suggesting
that. You can't really expect us to hold an API stable when upstream
isn't...that's just silly.


No, what is silly is to actually try to use a platform that you know is
going to break because the people building it have no concern for the
people using it. Even simple things like the change in samba that broke
backuppc's ability to pass windows authentication some time ago can be a
disaster.



At best you could maybe hope for a subset of available technologies to
be identified as upstream interface stable, and get a subset of
maintainers to pledge to keep interfaces stable inside a release
timeframe in conjunction with those upstream projects.


Who forces you to push interface-changing updates out of rawhide? If I
wanted today's bugs from an upstream project I'd grab it from there
instead of using a distribution's release version of the code. The
fedora major release cycle is already fast enough anyway. If some
upstream project can't settle on an interface you are doing your users a
favor by keeping it away from them.



There is no
coherent initiative towards what could be generously termed a 'Fedora
SDK'. I've seen no interest from a group of active
maintainers..ever..to take on that problem space and commit to seeing
it happen. Something like this would require a community member to
step forward and be a strong, active, persuasive leader on the effort.


I'm not sure what that even means. If fedora has something unique, I
don't particularly want it and don't understand why anyone would develop
for something intentionally non-standard. What I'd really want is for
LSB-compliance to someday get to the point where programs running on
Fedora would never need to know that it is fedora at all, much less the
version and last-update-date underneath.



I very much doubt that you are the right person to lead such an
effort, even if you did decide this is the issue that would finally
get you off the fence and working on something constructively. So my
advice to you is, dial back the rhetoric and see if you can get other
people talking about this and identify the person you think can lead
this initiative.


Is there someone involved in development that eats his own dog food
(i.e. uses fedora with current updates as infrastructure for some large
project or even in a lab setting with many users)?


--
Les Mikesell
lesmikesell@gmail.com

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-12-2008, 08:51 PM
"Jeff Spaleta"
 
Default Proposal: Rolling Release

On Wed, Nov 12, 2008 at 12:44 PM, Les Mikesell <lesmikesell@gmail.com> wrote:
> I'd like that very much but given what you have to work with, I'll agree it
> is impossible. However, like any other QA aspect, I'm suggesting that you
> do the best you can not to break local or 3rd party programs built on the
> platform you just shipped.

How about this for an answer. Given what we have to work with right
now. We are doing our best.
Now if you and anyone else don't think our current best effort is not
good enough.. you can certainly choose to add your manhours into the
effort. Which packages would you specifically like to help
co-maintain?

-jef

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-12-2008, 10:02 PM
Les Mikesell
 
Default Proposal: Rolling Release

Jeff Spaleta wrote:

On Wed, Nov 12, 2008 at 12:44 PM, Les Mikesell <lesmikesell@gmail.com> wrote:

I'd like that very much but given what you have to work with, I'll agree it
is impossible. However, like any other QA aspect, I'm suggesting that you
do the best you can not to break local or 3rd party programs built on the
platform you just shipped.


How about this for an answer. Given what we have to work with right
now. We are doing our best.


OK, but if breakage didn't scare off the user base maybe there would be
a lot more to work with.



Now if you and anyone else don't think our current best effort is not
good enough.. you can certainly choose to add your manhours into the
effort. Which packages would you specifically like to help
co-maintain?


It's not really about effort or engineering or packaging, all of which
are probably better in fedora than anywhere else. It's more about
timing and recognizing the effect of an interface change on the things
on the other side of it. Just admitting that there are things on the
other side of the interfaces you ship would be a start. Otherwise it is
an endless package shuffle for no end purpose and no way to tell if you
are going forwards or backwards.


--
Les Mikesell
lesmikesell@gmail.com

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-12-2008, 10:02 PM
Bojan Smojver
 
Default Proposal: Rolling Release

David Nielsen <gnomeuser <at> gmail.com> writes:

> And if it's deemed stable enough for F10 as a release then surely it should be
stable enough as an update for F9. A big and not uncomplicated update granted
but we could in theory put this into updates-testing and roll it out for F9 as
well. If the argument against doing this would be stability one would be left
questioning how F10 could be labelled stable in the fist place.

An oversimplification, IMHO. Just because all that was stable with the rest of
the stuff shipped with F-10, doesn't mean the effect will be the same when it
lands next to the rest of the stuff from F-9. It needs to be compiled (with a
different compiler and libs?), packaged (against different dependencies?) and
tested _again_ (in how many combinations?).

It is just too much work for not good reason whatsoever.

--
Bojan

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-13-2008, 12:01 PM
"Horst H. von Brand"
 
Default Proposal: Rolling Release

Les Mikesell <lesmikesell@gmail.com> wrote:
> Jeff Spaleta wrote:

[...]

> > Are you suggesting that we should never provide an unstable interface
> > in any of the libraries or scripting modules that we package?

> No, I'm saying that necessary changes should be planned, and to the
> extent possible, batched at version releases.

That means even more of the bureaucracy that people are so quick to
disparage here...

> And where that isn't
> possible, interface and command line changes to expect should be
> published before the update so users and 3rd parties know how to work
> around the breakage.

That isn't always obvious to the packager of some piece of infrastructure.
Change GCC, the "normal" applications continue compiling fine (or get fixed
as part of the update in the distributin), but some strange package
somewhere was relying on a GCC bug (or misfeature, or sloppiness) and blows
up when you try to build it. Has happened dozens of times to me, and I'm
still grateful GCC moves forward and becomes more standards-conforming.

> > And
> > that we only provide technologies that upstream has committed to API
> > stability between subsequent releases?

> I'd like that very much but given what you have to work with, I'll
> agree it is impossible. However, like any other QA aspect, I'm
> suggesting that you do the best you can not to break local

That is done, albeit imperfectly. It usually gets caught and fixed quickly.

> or 3rd
> party programs built on the platform you just shipped.

That is impossible, and besides the point anyway: Part of the benefit of
being part of the distribution is the previous point.

[...]

> > At best you could maybe hope for a subset of available technologies to
> > be identified as upstream interface stable, and get a subset of
> > maintainers to pledge to keep interfaces stable inside a release
> > timeframe in conjunction with those upstream projects.

> Who forces you to push interface-changing updates out of rawhide?

New upstream versions... go talk to them ;-)

> If
> I wanted today's bugs from an upstream project I'd grab it from there
> instead of using a distribution's release version of the code. The
> fedora major release cycle is already fast enough anyway.

It is fast /because/ it integrates upstream changes as early as
possible. Can't have fast advances and no change at the same time.

> If some
> upstream project can't settle on an interface you are doing your users
> a favor by keeping it away from them.

OK. Leave out the kernel, ...

> > There is no
> > coherent initiative towards what could be generously termed a 'Fedora
> > SDK'. I've seen no interest from a group of active
> > maintainers..ever..to take on that problem space and commit to seeing
> > it happen. Something like this would require a community member to
> > step forward and be a strong, active, persuasive leader on the effort.

> I'm not sure what that even means. If fedora has something unique, I
> don't particularly want it

Choose something else and leave us in peace then.

> and don't understand why anyone would
> develop for something intentionally non-standard.

Some people do so even if you don't understand them. That would mean your
understanding of what and why people do as they do is flawed, not
(necessarily) said developers.

[A standard is developed by consensus among people trying various
non-standard approaches on what the best way to do something is. This
means exploring non-standard approaches (even ones going against said
standards at times).]

> What I'd really
> want is for LSB-compliance to someday get to the point where programs
> running on Fedora would never need to know that it is fedora at all,
> much less the version and last-update-date underneath.

LSB and similar standards mean aiming at the lowest common denominator.
I.e., it might work just fine, but it will certainly waste much of what
Fedora (or any other particular distribution) is all about

> > I very much doubt that you are the right person to lead such an
> > effort, even if you did decide this is the issue that would finally
> > get you off the fence and working on something constructively. So my
> > advice to you is, dial back the rhetoric and see if you can get other
> > people talking about this and identify the person you think can lead
> > this initiative.

> Is there someone involved in development that eats his own dog food
> (i.e. uses fedora with current updates as infrastructure for some
> large project or even in a lab setting with many users)?

I'm using Fedora rawhide daily. Our labs (several hundred users) are
running latest Fedora most of the time (except when the releases fall at
awkward times in our terms).
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-13-2008, 09:29 PM
Les Mikesell
 
Default Proposal: Rolling Release

Horst H. von Brand wrote:



Are you suggesting that we should never provide an unstable interface
in any of the libraries or scripting modules that we package?



No, I'm saying that necessary changes should be planned, and to the
extent possible, batched at version releases.


That means even more of the bureaucracy that people are so quick to
disparage here...


But just regarding timing the move from rawhide to release, and it would
be less arbitrary if the answer was always 'release at a version
release' unless you are fixing something horribly broken as shipped.



And where that isn't
possible, interface and command line changes to expect should be
published before the update so users and 3rd parties know how to work
around the breakage.


That isn't always obvious to the packager of some piece of infrastructure.
Change GCC, the "normal" applications continue compiling fine (or get fixed
as part of the update in the distributin), but some strange package
somewhere was relying on a GCC bug (or misfeature, or sloppiness) and blows
up when you try to build it. Has happened dozens of times to me, and I'm
still grateful GCC moves forward and becomes more standards-conforming.


Being grateful it moves is one thing. Being surprised when it regresses
mid distro-version is something else. The problem is that every update
is not 'forward'.





Who forces you to push interface-changing updates out of rawhide?


New upstream versions... go talk to them ;-)


That makes sense as a reason to go into rawhide. Why do they have to go
into production before a release point?



If
I wanted today's bugs from an upstream project I'd grab it from there
instead of using a distribution's release version of the code. The
fedora major release cycle is already fast enough anyway.


It is fast /because/ it integrates upstream changes as early as
possible. Can't have fast advances and no change at the same time.


If you want rawhide you can run rawhide. Otherwise what's so important
that it can't wait for a release point?



If some
upstream project can't settle on an interface you are doing your users
a favor by keeping it away from them.


OK. Leave out the kernel, ...


If there were a nexenta-like flavor of fedora (our familiar userland on
top of opensolaris) I'd certainly give it a shot. Otherwise the
overwhelming need to constrain and manage Linux kernel changes keeps
several large corporations in business.



What I'd really
want is for LSB-compliance to someday get to the point where programs
running on Fedora would never need to know that it is fedora at all,
much less the version and last-update-date underneath.


LSB and similar standards mean aiming at the lowest common denominator.
I.e., it might work just fine, but it will certainly waste much of what
Fedora (or any other particular distribution) is all about


If people can't agree that the interfaces/libraries are the right way to
do things, then there's a pretty good chance that they aren't, and that
they will probably change or go away soon. I don't have time to waste
chasing a lot of things that are going to change and break underneath
the things that might depend on them.



Is there someone involved in development that eats his own dog food
(i.e. uses fedora with current updates as infrastructure for some
large project or even in a lab setting with many users)?


I'm using Fedora rawhide daily. Our labs (several hundred users) are
running latest Fedora most of the time (except when the releases fall at
awkward times in our terms).


Do the users ever have things break because libraries changed under
them? Is this the sort of lab where work progresses over years or
decades or where the universe is re-created every semester? The latter
doesn't exactly match the real world.


--
Les Mikesell
lesmikesell@gmail.com

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 

Thread Tools




All times are GMT. The time now is 12:05 PM.

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