river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryan Thompson <br...@blazegraph.com>
Subject Re: State of the project
Date Thu, 05 May 2016 12:15:03 GMT
There are several key reasons for moving to git, and a read-only repository
would not support most of them:

* Git makes it significantly easier to branch and merge when compared to
SVN, CVS, etc.
* Git pull requests encapsulate an opportunity for feedback on branches and
easy diffs between branches that is unparalleled by SVN, etc.
* PRs can be contributed more easily from the broader community (but such
PRs would require Apache CLAs, etc. before they could be incorporated into
an Apache project so we might not get much utility from this).
* Git repositories can be easily forked (a read-only view would support
this), and these forks can flow updates back to the original project (this
would again run into trouble with the Apache CLA process).

Thanks,
Bryan

On Tue, May 3, 2016 at 7:48 AM, Patricia Shanahan <pats@acm.org> wrote:

> Currently, I believe only read-only Git mirrors are supported for most
> projects. See http://www.apache.org/dev/git.html. It looks as though the
> process for adding a mirror is fairly simple. Would that level of support
> be useful?
>
> There is an experiment going on to extend Git use. I suggest at least one
> of you should subscribe to the infrastructure-dev@ list to follow what is
> happening.
>
> On 5/3/2016 4:22 AM, Tom Hobbs wrote:
>
>> Could we consider a service registrar that doesn't require code
>>> downloads? Other language support?  What might it look like?
>>>
>>
>> This is my particular itch right now.  I’m happy to work on pulling
>> reggie out as one of the first modules.
>>
>> And +1 for git.
>>
>>
>> On 3 May 2016, at 11:29, Peter <jini@zeus.net.au> wrote:
>>>
>>> Could we consider a service registrar that doesn't require code
>>> downloads? Other language support?  What might it look like?
>>>
>>
>>
>>

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