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? _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx/message/6QMXAWYANJ4J2F5QX2H55MUQIU2B5H3D/
