#5894: git branches for SCL packages
Fedora Release Engineering
rel-eng at fedoraproject.org
Mon Jun 30 09:37:30 UTC 2014
#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
More information about the rel-eng
mailing list