Fedora hosted planning

[Paul W. Frields]

On Tue, Mar 10, 2015 at 09:26:59PM -0500, Dennis Gilmore wrote:
> On Tuesday, March 10, 2015 05:56:58 PM Paul W. Frields wrote:
> > On Tue, Mar 03, 2015 at 10:17:41PM -0600, Dennis Gilmore wrote:
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > > 
> > > On Tue, 3 Mar 2015 13:30:26 -0700
> > > 
> > > Stephen John Smoogen <smooge at gmail.com> wrote:
> > > > On 3 March 2015 at 13:22, Kevin Fenzi <kevin at scrye.com> wrote:
> > > > > Greetings.
> > > > > 
> > > > > So, looking at fedorahosted, I thought I would start some discussion
> > > > > about where we are and where we need to go short and longer term.
> > > > > 
> > > > > Right now hosted03/04 are rhel6 and still in puppet. Short term, I
> > > > > would very much like to move them to ansible, and ideally to rhel7.
> > > > > 
> > > > > I looked into the trac situation upstream. We are currently using
> > > > > 0.12.5 long term release on rhel6 (from epel6). There's a 0.12.6
> > > > > thats out, but it looks like that might be the last release in the
> > > > > 0.12 series (or there might be a 0.12.7, but thats likely to be
> > > > > it). They are looking at doing releases yearly if they can manage,
> > > > > so 1.2 would appear later this year, then 1.3, etc. It's not clear
> > > > > how long 1.0 will be supported really. At least a year, but not
> > > > > clear after that.
> > > > > 
> > > > > So, as I see it, our options are:
> > > > > 
> > > > > 1 Just move to ansible, leave on rhel6 for now until we decide
> > > > > 
> > > > >   something better.
> > > > > 
> > > > > 2 Move to ansible and rhel7, and build out trac-1.0 and plugins in
> > > > > 
> > > > >   epel7. This will take a bit longer since there's so many plugins,
> > > > > 
> > > > > but shouldn't really be that hard.
> > > > > 
> > > > > 3 Move to ansible and rhel7 and progit. I'm not sure if progit is
> > > > > ready to replace trac though. I think it might need wiki features
> > > > > and also more ticket handling stuff, since some of our projects use
> > > > > trac ticketing heavily.
> > > > > 
> > > > > 4 a combo of 2 and 3 (ie, offer trac and progit both)
> > > > > 
> > > > > 5. a combo of 1 and 3 (ie, old trac projects stay on old hosted, we
> > > > > move ones that want to progit, eventually we have a flag day and
> > > > > move the rest).
> > > > 
> > > > 5 sounds like the most likely. There are a lot of work flows which
> > > > groups are using with the current trac. If they didn't.. they would
> > > > have probably moved over to github by now. Having the old boxes on
> > > > ansible is probably faster by at least 18 months over getting people
> > > > moved to the newer system.
> > > 
> > > I refuse to use github because I personally think its very bad for us as
> > > a open and transparent community and project that prides itself on
> > > making sure everyone can mimic what we do exactly to use something
> > > closed and proprietary. For my own projects I think I would mostly be
> > > okay with progit though something would be needed for ticketing for
> > > releng, wiki space would be good for some projects but is not really
> > > needed on all projects. some like mash only have a git repo on
> > > fedorahosted, there is no associated trac. I think 4 or 5 would both be
> > > viable.
> > 
> > [Sorry for catching up late to this thread.]
> > 
> > I'm not comfortable yet with the idea of taking on the service
> > build-out that (3) represents above.  That's a lot of commitment for
> > something I don't think we can call critical path.  Github may be a
> > closed/paid service solution but it doesn't affect the public
> > availability, transparency or forkability of any of our code.  And a
> > long-term investment in chasing that solution as a Fedora-specific
> > service to replace hosted is not necessarily the best use of our
> > resources.
> We can agree to disagree here. I think without a good viable open source 
> option we will be locked into a closed proprietary platform.

Define "locked"?  If we're able to take our data (and even issues) and
go elsewhere, where's the lock-in?

I would agree with you if this were about email, wiki, file storage,
or some other data type.  The DVCS factor clearly separates Github
from being an issue of lock-in or a slippery slope.  I don't know of
another type of data store where there's transparent, potentially
infinite mirroring to prevent lock-in.

> if github jacks up the price or closes down, yes we still have our
> clones and can put the data elsewhere. but there will be nowhere
> else viable to put the data

That's not how I read the above.  I don't believe Kevin suggested that
e.g. git.fedorahosted.org is dying or needs to shut down imminently,
or that Trac was no longer working.  I think the discussion is about
the long term roadmap for Trac, which is a living and breathing
(albeit slow moving AFAICT) upstream project we don't have to maintain
ourselves.

> additionally we are saying its okay to compromise our principles
> when it suits us and puts us on a slippery road.  I do not think we
> should have or want a Fedora specific service. we could potentially
> use some new service not only for for fedorahosted but for pkgs
> git.

Has someone already looked at Gitlab's hosted offering?  I understand
the reasons it's difficult to host our own instance, so I'm referring
to gitlab.com itself.

> having a good way for people to develop test and send patches to
> others seems like a huge win to me. I am sure we could probably work
> cross distro to have a universal solution with a big developer base.

Define "big"?  Working cross distro is a fine idea, but it only puts
us in front of the small percentage of developers working in distro
communities.  Most of them are elsewhere, and Github is one of the
largest communities of developers, as Matthew Miller has pointed out
in his FPL presentations.

None of this seems to address the resource problem.  Github gives us a
frictionless and transparent way to collaborate, it can't steal our
code, and the Fedora Engineering team doesn't have the cost of
maintaining it in the long run.

-- 
Paul W. Frields                                http://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
  http://redhat.com/   -  -  -  -   http://pfrields.fedorapeople.org/
    The open source story continues to grow: http://opensource.com