From Fedora Project Wiki
Line 41: Line 41:
** IRC Nick: sicampbell
** IRC Nick: sicampbell
** FAS: [[User:Sic|sic]]
** FAS: [[User:Sic|sic]]
* Václav Pavlín
** IRC Nick: vpavlin
** FAS: [[User:Vpavlin|vpavlin]]


== [[User:ncoghlan|Nick Coghlan]] (ncoghlan) ==
== [[User:ncoghlan|Nick Coghlan]] (ncoghlan) ==

Revision as of 12:50, 11 June 2015

Important.png
The nomination period is OPEN
The nomination period ends at 23:59:59 UTC on June 14, 2015.

The following elections will take place in June 2015:

All dates and times noted are UTC time.

Env and Stacks Elections June 2015

The following group Members finish their terms, and the seats are up for re-election:

More information at the Env and Stacks Env and Stacks wiki page and Governance Charter.

Note.png
Eligible Voters
Voting eligibility is determined by a community member's Fedora Account System (FAS) memberships.

To vote for Environment and Stacks Working Group you must have cla_done + one other "non-cla" group in FAS.

Candidate Nominations

Please nominate just by Name, IRC nick and FAS account ID. The introduction will be published in Fedora Magazine, at the end of the "Campaign" period.

  • NAME (IRC nick/FAS account ID)
  • Honza Horak
  • Jens Petersen
  • Stuart Campbell
    • IRC Nick: sicampbell
    • FAS: sic
  • Václav Pavlín

Nick Coghlan (ncoghlan)

  • Mission Statement:
    • Use increased automation to create toolchains that meet the disparate needs of development and operations teams
  • Background:
    • Upstream CPython core developer
    • BDFL-Delegate (i.e. design authority) for Python packaging interoperability PEPs
    • Red Hat internal toolsmith
    • Previously development lead for beaker-project.org (which is when I got frustrated with the annoyingly manual process of repackaging Python projects as policy compliant RPMs)
  • Future plans:
    • Work on evolving the Aleph proposal for user level package management into a system-wide Fedora change proposal
    • Explore the use of Nix as a developer focused dependency management tool
    • Evolve the upstream Python packaging formats to allow automatic generation of policy compliant RPMs from upstream Python packages

Env and Stacks Elections January 2015

As per the responses to the mailing list request, the following finish their terms, and the seats are up for re-election:

More information at the Env and Stacks Env and Stacks wiki page and Governance Charter.


Note.png
Eligible Voters
Voting eligibility is determined by a community member's Fedora Account System (FAS) memberships.

To vote for Environment and Stacks Working Group you must have cla_done + one other "non-cla" group in FAS.

Candidates (January 2015)

Slavek Kabrda (bkabrda)

Introduction

  • Mission Statement:
    • Ensure that Fedora is a developer friendly distribution well integrated with upstream tooling.
  • Past work summary:
    • I've been member of Env & Stacks WG since its inception.
    • I was Ruby and JRuby maintainer for more than a year.
    • I've been primary maintainer of Python 2 and 3 interpreter packages for more than year and a half. I also maintain a decent number of Python extension packages in Fedora.
    • I'm author of DevAssistant, a tool which is supposed to help developers with their everyday tasks. DevAssistant has been part of Fedora Workstation since Fedora 21.
  • Future plans:
    • Ensure that Fedora's developer tooling integrates well with upstream tools, instead of fighting them.
      • Continue driving the DevPI pilot, which is supposed to create a downstream Fedora mirror of Python Package Index. Try to apply the experience from this pilot to other languages.
      • Review the "rings" proposal for Fedora.next with other members of Env & Stacks WG and put it to work. Most importantly, we should promote Copr/Playground and define how non-RPM content of the outer rings (as mentioned in the DevPI plans) fits into Fedora future.
    • Make sure that DevAssistant continuously improves, making it an ultimate developer tool - and Fedora along with it.
    • Continue driving the migration of Fedora to Python 3 as a default - for benefit of Fedora and wider Python community.
    • Evolve Python packaging in Fedora to be more automated and thus simpler. The concepts and thoughts from the improvements should be appliable to packaging of other (dynamic) languages as well.


ColinWalters (walters)

Introduction

  • Mission Statement:
    • Drive continuous delivery, containerization, atomic upgrades, and high quality FOSS in Fedora
  • Future plans:
    • Improve Docker and other container systems in Fedora - e.g. better tools to generate and maintain images
    • Improve rpm-ostree with package layering and other features
    • Try to migrate some of the GnomeContinuous technologies into Fedora, such as:


Tomas Tomecek (ttomecek)

Introduction

  • Mission Statement:
    • Make Fedora user friendly GNU/Linux distribution
  • Past work summary:
    • python, django, web developer
    • Fedora packager
    • currently working on tooling around docker
    • was working on tooling around static analysis
  • Future plans:
    • Make Fedora #1 GNU/Linux distro for developers
      • provide Fedora with docker ecosystem (build system, docs, image store, workflows) and integrate it with existing Fedora infrastructure
      • development stacks should be easily available to developers
      • it should be easy to set up a development environment and start coding right away

Petr Hracek (phracek)

Introduction

  • Mission Statement:
    • Make Fedora first Linux desktop environment
    • Help users and developers with developping and package maintaining
  • Past work summary:
    • python
    • my past work was on DevAssistantGUI which is going to be redesigned now.
    • Fedora packager
    • currently working on preupgrade-assistant (tool for assessment before an upgrade)
    • currently working on rebase-helper (tool for rebasing packages)
  • Future plans:
    • Make Fedora first Linux distro for developers and maintainers
    • Help advanced users with package maintainance
    • Help users with upgrading issues