On Wed, 2008-10-22 at 12:07 -0500, Rex Dieter wrote:
> 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.

Of _course_ it's not about specific cases. That would require actual
substantiated facts which can be verified or disproved; not just
handwaving and ranting.

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

On Wed, Oct 22, 2008 at 12:16 PM, Les Mikesell <lesmikesell@gmail.com> wrote:
> 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.


Have any of your discussions of this nature yielded fruitful results?
If not, your approach is failed, even if the intent is good. In which
case you need to come up with a more productive approach.


--
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )

--
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 06:25:11PM +0100, David Woodhouse wrote:
>
> Of _course_ it's not about specific cases. That would require actual
> substantiated facts which can be verified or disproved; not just
> handwaving and ranting.

I answered to Rex giving a specific case, regarding ConsoleKit and
various dm breakage. You want the bugzilla entries or you trust me?

--
Pat

--
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 17:20 +0100, Daniel P. Berrange wrote:
> 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.

Dictate, no, criticize, yes.

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

Well, for me, it means that I will use python for smaller projects, and
probably java for large/persistent projects. However, there are ripple
effects in that people that have developed tools that I want to use in
python, i. e. zope, are also placed in an untenable position.

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

True, but that cuts both ways. If one of the goals is to get more
people to use open source, then making sure that it is usable ought to
be something of a priority. If enterprises are going to make major
investments to develop software, then the current state of turmoil in
the open source software ecology is not attractive.

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 4:42 PM, David G. Mackay <mackay_d@bellsouth.net> wrote:
> On Wed, 2008-10-22 at 17:20 +0100, Daniel P. Berrange wrote:
>> 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.
>
> Dictate, no, criticize, yes.
>
>> 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.
>
> Well, for me, it means that I will use python for smaller projects, and
> probably java for large/persistent projects. However, there are ripple
> effects in that people that have developed tools that I want to use in
> python, i. e. zope, are also placed in an untenable position.


>From what I understand, Python is designed to be parallel installable.
Just a tidbit of info I had come across.


--
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )

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

2008/10/22 om prakash <omprakash79@hotmail.com>:
> dont give me a mail

I've deleted your launchpad-users subscription.

--
Matthew Revell - Launchpad.net - free software collaboration and project hosting

--
launchpad-users mailing list
launchpad-users@lists.canonical.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/launchpad-users

2008/10/22 y@ry <yaricammi@hotmail.it>:
> delete my account plaese....i've lost my password

Your launchpad-users mailing list subscription or your Launchpad account?


--
Matthew Revell - Launchpad.net - free software collaboration and project hosting

--
launchpad-users mailing list
launchpad-users@lists.canonical.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/launchpad-users

On Wed, 2008-10-22 at 20:46 +0200, Patrice Dumas wrote:
> On Wed, Oct 22, 2008 at 06:25:11PM +0100, David Woodhouse wrote:
> >
> > Of _course_ it's not about specific cases. That would require actual
> > substantiated facts which can be verified or disproved; not just
> > handwaving and ranting.
>
> I answered to Rex giving a specific case, regarding ConsoleKit and
> various dm breakage. You want the bugzilla entries or you trust me?

/me looks back...

On Wed, 2008-10-22 at 15:06 +0200, Patrice Dumas wrote:
> It is not that simple. The distinction between fedora and upstream in
> many cases is rather fuzzy. For example the hal/dbus/consoleKit/*Kit is
> put in fedora when it is at early development stages, and many of the
> developpers involved in these are also involved in fedora. And the
> changes are pushed in fedora without taking seriously the backward
> compatibility issues. For example wdm and xdm (and slim) are broken
> since consolekit replaced pam_console, and although there is a rather
> simple solution to integrate those dm it has never been planned and it
> is still not fixed, though a fix exist for months. As long as it worked
> in gdm it was fine for fedora. You can tell, hey, xdm, wdm and slim can
> copy what gdm does, but when the solution implemented in gdm is specific
> and not consistent with the previous designs, it is not so easy. Fedora
> controls some upstream so can do anything in these, but doesn't control
> all of them.

Yeah, that sucks. We should do better than that.

Although I've always been a little dubious about our 'Feature Process',
it does seem that it addresses this kind of problem. For the feature to
reach 100% completion, it should obviously involve fixes for the other
display managers. And there is a 'reversion plan' in case we don't
manage to complete the feature in time for the release.

>From what you say above, it sounds like the ConsoleKit feature should be
declared incomplete, and we should be reverting it unless the feature
owners finish the job.

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

On Thu, Oct 23, 2008 at 09:30:57AM +0100, David Woodhouse wrote:
>
> Yeah, that sucks. We should do better than that.
>
> Although I've always been a little dubious about our 'Feature Process',
> it does seem that it addresses this kind of problem. For the feature to
> reach 100% completion, it should obviously involve fixes for the other
> display managers. And there is a 'reversion plan' in case we don't
> manage to complete the feature in time for the release.

Here, simply keeping up using pam_console would have worked. But lead to
much less testing of fast user switching. The whole story can be tracked
down from this bug, from 2007-02-09:
https://bugzilla.redhat.com/show_bug.cgi?id=228110

Later a pam module was added for login. And even later a solution has
been found for dm, building on what was done for xinit, that plays
well with wdm/xdm/slim, though it is still not applied:
https://bugzilla.redhat.com/show_bug.cgi?id=452156

>From my point of view, this comment (certainly biased, it is a comment
from me) summary the situation, and it is really a fedora issue,
not only an upstream issue:
https://bugzilla.redhat.com/show_bug.cgi?id=452156#c15

> From what you say above, it sounds like the ConsoleKit feature should be
> declared incomplete, and we should be reverting it unless the feature
> owners finish the job.

If this is the case, then we would only have had ConsoleKit in F-11...

At the time the issue happened, there was no feature process, but I
can't see how it would have changed anything. A feature process cannot
prevent lack of planning, focus on gnome, lack of integration with
existing frameworks and lack of consideration for alternative setups, if
this attitude is endorsed by the project on a whole, which is the case
for fedora, see for example
https://bugzilla.redhat.com/show_bug.cgi?id=228110#c19
and look at all the conversations on this mailing list or fesco
decisions.

A FESCo vote (at least of today FESCo) would certainly be to let the
minor dm be broken (hopefully they will be fixed for the RHEL release),
so even if a Feature was not considered finished I doubt the changes
would have been reversed. Once again, I don't think that such an
attitude is fundamentaly problematic, this allowed to have much more
testing for gdm, kdm and fast user switching, which is good. But this is
also, in my opinion, a good example of what fedora really is, and my
personnal point of view is that it is becoming even more so.

As a side note I thought that having more packages, and packages that
are not mainstream, with the corresponding packagers being part of the
community would lead to a push to another direction, but for
good or bad, this didn't happened -- and I think that in the fedora
community, those, like me, not in complete agreement with the
'mainstream' fedora (more testing than planning, innovation breaking
old frameworks, focus on major desktop components) are, in my opinion,
getting less and less consideration. The corresponding packages are
simply broken intermitently, always on the struggle to catch up with
the constant changes.

--
Pat

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

On Thu, 2008-10-23 at 11:20 +0200, Patrice Dumas wrote:
> > From what you say above, it sounds like the ConsoleKit feature should be
> > declared incomplete, and we should be reverting it unless the feature
> > owners finish the job.
>
> If this is the case, then we would only have had ConsoleKit in F-11...
>
> At the time the issue happened, there was no feature process, but I
> can't see how it would have changed anything. A feature process cannot
> prevent lack of planning, focus on gnome, lack of integration with
> existing frameworks and lack of consideration for alternative setups,

I think that's a fundamental part of what the feature process _should_
be doing. The whole point of the feature process, as I see it, is about
precisely the _planning_ you say we lack. Otherwise, we're just be
throwing new stuff in willy-nilly and just writing it up in the release
notes after the fact.

In this case, there seems to have been a disagreement about _how_ the
other display managers should be fixed. Regardless of that, I think it's
clear that they _SHOULD_ have been fixed...

> if this attitude is endorsed by the project on a whole, which is the case
> for fedora, see for example
> https://bugzilla.redhat.com/show_bug.cgi?id=228110#c19
> and look at all the conversations on this mailing list or fesco
> decisions.

... but I also think Jeremy was right in the above-mentioned #c19, where
he dropped the bug status to 'tracker'. That's 'SHOULD', not 'MUST'.

> A FESCo vote (at least of today FESCo) would certainly be to let the
> minor dm be broken

Maybe. I, for one, would vote against it -- I'd expect those responsible
for the PackageKit 'feature' to fix it _somehow_, rather than just
leaving it broken. Even if there is some argument that the fix could be
done a better way.

> (hopefully they will be fixed for the RHEL release),

I hope that's not an issue for FESCo members -- although it _should_ be
a factor in the decision-making process of @redhat.com folks working on
stuff. "We're going to have to do the sensible thing in RHEL in the end
anyway; let's do it right away and not screw Fedora over".

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