On 22 January 2018 at 20:58, Matthew Miller <mat...@fedoraproject.org>
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
--
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
