#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:46 toshio]:
Replying to [comment:44 bkabrda]:
> What is unsuitable about the nightly branches? The only thing that I
see
might be problematic for someone are the SCL macros. It's true that
guidelines say that there should be a comment on top of the specfile about
this [1], but the SCL macros can actually be present in the specfile, if
they're turned of in official builds. If you want us to add the comment,
just say so - otherwise I don't see anything unsuitable in the nightly
branches.
>
> [1]
https://fedoraproject.org/wiki/Packaging:Guidelines#Software_Collection_M...
As part of the FPC discussion of making SCLs official and this ticket,
the
decision has been made that SCL macros are not allowed in the
mainstream spec files.
When has this decision been made and where is it in guidelines? AFAIK it
is customary to write specfiles according to *current* guidelines and when
new guidelines come in effect, old-style specfiles are "grandfathered" (I
believe that is the term for "they don't need to be touched assuming they
still work"). At the time the python-nightly branches were created I
didn't see (and I still don't see) any part of guidelines that they'd
break. Therefore I don't see why I should remove them.
Also, as a reply to comment 45:
- "Here we're looking at doing builds in coprs of unapproved packages" -
unapproved in what sense?
- "storing the sources for those in the Fedora package git repo" - no, we
don't store sources anywhere, just downstream patches and specfiles
- "That's not a clean way of doing things." - that's your opinion, not
a
fact. In my opinion, it *is* a clear way, since it allows us to keep
variants of specfile of a single package in one git repo, therefore
centralizing it's development and getting benefits from it (e.g. merging
branches etc).
- "Might as well give orion comaintainership of the python3 package so
that he can work on the python3.4 package for EPEL in the existing git
tree." - I don't see why I wouldn't. I explicitly announced that I myself
won't build and maintain python3 for EPEL, but I also announced that I'll
gladly leave this burden to anyone who will want it.
--
Ticket URL: <
https://fedorahosted.org/rel-eng/ticket/5894#comment:48>
Fedora Release Engineering <
http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project