This is a part of FESCo Elections interviews series.

Voting is open to all Fedora contributors. The elections started on January 26th and closes promptly at 23:59 UTC on February 3rd.

Please read the responses from candidates and make your choices carefully.

Feel free to ask questions of the candidates here or elsewhere!

Interview with Debarshi Ray (rishi)


What is your background in Fedora? What have you worked on and what are you doing now?

You can find a summary at

If you want details about my GNOME activity, then I work on our online accounts stack – its various underpinnings and the applications involved (includes nautilus, gvfs, gnome-documents, gnome-control-center, etc.). I also work on gnome-terminal and tracker.

Do you think Fedora should be time based or more feature driven distribution? Or compromise?

Time-based. Having a predictable release schedule is very important in
my opinion.

What are the most pressing issues facing Fedora today (from engineering POV)? What should we do about them?

I think that the way we push updates to our users needs to be improved, and there are a few relatively simple things that we can do in this area. We spend a lot of effort making sure that our releases are of the highest quality, but then we barely do anything to ensure the quality of the updates being pushed out to a stable releases. This often leads to surprises (or regressions) and annoyances (too many updates).

We should stop the practice of pushing out updates asynchronously, unless they have security implications. We should push them out monthly or fortnightly to updates-testing so that testers get a chance to QA a well defined combination of packages, instead of a constantly moving set, which is the case now. This is not different from the system of

freezes that are used to QA our releases.

We should have a few people auditing updates, and a strict set of guidelines on what is allowed in a stable release. I believe this is the case in Debian and Ubuntu. Fedora releases are already short-lived (as compared to RHEL or CentOS) to begin with so there is no need to introduce significant UI or code changes and lead to the problems mentioned in the previous paragraph.

A more intrusive improvement would be the ability to roll back updates.

Finally, we should start looking at sandboxing and application bundles that GNOME has been working on. A well-packaged distribution will always have its strengths, but sandboxing and bundles solve an important problem. We should explore how we can leverage them to our advantage.

Care to share a screenshot of your Fedora desktop?


What are your interests and experience outside of Fedora? What of those things will help you in this role?

Outside Fedora I am a GNOME developer working on our online accounts story. Recently GNOME has been playing a pioneering role in the way we look at GNU/Linux desktop applications

I believe this gives me a good background to improve Fedora Workstation as an end-user facing (or client-side) operating system.

How can FESCo do a better job communicating with the rest of the Fedora community, or do you feel that FESCo is already doing well here?

Historically, the people behind Fedora’s desktop spin had felt a certain amount of disconnect with FESCo. This was fueled by lack of communication between people on both sides of the divide, and something that we should avoid.

I would expect FESCo members to reach out to the various technical stakeholders in the project (eg., WGs, spins, feature owners) to better understand what they are trying to achieve. This can happen on public mailing lists and IRC, or via private conversations over email and hallway tracks at conferences.

Committee members can shape the overall direction of the project by blogging and presenting at conferences on matters that they think are of strategic importance to Fedora.

What can you accomplish as part of FESCo that you couldn’t accomplish as a contributor to Fedora without sitting on FESCo?

Sitting on FESCo would help me guide Fedora, and particularly Workstation, towards a better application and updates story. While I can contribute towards the same objectives as an individual, some aspects require broad project wide changes and being a FESCo member would help in realizing them.

What degree of leeway do you feel that the Working Groups should have to diverge from one another in establishing their own identity?

The Working Groups are the ones who should be in charge of defining their product and be allowed to diverge from one another as long as it is not to the disadvantage of another product or WG.

How would you define the set of criteria for promoting a spin to a product? What about the reverse?

Products define the project. Each of them should be focused on a broad area that is strategic to the project. Currently our products are Workstation, Server and Cloud, which means that Fedora is focused on building operating systems for laptops / desktops, servers and cloud deployments.
For a spin to be promoted:

  1.  It should be sufficiently different from an existing product. Different enough that its objectives and needs are not and can not be addressed by one of the existing products. eg., entirely different target audience, different release schedules, different installation or release medium, , etc..
  2. Should be able to have a strong identity of its own, without hampering any of the existing products. Also see (1).
  3. A group behind it with a proven track record.

Similarly, I would demote a product if it no longer makes sense to have it as one of the flagships of the project:

  1. Fall in quality of what is being delivered.
  2. Target area is no longer strategic for the project. eg., if people stop using client-side operating systems, it will not make sense to have Workstation as a product.

With the advent of Fedora Council now, what do you see as the significance of FESCO in Fedora project?

FESCo is about overseeing the technical issues faced by the project, while the Council is more strategic. It is responsible for Fedora’s governance, budget and outreach. This is quite obvious from looking at the current composition of the Council. It has people with background in outreach, engineering, program management, and our fearless leader.

Therefore I don’t see any conflict of interest here.

How “closely” do you, as a member of FESCO, follow the devel mailing list before voting on FESCO meetings? In other words, apart from your own technical qualifications, what is your typical process in arriving at decisions?

I have never been on FESCo before, so I can not say how I voted in previous FESCo meetings. If I am elected, I would try to inform myself by not only following devel@lists.fp.o, but more importantly, talking to the individual stake holders and understanding the technical issues being voted upon. Attending conferences and making myself accessible to people would help in this area.