Hi All,
We have just shy of 6 calendar weeks until the PRD for Workstation is due (Jan 13). However, with the holidays likely eating up a good chunk of that it's realistically closer to a month.
We've had 5 revisions of the PRD Christian has drafted so far, with some good feedback along the way. I don't think we're going to be able to specifically list everyone's personal favorite use case in the PRD itself, but the use cases we have should cover a broad set of people already. I suggested moving the multiple-monitor and many terminal windows items under e.g. the Corporate developer user case and that should at least meet much of the technical requirements for Sysadmins too (at least to start).
Ideally, I'd like to get a final PRD draft sent and approved by the WG before the holiday break. That would give FESCo plenty of time for review, and would allow us to get started in January on the next item, which is a list of changes the WG would need from existing Fedora to accomplish the PRD goals. I suspect that is going to take a significant amount of work to settle, and the more time we have the better.
If there are critical changes you think are needed for the PRD, please speak up now and list them. That is particularly true for any of the WG members. We can evaluate them as they come in.
Thanks.
josh
On Wed, Dec 04, 2013 at 11:11:15AM -0500, Josh Boyer wrote:
If there are critical changes you think are needed for the PRD, please speak up now and list them. That is particularly true for any of the WG members. We can evaluate them as they come in.
I'm working on an alternate version of the PRD. I'll post that shortly, probably by the end of the week.
On Wed, Dec 4, 2013 at 12:27 PM, Matthew Garrett mjg59@srcf.ucam.org wrote:
On Wed, Dec 04, 2013 at 11:11:15AM -0500, Josh Boyer wrote:
If there are critical changes you think are needed for the PRD, please speak up now and list them. That is particularly true for any of the WG members. We can evaluate them as they come in.
I'm working on an alternate version of the PRD. I'll post that shortly, probably by the end of the week.
Did you send this out and I missed it? The end of the week has come and gone, and I'm still concerned we're going to run short on time.
josh
On 12/09/2013 07:25 AM, Matthew Garrett wrote:
On Sun, Dec 08, 2013 at 03:13:53PM -0500, Josh Boyer wrote:
Did you send this out and I missed it? The end of the week has come and gone, and I'm still concerned we're going to run short on time.
"The working group will also regularly meet with a designated representative of Red Hat to discuss how Red Hats product and development plans will affect the Fedora product development and resource allocation."
And here´ s yet another WG shenanigan you do realize that what we implement in the distribution and project wide needs to be done so with the resources the community has available.
We cannot as a community make plans or direction changes that depend on a available corporate resources be it from Red Hat or someone else.
JBG
On Mon, Dec 09, 2013 at 08:57:29AM +0000, "Jóhann B. Guðmundsson" wrote:
And here´ s yet another WG shenanigan you do realize that what we implement in the distribution and project wide needs to be done so with the resources the community has available.
Red Hat's developers are a resource available to the community.
On 12/09/2013 01:54 PM, Matthew Garrett wrote:
On Mon, Dec 09, 2013 at 08:57:29AM +0000, "Jóhann B. Guðmundsson" wrote:
And here´ s yet another WG shenanigan you do realize that what we implement in the distribution and project wide needs to be done so with the resources the community has available.
Red Hat's developers are a resource available to the community.
That's just an outright lie
I have never seen statement from Red Hat where it guarantees certain amount of resources in terms of manpower or anything to be available *always* to the community.
Even if what you said was true it would still be irrelevant and absolutely nothing the community should be dependant upon.
JBG
On Mon, Dec 09, 2013 at 02:21:54PM +0000, "Jóhann B. Guðmundsson" wrote:
On 12/09/2013 01:54 PM, Matthew Garrett wrote:
On Mon, Dec 09, 2013 at 08:57:29AM +0000, "Jóhann B. Guðmundsson" wrote:
And here´ s yet another WG shenanigan you do realize that what we implement in the distribution and project wide needs to be done so with the resources the community has available.
Red Hat's developers are a resource available to the community.
That's just an outright lie
I have never seen statement from Red Hat where it guarantees certain amount of resources in terms of manpower or anything to be available *always* to the community.
I've never seen a statement from any member of the community that guarantees they'll commit a certain level of time or effort to Fedora.
On 12/09/2013 02:26 PM, Matthew Garrett wrote:
On Mon, Dec 09, 2013 at 02:21:54PM +0000, "Jóhann B. Guðmundsson" wrote:
On 12/09/2013 01:54 PM, Matthew Garrett wrote:
On Mon, Dec 09, 2013 at 08:57:29AM +0000, "Jóhann B. Guðmundsson" wrote:
And here´ s yet another WG shenanigan you do realize that what we implement in the distribution and project wide needs to be done so with the resources the community has available.
Red Hat's developers are a resource available to the community.
That's just an outright lie
I have never seen statement from Red Hat where it guarantees certain amount of resources in terms of manpower or anything to be available *always* to the community.
I've never seen a statement from any member of the community that guarantees they'll commit a certain level of time or effort to Fedora.
Which is to be expected after all communities are made up of people *volunteering their free time* to the community and that time is not being volunteer to benefit Red Hat but Fedora but ofcourse Red Hat does what it can to misuse that contributed time to their own benefits + I dont see how that's related to you claiming that Red Hat developers are resources available to the community.
JBG
On Mon, Dec 09, 2013 at 02:40:56PM +0000, "Jóhann B. Guðmundsson" wrote:
Which is to be expected after all communities are made up of people *volunteering their free time* to the community and that time is not being volunteer to benefit Red Hat but Fedora but ofcourse Red Hat does what it can to misuse that contributed time to their own benefits + I dont see how that's related to you claiming that Red Hat developers are resources available to the community.
We can't guarantee that Red Hat will always continue contributing to Fedora, but nor can we guarantee that anyone else will either.
On Mon, Dec 9, 2013 at 9:53 AM, Matthew Garrett mjg59@srcf.ucam.org wrote:
On Mon, Dec 09, 2013 at 02:40:56PM +0000, "Jóhann B. Guðmundsson" wrote:
Which is to be expected after all communities are made up of people *volunteering their free time* to the community and that time is not being volunteer to benefit Red Hat but Fedora but ofcourse Red Hat does what it can to misuse that contributed time to their own benefits + I dont see how that's related to you claiming that Red Hat developers are resources available to the community.
We can't guarantee that Red Hat will always continue contributing to Fedora, but nor can we guarantee that anyone else will either.
This discussion has been had numerous times in numerous forums. It isn't productive and continuing to rehash it is just filling up people mailboxes with useless email.
Red Hat contributes to Fedora based on its interests, gaining benefit from Fedora. Volunteer members contribute to Fedora based on their interests, gaining benefit from Fedora.
Those two groups of people are not separate and are collectively "the Fedora community". If a person does not like that community, they aren't required to be part of it.
josh
On 12/09/2013 02:59 PM, Josh Boyer wrote:
This discussion has been had numerous times in numerous forums. It isn't productive and continuing to rehash it is just filling up people mailboxes with useless email.
Red Hat contributes to Fedora based on its interests, gaining benefit from Fedora.
Contributing is one thing dictating it's direction while giving false sense of freedom is another.
Volunteer members contribute to Fedora based on their interests, gaining benefit from Fedora.
Those two groups of people are not separate and are collectively "the Fedora community". If a person does not like that community, they aren't required to be part of it.
If a company misuses that community they should be excluded from it not the community made more depended on it.
People coming to participate in that community should be informed on what and how historically as well as currently the company exploding the community has and is doing so, so volunteers considering contributing their free time can make an enlighten decision if the said community is indeed what they want to be contributing their free time to or for.
JBG
"Jóhann B. Guðmundsson" writes:
On 12/09/2013 02:26 PM, Matthew Garrett wrote:
On Mon, Dec 09, 2013 at 02:21:54PM +0000, "Jóhann B. Guðmundsson" wrote:
On 12/09/2013 01:54 PM, Matthew Garrett wrote:
On Mon, Dec 09, 2013 at 08:57:29AM +0000, "Jóhann B. Guðmundsson" wrote:
And here´ s yet another WG shenanigan you do realize that what we implement in the distribution and project wide needs to be done so with the resources the community has available.
Red Hat's developers are a resource available to the community.
That's just an outright lie
I have never seen statement from Red Hat where it guarantees certain amount of resources in terms of manpower or anything to be available *always* to the community.
I've never seen a statement from any member of the community that guarantees they'll commit a certain level of time or effort to Fedora.
Which is to be expected after all communities are made up of people *volunteering their free time* to the community and that time is not being volunteer to benefit Red Hat but Fedora but ofcourse Red Hat does what it can to misuse that contributed time to their own benefits + I dont see how that's related to you claiming that Red Hat developers are resources available to the community.
As an academic user I see no problems engaging with Redhat explicitly. Many university setups are such that on the server and centrally managed infrastructure we have RHEL or Centos, and individual user laptops/desktops can be on random operating systems including Fedora. So I see it a net positive if there is some cross-talk between Fedora and RHEL, especially if that influences the latter in a useful way.
--Marcel
Ok, so looking over this it seems the primary change you made was replace the use cases, with the first use case being 'general user'? Is that truly useful usecase to call out? Prioritizing something to target 'everyone' isn't really prioritization at all.
Christian
----- Original Message ----- From: "Matthew Garrett" mjg59@srcf.ucam.org To: "Discussions about development for the Fedora desktop" desktop@lists.fedoraproject.org Sent: Monday, December 9, 2013 8:25:41 AM Subject: Re: Workstation PRD approval
On Sun, Dec 08, 2013 at 03:13:53PM -0500, Josh Boyer wrote:
Did you send this out and I missed it? The end of the week has come and gone, and I'm still concerned we're going to run short on time.
Attached.
On Mon, Dec 09, 2013 at 04:51:13AM -0500, Christian Schaller wrote:
Ok, so looking over this it seems the primary change you made was replace the use cases, with the first use case being 'general user'? Is that truly useful usecase to call out? Prioritizing something to target 'everyone' isn't really prioritization at all.
Yes, it's a vital use case to call out, because it covers the set of behaviour that almost everyone who uses the Workstation product will require. If we concentrate on improving the developer experience to the exclusion of caring about the general user case, no developers are actually going to bother with Fedora. They'll just use OS X instead, because it'll be a nicer desktop OS and almost as good a development environment.
Or you could assume that it is included in the developer usecase, because focusing on the developer usecase in a way that makes no developer want to use the system is actually the opposite of focusing on the developer usecase.
Christian
----- Original Message ----- From: "Matthew Garrett" mjg59@srcf.ucam.org To: "Discussions about development for the Fedora desktop" desktop@lists.fedoraproject.org Sent: Monday, December 9, 2013 2:53:18 PM Subject: Re: Workstation PRD approval
On Mon, Dec 09, 2013 at 04:51:13AM -0500, Christian Schaller wrote:
Ok, so looking over this it seems the primary change you made was replace the use cases, with the first use case being 'general user'? Is that truly useful usecase to call out? Prioritizing something to target 'everyone' isn't really prioritization at all.
Yes, it's a vital use case to call out, because it covers the set of behaviour that almost everyone who uses the Workstation product will require. If we concentrate on improving the developer experience to the exclusion of caring about the general user case, no developers are actually going to bother with Fedora. They'll just use OS X instead, because it'll be a nicer desktop OS and almost as good a development environment.
On Mon, Dec 09, 2013 at 08:56:37AM -0500, Christian Schaller wrote:
Or you could assume that it is included in the developer usecase, because focusing on the developer usecase in a way that makes no developer want to use the system is actually the opposite of focusing on the developer usecase.
Why include it in the developer usecase? We don't want to limit the product to developers.
No, but if you are not going to put in the resources needed to truly target the consumer market then adding a usecase where you claim you are is misleading.
Christian
----- Original Message ----- From: "Matthew Garrett" mjg59@srcf.ucam.org To: "Discussions about development for the Fedora desktop" desktop@lists.fedoraproject.org Sent: Monday, December 9, 2013 3:01:07 PM Subject: Re: Workstation PRD approval
On Mon, Dec 09, 2013 at 08:56:37AM -0500, Christian Schaller wrote:
Or you could assume that it is included in the developer usecase, because focusing on the developer usecase in a way that makes no developer want to use the system is actually the opposite of focusing on the developer usecase.
Why include it in the developer usecase? We don't want to limit the product to developers.
On Mon, Dec 09, 2013 at 09:29:04AM -0500, Christian Schaller wrote:
No, but if you are not going to put in the resources needed to truly target the consumer market then adding a usecase where you claim you are is misleading.
What resources are required for doing so that wouldn't also be required to support the developer usecase?
Ok, we are going in circles here. So lets be clear we all agree that we need a system where the basics are working well. Ease of installation, robustness, driver support and so on. The system can not be inherently broken. We all agree on that point.
So the next question becomes, what is the point of the PRD? First of all it is not to define what applications people can or can not package for the Fedora ecosystem. If someone wants to package 'My little Pony click-along adventures' that is perfectly fine no matter what usecases or targets we list in the PRD.
The point of the PRD is to give an overall set of priorities/goals for the development effort around each product. Meaning where are we going to spend engineering time beyond the basic 'make the system work smoothly'. So if you are going to make general consumers a specific target we need to back that up with development plans for general consumer, like writing new applications for smoother facebook usage or more educational software for kids or whatever you decide the 'general consumer' wants. So while there might be software in such categories which ends up getting packaged for Fedora, I don't think there is anyone on this list who actually plans on writing such software for Fedora specifically.
So as I stated before and which also the PRD stated, we do hope that the workstation becomes a solid and nice desktop that a lot of people can like and want to use, because at the end of the day all users, developer or others, want the same baseline, a stable and well working system. But I think the crucial thing here is that the goal of the new products is not to just be the traditional Fedora packaging effort, but to be actual development targets where at least Red Hat plans to put paid time on developing these features. And thus putting in 'general users' as a usecase doesn't make sense to me here, because as much as we all here would love to see 2014 be the year of the linux desktop, that is very unlikely to happen just because we general users it in the PRD.
Christian
----- Original Message ----- From: "Matthew Garrett" mjg59@srcf.ucam.org To: "Discussions about development for the Fedora desktop" desktop@lists.fedoraproject.org Sent: Monday, December 9, 2013 3:35:20 PM Subject: Re: Workstation PRD approval
On Mon, Dec 09, 2013 at 09:29:04AM -0500, Christian Schaller wrote:
No, but if you are not going to put in the resources needed to truly target the consumer market then adding a usecase where you claim you are is misleading.
What resources are required for doing so that wouldn't also be required to support the developer usecase?
On Mon, Dec 09, 2013 at 10:01:46AM -0500, Christian Schaller wrote:
So as I stated before and which also the PRD stated, we do hope that the workstation becomes a solid and nice desktop that a lot of people can like and want to use, because at the end of the day all users, developer or others, want the same baseline, a stable and well working system. But I think the crucial thing here is that the goal of the new products is not to just be the traditional Fedora packaging effort, but to be actual development targets where at least Red Hat plans to put paid time on developing these features. And thus putting in 'general users' as a usecase doesn't make sense to me here, because as much as we all here would love to see 2014 be the year of the linux desktop, that is very unlikely to happen just because we general users it in the PRD.
The aim of the PRD is to describe the product that we are developing. It is a requirement that the product we develop be usable as a general purpose desktop, as otherwise aproximately nobody is going to use it. Therefore, the PRD must discuss the requirements of a usable general purpose desktop.
On Mon, Dec 9, 2013 at 4:01 PM, Christian Schaller cschalle@redhat.com wrote:
Ok, we are going in circles here. So lets be clear we all agree that we need a system where the basics are working well. Ease of installation, robustness, driver support and so on. The system can not be inherently broken. We all agree on that point.
So the next question becomes, what is the point of the PRD? First of all it is not to define what applications people can or can not package for the Fedora ecosystem. If someone wants to package 'My little Pony click-along adventures' that is perfectly fine no matter what usecases or targets we list in the PRD.
The point of the PRD is to give an overall set of priorities/goals for the development effort around each product. Meaning where are we going to spend engineering time beyond the basic 'make the system work smoothly'. So if you are going to make general consumers a specific target we need to back that up with development plans for general consumer, like writing new applications for smoother facebook usage or more educational software for kids or whatever you decide the 'general consumer' wants. So while there might be software in such categories which ends up getting packaged for Fedora, I don't think there is anyone on this list who actually plans on writing such software for Fedora specifically.
So as I stated before and which also the PRD stated, we do hope that the workstation becomes a solid and nice desktop that a lot of people can like and want to use, because at the end of the day all users, developer or others, want the same baseline, a stable and well working system.
It seems like you and Matthew don't really disagree much on what we should produce just whether we should add the general user to the PRD. Given that we are going to cover this case anyway (because in the end everyone is a "general user") ... how does adding it hurts us? It just a clear statement that non developers are not excluded.
On Mon, Dec 9, 2013 at 1:23 PM, drago01 drago01@gmail.com wrote:
On Mon, Dec 9, 2013 at 4:01 PM, Christian Schaller cschalle@redhat.com wrote:
Ok, we are going in circles here. So lets be clear we all agree that we need a system where the basics are working well. Ease of installation, robustness, driver support and so on. The system can not be inherently broken. We all agree on that point.
So the next question becomes, what is the point of the PRD? First of all it is not to define what applications people can or can not package for the Fedora ecosystem. If someone wants to package 'My little Pony click-along adventures' that is perfectly fine no matter what usecases or targets we list in the PRD.
The point of the PRD is to give an overall set of priorities/goals for the development effort around each product. Meaning where are we going to spend engineering time beyond the basic 'make the system work smoothly'. So if you are going to make general consumers a specific target we need to back that up with development plans for general consumer, like writing new applications for smoother facebook usage or more educational software for kids or whatever you decide the 'general consumer' wants. So while there might be software in such categories which ends up getting packaged for Fedora, I don't think there is anyone on this list who actually plans on writing such software for Fedora specifically.
So as I stated before and which also the PRD stated, we do hope that the workstation becomes a solid and nice desktop that a lot of people can like and want to use, because at the end of the day all users, developer or others, want the same baseline, a stable and well working system.
It seems like you and Matthew don't really disagree much on what we should produce just whether we should add the general user to the PRD. Given that we are going to cover this case anyway (because in the end everyone is a "general user") ... how does adding it hurts us? It just a clear statement that non developers are not excluded.
The problem, as I see it, is that "general user" is much too flexible of a usecase. It leaves open things like "user X wants to use a mismash of applications from different DEs" and "user Y is a general user but wants to use a different DE". It focuses too much on personal preference, which leads to a somewhat nebulous target and is difficult to meet. Sure, we can say that isn't something Workstation is aimed at, but it's hard to stand your ground when the user is listed as "general".
However, "general desktop _usage_" is certainly within scope. Developers, sysadmins, students, grandma, all use a desktop. They read email. They use a web browser. The basics of using your computer are implicit as Christian says, but Matthew contends leaving them out reads as if there will be no focus given to them.
I would argue the target users are additive to general desktop usage. So instead, perhaps the PRD could incorporate somewhere that we wish to produce a Workstation that is high quality and usable for daily computing but with focus improvements in the developer areas. This could perhaps be done very simply as a line addition or slight rewording in the mission statement.
josh
Josh Boyer (jwboyer@fedoraproject.org) said:
However, "general desktop _usage_" is certainly within scope. Developers, sysadmins, students, grandma, all use a desktop. They read email. They use a web browser. The basics of using your computer are implicit as Christian says, but Matthew contends leaving them out reads as if there will be no focus given to them.
I would argue the target users are additive to general desktop usage. So instead, perhaps the PRD could incorporate somewhere that we wish to produce a Workstation that is high quality and usable for daily computing but with focus improvements in the developer areas. This could perhaps be done very simply as a line addition or slight rewording in the mission statement.
This seems like a worthwhile effort to clarify. If I look at the latest draft of the PRD, it does:
Target Audience - Developer type A - Developer type B - Developer type C - Developer type D - Other users
Plans, Policies and Work: - Robust upgrades (not developer specific at all) - Quality releases (not developer specific at all) - Better upgrade/rollback control (not developer specific at all) - 3rd party software (not developer specific at all) - Fedora ecosystem integration (not developer specific at all) - Standardize/unify Linux desktop space (only relevant for platform developers, which is not a developer type called out above) - Develop app guidelines (only relevant for a subset of developers that isn't a specifc one of A/B/C/D above) - Container-based app install (only relevant for a subset...) - Encapsulated dev environments (developer specific)
So I would agree there's a bit of a disconnect in the document between what is said to be targeted and what is planned to be done.
Bill
Hi everyone, Sorry for being a bit late with chimming in again, was travelling then knocked out with acute food poisoning.
Anyway, the second non-heading sentence of the document says 'We want to create a stable, integrated, polished and user friendly system that can appeal to a wide general audience, but with a special focus on providing a platform for development of server side and client applications.' This is in the Mission statement. So I still fail to see how we are not covering this aspect of things.
Would it help people if we boldface that line?
Christian
----- Original Message ----- From: "Bill Nottingham" notting@redhat.com To: "Discussions about development for the Fedora desktop" desktop@lists.fedoraproject.org Sent: Tuesday, December 10, 2013 8:45:16 PM Subject: Re: Workstation PRD approval
Josh Boyer (jwboyer@fedoraproject.org) said:
However, "general desktop _usage_" is certainly within scope. Developers, sysadmins, students, grandma, all use a desktop. They read email. They use a web browser. The basics of using your computer are implicit as Christian says, but Matthew contends leaving them out reads as if there will be no focus given to them.
I would argue the target users are additive to general desktop usage. So instead, perhaps the PRD could incorporate somewhere that we wish to produce a Workstation that is high quality and usable for daily computing but with focus improvements in the developer areas. This could perhaps be done very simply as a line addition or slight rewording in the mission statement.
This seems like a worthwhile effort to clarify. If I look at the latest draft of the PRD, it does:
Target Audience - Developer type A - Developer type B - Developer type C - Developer type D - Other users
Plans, Policies and Work: - Robust upgrades (not developer specific at all) - Quality releases (not developer specific at all) - Better upgrade/rollback control (not developer specific at all) - 3rd party software (not developer specific at all) - Fedora ecosystem integration (not developer specific at all) - Standardize/unify Linux desktop space (only relevant for platform developers, which is not a developer type called out above) - Develop app guidelines (only relevant for a subset of developers that isn't a specifc one of A/B/C/D above) - Container-based app install (only relevant for a subset...) - Encapsulated dev environments (developer specific)
So I would agree there's a bit of a disconnect in the document between what is said to be targeted and what is planned to be done.
Bill
On Mon, Dec 16, 2013 at 05:13:10AM -0500, Christian Schaller wrote:
Hi everyone,
Sorry for being a bit late with chimming in again, was travelling then knocked out with acute food poisoning.
Anyway, the second non-heading sentence of the document says 'We want to create a stable, integrated, polished and user friendly system that can appeal to a wide general audience, but with a special focus on providing a platform for development of server side and client applications.' This is in the Mission statement. So I still fail to see how we are not covering this aspect of things.
Given that you agree that it's in scope, what's your objection to rewriting part of the PRD to make it clear that it's an explicit part of the project?
I did rewrite part of the PRD to make it an (even more) explicit part of the project, I just didn't want it in the usecase list due to the way we are focusing the development effort around the desktop I don't want to give a false impression of a lot of engineering resources being put into specific development for 'general users'. Our 'general user' story is that we will have a solid foundation that 'just works' and of course many of the applications packaged for Fedora are of interest to general users. But to me if we are to add 'general users' as a usecase it should be accompanied by plans to write new desktop applications for Fedora that would appeal to such users. For instance if we planned to write a desktop Hulu app or a Facebook assistant or whatever the idea would be.
The goal of the 3 products to me is to start building sellable stories for why someone would want to use Fedora specifically as opposed to linux in general. Which is why we are trying to tie development resources to the plan. I mean yes, we can say that Fedora is a nice choice for Photographers since we have Darktable packaged for it, but that is equally true for almost any distribution out there. And since we are not planning to put specific work into Darktable or similar for Fedora I haven't put 'Photographers' on our usecase list. That said being a solid operating system that packages Darktable it could very well be a great option for a lot of photographers out there and I do hope we will have a lot of photographers using it. As who knows, maybe as we move forward we will decide to target photographers specifically with some development work.
Christian
'On Wed, 2013-12-18 at 18:04 +0000, Matthew Garrett wrote:
On Mon, Dec 16, 2013 at 05:13:10AM -0500, Christian Schaller wrote:
Hi everyone,
Sorry for being a bit late with chimming in again, was travelling then knocked out with acute food poisoning.
Anyway, the second non-heading sentence of the document says 'We want to create a stable, integrated, polished and user friendly system that can appeal to a wide general audience, but with a special focus on providing a platform for development of server side and client applications.' This is in the Mission statement. So I still fail to see how we are not covering this aspect of things.
Given that you agree that it's in scope, what's your objection to rewriting part of the PRD to make it clear that it's an explicit part of the project?
-- Matthew Garrett | mjg59@srcf.ucam.org
On Mon, Jan 6, 2014 at 1:47 PM, Christian Fredrik Kalager Schaller cschalle@redhat.com wrote:
I did rewrite part of the PRD to make it an (even more) explicit part of the project [...]
Did you forgot to attach it or are you referring to your last draft?
I was referring to the last draft I sent just before Christmas
Christian
----- Original Message ----- From: "drago01" drago01@gmail.com To: "Discussions about development for the Fedora desktop" desktop@lists.fedoraproject.org Sent: Monday, January 6, 2014 2:19:59 PM Subject: Re: Workstation PRD approval
On Mon, Jan 6, 2014 at 1:47 PM, Christian Fredrik Kalager Schaller cschalle@redhat.com wrote:
I did rewrite part of the PRD to make it an (even more) explicit part of the project [...]
Did you forgot to attach it or are you referring to your last draft?
On Mon, Jan 06, 2014 at 01:47:48PM +0100, Christian Fredrik Kalager Schaller wrote:
I did rewrite part of the PRD to make it an (even more) explicit part of the project, I just didn't want it in the usecase list due to the way we are focusing the development effort around the desktop I don't want to give a false impression of a lot of engineering resources being put into specific development for 'general users'.
So who do we expect to provide those engineering resources? We seem to agree that those general users are, in many cases, the developers and enthusiasts that we expect to support, so we need to ensure that there's development effort put into ensuring that the desktop experience itself is compelling.
Our 'general user' story is that we will have a solid foundation that 'just works' and of course many of the applications packaged for Fedora are of interest to general users. But to me if we are to add 'general users' as a usecase it should be accompanied by plans to write new desktop applications for Fedora that would appeal to such users. For instance if we planned to write a desktop Hulu app or a Facebook assistant or whatever the idea would be.
The list of use cases is supposed to define the sets of users that we'll consider during development. We agree that the needs of the general desktop user are important and have to be considered during development, which means that it's a supported use case. Which obviously means it should be enumerated in the set of use cases.
----- Original Message -----
From: "Matthew Garrett" mjg59@srcf.ucam.org To: "Discussions about development for the Fedora desktop" desktop@lists.fedoraproject.org Sent: Monday, January 6, 2014 11:46:38 PM Subject: Re: Workstation PRD approval
On Mon, Jan 06, 2014 at 01:47:48PM +0100, Christian Fredrik Kalager Schaller wrote:
I did rewrite part of the PRD to make it an (even more) explicit part of the project, I just didn't want it in the usecase list due to the way we are focusing the development effort around the desktop I don't want to give a false impression of a lot of engineering resources being put into specific development for 'general users'.
So who do we expect to provide those engineering resources? We seem to agree that those general users are, in many cases, the developers and enthusiasts that we expect to support, so we need to ensure that there's development effort put into ensuring that the desktop experience itself is compelling.
I expect the vast majority of our engineering resources to come from Red Hat.
Our 'general user' story is that we will have a solid foundation that 'just works' and of course many of the applications packaged for Fedora are of interest to general users. But to me if we are to add 'general users' as a usecase it should be accompanied by plans to write new desktop applications for Fedora that would appeal to such users. For instance if we planned to write a desktop Hulu app or a Facebook assistant or whatever the idea would be.
The list of use cases is supposed to define the sets of users that we'll consider during development. We agree that the needs of the general desktop user are important and have to be considered during development, which means that it's a supported use case. Which obviously means it should be enumerated in the set of use cases.
I disagree, it is meant to enumerate the areas we give special focus during development. Adding a 'catch all' usecase like 'general users' doesn't help anyone do anything.
Christian
-- Matthew Garrett | mjg59@srcf.ucam.org -- desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop
On Tue, Jan 07, 2014 at 05:34:31AM -0500, Christian Schaller wrote:
On Mon, Jan 06, 2014 at 01:47:48PM +0100, Christian Fredrik Kalager Schaller wrote: So who do we expect to provide those engineering resources? We seem to agree that those general users are, in many cases, the developers and enthusiasts that we expect to support, so we need to ensure that there's development effort put into ensuring that the desktop experience itself is compelling.
I expect the vast majority of our engineering resources to come from Red Hat.
Red Hat will be committing engineering resources to support the general user desktop?
The list of use cases is supposed to define the sets of users that we'll consider during development. We agree that the needs of the general desktop user are important and have to be considered during development, which means that it's a supported use case. Which obviously means it should be enumerated in the set of use cases.
I disagree, it is meant to enumerate the areas we give special focus during development. Adding a 'catch all' usecase like 'general users' doesn't help anyone do anything.
I don't think you understand what "use case" means. It's the set of ways that people can use our system that we wish to support. We wish to support users who aren't actively engaging in development and who aren't CS students, so they should be included in the set of use cases that we support.
On Tue, Jan 7, 2014 at 11:14 AM, Matthew Garrett mjg59@srcf.ucam.org wrote:
On Tue, Jan 07, 2014 at 05:34:31AM -0500, Christian Schaller wrote:
On Mon, Jan 06, 2014 at 01:47:48PM +0100, Christian Fredrik Kalager Schaller wrote: So who do we expect to provide those engineering resources? We seem to agree that those general users are, in many cases, the developers and enthusiasts that we expect to support, so we need to ensure that there's development effort put into ensuring that the desktop experience itself is compelling.
I expect the vast majority of our engineering resources to come from Red Hat.
Red Hat will be committing engineering resources to support the general user desktop?
The list of use cases is supposed to define the sets of users that we'll consider during development. We agree that the needs of the general desktop user are important and have to be considered during development, which means that it's a supported use case. Which obviously means it should be enumerated in the set of use cases.
I disagree, it is meant to enumerate the areas we give special focus during development. Adding a 'catch all' usecase like 'general users' doesn't help anyone do anything.
I don't think you understand what "use case" means. It's the set of ways that people can use our system that we wish to support. We wish to support users who aren't actively engaging in development and who aren't CS students, so they should be included in the set of use cases that we support.
We've reached a stalemate on this.
On the one hand we have a case that aims Workstation at becoming a development environment for a broad set of possible software. On the other we have one that places importance on general desktop usage. Neither of them are actually conflicting with each other in any way other than whether the latter is implicit in the former.
It seems we have a trust issue here. There's a lack of trust that a development focused Workstation can possibly be generally usable while also solving problems for the developer set. There's a lack of trust that resources will be put forward where necessary. And there's a complete lack of faith that other contributors and upstreams can fill the role of developing applications and such for the general use case.
I can't solve this, but the (agonizingly delayed) back and forth going on right now is not lending itself to actually accomplishing anything at all. If we don't set a direction soon, and have faith that people won't have their heads up their collective arses and hold myopic views of "targets", then we're going to continue to languish.
We have a deadline for the PRD coming up in about a week. I'd like to actually have something to present to FESCo. Can we please either agree to trust each other or barring that call for a vote on one of the current draft PRDs? Members of the Workstation WG really need to speak up here.
josh
Hi,
We have a deadline for the PRD coming up in about a week. I'd like to actually have something to present to FESCo. Can we please either agree to trust each other or barring that call for a vote on one of the current draft PRDs? Members of the Workstation WG really need to speak up here.
Is possible to have some compromise/midway between the two drafts? As I see it they mostly just differ in the contexts they set: Christian's having more emphasis on different types of developers and Matthew's being closer perhaps to the traditional Fedora user audience.
I feel like a lot of the arguments have been "Desktop vs Workstation", and I agree that the core subset of Workstation (ie essentially minus all the developers tools and libraries/devel stacks) should also be good too for general non-developer users.
There is a lot of text about making Fedora Workstation an enticing platform for developers which I am all for but I do feel that the PRD should also cover some basic criteria for a successful core desktop to support that: things like being lightweight and generally getting out of the users way, and supporting an informative configurable panel out of the box, etc. It doesn't have to be a detailed explicit feature list but some kind of vision on the type/flavor of core desktop we are aspiring to for Workstations would be appealing to include IMHO.
Since time is running out, should we have a WG meeting this week to seek agreement and flesh out any final changes? I don't feel we are so far from an acceptable final document.
Jens
On Thu, Jan 09, 2014 at 11:51:25AM -0500, Josh Boyer wrote:
On Tue, Jan 7, 2014 at 11:14 AM, Matthew Garrett mjg59@srcf.ucam.org wrote:
On Tue, Jan 07, 2014 at 05:34:31AM -0500, Christian Schaller wrote:
On Mon, Jan 06, 2014 at 01:47:48PM +0100, Christian Fredrik Kalager Schaller wrote: So who do we expect to provide those engineering resources? We seem to agree that those general users are, in many cases, the developers and enthusiasts that we expect to support, so we need to ensure that there's development effort put into ensuring that the desktop experience itself is compelling.
I expect the vast majority of our engineering resources to come from Red Hat.
Red Hat will be committing engineering resources to support the general user desktop?
The list of use cases is supposed to define the sets of users that we'll consider during development. We agree that the needs of the general desktop user are important and have to be considered during development, which means that it's a supported use case. Which obviously means it should be enumerated in the set of use cases.
I disagree, it is meant to enumerate the areas we give special focus during development. Adding a 'catch all' usecase like 'general users' doesn't help anyone do anything.
I don't think you understand what "use case" means. It's the set of ways that people can use our system that we wish to support. We wish to support users who aren't actively engaging in development and who aren't CS students, so they should be included in the set of use cases that we support.
We've reached a stalemate on this.
On the one hand we have a case that aims Workstation at becoming a development environment for a broad set of possible software. On the other we have one that places importance on general desktop usage. Neither of them are actually conflicting with each other in any way other than whether the latter is implicit in the former.
It seems we have a trust issue here. There's a lack of trust that a development focused Workstation can possibly be generally usable while also solving problems for the developer set. There's a lack of trust that resources will be put forward where necessary. And there's a complete lack of faith that other contributors and upstreams can fill the role of developing applications and such for the general use case.
I can't solve this, but the (agonizingly delayed) back and forth going on right now is not lending itself to actually accomplishing anything at all. If we don't set a direction soon, and have faith that people won't have their heads up their collective arses and hold myopic views of "targets", then we're going to continue to languish.
We have a deadline for the PRD coming up in about a week. I'd like to actually have something to present to FESCo. Can we please either agree to trust each other or barring that call for a vote on one of the current draft PRDs? Members of the Workstation WG really need to speak up here.
I hope it's not my mail client acting up, but it looks like no replies here from WG members. I'd like to explicitly say I for one trust that those expecting (and expected) to do a majority of the work do care about the general use case. And I'd expect many, and perhaps most, of the things that improve by focusing on a good experience for developers will also benefit general users.
Personally I'm a lot more like the latter than the former, which is why I want to trust the contributors to do the right thing.
We've reached a stalemate on this.
On the one hand we have a case that aims Workstation at becoming a development environment for a broad set of possible software. On the other we have one that places importance on general desktop usage. Neither of them are actually conflicting with each other in any way other than whether the latter is implicit in the former.
It seems we have a trust issue here. There's a lack of trust that a development focused Workstation can possibly be generally usable while also solving problems for the developer set. There's a lack of trust that resources will be put forward where necessary. And there's a complete lack of faith that other contributors and upstreams can fill the role of developing applications and such for the general use case.
I can't solve this, but the (agonizingly delayed) back and forth going on right now is not lending itself to actually accomplishing anything at all. If we don't set a direction soon, and have faith that people won't have their heads up their collective arses and hold myopic views of "targets", then we're going to continue to languish.
We have a deadline for the PRD coming up in about a week. I'd like to actually have something to present to FESCo. Can we please either agree to trust each other or barring that call for a vote on one of the current draft PRDs? Members of the Workstation WG really need to speak up here.
I hope it's not my mail client acting up, but it looks like no replies here from WG members. I'd like to explicitly say I for one trust that those expecting (and expected) to do a majority of the work do care about the general use case. And I'd expect many, and perhaps most, of the things that improve by focusing on a good experience for developers will also benefit general users.
Personally I'm a lot more like the latter than the former, which is why I want to trust the contributors to do the right thing.
While generally I agree with your sentiment about people doing the right thing I would still like to see it documented. It's amazing how often we need to dig back through mailing lists and email archives and other things to work why things are in a particular way so if it's documented in the main location the exact details won't get lost, or at least covered, with the sands of time.
Peter
On 01/07/2014 10:34 AM, Christian Schaller wrote:
I expect the vast majority of our engineering resources to come from Red Hat.
This despite this bold resource devotion on behalf of Red Hat aside, Red Hat will be continuing on it's path stamping on the community will and forcing Fedora to it's image ( since obviously it will only devote it's corporate resources to what benefits the corporate ) ?
JBG
On Mon, Dec 09, 2013 at 07:23:37PM +0100, drago01 wrote:
It seems like you and Matthew don't really disagree much on what we should produce just whether we should add the general user to the PRD. Given that we are going to cover this case anyway (because in the end everyone is a "general user") ... how does adding it hurts us? It just a clear statement that non developers are not excluded.
Right. The inevitable consequence of us publishing a PRD that doesn't explicitly discuss usage by people who aren't highly technical users is that it'll be interpreted as us no longer being interested in any of the other people who currently run Fedora, such as home users who just want an OS that's committed to freedom, content creators who appreciate our open development process or people who don't care about Linux at all but just want a free upgrade for XP that'll let them run Firefox.
Giving the impression that we aren't interested in those people (accurately or otherwise) is inevitably going to impact our contributor pool, both because some people won't start running Fedora in the first place and because some people aren't interested in developing an OS that's not usable by people they know. That impairs our ability to implement the compelling desktop experience that's a vital part of implementing a compelling developer environment.
When I say I want us to support a general desktop user, I don't want to give the impression that I want us to support every single possible user request. Other desktop operating systems have demonstrated that having a well-defined concept of what the desktop is and what features it should offer is compatible with having broad appeal. That's a goal we should strive for, and explicit goals should be explicitly enumerated in the PRD.
Matthew Garrett writes:
Attached.
Some comments on this proposal: From my POV what is missing is the academic/science/engineering workstation use:
* Use of a variety of standard, in-house developed, and/or third party tools to run simulations, analyze data, visualize results, etc. Examples are R, Scipy, Sagemath, gnuplot, ... from standard repository, as well as Matlab, Mathematica, IDL, ... from the proprietary universe
* Complex workflows involving a variety of different tools
* Users depend on window manger for managing windows (it cannot be assumed that applications are nice/self-managing in any way, often no IDE or several IDEs as mixture of tools is too diverse). Typical scenarios are lots of terminal windows displaying text diagnostic output of long-running jobs on local or remote machines, lots of visualization windows created by various tools - often home-brewed, all mixed with editor windows for program or glue code, wordprocessing, LaTeX, web, several open documents in PDF viewer, email, everything is part of the same workflow.
* At least on centrally managed machines software selection is close to install everything as academic users tend to have very different ideas of what software they should use, so system administrators will install a lot. Disk space is cheap, but it's taxing on menus/app selection.
* Use of big/high-res/multiple screens in various geometric configurations; also: projector use for presentations needs to absolutely work in all circumstances (which it mostly does nowadays, from my observations at least on par with Windows/Mac now). Especially in academia on tends to encounter a great variety of different projector generations of varying quality, typically without the chance of much prior testing, so it absolutely needs to work blindly.
* Various roaming scenarios need to work (VPN, eduroam which is PEAP/MSCHAPv2 authentication). This should in principle be a non-issue, but I mention this because of recent problems with both, so I get the impression that QA in this area is not very strong.
Particular challenges for the desktop:
* How to unclutter menus, make entries non-ambiguous?
* How to reliably find a particular window if you have 10 terminal windows each displaying number columns? (This is where Gnome 3 falls flat, for example.)
* How to efficiently navigate to windows on big/multiple screen setups?
* How to efficiently manage windows on big/multiple screens? (maximize, edge snap is usually doing the wrong thing. Vertical maximize works usually better, good tiling strategies???)
* Good workspace switching, keep child windows on their proper workspaces even if they pop up in the background
* Taskbar or taskbar-like behavior for raising single windows without disturbing the visual context by overview mode.
Further comments:
* For big server/large workgroup installations, Fedora is probably too unstable by definition. I have only ever seen either RHEL/CentOS or OpenSuSE used in this context. So going for serious stability is probably out of scope, and conflicts at some level with the need to get timely updates on fast-moving software.
* From the draft: "This would include items like theming and making sure we offer a consistent accessibility story across different development toolkits." From my POV theming plays no role at all so long as the basic workflow requirements are met. Also, "consistent accessibility" I see more on the side of a consumer product. Consistency is nothing that Fedora can achieve at the level where it would really be useful, so what is more important is accessibility and compatibility in the face of real-world inconsistencies.
* From the draft: "a requirement that any software that wants to be part of Fedora Workstation can run against Wayland or directly output sound to Pulse Audio". I am not sure what that buys. Yes, it would be a generally good idea to fix up software that violate these goals. But that's a general (and worthy) Fedora goal. Especially for Fedora _Workstation_ I would see the requirement the other way round: can the base system be compatible enough so that I can get legacy code from back when Wayland was not even dreamed of, strange in-house developments, obscure toolkits etc. run at least in some way without running through impossible hoops.
* For compatibility with third party/commercial software, one should probably narrow down to specific needs. From my perspective, these would include Matlab, Mathematica, Maple, NAG libraries, ifortran, IDL, and similar tools with a long and usually good history of compatibility. But ideally the free software alternatives should be there and integrated well to reduce the need for commercial tools as much as possible while still acknowledging that people might have (legacy) needs which make it inconvenient or impossible to avoid proprietary software. Other users might have completely different needs, so it would be good to compile a collection of wider importance.
Regards, Marcel
On Mon, Dec 09, 2013 at 12:52:56PM +0100, Marcel Oliver wrote:
Matthew Garrett writes:
Attached.
Some comments on this proposal: From my POV what is missing is the academic/science/engineering workstation use:
The intent was to describe situations where a user class might have requirements that bear no relation to the general desktop case. For the most part the features you've described are things that are relevant to everybody, not just people in a research-oriented environment. The discussion of window management is an exception, but that's something that's likely to overlap significantly with the requirements of developers or admins.
However, when considering the needs of third-party vendors, it obviously does make sense to examine the existing widely-deployed third-party applications and identify their requirements before setting any kind of baseline for a supported ABI. The scientific community probably has a larger set of deployed third-party UNIX software than any other desktop community, so that has to play a big part here.
desktop@lists.fedoraproject.org
-
Bill Nottingham -
Christian Schaller -
drago01 -
Jens-Ulrik Petersen -
Josh Boyer -
Jóhann B. Guðmundsson -
Marcel Oliver -
Matthew Garrett -
Paul W. Frields -
Peter Robinson