On Wed, Dec 11, 2013 at 09:06:09AM +0100, Rune Morling wrote:
> Is it feasible to take just a few groups, like the "Minimal Install" group,
> to begin with? Because that looks reasonably self-sufficient to me? If so,
> then once we get the base working, we could also import Xorg as Mark T
> suggests?
>
> Or are you referring to a proper spin, anaconda and all?
I don't think that mirrorball has any support in it for limiting by
those groups. I was thinking of spin in the Fedora sense of spin,
because that seemed like the easiest thing to target without new
mirrorball development. I could be wrong.
> Also, would this happen on SAS-sponsored infra or locally?
Local to what, or to whom? The Foresight infrastructure is all on
SAS-owned equipment, and I'm assuming that it would be done on that
infrastructure, including source builds if developers wanted to take
that on.
> When it comes to UX ('because your desktop should be cool!') my guess is
> that we'll have our hands full with just keeping the binary imports and the
> SRPM rebuilds running smoothly, making this the primary focus for the next
> 3-6 months or so. Especially so now that António appears to have become
> engrossed in his family project.
Well, sure. My point in enumerating points was to make clear that
there was a logical progression and separation. Fortunately for me,
I never ran Foresight with the purpose of having the latest version
of GNOME! I'd use this just to manage Fedora systems even without
packages, but I'd probably contribute an xpra package to a Conary
layer on top, at least as long as xpra remains unpackaged in Fedora
due to complaints about how the upstream packaging has been done,
just to give a concrete example.
> If it means that I get to have Fedora + Conary, then yes, I'd be willing to
> help.
That's exactly what it means.
> Realistically, how many volunteers do you feel we need for this to become a
> success?
One person at SAS does almost all the work of importing both RHEL and
CentOS. Therefore, it's more about willingness and time to learn the
processes on the part of each participant, and total available time,
than the exact number of participants. I'd think that four volunteers
could very reasonably accomplish this work. Given that you have to
learn to wrangle mirrorball, many volunteers, each of whom doesn't have
time or inclination to learn this process, won't succeed.
The new development work is mainly of two kinds:
1. Solving the initial import problems. This will be the frustrating
part, and it will involve finding places where Conary policy and
whatnot don't line up with Fedora, and filing detailed reports in
the issue tracking system at https://opensource.sas.com/its/
so that issues can be addressed. Most likely, we'll end up with
short-term workarounds while the bugs are being addressed.
2. Once the initial work succeeds and mirrorball is running under
automation (SAS uses Jenkins to drive the process), being
available when mirrorball fails, to diagnose and address the
issue so that the monkeys can get back to doing the work.
Beyond that, volunteers to do any additional projects that they want
to do. This will work with no installer at all; you could install
the base Fedora and then "adopt" it into a Conary-managed system.
But if someone (me or someone else) wants, they can adapt flimage
to work with the results.
Finally, it doesn't get rid of the need to maintain infrastructure.
For example, upgrading JIRA and Confluence.
> For my own part, I have a 16GB quad core box sitting right next to me
> waiting to get started. However, I don't quite know where/how to begin.
> Is the old rPath documentation available anywhere these days? Or am I
> asking the wrong question in this regard?
The old rPath documentation is again available. It seems I didn't post
the URL to this list when it went live a few months ago, for which I
abjectly apologize. http://opensource.sas.com/conarywiki/
I am not currently aware of what documentation might be available for
running mirrorball. I can find out.
_______________________________________________
Foresight-devel mailing list
[email protected]
https://lists.foresightlinux.org/mailman/listinfo/foresight-devel
