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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
