2015-03-05 11:51 GMT+01:00 Stian Soiland-Reyes <st...@apache.org>: > 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 >
Very nice summary, Stain! I agree with you. > > > > > 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 > > > > -- > Stian Soiland-Reyes > Apache Taverna (incubating) > http://orcid.org/0000-0001-9842-9718 > -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter
