----- Original Message ----- > From: "Adam Williamson" <awilliam@xxxxxxxxxx> > To: "Discussions about development for the Fedora desktop" <desktop@xxxxxxxxxxxxxxxxxxxxxxx> > Sent: Tuesday, February 11, 2014 12:03:28 AM > Subject: Re: The vision for the Fedora Workstation > > On Mon, 2014-02-10 at 09:48 -0500, Christian Schaller wrote: > > A few little 'border' nitpicks here: > > > 3. Will other desktops be blocked from the Workstation? No. First of > > all the plan as I see it is that we will continue with both GNOME and > > KDE as release blocking as we do now. > > I don't think we should completely close the door on discussing this. > I've already noted that it's reasonable to expect that, overall, the > three product aspect of .next will result in an increased releng and QA > burden compared to what we currently have. Both of those groups (and > probably others, those are just the ones I'm familiar with) are > currently operating more or less at 'full capacity'. You can't really > expect the existing QA resources, especially, to cover the current level > of quality for base system, GNOME and KDE *plus* a similar level of > quality for the Cloud product *plus* a similar level of quality for the > Server product, across all arches, on a similar release schedule to the > one we currently have. > > or in other words, you can have comprehensive coverage, good coverage, > fast coverage, or 'cheap' coverage: pick about two and a half. > > If we don't want to wind up half assing things (which is also, let's > face it, a plausible outcome...), that's a circle we're going to have to > square *somewhere*, and I'm not sure it's wise to take any options off > the table at this point. Would it suck to stop blocking releases on KDE? > Sure. Is it obviously a worse choice than, say, not bothering to test > the Server product's role mechanism, or not bothering to test ARM, or > making the release cycle three months longer, or somehow convincing Red > Hat to fork out for another half dozen QA folks, or somehow convincing > another dozen people to suddenly get enthusiastic about volunteer QA? I > think we'd be wise to carefully evaluate all the options. Definitely, the way I think the process here will work in practice is that the working groups define their ideal product. We then go you(Fedora QA), the Fedora kernel team, Fedora RHEL eng etc., and 'negotiate' what is actually realistically possible today, what is not possible today, but we could look at down the line, and what is likely to never be possible. > > The rest will continue being available to the degree that their > > respective teams are able to keep providing them, like now. What will > > change is how you install those desktops and what is expected of them. > > The general idea here is that the Workstation install will install a > > small core package set onto your system. From there you can add what > > you need, including desktop environments from the Software installer. > > There will be some requirements for how these desktop environments > > operate, for instance they would need to make themselves available > > through GDM and respect any settings that come to them from GDM. They > > can not make changes to the system that will break the default Fedora > > Desktop session. And if one of the non-blocking desktops fail to be > > ready for a given release then the user will get dropped backed into > > the default session after upgrade, although we should if possible warn > > them through the installer that this would be the result of them > > upgrading. If a desktop is not interested in following these rules > > they will not be thrown out of the Fedora package repository of > > course, but they will not appear in the UI installer and people will > > have to get them from the command line. > > All of these seem to be very Workstation-centric statements. Am I > correct in assuming we can throw a "for the Workstation product" hedge > around essentially all of them? Yes, sorry for not being clear on that. > I'm thinking, for instance, of the netinst image, which there seems to > be a general assumption will still exist, and is clearly not a > Workstation product (any more than it's a Cloud or Server product). It > doesn't seem appropriate to require you to go 'through the Workstation' > to deploy a different desktop from netinst, if that's what you want to > do. > > The status of the DVD as it currently exists seems more open to debate, > but some people at least seem in favour of keeping it. > > > However the command line tools we have now are of course all still > > there, and using them you can of course change your system to your > > hearts content, but of course this is a option for the especially > > interested and just like you can't go to Volkswagen and complain about > > how the old 79 Beetle that you put a Porsche 911 engine into is a > > danger to drive, you can't come to Fedora and complain that your > > custom system has problems. > > This seems subject to the same problem as above. s/come to Fedora/come > to Fedora Workstation/ seems a safer way of putting it. As I conceive > it, at the point you start throwing out packages that are 'part of > Workstation' you are outside the Workstation tent, but still in the > Fedora tent. Of course, it's possible to do fairly silly things within > the Fedora tent and when you do so, the 'support' you get will likely > consist of people telling you that you just did a silly thing. > > Remember, when you're talking about a distribution like Fedora, the > concept of 'support obligations' is an extremely squishy one in any > case. When it comes down to brass tacks, the only cast-iron support > guarantee (boy, that was a terrible metaphor mix) you have from Fedora > is the 100% refund option... > > I'd just like to retain a bit of conceptual flexibility here. Yeah agreed, I think for me 'supported' in this context is simply that devs trying to decide which bugs they will attempt spending some time on will tend to filter out bugs coming from systems that seems obviously non-standard. I know that for a lot of the teams retrace.fedoraproject.org is one of the primary bug prioritization tools atm., and the goal would be to have more granularity on that site to for instance have the 3 products be something you can filter on. > > And if anyone wondered we will keep systemd as our init system despite > > it not working on Hurd :) > > CFV! CFV! > Actually according to Paragraph 239, subsection 57 of the Fedora constitution any CFV repeated more than once it automatically invalid and can not be re-submitted until the requirements for Paragraph 98, subsection 38 are fulfilled or 10 years has past :) > > 7. Will the Workstation use containers instead of RPM? For the short > > to median term the answer to this question is no. For the long term > > the answer is that most likely that we will continue using RPMS to > > some degree. Container technologies will be developed and matured over > > the next few years and the desktop working group will look to > > experiment with them and use them where it makes sense, in > > collaboration with the other working groups. Personally I don't see a > > 'pure' container based future as very likely, my expectation is that > > we will keep using RPMS for the core and containers for at least part > > of the application stack. I also expect that there is a good chance > > RPMS will be part of the composition toolset for building container > > apps. But we are speculating about the future here, so my general > > suggestion is that we will cross this bridge when we get to it, as > > arguing about it now easily end up being an unproductive discussion > > about the hypothetical features of the system we think the person we > > are discussing with has in his or her mind. > > This seems reasonable to me. Especially so long as it appears to be the > case that, if you know a bit of C and you're at a loose end on a rainy > Sunday, what you do is write a container mechanism... Hehe :) > > I hope this answers some of what I have been told is a bit unclear to > > people. I held of sending this email for quite a while simply because > > I felt it would preempt the work on the technical specification, but I > > was repeatedly told that it would be better to remove some > > misconceptions out there as quick as possible as long as I prefaced it > > with a disclaimer that the working group of course still need to run > > its course and that the final result of that work will not be a carbon > > copy of what I say here. > > Thanks for the clarification attempt. My pleasure :) Christian -- desktop mailing list desktop@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/desktop
