community-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Achim Nierbeck <bcanh...@googlemail.com>
Subject Re: GitLab?
Date Thu, 05 Mar 2015 11:44:55 GMT
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 <britter@apache.org>:

> 2015-03-05 11:51 GMT+01:00 Stian Soiland-Reyes <stain@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 <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
> >
> >
> >
> > --
> > 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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message