#5894: git branches for SCL packages

[Fedora Release Engineering]

#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:39 mmaslano]:
 > Replying to [comment:38 toshio]:
 > > Past few days I've had a comaintainer on a package committing SCL work
 destined for Copr into a "nightly" branch of the package.  I've been
 getting commit email about it.  I've told him to stop but he's said he
 wants it there because it's destined for copr.  I think that having SCL
 packages in the same repo, just in a different branch is problematic for
 people mentally.  They're thinking of the SCL conceptually as the same
 package when it needs to be thought of as a different package.  Taking
 mingw packages as a the model again:

 As I came up with the idea of doing Python nightly rebuilds in Copr, let
 me explain a bit:

 - To give a little background, we want to create Copr SCLs with nightly
 rebuild of python3/python-setuptools/python-wheel/python-pip. Ideally, we
 want to build latest upstream master branches of all these packages once a
 day. That has some benefit:
   - We'll know of any regressions very soon and we'll be able to report
 them back to Python upstream in matter of a single day.
   - We'll be able to rebase our patches continually and we'll know when
 they stop working.
   - Fedora users will be able to install latest python3 with
 easy_install/pip, hence the community will have an easy way to get hands
 on the newest features happening in Python 3 every day.
   - People will be able to extend the collection to build their own
 packages with latest Python 3 upstream master.
 - Primarily, the packages are supposed to be built in Copr as an SCL, but
 in the future, I want to be able to merge these branches in Fedora and
 build standard *non-SCL* Fedora builds from them.
 - I think SCL package is the same package. The fact that we will be able
 to merge it back to e.g. rawhide and build it without actually having to
 change anything (except maybe truncating changelog and changing revision)
 proves it.

 > > * the primary package maintainers do not see commit email for changes
 to the mingw package or bug reports.  That's not the case if we only use a
 separate branch.
 > > * the mingw package maintainer can opt-in or opt-out of getting commit
 and bug mail about the primary package if the packages have diverged.
 That's not the case here. (And should be more important here as the
 version of an SCL stays behind the main package whereas the mingw package
 attempts to keep up with the version in Fedora).

 Not true, at least not for what we intend to do with Python nightly builds
 - we actually want to stay *ahead* of Fedora, ideally sync every day with
 upstream master branch.

 > > * mingw packages that have not been approved plainly do not belong in
 the Fedora git repo as they're an unreviewed package.  That's apparently
 not clear with SCL as branch.
 >
 > Could you point me to the package and commiter? I'm aware of commits for
 python nightly stuff, but that's not related to SCL at all.

 I believe we're talking about python-setuptools and the commiter who did
 this was Miro Hroncok (a.k.a. churchyard). It's true that this branch uses
 SCL macros, but if/when we merge this back to Fedora, we won't actually
 build as SCLs.

 > I've seen many changes in specfiles, which I didn't like, it's not
 happening only with SCL. People just have different views about content of
 specs.

 I'd also like to add that I don't see why we couldn't use unofficial side
 branches in dist-git for this kind of work. It's not against any
 guidelines and it will be useful to both Fedora and Python community.

-- 
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5894#comment:40>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project