David Woodhouse wrote:



A "put up or shut up" attitude has only been harmful in several
occasions before. You cannot win volunteers with remarks like that.

Well, seems like the community is being solely gobbled up by
individuals who are both negative and non constructive.

That shouldn't be surprising for a project that doesn't value backwards
compatibility, stability, or interoperability with any third party
components.

Blame too those upstream projects who introduce these changes, fedora is
just a collection of all those items.
So you'll ship any sort of breakage with no regard to the interfaces you
promoted last month?


Of course not. We take care to ensure that when interfaces change, every
Fedora package is updated to cope.


Leaving everything all 3rd party work that tries to cooperate and a
user's own previous work useless. If a commercial system did that,
they'd be out of business in a heartbeat. A free distribution doesn't
have the same reasons to care about cooperation, but from the user's
perspective its all the same - if you can't count on interfaces being
maintained, a platform simply isn't worth the effort.


Whatever happened to the concept of an LSB definition that was complete
enough to permit apps to run unchanged across distributions? We need
something like that spanning at least 3 concurrent versions of fedora.


--
Les Mikesell
lesmikesell@gmail.com




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

On Wed, 2008-10-22 at 08:57 -0500, Les Mikesell wrote:
> >> So you'll ship any sort of breakage with no regard to the
> >> interfaces you promoted last month?
> >
> > Of course not. We take care to ensure that when interfaces change,
> > every Fedora package is updated to cope.
>
> Leaving everything all 3rd party work that tries to cooperate and a
> user's own previous work useless.

I've never found that to be the case, no. Any third party work that
"tried to co-operate" would be packaged as a Fedora package, and would
be included in my above statement.

And even my own personal hacks -- if it's a project of any significance
at all, then it's probably worth packaging. As much as I like to think
I'm unique (and I know others like to tell themselves that too), I'm
not. So if there's any piece of software which is _so_ useful to me that
I actually get off my lazy arse and _write_ it, then it's a fairly safe
bet it's going to be useful to someone else too.

> If a commercial system did that, they'd be out of business in a
> heartbeat.

The ability to cope with change is _precisely_ what distinguishes free
software from the commercial systems that it is slowly, but surely,
replacing.

The only people who really have a problem with it are those who fail to
work properly with whatever they call their 'upstream' project(s).

> A free distribution doesn't have the same reasons to care about
> cooperation, but from the user's perspective its all the same - if you
> can't count on interfaces being maintained, a platform simply isn't
> worth the effort.

There is a difference between internal and external APIs. Basic stuff
like GTK and glibc _don't_ break in incompatible ways very often. Those
are the kinds of things that external software uses.

If you're involved in the horrid details of the latest PackageKit API
change, then you really have no business being an _external_ piece of
software anyway. Whatever it is, it should be packaged and included in
the Fedora repository, and then we'll be able to take care of it when we
break it.

To be honest, Les, I think you're just spouting crap again. It's an
unfortunate habit with you, isn't it?

--
David Woodhouse Open Source Technology Centre
David.Woodhouse@intel.com Intel Corporation

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

Rex Dieter wrote:



Blame too those upstream projects who introduce these changes, fedora is
just a collection of all those items.

So you'll ship any sort of breakage with no regard to the interfaces you
promoted last month?


Thanks for putting words into my and fedora's mouth.


Actually I'm trying to give a user's perspective. As a closed black
box, fedora might work. I want to use 3rd party drivers, components,
apps, etc. but can't deal with them breaking every few months.



OK, I'll bite a bit...
when it's the choice of shipping an older unsupported version of software
vs. latest/supported, sometimes, yeah. It's a tough choice to have to
make.


Older/newer isn't quite the point here - it is more about why it is
necessary to break old functionality to add new or improved. Start with
the premise that fedora repositories don't and cannot contain all the
software that I want to run and perhaps you can see why interface change
is painful.



Unanswered:

Is there similar outrage against upstreams as well? Where is it?


Yes, to whatever extent upstream refuses to respect their own interfaces
as contracts with other programmers they deserve outrage as well. But,
you don't have to ship that stuff. Maybe if no one did, they'd decide
it was worth stabilizing interfaces to a point where others could cooperate.


--
Les Mikesell
lesmikesell@gmail.com

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

On Wed, 2008-10-22 at 10:01 -0500, Les Mikesell wrote:
> Yes, to whatever extent upstream refuses to respect their own interfaces
> as contracts with other programmers they deserve outrage as well. But,
> you don't have to ship that stuff. Maybe if no one did, they'd decide
> it was worth stabilizing interfaces to a point where others could cooperate.

Or more likely, everybody /but/ Fedora would ship it and then Fedora
would be laughed at for being too old and slow to adopt new upstream
releases.

--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

David Woodhouse wrote:



So you'll ship any sort of breakage with no regard to the
interfaces you promoted last month?
Of course not. We take care to ensure that when interfaces change,
every Fedora package is updated to cope.
Leaving everything all 3rd party work that tries to cooperate and a
user's own previous work useless.


I've never found that to be the case, no. Any third party work that
"tried to co-operate" would be packaged as a Fedora package, and would
be included in my above statement.


Give me a break... Nvidia, VMware, Sun Java, java apps, and on and on.
If something _has_ to be included as a Fedora package to work from one
release to the next, Fedora has failed for me.



If a commercial system did that, they'd be out of business in a
heartbeat.


The ability to cope with change is _precisely_ what distinguishes free
software from the commercial systems that it is slowly, but surely,
replacing.


How is having to modify and recompile every package every few months
'coping' with change? It is fairly rare to ever have to replace a
binary on a windows or mac due to an OS update. The mac even maintains
backwards compatibility across an update to a different CPU and wildly
different OS - and includes tools to migrate your settings and apps.
Without the stability factor that enterprise and long-term distributions
contribute, free software wouldn't be replacing anything.



The only people who really have a problem with it are those who fail to
work properly with whatever they call their 'upstream' project(s).


What should that mean to the user of the third party products that don't
'work properly' with fedora? Why would anyone need to 'work properly'
as opposed to following standard interfaces to interoperate correctly?



A free distribution doesn't have the same reasons to care about
cooperation, but from the user's perspective its all the same - if you
can't count on interfaces being maintained, a platform simply isn't
worth the effort.


There is a difference between internal and external APIs. Basic stuff
like GTK and glibc _don't_ break in incompatible ways very often. Those
are the kinds of things that external software uses.


What does mean in terms of being able to install vendor drivers, VMware,
Sun's Java with integration into the system path scheme, or something
from a random 3rd party repo?



If you're involved in the horrid details of the latest PackageKit API
change, then you really have no business being an _external_ piece of
software anyway. Whatever it is, it should be packaged and included in
the Fedora repository, and then we'll be able to take care of it when we
break it.


That is completely unrealistic, given a Fedora policy that excludes
things from the repository for various reasons, and just wrong to
require the system to be self-contained on general principles.



To be honest, Les, I think you're just spouting crap again. It's an
unfortunate habit with you, isn't it?


Its only crap if you believe that a distribution should require every
piece of software that it will run to 'work properly' with the
distribution provider according to the distribution provider's
definition. I don't - I believe interfaces are what makes software work.


--
Les Mikesell
lesmikesell@gmail.com

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

On Wed, 2008-10-22 at 08:39 -0500, Rex Dieter wrote:
> Unanswered:
> > Is there similar outrage against upstreams as well? Where is it?

On this list, it's shouted down. I commented some time ago about the
rather toxic behavior of the python developers vis-a-vis breaking
compatibility at virtually every release. You would have thought that I
had urinated in the holy water.

It's an ugly little wart on the free software movement. There's nowhere
near the incentive to take care of your user base without a direct
financial gain. Not, mind you, that commercial ventures haven't done
the same, but the consequences to them are more severe and direct.

Dave


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

On Wed, Oct 22, 2008 at 11:03:07AM -0500, David G. Mackay wrote:
>
> On Wed, 2008-10-22 at 08:39 -0500, Rex Dieter wrote:
> > Unanswered:
> > > Is there similar outrage against upstreams as well? Where is it?
>
> On this list, it's shouted down. I commented some time ago about the
> rather toxic behavior of the python developers vis-a-vis breaking
> compatibility at virtually every release. You would have thought that I
> had urinated in the holy water.
>
> It's an ugly little wart on the free software movement. There's nowhere
> near the incentive to take care of your user base without a direct
> financial gain. Not, mind you, that commercial ventures haven't done
> the same, but the consequences to them are more severe and direct.

You don't get to dictate what the upstream project's priorities are.
If you don't like the fact that apps break with every new python
release (I don't like it either), then pick a different programming
language with an upstream whose priorities better align with your
needs. eg, Perl or Java or OCaml or any number of other languages.
Open source is about freedom of choice & that applies to everyone,
users, developers, packagers alike. The python developers/community
have decided the level of stability they want between each of their
releases - they decided to accept a certain level of breakage. You
have the freedom to decide whether this matches your needs and if
not, no one is forcing you to use python.

Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

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

On Wed, Oct 22, 2008 at 03:42:08PM +0100, David Woodhouse wrote:
>
> I've never found that to be the case, no. Any third party work that
> "tried to co-operate" would be packaged as a Fedora package, and would
> be included in my above statement.

Packages included in fedora have been broken for months or years now.
You may think that these are not important packages, but still they are
in fedora. Now as I told already fixing these packages or coming up with
a design more backward compatible may entail some costs too, but
having packages in fedora isn't a insurance against breakage. Gnome
packages and major desktop package, sure will get a lot of love, but
packages that are not 'mainstream' fedora won't be taken in
consideration that much.

--
Pat

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

Patrice Dumas wrote:

> On Wed, Oct 22, 2008 at 03:42:08PM +0100, David Woodhouse wrote:
>>
>> I've never found that to be the case, no. Any third party work that
>> "tried to co-operate" would be packaged as a Fedora package, and would
>> be included in my above statement.
>
> Packages included in fedora have been broken for months or years now.

Keep in mind that this discussion (imo) is more about general intentions,
not specific cases.

-- Rex

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

Daniel P. Berrange wrote:



Is there similar outrage against upstreams as well? Where is it?

On this list, it's shouted down. I commented some time ago about the
rather toxic behavior of the python developers vis-a-vis breaking
compatibility at virtually every release. You would have thought that I
had urinated in the holy water.

It's an ugly little wart on the free software movement. There's nowhere
near the incentive to take care of your user base without a direct
financial gain. Not, mind you, that commercial ventures haven't done
the same, but the consequences to them are more severe and direct.


You don't get to dictate what the upstream project's priorities are.


But it should be something open for discussion, and something considered
when integrating a package into a distribution and when/if the
incompatible changes should be propagated.



If you don't like the fact that apps break with every new python
release (I don't like it either), then pick a different programming
language with an upstream whose priorities better align with your
needs. eg, Perl or Java or OCaml or any number of other languages.


That decision would be a lot more obvious if the history of backwards
compatibility of a project was tracked publicly, perhaps with the
packagers of affected apps keeping track of the time they spend just to
maintain functionality. That would help a new user decide where to
invest his own time.



Open source is about freedom of choice & that applies to everyone,
users, developers, packagers alike. The python developers/community
have decided the level of stability they want between each of their
releases - they decided to accept a certain level of breakage. You
have the freedom to decide whether this matches your needs and if
not, no one is forcing you to use python.


It is pretty hard not to use python in a fedora or RH-based distro. Or
to use any other version than what the distro updates to internally -
which means that any 3rd party or local additions will take extra work
to keep precisely in step.


--
Les Mikesell
lesmikesell@gmail.com

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