On 20 January 2018 at 06:27, Igor Gnatenko <ignatenkobrain@xxxxxxxxxxxxxxxxx> wrote: > > Even if people hope next version of EL will be better in this, it doesn't mean > that el6/el7 can be fixed easily. > > > Why I'm writing this? I want to hear from you if you think it would be good to > prohibit (or advise, or whatever mechanism would work) usage if conditionals in > (at least) master branch to allow us to develop features faster. Thoughts? > Suggestions? As EPEL is the only reason I stay in Fedora.. I would like to make sure it doesn't cause developers that much problems. As such I would be interested in seeing if the macros that Neal said could be better implemented throughout the releases. You are still going to have to deal with conditionals because of flag days between releases and the only way to not have that is to move Fedora to a rolling release. But that isn't going to fix anything even then. Maintainers don't drop things from spec files until they know that they have something better to replace code with. That means that those new tools need to be taught to them and that takes a lot of work dealing with what seems like stupid questions and obvious problems. However these people have to unlearn what they have been doing for N years and that takes time and effort on the people wanting to make a change. It is the part which the past rollouts of GNOME, KDE, systemd and others have shown is always much more than developers seem to think. [Instead there is this opposite idea that people will turn on a dime because it is so obvious what I wrote is superior to that old cruft. The reality is that IT NEVER IS THAT OBVIOUS.] If this change is needed to make the OS better in the long run, I am not against it. I however want to see more work done on getting people to know why and how they should write their new spec files.. and how they are to keep up to date with those methods in the years to come. Without that, you are going through a lot of effort for no gain. -- Stephen J Smoogen. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
