Mailing-List: contact dev-help@community.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@community.apache.org
MIME-Version: 1.0
References: 
 <CADmm+Kff9qR_zQstYxbW=sHMfV7=zZrFvuND_Mn7-8Ljp819hQ@mail.gmail.com>
 <CA+ULb+u9_9N3KoM7ya7Y7z+wj-MPybUA70FtOSz1RF1PJ3MFxg@mail.gmail.com>
 <CADmm+Kdem7DKtZ_+MYwrCfW5n_22ZbLhCtkc7frtv8iM8_t-Ew@mail.gmail.com>
 <CAMBJEmUoBu=mp=hBcEe_pBzh5f6drDRGGZcq8Z97L2KZy+TVbw@mail.gmail.com>
 <CAB917RLZgLGzNgXCGGupT8i1dhGsAYw=8vofwo3ucdBDZetSAw@mail.gmail.com>
 <CAD0r13ckDaVc+=9EnYEAsZirmiyoP5zq9H5RxXsVyfUHbCtBEg@mail.gmail.com>
 <CAM1yOjZgo7yTz=WmF-dnQ6-v7xQ4A3fgyBmdf=OueZ+H2+HW=A@mail.gmail.com>
From: "John D. Ament" <johndament@apache.org>
Date: Thu, 05 Mar 2015 13:14:58 +0000
Message-ID: 
 <CAOqetn_o8QZ2eZC5+Rq2gG1EV06umwVGROUkWfjuZ6jMbhbRSQ@mail.gmail.com>
Subject: Re: GitLab?
To: dev@community.apache.org
Content-Type: multipart/alternative; boundary=001a1137a48cd4bb9705108a5a5f

--001a1137a48cd4bb9705108a5a5f
Content-Type: text/plain; charset=UTF-8

On Thu, Mar 5, 2015 at 7:27 AM Mike Kienenberger <mkienenb@gmail.com> wrote:

> I'm a long-time CVS/SVN user (multiple decades), and I started using
> git and github about a year-and-a-half ago for a non-ASF project
> intermittently.   While I like the parallel development paths,
> merging, and speed that git provides, the integrated bug tracking,
> code commenting, code browsing, and low cost of entry as a new user in
> github really added to the community building of the project.
>
> Achim Nierbeck and Stian Soiland-Reyes are correct when they say that
> git without github loses a great deal of the full user experience of
> working in this kind of environment and I doubt I would have been
> pulled into that project's community and development nearly so much if
> github had not been part of the equation.
>

I think when I read statements like this, it reminds me of one of those
classic "this tool fixes everything" types of notes.  It's not the fact
that you have github that things are better, but the sheer fact that you
have a way to support external contributions in a more streamlined way.

I see projects today in ASF that use git, but apply external changes via
patch files.  That part boggles my mind.

There are lots of tools like github out there.  Heck, you could probably
even automate ICLAs with a custom license agreement.


>
> I'd rather seen Infra start the ball rolling to provide an official
> github alternative than see a bunch of projects build their own
> services.   First, I think that the value of a fully-functional github
> service is already proven.  That's why every ASF git project also has
> a github mirror.  Second, github doesn't just build community
> internally to a project but also builds community between projects
> which is an ASF goal.  You tend to jump from one project to another
> related project when code browsing.  Third, the adoption of a github
> service is inevitable anyway :)  Even as a new git user, when my ASF
> projects started supporting git, my first thought was "Where's the
> github service alternative"?
>
>
>
>
> On Thu, Mar 5, 2015 at 6:44 AM, Achim Nierbeck <bcanhome@googlemail.com>
> wrote:
> > 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=de2d370db6f037afa21ca10c3a51f2
> 192aaaddc5
> >> > 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
>

--001a1137a48cd4bb9705108a5a5f--