On 22 January 2018 at 20:58, Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> wrote:
On Mon, Jan 22, 2018 at 08:21:19PM +0000, Tomasz Kłoczko wrote:
> Yet anther thought ..
> As long as between major EL releases is huge "distance" in differences
> using %{rhel} within %ifings operators like <, <=, >, >= does not make to
> much sense.
That's likely true. But I think it'd be even better to avoid
base-os-name conditionals and use something like %{have_soft_deps} or
something like that.
So looks you understand at least this part.
OK .. good .. very good ... PERFECT! 🙃
== assumption ==
So now try to assume (temporary only) that it has been already proven that at least new branches based approach will be not more complicated to maintain EPEL corrections/adjustments as it is now with %ifings.
==============
Got it? ... next ..
So I think that we can expect some god/funny/interesting consequences:
- master and EPEL branches will have ONLY local package %bconds.
- Fedora and EPEL packagers will have 100% freedom of making any necessary changes without asking themselves "does my Fedora change will affect EPEL or not?" or "does my EPEL change will affect Fedora or not?" Only this will/can make whole ecosystem IMO muuuch more robust.
- EPEL maintainers can form separated task-force inside Fedora and even if they will vote on turn EPEL specs up side down it will not have any Fedora consequences and vice versa
- EPEL packagers will be making CONCISELY decisions about backporting some master branch changes and someone will really spend some time with own computer to test changes
- and last: .. funny but looks like probably we don't need ANY new macros. Eureka!! 😎
It is yet another interesting consequence which may attract RH developers.
As long as they will be snapshoting Fedora to create new major EL release thy can use straight Fedora git repo. If they will choose this way it may be potentially costs savings argument on maintaining necessary infrastructure.
If they will decide do this Fedora packagers will have straight access to all RH made changes. All without any kind of formalized communication!!!
I'm not sure is it possible to add git watch alarm on the branch.
If yes it will be devel platform with best possible cohabitation.
IMO whole concept stands firmly on KISS principle or IS with this principle compliant.
Every above point may have non-zero or at least positive impact .. but again: ONLY if top assumption is TRUE.
I'm only asking for help to prove or disprove this top assumption.
How to do this? I have no clear idea so far ..
Nevertheless I think that above is/must be truth (basing on my quite long exp) and I'm fully aware that cannot use this as curricula argument.
Maybe we need a bit more time to have whole subject "hanging on back of our heads". Maybe it will require few experiments as well.
There are few "maybe" here ..
However what I'm sure is that no one of us should be rushing 😀 "Rush" usually is very bad advisor.
There are sill many potential mass changes which can make general Fedora specs condition better.
From general strategy point of view we (definitely I) can deal with this by focus on very simple short term targets/mass changes.
Try to think about what I've already told about "undo thousands cuts" .. all those mass changes should be done with such goal.😋
kloczek
--
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
