Copying from #wikimedia-dev IRC (sorry) and cc'ing wikitech-l as requested:
[James_F] cscott: I think you're confused about fab.wmflabs.org. It's
not meant for use. It's meant for evaluation.
[cscott] James_F: and i'm saying that unless i can use it for
something i can't easily evaluate it
[greg-g] cscott: James_F crazy idea here: can some teams use it for
real (I think growth is, kinda?) and export/import to a future real
instance?
frontend...
[cscott] greg-g: i think that's more or less the plan, but it doesn't
really mean that the results will be applicable to the groups who
*aren't* using it.
that is, i could, for example, use the existing instance for work on
the PDF backend, which is a 1-2 person project. but that doesn't mean
that the results apply to how the parsoid team works.
[greg-g] cscott: of course, but it can't be on anyone else other than
those people to try it and report bugs, no one can impersonate you
effectively other than you.
[cscott] greg-g: i totally agree, which is why i'm arguing for a soft
transition.
[greg-g] cscott: I think it's mostly semantics at this point,
honestly. The difference between a soft transition and the RFC closing
with Yes, pending those blockers are addressed are the same thing,
especially since Platform (the usual suspects saddled with this kind
of stuff) won't have time to actually do anything production-like any
time soon with Phab.
[James_F] greg-g, cscott: I think that ultimately if we can't work out
how we use gerrit and boil it down to 10 bullet points we've failed.
It's a simple tool.
[cscott] greg-g: what i'm saying is i don't think it's worth closing
the RFC with a yes, but since those bugs are all show-stoppers to
Real Work right now.
[James_F] greg-g: A soft transition means go make a production
Phabricator instance.
Which is pretty bad if we never use it properly, and don't shut down
other systems.
[gwicke] we could agree to write a new RFC after actually trying it
;)
[YuviPanda] I tried setting our fab.wmflabs.org instance up for doing
CR with its own hosted repositories, so we could put a few small
projects there
spent 3-4 hours, and got close before giving up.
I can add other people to the project if they want to give it a shot
:) Note that none of this is puppetized so need to be slightly extra
careful
[cscott] James_F: if you want to phrase it that way, a yes but
means, we'll commit to transitioning to phabricator without ever
having seen an instance which will actually work for us
[greg-g] cscott: how is that different from any development problem/goal?
[cscott] James_F: i think all the extremes are bad. i don't think we
should give up on phabricator. and i think it's too early to
definitively commit to it. and i think we shouldn't spent 100% of the
resources to make a production instance before making a decision, and
I don't think we should make the decision without spending *any* of
the resources.
i don't think we can do a transition without some sort of integration
of new and old systems, and i also agree that maintaining the old and
new systems together indefinitely defeats the point.
[gwicke] fwiw, I tend to agree with cscott that it's hard to make any
informed decision without actually testing it in practice
[James_F] cscott: You're throwing around dramatic terms like
blockers without explaining what you mean. Again, please take this
to wikitech-l and let's have a proper discussion.
[cscott] James_F: I'm arguing for a middle path. devote *some*
resources, implement *some* interoperability, decide at *some later*
point when we have a more functional instance.
--
[http://cscott.net]
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
