[Fwd: Wikipidia - Goodbye Red Hat and Fedora]

[Patrice Dumas]

On Thu, Oct 23, 2008 at 12:38:20PM +0100, David Woodhouse wrote:
> 
> 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

This is partly that kind of planning, but the planning I am referring to
is more about upstream planning integration within the existing
frameworks.

In this precise case, there was a single point of control, the bug
report, and there was some kind of planning regarding the inclusion in
fedora.

But in any case, most of the changes don't fall under the feature
process, because they are upstream changes, so I can't see how this
could be controlled in Fedora, if the package maintainers are not
willing to be controlled.

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

That's not obvious to me that the main issue is how this should have
been fixed in fedora. ConsoleKit could also have been planned from 
the beginning with a consideration to how dm worked, for pam support, and
with a proposal for dm maintainers (or the packagers in fedora) for an
implementation. Instead we were pointed to a gdm patch after the fact.

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

Note that I didn't said that he was wrong.

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

But this is not that easy, especially in that case. I think that the kdm
patch, although functional is not right, because it hardcodes the
device path. As a package maintainer I would have preferred a broken wdm
rather than this patch. And I talked with the xdm upstream maintainer
and he was not going to accept such patch either.

That being said, I agree that people bringing forward the feature could
have been of more help and should have taken more attention to the help
I was asking for and the stuff I proposed. But they seem to be very
busy, so it is not easy.

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

I think that many people in the fedora community, especially @RH people
and people in the board prefer a fast moving fedora, even if some 
packages considered of less importance (like xdm) are screwed, 
that give some testing for RHEL rather than a careful avoidance of 
regressions. This is not the same thing, but quite consistent with 
the opposition toward leaving infra open after EOL, with the argument 
being 'Fedora is fast moving and RHEL/EPEL is stable, choose one of 
the two, another way is chimeric'. I don't want to start a flamewar
about RH hidden agendas and so on and so forth, it is just how I
personnally feel. And to repeat myself once again this may be a very
good path, though it is certainly not the one I would have followed if
I was in the position of deciding.

I also think in the today's fedora community, be it from @RH or not,
(except from some reactionary people like me who come from a past 
fedora and still haven't given up) there are a lot of people who 
want something fast moving even if some packages considered of 
less importance are screwed, without any reference to RHEL, but 
because they are enthousiast desktop people, the way fedora is 
fast moving suit them.

--
Pat