On 16 February 2018 at 15:50, Stephen John Smoogen <smooge@xxxxxxxxx> wrote:
Than you very much because you succeeded on what I've been failing so far here!!! :D
I can only repeat yet another time that only way solving whole class of issues like those with EL*/EPEL is NOT keeping EL{6,7} relevant changes on rawhide master branch!
At the moment each package has per Fedora version branches and some of the packages el{6,7} branches.
It is hard to understand why it is in this case such duality that on master are integrated changes relevant to el{6,7} or older Fedora on master.
What looks like handy from point of view single package maintainer creates whole chaos on master branch and moving forward all changes in this point with descent speed is only by this harder and harder from point of view of Fedora as distribution
In other words .. what looks like useful feature on single package scale is really UNACCEPTABLE on whole distro level.
If someone still has some doubts about necessary changes just ask yourselves what would happen if Linus would be accepting in his kernel git repo #ifdefed parts which will be used on older kernels? such #ifdefed parts does not make any sense as whole tree is in EXACT kernel version!!! -> such parts never would be tested!!!
Isn't it?
Because kernel has similar number of objects (text files) as Fedora, and needs to be maintained *as consistent set*, it delivers working example where some future Fedora changes should go.
Some package maintainers must as well step down on Earth to spot that what they are doing *has bigger context*.
Why? Because it is only LOGICAL way of keeping everything as *working and consistent set*.
[..]
Even before EPEL-5 was EOL, very little of Fedora would compile out of
the box and required massive amounts of %if and other hacks to even
try to compile from a rawhide spec file.
If someone wanted to keep compiling for EL-5 they should branch the
code themselves and maintain it as such versus trying to keep the
cruft in the main tree. I believe that is what arbitrary branching is
for.
I think that you are not fully aware what you've just done.
You just delivered *golden argument* on why EL{6,7} changes/tweaks should be not be kept as %ifed part of the spec on master branch.
You just delivered *golden argument* on why EL{6,7} changes/tweaks should be not be kept as %ifed part of the spec on master branch.
Than you very much because you succeeded on what I've been failing so far here!!! :D
I can only repeat yet another time that only way solving whole class of issues like those with EL*/EPEL is NOT keeping EL{6,7} relevant changes on rawhide master branch!
If at least one person will checkout exact older Fedora branch, do necessary updates, test it (somehow) and will be using such updated package it is absolute minimum guarantee that such updates may be working correct.
At the moment each package has per Fedora version branches and some of the packages el{6,7} branches.
It is hard to understand why it is in this case such duality that on master are integrated changes relevant to el{6,7} or older Fedora on master.
What looks like handy from point of view single package maintainer creates whole chaos on master branch and moving forward all changes in this point with descent speed is only by this harder and harder from point of view of Fedora as distribution
In other words .. what looks like useful feature on single package scale is really UNACCEPTABLE on whole distro level.
If someone still has some doubts about necessary changes just ask yourselves what would happen if Linus would be accepting in his kernel git repo #ifdefed parts which will be used on older kernels? such #ifdefed parts does not make any sense as whole tree is in EXACT kernel version!!! -> such parts never would be tested!!!
Isn't it?
Because kernel has similar number of objects (text files) as Fedora, and needs to be maintained *as consistent set*, it delivers working example where some future Fedora changes should go.
Some package maintainers must as well step down on Earth to spot that what they are doing *has bigger context*.
Why? Because it is only LOGICAL way of keeping everything as *working and consistent set*.
Q: What generally happens with Linux kernel tree when Linus releases new non-rc main kernel version?
A: Whole tree is cloned and maintained separately by people who at least are using exact kernel version.
EXACTLY the same methodology should be applied in case of the Fedora.
In both cases (kernel and fedora) general methodology is determined quite frankly by VCS tooling which in both cases is git.
EXACTLY the same methodology should be applied in case of the Fedora.
In both cases (kernel and fedora) general methodology is determined quite frankly by VCS tooling which in both cases is git.
With proper separations will be possible to remove INSTANTLY tons of %ifings from rawhide specs which will make all specs *way more readable* and NOT affected by any changes in older Fedoras or EL*.
Simpler form/shorter specs -> lower possibility of mistakes and lower effort on understand what is done in exact spec.
Simpler form/shorter specs -> lower possibility of mistakes and lower effort on understand what is done in exact spec.
It lowers energy barrier on introduce large scale changes (if they will be needed) as well on any branches.
Q.E.D.
kloczek
kloczek
--
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
--
Tomasz Kłoczko | Tel: 0774 1209067 | LinkedIn: http://lnkd.in/FXPWxH
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
