community-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thiago H de Paula Figueiredo" <thiag...@gmail.com>
Subject Re: GitLab?
Date Fri, 06 Mar 2015 21:56:46 GMT
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 <stain@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 <niclas@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 <roman@shaposhnik.org>
>> wrote:
>>
>>> On Wed, Mar 4, 2015 at 7:24 PM, Niclas Hedhman <niclas@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

Mime
View raw message