Hi, just my 2 cents, something like that would really improve the "user-experience" compared to what we have right now. :-) I'm very thankfull that we have a git repo already but something "eye-candy" like what is possible with that gitlab stuff seems very charming to me. In that case I'd rather use links to those pages for discussing certain code-snippets with other instead of what I do now, use a link to the github project.
I think this is the last missing piece to get a good "user-experience" for those github spoiled people out there :-) regards, Achim 2015-03-05 12:09 GMT+01:00 Benedikt Ritter <brit...@apache.org>: > 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 > -- Apache Member Apache Karaf <http://karaf.apache.org/> Committer & PMC OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & Project Lead blog <http://notizblog.nierbeck.de/> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS> Software Architect / Project Manager / Scrum Master