Trials lead to services that need to be maintained. No trial unless we know we can maintain it.
For that to happen someone needs to come up with a full proposal for the infra team to evaluate with clear justification for the approach and clarity on how ASF budgets would need to scale to support it in the long term. I would strongly suggest starting with the Allura community. Sent from my Windows Phone ________________________________ From: Thiago H de Paula Figueiredo<mailto:thiag...@gmail.com> Sent: 3/6/2015 1:58 PM To: dev@community.apache.org<mailto:dev@community.apache.org> Subject: Re: GitLab? 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
