On 23 January 2018 at 09:25, Vít Ondruch <vondruch@xxxxxxxxxx> wrote:
[..]
> Well I think maintainers should chose the ideal solution for their case. If use of macros just complicates things too much, maybe use of branches might make more sense. On the other hand does it really make sense to enforce maintaining different branches for a few conditionals?
Oh it definitely does.
I am handling mass rebuilds of Ruby packages or updates of Ruby on
Rails. This is complex task requiring touching plenty of packages. Due
to update of Rails in master, I simply cannot contact maintainers of all
packages and assuring their branches still works. I cannot test the
.spec files on Rawhide and EPEL just because there is chance somebody is
going to build the packages on EPEL. At the and, you cannot even trust
the EPEL macros in Fedora.
And of course every branch specific branches makes this mass changes
more complicated, because you simply cannot script it.
If there were no branch macros and we could consider just Rawhide doing
such changes, the .spec files in Fedora would be generally i better shape.
Just FTR: above we have "I think" vs "in practice, it looks not like you may think".
Real engineering is about 1) testing, 2) testing, 3) testing.
"Assumption" like, "I think" is/should be the real enemy of each engineer.
Stricter use of branching will have yet another effects that for example older Fedoras will have less updates.
IMO those updates should be only about security and critical updates.
On first look, it may look as the negative side effect because some end users/consumers may expect some number of "refreshes" for every Fedora release which is still not EOSed like it is now.
However, as Fedora has short development cycle not releasing those "refreshes" for older Fedoras have IMO much greater positive effects:
1) easier to test upgrades between Fedora versions
As each Fedora major release may have in updates only security and critical fixes and ABI (libraries SONAME changes) will be completely locked down it will be easier work on a set of test units testing upgrades on top of different sets of installed packages.
2) more people (packagers and regular end users) will be focused on testing of latest Fedora version
Simple more eyeballs using exact latest Fedora than more likely that after hitting sometimes small issue it will be reported to BTS.
As consequence RH people making own snapshot to start working next major EL version may expect that they will have fewer issues to resolve after making such snapshot.
3) fewer packagers will be spending time on backporting some changes
This is as well important because as result those people will have MORE time to work on changes on master. In other words, it will allow better concentration of limited man/hours resources to make each major Fedora release better/more tested.
There is always cost some changes. There is no "something for nothing".
IMO in altering general policy about release updates of older Fedora version will have the weight of those "good consequences" greater than the weight of those "bad effects" which in some people opinion such change may introduce.
Simple it is not possible to make happy everyone and the decisive point should be not close to single end-user needs but in point where it is possible to have broader/whole view of distribution issues.
At the moment as master branch is used to make every not EOSed Fedora, it forces to use much more complicated by %ifings form of most of the Fedora spec files,
This as consequences make many large-scale distribution changes *much more complicated*.
kloczek
--
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
