Hi,
the Voting period of the currently running Fedora Elections [0] has just started. Please vote for your candidates to FESCo [1]. You can vote till June 13th, 2018 when the voting ends at 23:59:59 UTC.
On Community blog [2] you can also find interviews with all the candidates. Please have a look at it.
[0] https://fedoraproject.org/wiki/Elections [1] https://admin.fedoraproject.org/voting/vote/fesco-may-2018 [2] https://communityblog.fedoraproject.org/tag/may-2018-elections-fesco/ [2.1] Justin Forbes: https://communityblog.fedoraproject.org/fesco-election-interview-justin-forb... [2.2] Stephen Gallagher: https://communityblog.fedoraproject.org/fesco-election-interview-stephen-gal... [2.3] Till Maas: https://communityblog.fedoraproject.org/fesco-election-interview-till-maas-t... [2.4] Randy Barlow: https://communityblog.fedoraproject.org/fesco-election-interview-randy-barlo... [2.5] Petr Šabata: https://communityblog.fedoraproject.org/fesco-election-interview-petr-sabata...
Thanks for your support. Regards, Jan
On 7 June 2018 at 03:17, Jan Kurik jkurik@redhat.com wrote: [..]
[2.1] Justin Forbes: https://communityblog.fedoraproject.org/fesco-election-interview-justin- forbes-jforbes/ [2.2] Stephen Gallagher: https://communityblog.fedoraproject.org/fesco-election-interview-stephen- gallagher-sgallagh/ [2.3] Till Maas: https://communityblog.fedoraproject.org/fesco- election-interview-till-maas-till/ [2.4] Randy Barlow: https://communityblog.fedoraproject.org/fesco-election-interview-randy- barlow-bowlofeggs/ [2.5] Petr Šabata: https://communityblog.fedoraproject.org/fesco-election-interview-petr- sabata-psabata-contyk/
3 out of 5 candidates as most important feature which seems they want to push forward encircles Modularity. Doesn't matter that rpm never been designed in mind to handle cohabitation packages in different variants. What now Modularity offers is +1.5y behind original schedule and still in most of the cases it does not work. No one points on things like discussion on: - common specs coding style - cutting number of %iffings (and use instead SCM branches which git offers) - cutting legacy tails like still using tons of scriptlets which can be easily cleaned of remove dependencies on initscripts and maaany more like this which could make at least @core solid fundamentals other features - cutting number of dependencies (how many years ago was first discussion about use --as-needed in linker options?) - caring about quite basic security (look decision about add ~/.local/bin to the $PATH and complete kind of "desinteressement" about remove /usr/local/{bin,sbin} from already used $PATH which widely opens hell gates for malwares).
Second most important goal on which candidates are focused is how internal Fedora infrastructure works.
No one of the candidates seems is aware that people are leaving Fedora boat (look on distrowatch.com or https://w3techs.com/technologies/details/os-linux/all/all and few other similars stats) not because Modularity still doesn't work (and will never work as no one will not change some fundamental bits in rpm). Most of the candidates seems are completely unaware that end users of they work (binary packages) simple don't care about how all Fedora stuff is build but HOW IT WORKS.
On top of this more and more decisions in Fedora seems are made in less and less transparent and well technically justified way.
Personally I don't see any GoodEnough(tm) candidate on which I can vote .. candidate with descent own expertise of what is now Fedora Achilles heel .. sad :(
kloczek
On Thu, Jun 7, 2018 at 12:15 PM Tomasz Kłoczko kloczko.tomasz@gmail.com wrote:
On 7 June 2018 at 03:17, Jan Kurik jkurik@redhat.com wrote: [..]
[2.1] Justin Forbes: https://communityblog.fedoraproject.org/fesco-election-interview-justin-forb... [2.2] Stephen Gallagher: https://communityblog.fedoraproject.org/fesco-election-interview-stephen-gal... [2.3] Till Maas: https://communityblog.fedoraproject.org/fesco-election-interview-till-maas-t... [2.4] Randy Barlow: https://communityblog.fedoraproject.org/fesco-election-interview-randy-barlo... [2.5] Petr Šabata: https://communityblog.fedoraproject.org/fesco-election-interview-petr-sabata...
3 out of 5 candidates as most important feature which seems they want to push forward encircles Modularity. Doesn't matter that rpm never been designed in mind to handle cohabitation packages in different variants. What now Modularity offers is +1.5y behind original schedule and still in most of the cases it does not work. No one points on things like discussion on:
- common specs coding style
- cutting number of %iffings (and use instead SCM branches which git offers)
- cutting legacy tails like still using tons of scriptlets which can be easily cleaned of remove dependencies on initscripts and maaany more like this which could make at least @core solid fundamentals other features
- cutting number of dependencies (how many years ago was first discussion about use --as-needed in linker options?)
- caring about quite basic security (look decision about add ~/.local/bin to the $PATH and complete kind of "desinteressement" about remove /usr/local/{bin,sbin} from already used $PATH which widely opens hell gates for malwares).
Second most important goal on which candidates are focused is how internal Fedora infrastructure works.
No one of the candidates seems is aware that people are leaving Fedora boat (look on distrowatch.com or https://w3techs.com/technologies/details/os-linux/all/all and few other similars stats) not because Modularity still doesn't work (and will never work as no one will not change some fundamental bits in rpm). Most of the candidates seems are completely unaware that end users of they work (binary packages) simple don't care about how all Fedora stuff is build but HOW IT WORKS.
On top of this more and more decisions in Fedora seems are made in less and less transparent and well technically justified way.
Personally I don't see any GoodEnough(tm) candidate on which I can vote .. candidate with descent own expertise of what is now Fedora Achilles heel .. sad :(
Run for FESCo yourself or otherwise work to fix what you think are the problem areas.
josh
On Thu, Jun 7, 2018 at 11:15 AM, Tomasz Kłoczko kloczko.tomasz@gmail.com wrote:
On 7 June 2018 at 03:17, Jan Kurik jkurik@redhat.com wrote: [..]
[2.1] Justin Forbes:
https://communityblog.fedoraproject.org/fesco-election-interview-justin-forb... [2.2] Stephen Gallagher:
https://communityblog.fedoraproject.org/fesco-election-interview-stephen-gal... [2.3] Till Maas:
https://communityblog.fedoraproject.org/fesco-election-interview-till-maas-t... [2.4] Randy Barlow:
https://communityblog.fedoraproject.org/fesco-election-interview-randy-barlo... [2.5] Petr Šabata:
https://communityblog.fedoraproject.org/fesco-election-interview-petr-sabata...
3 out of 5 candidates as most important feature which seems they want to push forward encircles Modularity. Doesn't matter that rpm never been designed in mind to handle cohabitation packages in different variants. What now Modularity offers is +1.5y behind original schedule and still in most of the cases it does not work. No one points on things like discussion on:
- common specs coding style
- cutting number of %iffings (and use instead SCM branches which git offers)
- cutting legacy tails like still using tons of scriptlets which can be
easily cleaned of remove dependencies on initscripts and maaany more like this which could make at least @core solid fundamentals other features
- cutting number of dependencies (how many years ago was first discussion
about use --as-needed in linker options?)
- caring about quite basic security (look decision about add ~/.local/bin to
the $PATH and complete kind of "desinteressement" about remove /usr/local/{bin,sbin} from already used $PATH which widely opens hell gates for malwares).
No one has said modularity is the *only* issue, but it is a big change that Fedora is embracing. It is important that such a large scale change is handled in such a manner that existing users aren't left on the sidelines. Candidates were given only 3 questions, and 10 page answers are pointless, people don't read them. Security has always been a concern for Fedora, and that is not changing. There are several of us who start and end our day looking at CVE lists making sure Fedora is as protected as possible. We have implemented and continued to champion things like SE Linux and secure boot upstream. Sure, they might not start out as elegant as we would like, but they are constantly improved. Compiler flags are changed to support more secure features as they are introduced, and I expect to see work around IMA and other security initiatives going forward. Security is not a big new initiative for Fedora, it has been an important cornerstone for years. FESCo doesn't exist for members to do what they want, it is a service position, FESCo exists to serve the community. If you think FESCo should be addressing some issues differently, file a ticket, file a change request. A lot of the things mentioned here don't fall into the FESCo realm though, and would be best handled by the packaging committee.
Second most important goal on which candidates are focused is how internal Fedora infrastructure works.
No one of the candidates seems is aware that people are leaving Fedora boat (look on distrowatch.com or https://w3techs.com/technologies/details/os-linux/all/all and few other similars stats) not because Modularity still doesn't work (and will never work as no one will not change some fundamental bits in rpm). Most of the candidates seems are completely unaware that end users of they work (binary packages) simple don't care about how all Fedora stuff is build but HOW IT WORKS.
There is less attrition than these sites mentioned show. There was a large decline in users after the Gnome 3 switch, and things have been getting better since. It would be nice of those metrics were more readily available and not just occasionally pulled out when an issue arises and someone thinks to ask. There used to be a page. And the Fedora model is less suited to the web server space than some others because of how quickly we move. I would expect there are several Fedora users who are hosting sites on centos just because they don't have to upgrade it yearly. And yes, there is a lot of concern with how it works. things like CI and some of the infrastructure improvements have a lot more impact on insuring that better quality packages land in the hands of users. That is their entire purpose. It takes time and infrastructure to get those initiatives up and running, but the only reason those initiatives exist is to get better quality, functional packages into the hands of users.
On top of this more and more decisions in Fedora seems are made in less and less transparent and well technically justified way.
Personally I don't see any GoodEnough(tm) candidate on which I can vote .. candidate with descent own expertise of what is now Fedora Achilles heel .. sad :(
kloczek
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
Hi,
On Thu, Jun 07, 2018 at 05:15:04PM +0100, Tomasz Kłoczko wrote:
No one points on things like discussion on:
- common specs coding style
- cutting number of %iffings (and use instead SCM branches which git offers)
- cutting legacy tails like still using tons of scriptlets which can be
easily cleaned of remove dependencies on initscripts and maaany more like this which could make at least @core solid fundamentals other features
- cutting number of dependencies (how many years ago was first discussion
about use --as-needed in linker options?)
for this we need people to actually to the work. As a FESCo member it is possible to support initiatives for this and I support a more collaborative package maintainership that enables contributors to easier to mass changes to improve packages. Nevertheless without someone interested to do the ground work we will not get there.
- caring about quite basic security (look decision about add ~/.local/bin
to the $PATH and complete kind of "desinteressement" about remove /usr/local/{bin,sbin} from already used $PATH which widely opens hell gates for malwares).
You should not confuse disagreeing on the security implications of a setting with not caring about security. And it is best practices to provide a proof-of-concept when reporting a security issue. If you show one that allows to to get access to a web server that serves this CGI script:
--- #! /usr/bin/bash
PATH=${HOME}/bin:${HOME}/.local/bin:/usr/local/bin:/usr/local/sbin:${PATH} id ---
This was vulnerable to Shellshock, a serious security vulnerability. I am very interested to see how changing the PATH changes makes it significantly easier to exploit this script.
Second most important goal on which candidates are focused is how internal Fedora infrastructure works.
No one of the candidates seems is aware that people are leaving Fedora boat (look on distrowatch.com or https://w3techs.com/technologies/details/os-linux/all/all and few other similars stats) not because Modularity still doesn't work (and will never work as no one will not change some fundamental bits in rpm). Most of the
What is the reason for this in your opinion?
candidates seems are completely unaware that end users of they work (binary packages) simple don't care about how all Fedora stuff is build but HOW IT WORKS.
There was not question like "What do you think end users care about?", therefore I do not see how you came to this conclusion. However, I have the opinion that we need high quality tools to build high quality packages. Otherwise we will make more mistakes or have less time to focus on the tasks that need human intervention.
On top of this more and more decisions in Fedora seems are made in less and less transparent and well technically justified way.
Which decisions are you referring to?
Kind regards Till
On 06/07/2018 12:15 PM, Tomasz Kłoczko wrote:
No one points on things like discussion on:
- common specs coding style
- cutting number of %iffings (and use instead SCM branches which git offers)
- cutting legacy tails like still using tons of scriptlets which can be
easily cleaned of remove dependencies on initscripts and maaany more like this which could make at least @core solid fundamentals other features
- cutting number of dependencies (how many years ago was first
discussion about use --as-needed in linker options?)
These all sound like packaging concerns, and there is a formal Fedora Packaging Committee that oversees the rules around these kinds of things. FESCo usually defers decisions like these to that committee, similar to how we would typically defer server decisions to the Server Working Group.
I will say that I agree that it would be ideal if packagers would use SCM branches instead of if statements in spec files - that's kind of a pet peeve of mine. It makes the specs harder to read/predict, and it also makes the use of branches less meaningful. It's actually kinda strange to me that there seems to be a common pattern of using git merge to bring changes on the master branch back to older branches, especially since you can ask Koji to build off the master branch for non-rawhide releases. IMO, if you are going to have a spec file with if statements, why not just build all builds off master? Anyways, my personal mode of operation is to embrace SCM, and when I want a change on master to be in Fedora 27, I just cherry pick that commit back. This allows me to have nice clean spec files, and it's also pretty easy to apply changes from master to older branches without disturbing their changelogs, and without bringing changes that might be Rawhide specific backwards.
Anyways, after saying all of that, I am not inclined to make that a policy because it is a personal preference in my mind. I would rather try to persuade others to operate this way than force them to. I also try to "play along" when I work with other packagers that have a different workflow than I prefer.
Second most important goal on which candidates are focused is how internal Fedora infrastructure works.
I would advocate that this is important. Fedora's success depends on attracting and retaining contributors. It's important to acknowledge that there are many kinds of contributors other than packagers, and I admit that my focus on packagers is pretty apparent in this point, but I think it's good for FESCo to work towards enabling our contributors so that they can work more efficiently together to achieve their goals. Enabling the contributors to achieve more means that the end user receives a better product.
On top of this more and more decisions in Fedora seems are made in less and less transparent and well technically justified way.
FESCo meeting are held in the public on Freenode, and we post our agendas and minutes on this list every week. What further expectation of transparency do you expect?
On 06/08/2018 11:39 AM, Randy Barlow wrote:
Second most important goal on which candidates are focused is how internal Fedora infrastructure works.
Oh, and I also openly admit that I have a bias here too, since I work on the Fedora Infrastructure Team.
On Fri, Jun 8, 2018 at 11:39 AM, Randy Barlow bowlofeggs@fedoraproject.org wrote:
It's actually kinda strange to me that there seems to be a common pattern of using git merge to bring changes on the master branch back to older branches, especially since you can ask Koji to build off the master branch for non-rawhide releases. IMO, if you are going to have a spec file with if statements, why not just build all builds off master?
I actually didn't know this. Is this a recently added feature? Is there some place I can read about it?
My suspicion is that people are using "git merge" to bring changes to other branches because a) people don't know they can just build from master, and b) because various packaging tutorials [1] tell them to. (I think this is actually a big problem in Fedora right now-- infrastructure changes are happening faster than people are learning to use the new infrastructure, which is making it really hard for packagers to stay up to speed. It doesn't help that this stuff isn't always communicated clearly.)
Ben Rosser
[1] https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Updat...
On 06/08/2018 11:54 AM, Ben Rosser wrote:
you can ask Koji to build off the master branch for non-rawhide releases.
I actually didn't know this. Is this a recently added feature? Is there some place I can read about it?
I don't believe it is recently added, though I don't know Koji's history. I suspect it's been like this a long time though. I don't know it to be documented, I kinda just discovered it on my own. Basically, I noticed that "fedpkg build" really just calls Koji, and asks it to build a particular commit for a particular tag. For example, have a look at the "Source" field at:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1084812
It's git+https://src.fedoraproject.org/rpms/bodhi.git#9db03db15d7c9631887c759cc6bf19e...
That happens to be on Bodhi's master branch right now. So I could ask Koji to build that commit for f27 like this:
$ koji build f27 git+https://src.fedoraproject.org/rpms/bodhi.git#9db03db15d7c9631887c759cc6bf19e...
You can also use branch names after the # in that URL, for example:
$ koji build f27 git+https://src.fedoraproject.org/rpms/bodhi.git#master
My suspicion is that people are using "git merge" to bring changes to other branches because a) people don't know they can just build from master, and b) because various packaging tutorials [1] tell them to.
I agree.
However, I would continue to advocate taking advantage of the branches and using cherry picking to bring back specific changes to older releases. It really does help the spec file to be easier to read.
Putting if statements in your spec file is like putting if statements in your code for what version of the code it is. I could have just a master branch for Bodhi's upstream code, and I could put if statements in it like:
if bodhi_version > (3, 8, 0): # cool feature introduced in 3.8.0 here
But I don't do that because I have and use git branches. When I fix a bug in master that I want to backport to an older release, I just git cherry pick. In my opinion, spec files are also just code and it makes sense to treat them the same way.
(I think this is actually a big problem in Fedora right now-- infrastructure changes are happening faster than people are learning to use the new infrastructure, which is making it really hard for packagers to stay up to speed. It doesn't help that this stuff isn't always communicated clearly.)
Agreed.
On Fri, Jun 08, 2018 at 12:04:29PM -0400, Randy Barlow wrote:
On 06/08/2018 11:54 AM, Ben Rosser wrote:
you can ask Koji to build off the master branch for non-rawhide releases.
I actually didn't know this. Is this a recently added feature? Is there some place I can read about it?
I don't believe it is recently added, though I don't know Koji's history. I suspect it's been like this a long time though. I don't know it to be documented, I kinda just discovered it on my own. Basically, I noticed that "fedpkg build" really just calls Koji, and asks it to build a particular commit for a particular tag. For example, have a look at the "Source" field at:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1084812
It's git+https://src.fedoraproject.org/rpms/bodhi.git#9db03db15d7c9631887c759cc6bf19e...
That happens to be on Bodhi's master branch right now. So I could ask Koji to build that commit for f27 like this:
$ koji build f27 git+https://src.fedoraproject.org/rpms/bodhi.git#9db03db15d7c9631887c759cc6bf19e...
It is possible, but it will break when someone else will have to rebuild something else than Rawhide and make a change there. Also it will irritate people who are looking for sources for a package.
Kind regards Till
On 06/08/2018 01:59 PM, Till Maas wrote:
It is possible, but it will break when someone else will have to rebuild something else than Rawhide and make a change there. Also it will irritate people who are looking for sources for a package.
I don't disagree with your first point, but it is possible to know the sources. A recent Koji change went in where it records the commit hash that was used, even if you build without a commit hash in the URL[0].
I recently made a staging Koji build like this:
https://koji.stg.fedoraproject.org/koji/buildinfo?buildID=1083861
Note that in the Extra field, you can see that I asked Koji to build the master branch, but the Source field records the commit hash.
-
Ben Rosser -
Jan Kurik -
Josh Boyer -
Justin Forbes -
Randy Barlow -
Till Maas -
Tomasz Kłoczko