#5894: git branches for SCL packages
------------------------------+-----------------------
Reporter: mmaslano | Owner: rel-eng@…
Type: task | Status: new
Milestone: Fedora 21 Alpha | Component: git
Resolution: | Keywords:
Blocked By: | Blocking:
------------------------------+-----------------------
Comment (by bkabrda):
Replying to [comment:61 hhorak]:
Replying to [comment:60 bkabrda]:
> I checked a lot of them (not all, I admit) and I still see no
reasoning
behind the decision to prohibit putting SCL macros to mainline
specfiles (which is different from actually building packages as SCL
packages). Would you care to share the list of reasons here? It doesn't
have to be full, but I'd really like to see why keeping the macros in
mainline specfiles should be prohibited.
On the other hand, there indeed is a reason why SCL macros *should* be
allowed in
the mainline specfiles: code duplication -- having almost the
same spec files on two different places means double effort when fixing
things, resulting in non-consistent or outdated spec files.
Also, in cases where SCL and non-SCL maintainers wouldn't be same
persons, the
communication between them about back-porting fixes will
consume another time, while having only one spec file would allow to work
with much better efficiency.
We must try to make the live of maintainers easier, not the opposite.
I don't believe the reasoning for "not having SCL macros, which do
nothing, in the mainline" may justify so much maintainers work more.
I never implied we should force anyone to put SCL macros in specfiles. I
merely want to have the option, since I personally find it very practical.
It makes marging patches easier, because most of the time, you're going to
merge patches that are not SCL related, so having almost identical
specfiles would help you. This would make maintainers lives easier.
--
Ticket URL: <
https://fedorahosted.org/rel-eng/ticket/5894#comment:62>
Fedora Release Engineering <
http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project