I really like the idea of a GitHub-like platform link GitLab to power the
ASF's Git infrastructure instead of our current git-wip-us implementation.
Supposing there's no impediment to that (license, servers, etc), why not?
Stian's summary of why is quite good.
On Thu, 05 Mar 2015 07:51:06 -0300, Stian Soiland-Reyes <st...@apache.org>
wrote:
I think it would be interesting to do a trial, perhaps with a couple
of willing&new projects. How would you rally projects together to
"demand" it before seeing what it would be like?
For me personally, not having to manage VMs with development
infrastructure is one additional advantage of moving to Apache - I'm
OK to wait for the occasional INFRA requests than having to install
patches, monitoring etc. myself.
GitLab uses a normal git file-based storage for the repositories, so
it should be possible for that file system to be the same one uses by
git-wip-us (although git over NFS should raise alarm bells..)
I agree with Roman that the social benefit from Github happens at
Github - and the pull request integration is a great path into the
project for outsiders.
..but that doesn't mean we have to submit totally to Github for
"normal use" of the source code.
I believe Gitlab allows sign-in by GitHub id - but I am not so sure
about automatic mirroring from Gitlab to GitHub (or pull request
integration back again). This could still be achieved the classic way
if the repositories remains at git-wip-us.
The GitLab issue tracker (which looks very much like GitHub's issue
tracker) is an ideal tracker for many projects - not as complex as
Jira, and not as arcane as Bugzilla. I have not tested it in detail,
but if it has similar email integration as GitHub, then it becomes a
smooth integration with the dev@ lists as well.
With the GitHub/GitLab style of working you also tend to make several
smaller repositories rather than a monolithic $project.git. With a web
interface like Gitlab Enterprise, in theory the PMC chairs can be
granted karma to click the "Create" button for their project rather
than having to wait for INFRA to run a series of scripts.
Now browsing of git repositories is my bugbear..
In my own developer documentation I like to deep-link to the relevant
source code rather than just talk about things in the abstract or with
Javadoc links - this becomes then also an invitation to explore the
code and to contribute.
With our own git infrastructure there is not really a usable "Browse"
function - see for example:
https://git-wip-us.apache.org/repos/asf?p=incubator-taverna-language.git
- Where is the code? Oh, you have to click "Tree".
- How do I deep-link to code from our website and emails? Links like
https://git-wip-us.apache.org/repos/asf?p=incubator-taverna-language.git;a=blob;f=taverna-scufl2-api/src/main/java/org/apache/taverna/scufl2/api/io/WorkflowBundleIO.java;h=03bf3d1ece6674c97747612223f04e3fcd1802fd;hb=de2d370db6f037afa21ca10c3a51f2192aaaddc5
seem unpredictable and are hard to use.
- How do I even check out? Do some regular expressions in your head
from the current URL.
- How do I navigate the code? I have to click manually on README.md
files - which are not rendered as Markdown
Thus every project has to write a lot of documentation with basic
information like how to clone a repository and how to navigate the
code base -- or simply send people off to Github (which borders onto
product endorsement) and use Apache's git infrastructure as a
write-only service.
I would consider browsing of the code to be essential for being open
for outsiders. Apache insiders will know how to navigate these things,
or know when to use Github mirrors - but for anyone incubating into
Apache or bumping into an Apache project, being sent into the
git-wip-us interface basically looks like "Go away".
So as Apache is all about the community - we should consider:
1) Github presence is essential
2) Browsing code is essential
3) Apache-controlled infrastructure should be used for day-to-day
running of a project
On 5 March 2015 at 08:15, Niclas Hedhman <nic...@hedhman.org> wrote:
Yes, the network effect is important, but is it the only one? Can the
network effect happen on ASF systems? Would we want it to?
// Niclas
On Thu, Mar 5, 2015 at 1:43 PM, Roman Shaposhnik <ro...@shaposhnik.org>
wrote:
On Wed, Mar 4, 2015 at 7:24 PM, Niclas Hedhman <nic...@hedhman.org>
wrote:
> But, during my last 2-3 year absence, has the GitLab[1] option been
> discussed and/or tried? GitLab is open sourced, can run on our infra
and
> has many of the essential features of Github.
> But perhaps people are satisfied enough with the Github mirroring
that is
> already in place, but with GitLab in house, we could (in theory) add
> features around licensing (like ICLA style assurance, similar to
Jira),
and
> non-committers could(!) be allowed a direct route to the horse's
mouth...
Here's the way I look at it: the power of github.com comes not so much
from the
web UI or even API, but from a network effect. It is where developers
congregate.
Thus we'd have to have mirrors of our stuff there anyway to enable PR
workflow
for projects that care about it. And as long as THAT is in place, the
need for something
like GL is reduced, IMHO.
Thanks,
Roman.
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java
--
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br
