On Fri, 2014-02-07 at 09:00 -0500, Rich Mattes wrote:
On Thu, Feb 6, 2014 at 5:58 PM, Ankur Sinha <sanjay.ankur(a)gmail.com>
Looks like someone finished what I'd begun:
I'll test it out ASAP.
This is great news. I'll look into updating some of the packages that
are called out as out of date in the ticket.
Since we're moving towards using SCLs with Fedora.next, I was
if we could use SCLs to provide ROS releases in parallel? What
I think that's a reasonable approach. It looks like the SCL
guidelines are still in the works, but we can probably get started
using them anyway.
Aye. Me too. In the long run, we'd like to support all ROS releases and
SCLs are the best way of doing it.
Do you think should try to get the packages into Fedora proper once
the SCL process is defined? I think that would mean some manual work
for each package (getting it reviewed, making sure the generated spec
conforms to whatever packaging guidelines apply, etc)
Well, to begin with, I was thinking of just making 3 SCLs for
fuerte/groovy/hydro available in as copr projects (maybe start with
groovy since we're already working on it). I still need to check if
they've added SCL support to it. Once the SCL guidelines are complete
and they can be included in Fedora proper, we can start submitting
review tickets and tweaking our specs according to reviewer comments?
Similarly, does it make sense to see if the OSRF wants to take care of
building and maintaining Fedora packages in tandem with their Ubuntu
release process? SCLs are kind of designed to make it easier for
third party distributors to create and provide sane packages, and if
bloom knows how to do so then it might not be so bad. On the other
hand, keeping such a large packageset in sync with two distributions
is probably going to be a lot of work, and probably isn't going to
scale if they ever want to add official builds for more distributions
in the future. Keeping packages within the Fedora ecosystem means you
get the benefit of warnings if dependencies shift from underneath you,
coordinated updates, etc.
Yeah, it isn't scalable for them. I think it'll be better to keep
packages in the Fedora eco system as you say. It'll enable us to better
maintain packages. We also have QA infra already which OSRF don't. It'll
be quite like the mega GNOME updates the desktop SIG does, I expect.
I think that it would be good to coordinate with the OSRF on this, and
see if they plan on providing packages themselves. If not, we need to
coordinate the best way to get their packages into Fedora (copr,
fedora SCL, etc.)
We could talk to them, yes. Should we do this in the pull request
itself, or one of the mailing lists?
In the mean time, I've set up a copr repo already:
I don't think I can give a FAS group access on copr yet, but if you head
to the permissions tab and apply for permissions, I can give you access
to it. It looks like the only way of doing this at the moment:
Do you think we need to set up a shared repo for our spec/srpm files
somewhere? A github or fedorapeople repo? Copr needs them to be hosted
somewhere. For example:
Join Fedora! Come talk to us!