[PROPOSAL] Thrift

[Mark Slee <ms...@facebook.com>]

Hi all,
 
We've just posted the Apache Incubator proposal for Thrift onto the
Wiki:
http://wiki.apache.org/incubator/ThriftProposal
 
For those who prefer reading Wiki markup directly, it is copied below.
 
Cheers,
Mark
 
= Thrift Proposal =

== Abstract ==
Thrift is a framework for efficient cross-language data serialization,
RPC, and server programming.

== Proposal ==
Thrift is a software library and set of code-generation tools designed
to expedite development and implementation of efficient and scalable
backend services. Its primary goal is to enable efficient and reliable
communication across programming languages by abstracting the portions
of each language that tend to require the most customization into a
common library that is implemented in each language. Specifically,
Thrift allows developers to define datatypes and service interfaces in a
single language-neutral file and generate all the necessary code to
build RPC clients and servers.

== Background ==
Thrift was initially developed at Facebook starting in 2006 to power RPC
and data logging for a number of backend services for the site, such as
Search and News Feed. The package was designed for open source, and was
released in early 2007. Since then, a number of other developers have
submitted patches to the project and become de facto owners of major
parts. Support for many languages has been developed entirely outside of
Facebook.

== Rationale ==
The need for high performance, reliable communication across different
programming languages seems to be growing more and more common in modern
programming, particularly when writing software for the web.
Historically, this problem has forced developers to standardize on one
language/framework or adopt heavier-weight systems, such as CORBA or
SOAP. These systems tend to make tradeoffs that aren't always ideal for
the use case. SOAP, for example, may be ideal for calling across
disparate web services, but is unnecessarily verbose for service calls
on an intranet.

Most of these systems also require developers to learn the particulars
of their type systems, especially when dealing with containers or
objects. One of the primary goals of Thrift is to allow developers to
program across languages while still using the standard idioms and style
in each language. Custom type systems also makes code reuse more
difficult. Thrift allows developers to avoid creating unnecessary
wrapper interfaces by operating directly on native types.

== Initial Goals ==
Though the bulk of Thrift's initial development is complete, there are
still some large areas for future development. Some areas we hope to
focus on in Apache:

 * Better log storage/replay
 * Meta-data serialization
 * Higher-performance serialization, standard C extension model across
Python/PHP/etc.
 * Extending the abstraction to a multi-client that can fan-out across
multiple servers

== Current Status ==
=== Meritocracy ===
Though initial development was done at Facebook, Thrift was intended to
be released as an open source project from its inception. Since release,
many developers have adopted the framework and submitted significant
patches. Large portions of the codebase are now managed by those most
familiar with and responsible for them. Any potentially controversial
change is discussed on the public mailing list
(http://lists.pub.facebook.com/mailman/listinfo/thrift/) and good
suggestions are frequently implemented.

=== Community ===
Thrift is currently in use across a number of organizations, and we
expect this to grow as Thrift becomes a relevant and useful tool for
building more open source projects.

=== Core Developers ===
Thrift currently has developers across many organizations (e.g.
Facebook, Powerset, ReCaptcha, AmieStreet), many of whom are
contributors to other open source projects.

=== Alignment ===
Thrift is designed to integrate cleanly with other projects. We think
this is a particularly good fit for Apache due to integration potential
with other projects, specifically Hadoop/Hbase.

== Known Risks ==
=== Orphaned Products ===
Thrift is already deployed into production at multiple large websites
that are frequently iterating on the featureset. There's no realistic
chance of it becoming orphaned.

=== Inexperience with Open Source ===
The project has already been open source for nearly a year and has
attracted many developers already. Part of the reason to join Apache is
to make the project work even better as open source by removing some
obstacles, such as Facebook hosting the SVN, and putting the resources
all in a truly open space, being able to have more committers, etc. Most
of the core developers have a history of working with open source tools.

=== Homogenous Developers ===
The current set of developers work across a variety of organizations.
Naturally, most are websites with significant backend structure (and
hence a need for Thrift), but the problems they are solving are diverse,
and many don't work in the same programming languages.

=== Reliance on Salaried Developers ===
Thrift is a "means to an end." None of the developers (to my knowledge)
working on Thrift are salaried specifically to work on Thrift. Rather,
Thrift is useful in building other projects, which may or may not be for
salary. Realistically, it is likely that a decent portion of work on
Thrift will be done by someone at a company, but not specifically tasked
with working on Thrift. So long as the tool is relevant and useful, this
should result in developers contributing time both at work and
personally.

=== Relationships with Other Apache Projects ===
Thrift has already been introduced into the Hbase project. (See
https://issues.apache.org/jira/browse/HADOOP-2389) Since Thrift is a
development tool, it is designed and well-suited for use in other
projects. As a start, we definitely plan to continue integration work
with Hbase.

=== An Excessive Fascination with the Apache Brand ===
Thrift has already attracted a stable base of developers. The reasons
for joining Apache are not to advertise the project, but rather to
demonstrate the commitment to open source by divorcing the trunk from
any one corporation and pursuing further integration with other Apache
projects.

== Documentation ==
Existing page:
http://developers.facebook.com/thrift/

Mailing list (with archives):
http://lists.pub.facebook.com/mailman/listinfo/thrift/

== Initial Source ==
Currently hosted by Facebook:
http://svn.facebook.com/svnroot/thrift/

== Source and Intellectual Property Submission Plan ==
All code currently hosted in the Facebook public SVN folder will be
contributed.

== External Dependencies ==
All dependencies (libevent, Boost) have Apache compatible licenses.

== Cryptography ==
None

== Required Resources ==
=== Mailing lists ===
 * thrift-dev
 * thrift-private

=== Subversion Directory ===
https://svn.apache.org/repos/asf/incubator/thrift

We'd also be interested in using git to store the repo. Does apache have
infrastucture set up to support that? It'd make it easier for
non-committer developers to work on patches, checkpoint commits, etc.

=== Issue Tracking ===
Bugzilla Thrift

== Initial Committers ==
 * Mark Slee (mcslee at facebook dot com)
 * Aditya Agarwal (aditya at facebook dot com)
 * Marc Kwiatkowski (marc at facebook dot com)
 * David Reiss (david at facebook dot com)
 * James Wang (jwang at facebook dot com)
 * Chris Piro (cpiro at facebook dot com)
 * Ben Maurer (bmaurer at andrew dot cmu dot edu)
 * Kevin Clark (kevin at powerset dot com)
 * Jake Luciani (jakers at gmail dot com)

== Affiliations ==
 * People with Facebook email addresses - Facebook
 * Ben Maurer - ReCaptcha
 * Kevin Clark - Powerset

== Sponsors ==
=== Champion ===
 * Doug Cutting

=== Mentors ===
 * Paul Querna
 * Upayavira

=== Sponsoring Entity ===
 * Incubator


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Re: [PROPOSAL] Thrift

[David Reiss <dr...@facebook.com>]

> Niclas is correct - this can create hardships, resentments, control
> issues in your community.  If it's a simple as "we don't trust you
> Java folks on day one to properly indent Python code" I can sympathize
> with that concept.
That's about the extent of what we were thinking, but there has been so much 
opposition to this idea that Mark and I have decided to withdraw it from the 
proposal (wiki update coming soon).  I think Ben said it best: if someone 
can't be trusted to not start committing changes to modules they are 
unfamiliar with, they should not be a committer at all.  If we somehow get to 
a place where we are constantly merging patches from someone that we don't 
trust enough to make them a committer, we can discuss the possibility with our 
mentors.

--David

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [PROPOSAL] Thrift

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Yoav Shapira wrote:
> On Jan 30, 2008 2:24 AM, Mark Slee <ms...@facebook.com> wrote:
>> What we'd really
>> like to set up here is a system where there are different people with
>> committer priveleges to different parts of the project.
> 
> I'm not a huge fan of this, but I love the rest of the proposal, so +1
> to it!  I'm also happy to help as a mentor if one is still needed.

Before I vote, and before you get a flurey of "we won't accept this"
responses, please define *exactly* which partitions you forsee for
committers in the proposal, instead of leaving it as something vague
that some incubator folks here are very concerned with.

Niclas is correct - this can create hardships, resentments, control
issues in your community.  If it's a simple as "we don't trust you
Java folks on day one to properly indent Python code" I can sympathize
with that concept.

But if you spell out what the separations are, ask non-fluent coders
to submit patches for a while before demonstrating commit access to
those other code bases, it *can* work.  But beyond languages, and some
cliff of "demonstrated fluency in this subproject's language", you will
probably have committer issues by fracturing the community.

So if you want partitioning, please define it very narrowly, before
we move on to count this vote.

Bill

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [PROPOSAL] Thrift

[Yoav Shapira <yo...@apache.org>]

On Jan 30, 2008 2:24 AM, Mark Slee <ms...@facebook.com> wrote:
> What we'd really
> like to set up here is a system where there are different people with
> committer priveleges to different parts of the project.

I'm not a huge fan of this, but I love the rest of the proposal, so +1
to it!  I'm also happy to help as a mentor if one is still needed.

Maybe the easiest approach is to take the leap of faith now, and enter
incubation with a single committer pool.  Then as time progresses, we
can think about this further.  As Erik noted, there's precedence, e.g.
the httpd project itself, but we'd like to keep that an exception
rather than the rule.

Yoav

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Re: [PROPOSAL] Thrift

[Matthieu Riou <ma...@offthelip.org>]

On Feb 1, 2008 2:32 PM, Mark Slee <ms...@facebook.com> wrote:

> Following up on what David sent out yesterday, I think we're all on
> board with having a single committers pool based upon mutual trust and
> respect.
>
> However, dropping parts of the code feels counterproductive to me, as I
> think it might put up a perceived barrier to collaboration with the
> Thrift project. Alternate language bindings were one of the main things
> we were really hoping to see come from the open source community, and
> we'd like to make sure this continues to be a really approachable thing.
> We wouldn't want developers to feel like their changes to Thrift won't
> be accepted without an up front investment of time building reputation
> in the Thrift community.
>
> I think reverting and reapplying these changes creates another risk.
> Developers would have incentive to keep some language-specific changes
> to themselves and not share them, simply because it would be more
> efficient, not because they are philosophically opposed to open source
> or sharing their changes at all.
>
> And to be quite frank, it feels very counterproductive to me to remove
> code from the project with full a priori intention of putting it back
> in. We'd rather focus on keeping development open and moving forwards.
> Removing people's code from the project could send an insulting and
> negative message.
>

I tend to agree with your observation. There have been donations in the past
that weren't completely clear in term of IP at the time the incubation
started and that have been cleared later on. IP cleanup is actually one of
the main purpose of the incubator. So I don't think this is a roadblock for
incubation even though it definitely is one for an official Apache release
and you'll need to clear up the remaining issues *before* being able to
release.

I would also advise the creation of a page somewhere listing the parts of
the code that have unclear IPs as well as their respective status for the
sake of transparency and to keep track of the evolution. If you already have
a good idea of what these parts are, maybe this could even be included in
the proposal?

Cheers,
Matthieu


> Cheers,
> Mark
>
> -----Original Message-----
> From: Martijn Dashorst [mailto:martijn.dashorst@gmail.com]
> Sent: Wednesday, January 30, 2008 10:39 AM
> To: general@incubator.apache.org
> Subject: Re: Re: [PROPOSAL] Thrift
>
> Perhaps in the interest of code audit (which needs to be done) and
> community building, the code parts of the missing committers should be
> removed from the code drop prior to incubation start, and be
> re-introduced inside the incubating podling by providing patches through
> bugzilla?
> Martijn
>
> On 1/30/08, David Reiss <dr...@facebook.com> wrote:
> >
> > > If there are people who have already proven their *merit* on the
> > > project that are not included on the initial list of committers then
>
> > > I think they should be.
> >
> > >  > In reality, many parts of the Thrift code base are already
> > > entirely  > owned by non-Facebook entities. The Cocoa, C#, Perl, and
>
> > > Smalltalk  > implementations for Thrift were all developed entirely
> > > outside of  > Facebook, and although Facebook still maintains the
> > > trunk, we defer  > review of all these patches to the developers
> > > working on those  > libraries.
> > >
> > > So are these people on the initial list of committers?
> >
> > Perl was contributed by Jake Luciani, who is a committer, but the
> > developers of the Cocoa, C#, and Smalltalk bindings are not.  These
> > bindings were submitted as a set of a few patches (or in some cases,
> > even a single large patch), and added to the tree without extensive
> > review because, quite frankly, no committers were qualified to review
> > them.  Because, as far as we know, the original contributors are the
> > only users of these bindings, we've just been blindly committing any
> > changes they make, so it would make sense for them to have commit
> > access to their parts of the project.  However, they have not been
> > active enough in the Thrift community to warrant the trust that comes
> > with full commit access.
> >
> > I would say that the requirements for a language-binding contributor
> > to become a committer would be some amount of activity on the mailing
> > list and either a significant review of the binding by a qualified
> > committer or a significant project using the binding.
> >
> > --David
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >
>
>
> --
> Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0 is
> released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

Re: [PROPOSAL] Thrift

[Martijn Dashorst <ma...@gmail.com>]

On 2/8/08, Ted Husted <hu...@apache.org> wrote:
> On that note, since there has been so discussion on this thread, I
> think it might be time to open another thread and formally decide
> whether to accept the Thrift proposal, which I will go do now.

That was my aim. I didn't want the proposal conclude with a long
winding discussion, but rather a closure towards a vote.

Martijn

-- 
Buy Wicket in Action: http://manning.com/dashorst
Apache Wicket 1.3.1 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.1

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [PROPOSAL] Thrift

[Ted Husted <hu...@apache.org>]

On that note, since there has been so discussion on this thread, I
think it might be time to open another thread and formally decide
whether to accept the Thrift proposal, which I will go do now.

-Ted.

On Feb 7, 2008 9:14 AM, Martijn Dashorst <ma...@gmail.com> wrote:
> +1 to Ted's message. I am not trying to sabotage the proposal, just
> trying to point out the potential problems you might run into during
> incubation/at graduation.
>
> IIUC, you can release code that is completely vetted, so if parts are
> still unvetted, it would not prevent you from releasing the checked
> bits. (As long as the non-covered code is not part of the release).
>
> The incubator is a place to learn the Apache way and clear any
> concerns that have been voiced. The burden is not when entering the
> incubator but in the incubating process, and I am sure  thrift will do
> great in the incubator, and become a great addition to the foundation.
>
> Martijn
>
> --
> Buy Wicket in Action: http://manning.com/dashorst
> Apache Wicket 1.3.0 is released
> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0
>
> ---------------------------------------------------------------------
>
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>



-- 
HTH, Ted
http://husted.com/ted/blog/

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [PROPOSAL] Thrift

[Martijn Dashorst <ma...@gmail.com>]

+1 to Ted's message. I am not trying to sabotage the proposal, just
trying to point out the potential problems you might run into during
incubation/at graduation.

IIUC, you can release code that is completely vetted, so if parts are
still unvetted, it would not prevent you from releasing the checked
bits. (As long as the non-covered code is not part of the release).

The incubator is a place to learn the Apache way and clear any
concerns that have been voiced. The burden is not when entering the
incubator but in the incubating process, and I am sure  thrift will do
great in the incubator, and become a great addition to the foundation.

Martijn

-- 
Buy Wicket in Action: http://manning.com/dashorst
Apache Wicket 1.3.0 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [PROPOSAL] Thrift

[Ted Husted <hu...@apache.org>]

Yes, there is a subtle disjoint or two. :)

Excluding patches that simply modify an existing artifact, we do need
licensing agreements from all individual contributors, regardless of
whether they become ASF committers or members of the podling PMC.
Otherwise, the ASF does not have clear title to the code, and anyone
who uses the code would be endangered.

It is not unusual for us to collect a licensing agreement from a
non-committer before accepting a non-trivial contribution, especially
if it is a new artifact. One reason that ASF projects are successful
is because people trust us to do the right thing when it comes to IP,
even if the right thing is the hard thing.

In order to establish an Apache account for someone, we also need
licensing agreements from the account owner (regardless of whether
they have made a past contribution). Everyone on the initial list of
podling committers will need an Apache account, and therefore must
file a CLA.

One fine point is that the initial list of  podling committers, in
practice, ultimately becomes the list of initial PMC members. Once the
project is up and running, individuals who are only interested in
maintaining one piece of code could be a committer, without
necessarily becoming a PMC member, if that individual was not
interesting in helping with project oversight.

Project karma is usually a "staged release", where someone is first a
contributor, and then a committer, and finally a PMC member. In
practice, moving through all the stages can take someone a year or
longer. Podlings are a special case, since everyone becomes a PMC
member all at once. (Which is why we need multiple mentors.)

Culturally, we tend to offer PMC membership to any committer who
demonstrates a persistent, welcome interest in the project, and we
share code ownership with all committers and  PMC members. Since all
project actions are utterly transparent, sharing code ownership is not
usually a problem, so long as other committers and PMC members
peer-review the commits list. (Trust but verify.)

The key cultural bias is toward collaboration, and her handmaidens,
equality and transparency.

Infrastructure can be a sticky wicket, since there is a bias toward
sharing all resources with all projects, in the same way we share code
with all committers. Before any technology is deployed as a ASF
resource, people want to be sure there is sufficient resources so that
it could be shared with all 50+ projects.

In the past, projects have introduced technologies by "voting with
their feet". For example, people started using JIRA offsite, and
ultimately, we obtained our own JIRA instance. The same thing happened
with Confluence.

Not too long ago, the rule would have been "Any SCM so long as its
CVS". Initially, we ran dual systems, but once most projects
voluntarily migrated, we pulled the CVS plug -- but only after most
projects had already voted with their feet.

It is a hard-and-fast rule that the source code, web site, and mailing
lists have to be kept here, since they are key material assets of the
foundation, and must be under the foundation's direct control. But,
third parties often contribute other technologies to the community
that live elsewhere, like mailing list archives, source code viewers,
continuous build systems, and so forth. svn-git, hosted elsewhere at
first, could be another one of those.

Some projects even have special "zones" here where people can
experiment with new services. (Though I believe that space is becoming
precious.)

There is someplace to go with git. It's not something that would be
made available on a production ASF server right away. But, it is
something Thrift could pursue once past incubation.

Thrift looks like an interesting product, and I'm looking forward to
trying it with my next project.

HTH, Ted.

On Feb 4, 2008 6:48 PM, Mark Slee <ms...@facebook.com> wrote:
> Well, note that this isn't strictly an IP issue. The issue here was the
> committers list, not the IP of the code. I don't see why all the code
> would need to be written by people on the initial committers list to
> pass IP restrictions.
>
> These two seem like disjoint issues to me. All code in the codebase
> today has been committed by an approved committer with the consent of
> the people providing the patches, so things should be consistent on the
> IP front.
>
> Cheers,
> Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

RE: [PROPOSAL] Thrift

[Upayavira <uv...@odoko.co.uk>]

On Mon, 2008-02-04 at 15:48 -0800, Mark Slee wrote:
> Well, note that this isn't strictly an IP issue. The issue here was the
> committers list, not the IP of the code. I don't see why all the code
> would need to be written by people on the initial committers list to
> pass IP restrictions.
> 
> These two seem like disjoint issues to me. All code in the codebase
> today has been committed by an approved committer with the consent of
> the people providing the patches, so things should be consistent on the
> IP front.

The point to make clear here, and where folks are coming from, is that
we will require an ICLA (individual committer license agreement) to be
signed by all people who have provided any significant code to the
codebase (beyond a couple of lines of code). We will need to identify
all of these codebases, and then systematically contact each of these
people asking them to sign and fax or email the document. Depending upon
the nature of the contributors/codebase, this can be quite a bit of
work.

However, I've been through the process before, and it is achievable.

I agree that the issue that you were referring to was something
different, however I hope this at least explains where people are coming
from with reference to IP clearance.

Regards, Upayavira



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

RE: [PROPOSAL] Thrift

[Mark Slee <ms...@facebook.com>]

Well, note that this isn't strictly an IP issue. The issue here was the
committers list, not the IP of the code. I don't see why all the code
would need to be written by people on the initial committers list to
pass IP restrictions.

These two seem like disjoint issues to me. All code in the codebase
today has been committed by an approved committer with the consent of
the people providing the patches, so things should be consistent on the
IP front.

Cheers,
Mark

-----Original Message-----
From: Martijn Dashorst [mailto:martijn.dashorst@gmail.com] 
Sent: Monday, February 04, 2008 5:32 AM
To: general@incubator.apache.org
Subject: Re: [PROPOSAL] Thrift

On 2/4/08, Andrus Adamchik <an...@objectstyle.org> wrote:
>
> Sorry, you are right. I just doublechecked Cayenne incubator release 
> history, and we did clear all our IP issues before posting the first 
> release. Anyways, throwing away the code just to *enter* the Incubator

> is neither required


True



> nor seems like a good approach.


I don't see it any different from starting an incubation with an empty
committers list where all committers need to gain karma, which is a
perfectly valid incubation strategy.

Starting with a clean slate code wise could be a strategy for
incubation, which will alleviate any code provenance issues, and
probably be a good starting point for a prosperous and healthy
community.

I'm not saying that thrift must do this, I just provide it as a viable
alternative.

Martijn

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [PROPOSAL] Thrift

[Martijn Dashorst <ma...@gmail.com>]

On 2/4/08, Andrus Adamchik <an...@objectstyle.org> wrote:
>
> Sorry, you are right. I just doublechecked Cayenne incubator release
> history, and we did clear all our IP issues before posting the first
> release. Anyways, throwing away the code just to *enter* the Incubator
> is neither required


True



> nor seems like a good approach.


I don't see it any different from starting an incubation with an empty
committers list where all committers need to gain karma, which is a
perfectly valid incubation strategy.

Starting with a clean slate code wise could be a strategy for incubation,
which will alleviate any code provenance issues, and probably be a good
starting point for a prosperous and healthy community.

I'm not saying that thrift must do this, I just provide it as a viable
alternative.

Martijn

Re: [PROPOSAL] Thrift

[Andrus Adamchik <an...@objectstyle.org>]

Sorry, you are right. I just doublechecked Cayenne incubator release  
history, and we did clear all our IP issues before posting the first  
release. Anyways, throwing away the code just to *enter* the Incubator  
is neither required nor seems like a good approach.

Andrus


On Feb 4, 2008, at 2:47 PM, Martijn Dashorst wrote:

> On 2/4/08, Andrus Adamchik <an...@objectstyle.org> wrote:
>>
>>> As long as you remember that you can't release or graduate
>> without properly
>>> audited code with a paper trail to the original author of the code.
>>
>> You can release from the incubator before all IP is cleared.
>
>
> No you can't: from the policy [1]:
>
> Podlings in Incubation SHALL NOT perform any releases of software  
> without
> the explicit approval of the Incubator PMC. Such approval SHALL be  
> given
> only after the Incubator PMC has followed the process detailed in  
> these
> guidelines, and SHALL NOT occur until all source has been legally
> transferred to the ASF.
>
> Martijn
>
> [1] http://incubator.apache.org/incubation/Incubation_Policy.html#Releases
>
> -- 
> Buy Wicket in Action: http://manning.com/dashorst
> Apache Wicket 1.3.0 is released
> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [PROPOSAL] Thrift

[Martijn Dashorst <ma...@gmail.com>]

On 2/4/08, Andrus Adamchik <an...@objectstyle.org> wrote:
>
> > As long as you remember that you can't release or graduate
> without properly
> > audited code with a paper trail to the original author of the code.
>
> You can release from the incubator before all IP is cleared.


No you can't: from the policy [1]:

Podlings in Incubation SHALL NOT perform any releases of software without
the explicit approval of the Incubator PMC. Such approval SHALL be given
only after the Incubator PMC has followed the process detailed in these
guidelines, and SHALL NOT occur until all source has been legally
transferred to the ASF.

Martijn

[1] http://incubator.apache.org/incubation/Incubation_Policy.html#Releases

-- 
Buy Wicket in Action: http://manning.com/dashorst
Apache Wicket 1.3.0 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0

Re: [PROPOSAL] Thrift

[Craig L Russell <Cr...@Sun.COM>]

On Feb 4, 2008, at 3:41 AM, Andrus Adamchik wrote:

>
> On Feb 4, 2008, at 1:15 PM, Martijn Dashorst wrote:
>
>>>
>>> And to be quite frank, it feels very counterproductive to me to  
>>> remove
>>> code from the project with full a priori intention of putting it  
>>> back
>>> in.
>>
>>
>> Are you sure you will get the appropriate ICLA's from all the  
>> authors that
>> have contributed to the whole code base?
>
> I am with Mark - it is counterproductive to throw away code now. Go  
> in to the incubator with all your existing code base, and work on  
> getting all missing CLA's. That's what incubation is for. At the  
> end, even if you fail to clear some pieces, you'll have a hopefully  
> much smaller scope of the code to rewrite/replace.
>
>> As long as you remember that you can't release or graduate without  
>> properly
>> audited code with a paper trail to the original author of the code.
>
> You can release from the incubator before all IP is cleared.

Whoa. This may be a typo but it is *not* as I understand it.

My understanding is that *no* code can be released from Apache  
(including the incubator) without IP clearance.

Craig
>
>
> Andrus
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!

Re: [PROPOSAL] Thrift

[Andrus Adamchik <an...@objectstyle.org>]

On Feb 4, 2008, at 1:15 PM, Martijn Dashorst wrote:

>>
>> And to be quite frank, it feels very counterproductive to me to  
>> remove
>> code from the project with full a priori intention of putting it back
>> in.
>
>
> Are you sure you will get the appropriate ICLA's from all the  
> authors that
> have contributed to the whole code base?

I am with Mark - it is counterproductive to throw away code now. Go in  
to the incubator with all your existing code base, and work on getting  
all missing CLA's. That's what incubation is for. At the end, even if  
you fail to clear some pieces, you'll have a hopefully much smaller  
scope of the code to rewrite/replace.

> As long as you remember that you can't release or graduate without  
> properly
> audited code with a paper trail to the original author of the code.

You can release from the incubator before all IP is cleared.

Andrus

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Re: [PROPOSAL] Thrift

[Martijn Dashorst <ma...@gmail.com>]

On 2/1/08, Mark Slee <ms...@facebook.com> wrote:
>
> However, dropping parts of the code feels counterproductive to me, as I
> think it might put up a perceived barrier to collaboration with the
> Thrift project.


As long as you remember that you can't release or graduate without properly
audited code with a paper trail to the original author of the code.

We wouldn't want developers to feel like their changes to Thrift won't

be accepted without an up front investment of time building reputation
> in the Thrift community.


You need a paper trail, and you need people to maintain said code. Dropping
code into a project is not the same as "creating a community", which is what
Apache is about. Dropping code is something one can do very well at google
code, or sourceforge. When you accept a code drop without getting the
developer to maintain it, does it really help your community? Are the
current active developers going to maintain a code base in a language that
is not familiar to them?

Also note that in order for the ASF to provide legal protection to the
contributors, the code needs to be sound.

I think reverting and reapplying these changes creates another risk.
> Developers would have incentive to keep some language-specific changes
> to themselves and not share them, simply because it would be more
> efficient, not because they are philosophically opposed to open source
> or sharing their changes at all.


I don't understand what you are trying to say here. How does including the
code a priori make it any different? When they want to contribute changes,
they still need to go through proper channels: provide an ICLA, code grant
or patch through JIRA/bugzilla with the proper annotation.


> And to be quite frank, it feels very counterproductive to me to remove
> code from the project with full a priori intention of putting it back
> in.


Are you sure you will get the appropriate ICLA's from all the authors that
have contributed to the whole code base?

We'd rather focus on keeping development open and moving forwards.
> Removing people's code from the project could send an insulting and
> negative message.


You will not be able to graduate or release if not all code is accounted
for. That is just the way it works. Either get the appropriate documentation
(ICLA, code grant) from the contributors, strip the offending code or
rewrite the offending code (ensuring the proper licensing).

I am not sure how not including a code base without a proper licensing
history would be considered insulting though.

Martijn

RE: Re: [PROPOSAL] Thrift

[Mark Slee <ms...@facebook.com>]

Following up on what David sent out yesterday, I think we're all on
board with having a single committers pool based upon mutual trust and
respect.

However, dropping parts of the code feels counterproductive to me, as I
think it might put up a perceived barrier to collaboration with the
Thrift project. Alternate language bindings were one of the main things
we were really hoping to see come from the open source community, and
we'd like to make sure this continues to be a really approachable thing.
We wouldn't want developers to feel like their changes to Thrift won't
be accepted without an up front investment of time building reputation
in the Thrift community.

I think reverting and reapplying these changes creates another risk.
Developers would have incentive to keep some language-specific changes
to themselves and not share them, simply because it would be more
efficient, not because they are philosophically opposed to open source
or sharing their changes at all.

And to be quite frank, it feels very counterproductive to me to remove
code from the project with full a priori intention of putting it back
in. We'd rather focus on keeping development open and moving forwards.
Removing people's code from the project could send an insulting and
negative message.

Cheers,
Mark

-----Original Message-----
From: Martijn Dashorst [mailto:martijn.dashorst@gmail.com] 
Sent: Wednesday, January 30, 2008 10:39 AM
To: general@incubator.apache.org
Subject: Re: Re: [PROPOSAL] Thrift

Perhaps in the interest of code audit (which needs to be done) and
community building, the code parts of the missing committers should be
removed from the code drop prior to incubation start, and be
re-introduced inside the incubating podling by providing patches through
bugzilla?
Martijn

On 1/30/08, David Reiss <dr...@facebook.com> wrote:
>
> > If there are people who have already proven their *merit* on the 
> > project that are not included on the initial list of committers then

> > I think they should be.
>
> >  > In reality, many parts of the Thrift code base are already 
> > entirely  > owned by non-Facebook entities. The Cocoa, C#, Perl, and

> > Smalltalk  > implementations for Thrift were all developed entirely 
> > outside of  > Facebook, and although Facebook still maintains the 
> > trunk, we defer  > review of all these patches to the developers 
> > working on those  > libraries.
> >
> > So are these people on the initial list of committers?
>
> Perl was contributed by Jake Luciani, who is a committer, but the 
> developers of the Cocoa, C#, and Smalltalk bindings are not.  These 
> bindings were submitted as a set of a few patches (or in some cases, 
> even a single large patch), and added to the tree without extensive 
> review because, quite frankly, no committers were qualified to review 
> them.  Because, as far as we know, the original contributors are the 
> only users of these bindings, we've just been blindly committing any 
> changes they make, so it would make sense for them to have commit 
> access to their parts of the project.  However, they have not been 
> active enough in the Thrift community to warrant the trust that comes 
> with full commit access.
>
> I would say that the requirements for a language-binding contributor 
> to become a committer would be some amount of activity on the mailing 
> list and either a significant review of the binding by a qualified 
> committer or a significant project using the binding.
>
> --David
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>


--
Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0 is
released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Re: [PROPOSAL] Thrift

[Martijn Dashorst <ma...@gmail.com>]

Perhaps in the interest of code audit (which needs to be done) and community
building, the code parts of the missing committers should be removed from
the code drop prior to incubation start, and be re-introduced inside the
incubating podling by providing patches through bugzilla?
Martijn

On 1/30/08, David Reiss <dr...@facebook.com> wrote:
>
> > If there are people who have already proven their *merit* on the
> > project that are not included on the initial list of committers then I
> > think they should be.
>
> >  > In reality, many parts of the Thrift code base are already entirely
> >  > owned by non-Facebook entities. The Cocoa, C#, Perl, and Smalltalk
> >  > implementations for Thrift were all developed entirely outside of
> >  > Facebook, and although Facebook still maintains the trunk, we defer
> >  > review of all these patches to the developers working on those
> >  > libraries.
> >
> > So are these people on the initial list of committers?
>
> Perl was contributed by Jake Luciani, who is a committer, but the
> developers
> of the Cocoa, C#, and Smalltalk bindings are not.  These bindings were
> submitted as a set of a few patches (or in some cases, even a single large
> patch), and added to the tree without extensive review because, quite
> frankly,
> no committers were qualified to review them.  Because, as far as we know,
> the
> original contributors are the only users of these bindings, we've just
> been
> blindly committing any changes they make, so it would make sense for them
> to
> have commit access to their parts of the project.  However, they have not
> been
> active enough in the Thrift community to warrant the trust that comes with
> full commit access.
>
> I would say that the requirements for a language-binding contributor to
> become
> a committer would be some amount of activity on the mailing list and
> either a
> significant review of the binding by a qualified committer or a
> significant
> project using the binding.
>
> --David
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>


-- 
Buy Wicket in Action: http://manning.com/dashorst
Apache Wicket 1.3.0 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0

Re: Re: [PROPOSAL] Thrift

[David Reiss <dr...@facebook.com>]

> If there are people who have already proven their *merit* on the
> project that are not included on the initial list of committers then I
> think they should be.

>  > In reality, many parts of the Thrift code base are already entirely
>  > owned by non-Facebook entities. The Cocoa, C#, Perl, and Smalltalk
>  > implementations for Thrift were all developed entirely outside of
>  > Facebook, and although Facebook still maintains the trunk, we defer
>  > review of all these patches to the developers working on those
>  > libraries.
> 
> So are these people on the initial list of committers?

Perl was contributed by Jake Luciani, who is a committer, but the developers 
of the Cocoa, C#, and Smalltalk bindings are not.  These bindings were 
submitted as a set of a few patches (or in some cases, even a single large 
patch), and added to the tree without extensive review because, quite frankly, 
no committers were qualified to review them.  Because, as far as we know, the 
original contributors are the only users of these bindings, we've just been 
blindly committing any changes they make, so it would make sense for them to 
have commit access to their parts of the project.  However, they have not been 
active enough in the Thrift community to warrant the trust that comes with 
full commit access.

I would say that the requirements for a language-binding contributor to become 
a committer would be some amount of activity on the mailing list and either a 
significant review of the binding by a qualified committer or a significant 
project using the binding.

--David

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [PROPOSAL] Thrift

[Niall Pemberton <ni...@gmail.com>]

On Jan 30, 2008 7:24 AM, Mark Slee <ms...@facebook.com> wrote:
> Hi Martin,
>
> *If I look at the initial committers list, I see a big portion to be
> facebook developers. During incubation you should work on diversifying.*
>
> *Again, it seems like a huge contingent of facebook developers. You
> really should work on diversification during incubation.*
>
> Points well taken. We actually have a much bigger list of developers who
> have contributed significant patches to Thrift. The issue, as Upayavira
> pointed out in his other email, is that Thrift is a project spanning
> many programming languages but striving to make them all work together
> seamlessly. The result is that we have many developers familiar with
> particular language implementations, but not others. What we'd really
> like to set up here is a system where there are different people with
> committer priveleges to different parts of the project. It's really an
> interesting community dynamic... over time (already in fact) *no one*
> will really understand all the Thrift codebase. So what we'd like to
> develop is a community where people may become experts in some languages
> and have committer priveleges there but not universally. We erred on the
> side of having the initial committer list be shorter at first, as we'd
> have to figure out how exactly to structure a partitioned commiters
> system in the Apache environment.

If there are people who have already proven their *merit* on the
project that are not included on the initial list of committers then I
think they should be. My guess is that diversity is going to be a
bigger issue for you than any code *partitioning* and facebook is
going to loose the control its had here at Apache - so you may as well
take the plunge from the start. I believe those people and the Thrift
community will benefit greatly from having them involved from the
outset.

> In reality, many parts of the Thrift code base are already entirely
> owned by non-Facebook entities. The Cocoa, C#, Perl, and Smalltalk
> implementations for Thrift were all developed entirely outside of
> Facebook, and although Facebook still maintains the trunk, we defer
> review of all these patches to the developers working on those
> libraries.

So are these people on the initial list of committers?

> In another case, the Ruby implementation was initially done
> at Facebook, but we have passed de facto ownership to Powerset after
> some great patches from Kevin Clark which really improved the
> implementation. We now also defer all Ruby code reviews, and if we had
> the partioned committers system in place already I wouldn't even
> recommend any Facebook developers (myself included) as initial
> committers for the Ruby codebase.
>
> So... that's a lot of rambling, but it's sort of a unique committers
> situation. Interested to hear if there are other projects that have had
> this sort of setup.
>
> *Hmm, hosting at googlecode, or sourceforge would statisfy that as well.
> So why does the project want to join Apache specifically?*
>
> One big reason is that we think this project could provide a lot of
> utility for many other Apache projects. Having Thrift in Apache, closer
> to other similar projects, should mean less obstacles to a clean
> integration, more communication and input into the different use cases,
> feature prioritization, and hopefully some development collaboration as
> well.
>
> *What is the affiliation of Jake Luciani?*
>
> Jake runs a website http://www.junkdepot.com/ and has also independently
> developed some open source applications built on top of Thrift,
> available at:
> http://code.google.com/p/thrudb/
>
> This has also now been picked up by Ross McFarland, who's working on a
> ThruDB-based document store:
> http://diststore.com/
>
> So... already we're seeing a cool open source mini-ecosystem develop
> about Thrift. Facebook also plans to open source Scribe, a distributed
> logging framework built on Thrift. If accepted into Apache, we'd likely
> also include Scribe as a sub-project or contrib submission to Thrift.
> We'd be interested to hear if that'd be appropriate or what the general
> approach is to subprojects or non-core addons.
>
> Cheers,
> Mark
>
> -----Original Message-----
> From: Martijn Dashorst [mailto:martijn.dashorst@gmail.com]
> Sent: Tuesday, January 29, 2008 1:34 AM
> To: general@incubator.apache.org
> Cc: thrift@publists.facebook.com
>
> Subject: Re: [PROPOSAL] Thrift
>
> On 1/24/08, Mark Slee <ms...@facebook.com> wrote:
> >
> > === Core Developers ===
> > Thrift currently has developers across many organizations (e.g.
> > Facebook, Powerset, ReCaptcha, AmieStreet), many of whom are
> > contributors to other open source projects.
>
>
> If I look at the initial committers list, I see a big portion to be
> facebook developers. During incubation you should work on diversifying.
>
> Part of the reason to join Apache is
> > to make the project work even better as open source by removing some
> > obstacles, such as Facebook hosting the SVN, and putting the resources
>
> > all in a truly open space, being able to have more committers, etc.
> > Most of the core developers have a history of working with open source
> tools.
>
>
> Hmm, hosting at googlecode, or sourceforge would statisfy that as well.
> So why does the project want to join Apache specifically?
>
> === Homogenous Developers ===
> > The current set of developers work across a variety of organizations.
> > Naturally, most are websites with significant backend structure (and
> > hence a need for Thrift), but the problems they are solving are
> > diverse, and many don't work in the same programming languages.
>
>
> Again, it seems like a huge contingent of facebook developers. You
> really should work on diversification during incubation.
>
>
>
> === Subversion Directory ===
> > https://svn.apache.org/repos/asf/incubator/thrift
> >
> > We'd also be interested in using git to store the repo. Does apache
> > have infrastucture set up to support that? It'd make it easier for
> > non-committer developers to work on patches, checkpoint commits, etc.
>
>
> There is no current infrastructure for this available. There has been an
> experiment done by the Maven devs, but I'm out of touch with its status.
>
> == Initial Committers ==
> > * Mark Slee (mcslee at facebook dot com)
> > * Aditya Agarwal (aditya at facebook dot com)
> > * Marc Kwiatkowski (marc at facebook dot com)
> > * David Reiss (david at facebook dot com)
> > * James Wang (jwang at facebook dot com)
> > * Chris Piro (cpiro at facebook dot com)
> > * Ben Maurer (bmaurer at andrew dot cmu dot edu)
> > * Kevin Clark (kevin at powerset dot com)
> > * Jake Luciani (jakers at gmail dot com)
>
>
> == Affiliations ==
> > * People with Facebook email addresses - Facebook
> > * Ben Maurer - ReCaptcha
> > * Kevin Clark - Powerset
>
>
> What is the affiliation of Jake Luciani?
>
> === Mentors ===
> > * Paul Querna
> > * Upayavira
>
>
> I think you need one more mentor, but (s)he may present her/himself
> during the vote for the proposal.
>
>
> Martijn
>
> --
> Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0 is
> released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [PROPOSAL] Thrift

[Paul Fremantle <pz...@gmail.com>]

Niclas

I also had exactly the same thoughts on reading the email. I think
learning that committership is a position of trust is a key part of
the incubation process.

So I'm +1 on the proposal, but I would definitely be -1 on graduation
if such a scheme were to be implemented during incubation.

Paul

On Jan 30, 2008 9:35 AM, Niclas Hedhman <ni...@hedhman.org> wrote:
> On Wednesday 30 January 2008 15:24, Mark Slee wrote:
> > What we'd really
> > like to set up here is a system where there are different people with
> > committer priveleges to different parts of the project.
>
> Hmmm... I would oppose this for two reasons;
>
>  1. Creating boundaries within a project, yet collaborate on the PMC level
> seems odd to me. Either people are entrusted within the project (committer
> rights) or they are not (no committer rights). If you think that a Thrift
> Java programmer will mess up the Ruby Thrift code, then you have bigger
> problems to deal with, IMHO.
>
>  2. Some people will eventually become fluent in more than one of these. Are
> you now going to start a VOTE on granting access to such member to another
> part of the project? Who is to decide that? The people involved in that
> language only or the whole PMC (ignoring for a fact that ASF has rules for
> this)? I can't see it work in practice.
>
> So if you drop that idea, I can vote in favour of incubating this project.
>
>
> Cheers
> --
> Niclas Hedhman, Software Developer
>
> I  live here; http://tinyurl.com/2qq9er
> I  work here; http://tinyurl.com/2ymelc
> I relax here; http://tinyurl.com/2cgsug
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>



-- 
Paul Fremantle
Co-Founder and VP of Technical Sales, WSO2
OASIS WS-RX TC Co-chair

blog: http://pzf.fremantle.org
paul@wso2.com

"Oxygenating the Web Service Platform", www.wso2.com

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [PROPOSAL] Thrift

[Niclas Hedhman <ni...@hedhman.org>]

On Wednesday 30 January 2008 19:30, Erik Abele wrote:
> In the end they are here to learn The A Way and if it turns out to be  
> a problem then they won't be able to graduate so I think it's  
> premature to turn down the proposal just because of this.

Correct, but putting it in place increases the burden on the Mentors.


Cheers
-- 
Niclas Hedhman, Software Developer

I  live here; http://tinyurl.com/2qq9er
I  work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [PROPOSAL] Thrift

[Erik Abele <er...@codefaktor.de>]

On 30.01.2008, at 10:35, Niclas Hedhman wrote:

> On Wednesday 30 January 2008 15:24, Mark Slee wrote:
>> What we'd really
>> like to set up here is a system where there are different people with
>> committer priveleges to different parts of the project.
>
> Hmmm... I would oppose this for two reasons;
>
>  1. Creating boundaries within a project, yet collaborate on the  
> PMC level
> seems odd to me. Either people are entrusted within the project  
> (committer
> rights) or they are not (no committer rights). If you think that a  
> Thrift
> Java programmer will mess up the Ruby Thrift code, then you have  
> bigger
> problems to deal with, IMHO.
>
>  2. Some people will eventually become fluent in more than one of  
> these. Are
> you now going to start a VOTE on granting access to such member to  
> another
> part of the project? Who is to decide that? The people involved in  
> that
> language only or the whole PMC (ignoring for a fact that ASF has  
> rules for
> this)? I can't see it work in practice.

We already have something like this in place for other projects; e.g.  
in HTTPD we sometimes give only access to the docs or specific module  
sub-trees instead of the whole codebase and the same is done with log4 
(j|net|php|cxx) and lucene-(java|net|c)...

I agree that it's not the optimal way to do things and that trust  
should be enough to manage it, but OTOH I don't see it as a real  
obstacle which would warrant a -1 for incubation. Partioning _can_  
make sense and might prove useful if the committership is growing  
quickly...

In the end they are here to learn The A Way and if it turns out to be  
a problem then they won't be able to graduate so I think it's  
premature to turn down the proposal just because of this.

Cheers,
Erik

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [PROPOSAL] Thrift

[Simon Kitching <sk...@ops.co.at>]

Niclas Hedhman schrieb:
> On Wednesday 30 January 2008 15:24, Mark Slee wrote:
>   
>> What we'd really
>> like to set up here is a system where there are different people with
>> committer priveleges to different parts of the project.
>>     
>
> Hmmm... I would oppose this for two reasons;
>
>  1. Creating boundaries within a project, yet collaborate on the PMC level 
> seems odd to me. Either people are entrusted within the project (committer 
> rights) or they are not (no committer rights). If you think that a Thrift 
> Java programmer will mess up the Ruby Thrift code, then you have bigger 
> problems to deal with, IMHO.
>
>  2. Some people will eventually become fluent in more than one of these. Are 
> you now going to start a VOTE on granting access to such member to another 
> part of the project? Who is to decide that? The people involved in that 
> language only or the whole PMC (ignoring for a fact that ASF has rules for 
> this)? I can't see it work in practice.
>
> So if you drop that idea, I can vote in favour of incubating this project.
>   

And I would second that.

In the Apache Jakarta project, there were initally access rights
per-project. Later these were abolished (except for one project which
needed "clean room" type development for legal reasons). There was never
a problem with people committing to stuff that they weren't "allowed"
to, and it cleared away a lot of red tape. A simple convention of
*asking* before committing to a new area was sufficient.

Regards, SImon


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [PROPOSAL] Thrift

[Niclas Hedhman <ni...@hedhman.org>]

On Wednesday 30 January 2008 15:24, Mark Slee wrote:
> What we'd really
> like to set up here is a system where there are different people with
> committer priveleges to different parts of the project.

Hmmm... I would oppose this for two reasons;

 1. Creating boundaries within a project, yet collaborate on the PMC level 
seems odd to me. Either people are entrusted within the project (committer 
rights) or they are not (no committer rights). If you think that a Thrift 
Java programmer will mess up the Ruby Thrift code, then you have bigger 
problems to deal with, IMHO.

 2. Some people will eventually become fluent in more than one of these. Are 
you now going to start a VOTE on granting access to such member to another 
part of the project? Who is to decide that? The people involved in that 
language only or the whole PMC (ignoring for a fact that ASF has rules for 
this)? I can't see it work in practice.

So if you drop that idea, I can vote in favour of incubating this project.


Cheers
-- 
Niclas Hedhman, Software Developer

I  live here; http://tinyurl.com/2qq9er
I  work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [Thrift] RE: [PROPOSAL] Thrift

[Jim Jagielski <ji...@jaguNET.com>]

On Jan 30, 2008, at 5:55 AM, Upayavira wrote:
>
> As you can see from other proposals, I think you'll find it work  
> better
> with a single committer pool. As others have said, I personally have
> never seen a problem with this approach - people steer away from code
> that they are unfamiliar with, or tend to ask permission before
> wandering that way. So, so while separating committerships might sound
> useful, I don't think it is really necessary.
>

++1... In fact, I would almost consider this a deal-breaker
for incubation.

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [Thrift] RE: [PROPOSAL] Thrift

[Upayavira <uv...@odoko.co.uk>]

On Wed, 2008-01-30 at 11:50 -0500, Ben Maurer wrote:
> On Wed, 30 Jan 2008, Upayavira wrote:
> > As you can see from other proposals, I think you'll find it work better
> > with a single committer pool. As others have said, I personally have
> > never seen a problem with this approach - people steer away from code
> > that they are unfamiliar with, or tend to ask permission before
> > wandering that way. So, so while separating committerships might sound
> > useful, I don't think it is really necessary.
> >
> > "Control" of codebases works best in Apache when it is done through
> > human respect rather than access rights - in the end, the whole project
> > management committee (which is made up of all or some committers, plus
> > mentors during incubation) is responsible for the whole codebase.
> 
> +1 for this. Having "committer" access does not mean "unilateral 
> permission to check in new code". I think that Thrift is going to need a 
> code review model that is more strict than projects of a similar age -- 
> Thrift is so essential for a number of people's production infratructure 
> that having many eyes look over patches is important.
> 
> People given commit access should be trusted to be reasonable with the 
> power they have been granted. If this level of trust isn't present, then 
> they shouldn't have ANY commit access.

Exactly.

> In regards to too many Facebook developers -- I don't think this is a huge 
> issue at this point. What is most important is that the folks at Facebook 
> are open about contributions they make and that they treat non-Facebook 
> developers equally. I think that this is already happening, and that the 
> Facebook developers are committed to making this a ture community project.

The issue is a graduation issue. Thrift won't graduate with a
preponderance of Facebook committers - it needs to be a sufficient
balance of folks such that, even if Facebook pulled out of development,
Thrift would survive. Also, there needs to be sufficient non-Facebook
developers such that, should (heaven forbid) Facebook try to subvert the
project, there are sufficient developers to prevent this.

Of course, this concern applies to all companies, and is not specific to
Facebook.

Regards, Upayavira



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [Thrift] RE: [PROPOSAL] Thrift

[Ben Maurer <bm...@andrew.cmu.edu>]

On Wed, 30 Jan 2008, Upayavira wrote:
> As you can see from other proposals, I think you'll find it work better
> with a single committer pool. As others have said, I personally have
> never seen a problem with this approach - people steer away from code
> that they are unfamiliar with, or tend to ask permission before
> wandering that way. So, so while separating committerships might sound
> useful, I don't think it is really necessary.
>
> "Control" of codebases works best in Apache when it is done through
> human respect rather than access rights - in the end, the whole project
> management committee (which is made up of all or some committers, plus
> mentors during incubation) is responsible for the whole codebase.

+1 for this. Having "committer" access does not mean "unilateral 
permission to check in new code". I think that Thrift is going to need a 
code review model that is more strict than projects of a similar age -- 
Thrift is so essential for a number of people's production infratructure 
that having many eyes look over patches is important.

People given commit access should be trusted to be reasonable with the 
power they have been granted. If this level of trust isn't present, then 
they shouldn't have ANY commit access.

In regards to too many Facebook developers -- I don't think this is a huge 
issue at this point. What is most important is that the folks at Facebook 
are open about contributions they make and that they treat non-Facebook 
developers equally. I think that this is already happening, and that the 
Facebook developers are committed to making this a ture community project.

- Ben

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [Thrift] RE: [PROPOSAL] Thrift

[Upayavira <uv...@odoko.co.uk>]

On Tue, 2008-01-29 at 23:24 -0800, Mark Slee wrote:
> Hi Martin,
> 
> *If I look at the initial committers list, I see a big portion to be
> facebook developers. During incubation you should work on diversifying.*
> 
> *Again, it seems like a huge contingent of facebook developers. You
> really should work on diversification during incubation.*
> 
> Points well taken. We actually have a much bigger list of developers who
> have contributed significant patches to Thrift. The issue, as Upayavira
> pointed out in his other email, is that Thrift is a project spanning
> many programming languages but striving to make them all work together
> seamlessly. The result is that we have many developers familiar with
> particular language implementations, but not others. What we'd really
> like to set up here is a system where there are different people with
> committer priveleges to different parts of the project. It's really an
> interesting community dynamic... over time (already in fact) *no one*
> will really understand all the Thrift codebase. So what we'd like to
> develop is a community where people may become experts in some languages
> and have committer priveleges there but not universally. We erred on the
> side of having the initial committer list be shorter at first, as we'd
> have to figure out how exactly to structure a partitioned commiters
> system in the Apache environment.
> 
> In reality, many parts of the Thrift code base are already entirely
> owned by non-Facebook entities. The Cocoa, C#, Perl, and Smalltalk
> implementations for Thrift were all developed entirely outside of
> Facebook, and although Facebook still maintains the trunk, we defer
> review of all these patches to the developers working on those
> libraries. In another case, the Ruby implementation was initially done
> at Facebook, but we have passed de facto ownership to Powerset after
> some great patches from Kevin Clark which really improved the
> implementation. We now also defer all Ruby code reviews, and if we had
> the partioned committers system in place already I wouldn't even
> recommend any Facebook developers (myself included) as initial
> committers for the Ruby codebase.
> 
> So... that's a lot of rambling, but it's sort of a unique committers
> situation. Interested to hear if there are other projects that have had
> this sort of setup.
> 
> *Hmm, hosting at googlecode, or sourceforge would statisfy that as well.
> So why does the project want to join Apache specifically?*
> 
> One big reason is that we think this project could provide a lot of
> utility for many other Apache projects. Having Thrift in Apache, closer
> to other similar projects, should mean less obstacles to a clean
> integration, more communication and input into the different use cases,
> feature prioritization, and hopefully some development collaboration as
> well.
> 
> *What is the affiliation of Jake Luciani?*
> 
> Jake runs a website http://www.junkdepot.com/ and has also independently
> developed some open source applications built on top of Thrift,
> available at:
> http://code.google.com/p/thrudb/
> 
> This has also now been picked up by Ross McFarland, who's working on a
> ThruDB-based document store:
> http://diststore.com/
> 
> So... already we're seeing a cool open source mini-ecosystem develop
> about Thrift. Facebook also plans to open source Scribe, a distributed
> logging framework built on Thrift. If accepted into Apache, we'd likely
> also include Scribe as a sub-project or contrib submission to Thrift.
> We'd be interested to hear if that'd be appropriate or what the general
> approach is to subprojects or non-core addons.

As you can see from other proposals, I think you'll find it work better
with a single committer pool. As others have said, I personally have
never seen a problem with this approach - people steer away from code
that they are unfamiliar with, or tend to ask permission before
wandering that way. So, so while separating committerships might sound
useful, I don't think it is really necessary. 

"Control" of codebases works best in Apache when it is done through
human respect rather than access rights - in the end, the whole project
management committee (which is made up of all or some committers, plus
mentors during incubation) is responsible for the whole codebase.

Regards, Upayavira



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

RE: [PROPOSAL] Thrift

[Mark Slee <ms...@facebook.com>]

Hi Martin,

*If I look at the initial committers list, I see a big portion to be
facebook developers. During incubation you should work on diversifying.*

*Again, it seems like a huge contingent of facebook developers. You
really should work on diversification during incubation.*

Points well taken. We actually have a much bigger list of developers who
have contributed significant patches to Thrift. The issue, as Upayavira
pointed out in his other email, is that Thrift is a project spanning
many programming languages but striving to make them all work together
seamlessly. The result is that we have many developers familiar with
particular language implementations, but not others. What we'd really
like to set up here is a system where there are different people with
committer priveleges to different parts of the project. It's really an
interesting community dynamic... over time (already in fact) *no one*
will really understand all the Thrift codebase. So what we'd like to
develop is a community where people may become experts in some languages
and have committer priveleges there but not universally. We erred on the
side of having the initial committer list be shorter at first, as we'd
have to figure out how exactly to structure a partitioned commiters
system in the Apache environment.

In reality, many parts of the Thrift code base are already entirely
owned by non-Facebook entities. The Cocoa, C#, Perl, and Smalltalk
implementations for Thrift were all developed entirely outside of
Facebook, and although Facebook still maintains the trunk, we defer
review of all these patches to the developers working on those
libraries. In another case, the Ruby implementation was initially done
at Facebook, but we have passed de facto ownership to Powerset after
some great patches from Kevin Clark which really improved the
implementation. We now also defer all Ruby code reviews, and if we had
the partioned committers system in place already I wouldn't even
recommend any Facebook developers (myself included) as initial
committers for the Ruby codebase.

So... that's a lot of rambling, but it's sort of a unique committers
situation. Interested to hear if there are other projects that have had
this sort of setup.

*Hmm, hosting at googlecode, or sourceforge would statisfy that as well.
So why does the project want to join Apache specifically?*

One big reason is that we think this project could provide a lot of
utility for many other Apache projects. Having Thrift in Apache, closer
to other similar projects, should mean less obstacles to a clean
integration, more communication and input into the different use cases,
feature prioritization, and hopefully some development collaboration as
well.

*What is the affiliation of Jake Luciani?*

Jake runs a website http://www.junkdepot.com/ and has also independently
developed some open source applications built on top of Thrift,
available at:
http://code.google.com/p/thrudb/

This has also now been picked up by Ross McFarland, who's working on a
ThruDB-based document store:
http://diststore.com/

So... already we're seeing a cool open source mini-ecosystem develop
about Thrift. Facebook also plans to open source Scribe, a distributed
logging framework built on Thrift. If accepted into Apache, we'd likely
also include Scribe as a sub-project or contrib submission to Thrift.
We'd be interested to hear if that'd be appropriate or what the general
approach is to subprojects or non-core addons.

Cheers,
Mark

-----Original Message-----
From: Martijn Dashorst [mailto:martijn.dashorst@gmail.com] 
Sent: Tuesday, January 29, 2008 1:34 AM
To: general@incubator.apache.org
Cc: thrift@publists.facebook.com
Subject: Re: [PROPOSAL] Thrift

On 1/24/08, Mark Slee <ms...@facebook.com> wrote:
>
> === Core Developers ===
> Thrift currently has developers across many organizations (e.g.
> Facebook, Powerset, ReCaptcha, AmieStreet), many of whom are 
> contributors to other open source projects.


If I look at the initial committers list, I see a big portion to be
facebook developers. During incubation you should work on diversifying.

Part of the reason to join Apache is
> to make the project work even better as open source by removing some 
> obstacles, such as Facebook hosting the SVN, and putting the resources

> all in a truly open space, being able to have more committers, etc. 
> Most of the core developers have a history of working with open source
tools.


Hmm, hosting at googlecode, or sourceforge would statisfy that as well.
So why does the project want to join Apache specifically?

=== Homogenous Developers ===
> The current set of developers work across a variety of organizations.
> Naturally, most are websites with significant backend structure (and 
> hence a need for Thrift), but the problems they are solving are 
> diverse, and many don't work in the same programming languages.


Again, it seems like a huge contingent of facebook developers. You
really should work on diversification during incubation.



=== Subversion Directory ===
> https://svn.apache.org/repos/asf/incubator/thrift
>
> We'd also be interested in using git to store the repo. Does apache 
> have infrastucture set up to support that? It'd make it easier for 
> non-committer developers to work on patches, checkpoint commits, etc.


There is no current infrastructure for this available. There has been an
experiment done by the Maven devs, but I'm out of touch with its status.

== Initial Committers ==
> * Mark Slee (mcslee at facebook dot com)
> * Aditya Agarwal (aditya at facebook dot com)
> * Marc Kwiatkowski (marc at facebook dot com)
> * David Reiss (david at facebook dot com)
> * James Wang (jwang at facebook dot com)
> * Chris Piro (cpiro at facebook dot com)
> * Ben Maurer (bmaurer at andrew dot cmu dot edu)
> * Kevin Clark (kevin at powerset dot com)
> * Jake Luciani (jakers at gmail dot com)


== Affiliations ==
> * People with Facebook email addresses - Facebook
> * Ben Maurer - ReCaptcha
> * Kevin Clark - Powerset


What is the affiliation of Jake Luciani?

=== Mentors ===
> * Paul Querna
> * Upayavira


I think you need one more mentor, but (s)he may present her/himself
during the vote for the proposal.


Martijn

--
Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0 is
released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [PROPOSAL] Thrift

[Martijn Dashorst <ma...@gmail.com>]

On 1/24/08, Mark Slee <ms...@facebook.com> wrote:
>
> === Core Developers ===
> Thrift currently has developers across many organizations (e.g.
> Facebook, Powerset, ReCaptcha, AmieStreet), many of whom are
> contributors to other open source projects.


If I look at the initial committers list, I see a big portion to be facebook
developers. During incubation you should work on diversifying.

Part of the reason to join Apache is
> to make the project work even better as open source by removing some
> obstacles, such as Facebook hosting the SVN, and putting the resources
> all in a truly open space, being able to have more committers, etc. Most
> of the core developers have a history of working with open source tools.


Hmm, hosting at googlecode, or sourceforge would statisfy that as well. So
why does the project want to join Apache specifically?

=== Homogenous Developers ===
> The current set of developers work across a variety of organizations.
> Naturally, most are websites with significant backend structure (and
> hence a need for Thrift), but the problems they are solving are diverse,
> and many don't work in the same programming languages.


Again, it seems like a huge contingent of facebook developers. You really
should work on diversification during incubation.



=== Subversion Directory ===
> https://svn.apache.org/repos/asf/incubator/thrift
>
> We'd also be interested in using git to store the repo. Does apache have
> infrastucture set up to support that? It'd make it easier for
> non-committer developers to work on patches, checkpoint commits, etc.


There is no current infrastructure for this available. There has been an
experiment done by the Maven devs, but I'm out of touch with its status.

== Initial Committers ==
> * Mark Slee (mcslee at facebook dot com)
> * Aditya Agarwal (aditya at facebook dot com)
> * Marc Kwiatkowski (marc at facebook dot com)
> * David Reiss (david at facebook dot com)
> * James Wang (jwang at facebook dot com)
> * Chris Piro (cpiro at facebook dot com)
> * Ben Maurer (bmaurer at andrew dot cmu dot edu)
> * Kevin Clark (kevin at powerset dot com)
> * Jake Luciani (jakers at gmail dot com)


== Affiliations ==
> * People with Facebook email addresses - Facebook
> * Ben Maurer - ReCaptcha
> * Kevin Clark - Powerset


What is the affiliation of Jake Luciani?

=== Mentors ===
> * Paul Querna
> * Upayavira


I think you need one more mentor, but (s)he may present her/himself during
the vote for the proposal.


Martijn

-- 
Buy Wicket in Action: http://manning.com/dashorst
Apache Wicket 1.3.0 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0

Re: [PROPOSAL] Thrift

[Niall Pemberton <ni...@gmail.com>]

I'm happy with the reponses given so +1 to Thrift from me.

Niall

On Jan 24, 2008 2:07 AM, Mark Slee <ms...@facebook.com> wrote:
> Hi all,
>
> We've just posted the Apache Incubator proposal for Thrift onto the
> Wiki:
> http://wiki.apache.org/incubator/ThriftProposal
>
> For those who prefer reading Wiki markup directly, it is copied below.
>
> Cheers,
> Mark
>
> = Thrift Proposal =
>
> == Abstract ==
> Thrift is a framework for efficient cross-language data serialization,
> RPC, and server programming.
>
> == Proposal ==
> Thrift is a software library and set of code-generation tools designed
> to expedite development and implementation of efficient and scalable
> backend services. Its primary goal is to enable efficient and reliable
> communication across programming languages by abstracting the portions
> of each language that tend to require the most customization into a
> common library that is implemented in each language. Specifically,
> Thrift allows developers to define datatypes and service interfaces in a
> single language-neutral file and generate all the necessary code to
> build RPC clients and servers.
>
> == Background ==
> Thrift was initially developed at Facebook starting in 2006 to power RPC
> and data logging for a number of backend services for the site, such as
> Search and News Feed. The package was designed for open source, and was
> released in early 2007. Since then, a number of other developers have
> submitted patches to the project and become de facto owners of major
> parts. Support for many languages has been developed entirely outside of
> Facebook.
>
> == Rationale ==
> The need for high performance, reliable communication across different
> programming languages seems to be growing more and more common in modern
> programming, particularly when writing software for the web.
> Historically, this problem has forced developers to standardize on one
> language/framework or adopt heavier-weight systems, such as CORBA or
> SOAP. These systems tend to make tradeoffs that aren't always ideal for
> the use case. SOAP, for example, may be ideal for calling across
> disparate web services, but is unnecessarily verbose for service calls
> on an intranet.
>
> Most of these systems also require developers to learn the particulars
> of their type systems, especially when dealing with containers or
> objects. One of the primary goals of Thrift is to allow developers to
> program across languages while still using the standard idioms and style
> in each language. Custom type systems also makes code reuse more
> difficult. Thrift allows developers to avoid creating unnecessary
> wrapper interfaces by operating directly on native types.
>
> == Initial Goals ==
> Though the bulk of Thrift's initial development is complete, there are
> still some large areas for future development. Some areas we hope to
> focus on in Apache:
>
>  * Better log storage/replay
>  * Meta-data serialization
>  * Higher-performance serialization, standard C extension model across
> Python/PHP/etc.
>  * Extending the abstraction to a multi-client that can fan-out across
> multiple servers
>
> == Current Status ==
> === Meritocracy ===
> Though initial development was done at Facebook, Thrift was intended to
> be released as an open source project from its inception. Since release,
> many developers have adopted the framework and submitted significant
> patches. Large portions of the codebase are now managed by those most
> familiar with and responsible for them. Any potentially controversial
> change is discussed on the public mailing list
> (http://lists.pub.facebook.com/mailman/listinfo/thrift/) and good
> suggestions are frequently implemented.
>
> === Community ===
> Thrift is currently in use across a number of organizations, and we
> expect this to grow as Thrift becomes a relevant and useful tool for
> building more open source projects.
>
> === Core Developers ===
> Thrift currently has developers across many organizations (e.g.
> Facebook, Powerset, ReCaptcha, AmieStreet), many of whom are
> contributors to other open source projects.
>
> === Alignment ===
> Thrift is designed to integrate cleanly with other projects. We think
> this is a particularly good fit for Apache due to integration potential
> with other projects, specifically Hadoop/Hbase.
>
> == Known Risks ==
> === Orphaned Products ===
> Thrift is already deployed into production at multiple large websites
> that are frequently iterating on the featureset. There's no realistic
> chance of it becoming orphaned.
>
> === Inexperience with Open Source ===
> The project has already been open source for nearly a year and has
> attracted many developers already. Part of the reason to join Apache is
> to make the project work even better as open source by removing some
> obstacles, such as Facebook hosting the SVN, and putting the resources
> all in a truly open space, being able to have more committers, etc. Most
> of the core developers have a history of working with open source tools.
>
> === Homogenous Developers ===
> The current set of developers work across a variety of organizations.
> Naturally, most are websites with significant backend structure (and
> hence a need for Thrift), but the problems they are solving are diverse,
> and many don't work in the same programming languages.
>
> === Reliance on Salaried Developers ===
> Thrift is a "means to an end." None of the developers (to my knowledge)
> working on Thrift are salaried specifically to work on Thrift. Rather,
> Thrift is useful in building other projects, which may or may not be for
> salary. Realistically, it is likely that a decent portion of work on
> Thrift will be done by someone at a company, but not specifically tasked
> with working on Thrift. So long as the tool is relevant and useful, this
> should result in developers contributing time both at work and
> personally.
>
> === Relationships with Other Apache Projects ===
> Thrift has already been introduced into the Hbase project. (See
> https://issues.apache.org/jira/browse/HADOOP-2389) Since Thrift is a
> development tool, it is designed and well-suited for use in other
> projects. As a start, we definitely plan to continue integration work
> with Hbase.
>
> === An Excessive Fascination with the Apache Brand ===
> Thrift has already attracted a stable base of developers. The reasons
> for joining Apache are not to advertise the project, but rather to
> demonstrate the commitment to open source by divorcing the trunk from
> any one corporation and pursuing further integration with other Apache
> projects.
>
> == Documentation ==
> Existing page:
> http://developers.facebook.com/thrift/
>
> Mailing list (with archives):
> http://lists.pub.facebook.com/mailman/listinfo/thrift/
>
> == Initial Source ==
> Currently hosted by Facebook:
> http://svn.facebook.com/svnroot/thrift/
>
> == Source and Intellectual Property Submission Plan ==
> All code currently hosted in the Facebook public SVN folder will be
> contributed.
>
> == External Dependencies ==
> All dependencies (libevent, Boost) have Apache compatible licenses.
>
> == Cryptography ==
> None
>
> == Required Resources ==
> === Mailing lists ===
>  * thrift-dev
>  * thrift-private
>
> === Subversion Directory ===
> https://svn.apache.org/repos/asf/incubator/thrift
>
> We'd also be interested in using git to store the repo. Does apache have
> infrastucture set up to support that? It'd make it easier for
> non-committer developers to work on patches, checkpoint commits, etc.
>
> === Issue Tracking ===
> Bugzilla Thrift
>
> == Initial Committers ==
>  * Mark Slee (mcslee at facebook dot com)
>  * Aditya Agarwal (aditya at facebook dot com)
>  * Marc Kwiatkowski (marc at facebook dot com)
>  * David Reiss (david at facebook dot com)
>  * James Wang (jwang at facebook dot com)
>  * Chris Piro (cpiro at facebook dot com)
>  * Ben Maurer (bmaurer at andrew dot cmu dot edu)
>  * Kevin Clark (kevin at powerset dot com)
>  * Jake Luciani (jakers at gmail dot com)
>
> == Affiliations ==
>  * People with Facebook email addresses - Facebook
>  * Ben Maurer - ReCaptcha
>  * Kevin Clark - Powerset
>
> == Sponsors ==
> === Champion ===
>  * Doug Cutting
>
> === Mentors ===
>  * Paul Querna
>  * Upayavira
>
> === Sponsoring Entity ===
>  * Incubator
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [PROPOSAL] Thrift

[Matthieu Riou <ma...@offthelip.org>]

On Jan 29, 2008 2:44 AM, Upayavira <uv...@odoko.co.uk> wrote:

> Sorry I didn't post in response to your original mail - I was in the
> middle of a laptop failure (now recovered with no harm done).
>
> I'm certainly in favour of this as a project. My main concern is that it
> is already relatively mature, which will make it harder to draw a
> broader community. Also, making one community around five-odd languages
> will be interesting.
>
> However, I see these as things to be sorted during incubation, and am
> therefore supportive of this project, and have volunteered to be a
> mentor.
>
> In response to Martijn's comment about needing another mentor, it is
> recommended to have three, but not required. What _is_ required is to
> get at least three votes from Incubator PMC members for the proposal when
> put to a vote.
>

If mentoring help is still needed, count me in.

Cheers,
Matthieu


>
> Regards, Upayavira
>
> On Mon, 2008-01-28 at 21:23 -0800, Mark Slee wrote:
> > Hi everyone,
> >
> > Unless my mail filters are playing tricks on me, haven't seen any
> > feedback on the incubator list since sending this proposal out last
> > week. Hopefully that's a good thing, meaning no one's opposed. =)
> >
> > Anyone have feedback? If no objections are voiced, when would it be
> > appropriate for us to move forward with a VOTE thread on this?
> >
> > Cheers,
> > Mark
> >
> > -----Original Message-----
> > From: Mark Slee [mailto:mslee@facebook.com]
> > Sent: Wednesday, January 23, 2008 6:07 PM
> > To: general@incubator.apache.org
> > Cc: thrift@publists.facebook.com
> > Subject: [PROPOSAL] Thrift
> >
> > Hi all,
> >
> > We've just posted the Apache Incubator proposal for Thrift onto the
> > Wiki:
> > http://wiki.apache.org/incubator/ThriftProposal
> >
> > For those who prefer reading Wiki markup directly, it is copied below.
> >
> > Cheers,
> > Mark
> >
> > = Thrift Proposal =
> >
> > == Abstract ==
> > Thrift is a framework for efficient cross-language data serialization,
> > RPC, and server programming.
> >
> > == Proposal ==
> > Thrift is a software library and set of code-generation tools designed
> > to expedite development and implementation of efficient and scalable
> > backend services. Its primary goal is to enable efficient and reliable
> > communication across programming languages by abstracting the portions
> > of each language that tend to require the most customization into a
> > common library that is implemented in each language. Specifically,
> > Thrift allows developers to define datatypes and service interfaces in a
> > single language-neutral file and generate all the necessary code to
> > build RPC clients and servers.
> >
> > == Background ==
> > Thrift was initially developed at Facebook starting in 2006 to power RPC
> > and data logging for a number of backend services for the site, such as
> > Search and News Feed. The package was designed for open source, and was
> > released in early 2007. Since then, a number of other developers have
> > submitted patches to the project and become de facto owners of major
> > parts. Support for many languages has been developed entirely outside of
> > Facebook.
> >
> > == Rationale ==
> > The need for high performance, reliable communication across different
> > programming languages seems to be growing more and more common in modern
> > programming, particularly when writing software for the web.
> > Historically, this problem has forced developers to standardize on one
> > language/framework or adopt heavier-weight systems, such as CORBA or
> > SOAP. These systems tend to make tradeoffs that aren't always ideal for
> > the use case. SOAP, for example, may be ideal for calling across
> > disparate web services, but is unnecessarily verbose for service calls
> > on an intranet.
> >
> > Most of these systems also require developers to learn the particulars
> > of their type systems, especially when dealing with containers or
> > objects. One of the primary goals of Thrift is to allow developers to
> > program across languages while still using the standard idioms and style
> > in each language. Custom type systems also makes code reuse more
> > difficult. Thrift allows developers to avoid creating unnecessary
> > wrapper interfaces by operating directly on native types.
> >
> > == Initial Goals ==
> > Though the bulk of Thrift's initial development is complete, there are
> > still some large areas for future development. Some areas we hope to
> > focus on in Apache:
> >
> >  * Better log storage/replay
> >  * Meta-data serialization
> >  * Higher-performance serialization, standard C extension model across
> > Python/PHP/etc.
> >  * Extending the abstraction to a multi-client that can fan-out across
> > multiple servers
> >
> > == Current Status ==
> > === Meritocracy ===
> > Though initial development was done at Facebook, Thrift was intended to
> > be released as an open source project from its inception. Since release,
> > many developers have adopted the framework and submitted significant
> > patches. Large portions of the codebase are now managed by those most
> > familiar with and responsible for them. Any potentially controversial
> > change is discussed on the public mailing list
> > (http://lists.pub.facebook.com/mailman/listinfo/thrift/) and good
> > suggestions are frequently implemented.
> >
> > === Community ===
> > Thrift is currently in use across a number of organizations, and we
> > expect this to grow as Thrift becomes a relevant and useful tool for
> > building more open source projects.
> >
> > === Core Developers ===
> > Thrift currently has developers across many organizations (e.g.
> > Facebook, Powerset, ReCaptcha, AmieStreet), many of whom are
> > contributors to other open source projects.
> >
> > === Alignment ===
> > Thrift is designed to integrate cleanly with other projects. We think
> > this is a particularly good fit for Apache due to integration potential
> > with other projects, specifically Hadoop/Hbase.
> >
> > == Known Risks ==
> > === Orphaned Products ===
> > Thrift is already deployed into production at multiple large websites
> > that are frequently iterating on the featureset. There's no realistic
> > chance of it becoming orphaned.
> >
> > === Inexperience with Open Source ===
> > The project has already been open source for nearly a year and has
> > attracted many developers already. Part of the reason to join Apache is
> > to make the project work even better as open source by removing some
> > obstacles, such as Facebook hosting the SVN, and putting the resources
> > all in a truly open space, being able to have more committers, etc. Most
> > of the core developers have a history of working with open source tools.
> >
> > === Homogenous Developers ===
> > The current set of developers work across a variety of organizations.
> > Naturally, most are websites with significant backend structure (and
> > hence a need for Thrift), but the problems they are solving are diverse,
> > and many don't work in the same programming languages.
> >
> > === Reliance on Salaried Developers ===
> > Thrift is a "means to an end." None of the developers (to my knowledge)
> > working on Thrift are salaried specifically to work on Thrift. Rather,
> > Thrift is useful in building other projects, which may or may not be for
> > salary. Realistically, it is likely that a decent portion of work on
> > Thrift will be done by someone at a company, but not specifically tasked
> > with working on Thrift. So long as the tool is relevant and useful, this
> > should result in developers contributing time both at work and
> > personally.
> >
> > === Relationships with Other Apache Projects === Thrift has already been
> > introduced into the Hbase project. (See
> > https://issues.apache.org/jira/browse/HADOOP-2389) Since Thrift is a
> > development tool, it is designed and well-suited for use in other
> > projects. As a start, we definitely plan to continue integration work
> > with Hbase.
> >
> > === An Excessive Fascination with the Apache Brand === Thrift has
> > already attracted a stable base of developers. The reasons for joining
> > Apache are not to advertise the project, but rather to demonstrate the
> > commitment to open source by divorcing the trunk from any one
> > corporation and pursuing further integration with other Apache projects.
> >
> > == Documentation ==
> > Existing page:
> > http://developers.facebook.com/thrift/
> >
> > Mailing list (with archives):
> > http://lists.pub.facebook.com/mailman/listinfo/thrift/
> >
> > == Initial Source ==
> > Currently hosted by Facebook:
> > http://svn.facebook.com/svnroot/thrift/
> >
> > == Source and Intellectual Property Submission Plan == All code
> > currently hosted in the Facebook public SVN folder will be contributed.
> >
> > == External Dependencies ==
> > All dependencies (libevent, Boost) have Apache compatible licenses.
> >
> > == Cryptography ==
> > None
> >
> > == Required Resources ==
> > === Mailing lists ===
> >  * thrift-dev
> >  * thrift-private
> >
> > === Subversion Directory ===
> > https://svn.apache.org/repos/asf/incubator/thrift
> >
> > We'd also be interested in using git to store the repo. Does apache have
> > infrastucture set up to support that? It'd make it easier for
> > non-committer developers to work on patches, checkpoint commits, etc.
> >
> > === Issue Tracking ===
> > Bugzilla Thrift
> >
> > == Initial Committers ==
> >  * Mark Slee (mcslee at facebook dot com)
> >  * Aditya Agarwal (aditya at facebook dot com)
> >  * Marc Kwiatkowski (marc at facebook dot com)
> >  * David Reiss (david at facebook dot com)
> >  * James Wang (jwang at facebook dot com)
> >  * Chris Piro (cpiro at facebook dot com)
> >  * Ben Maurer (bmaurer at andrew dot cmu dot edu)
> >  * Kevin Clark (kevin at powerset dot com)
> >  * Jake Luciani (jakers at gmail dot com)
> >
> > == Affiliations ==
> >  * People with Facebook email addresses - Facebook
> >  * Ben Maurer - ReCaptcha
> >  * Kevin Clark - Powerset
> >
> > == Sponsors ==
> > === Champion ===
> >  * Doug Cutting
> >
> > === Mentors ===
> >  * Paul Querna
> >  * Upayavira
> >
> > === Sponsoring Entity ===
> >  * Incubator
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

RE: [PROPOSAL] Thrift

[Upayavira <uv...@odoko.co.uk>]

Sorry I didn't post in response to your original mail - I was in the
middle of a laptop failure (now recovered with no harm done).

I'm certainly in favour of this as a project. My main concern is that it
is already relatively mature, which will make it harder to draw a
broader community. Also, making one community around five-odd languages
will be interesting.

However, I see these as things to be sorted during incubation, and am
therefore supportive of this project, and have volunteered to be a
mentor.

In response to Martijn's comment about needing another mentor, it is 
recommended to have three, but not required. What _is_ required is to 
get at least three votes from Incubator PMC members for the proposal when
put to a vote.

Regards, Upayavira

On Mon, 2008-01-28 at 21:23 -0800, Mark Slee wrote:
> Hi everyone,
> 
> Unless my mail filters are playing tricks on me, haven't seen any
> feedback on the incubator list since sending this proposal out last
> week. Hopefully that's a good thing, meaning no one's opposed. =)
> 
> Anyone have feedback? If no objections are voiced, when would it be
> appropriate for us to move forward with a VOTE thread on this?
> 
> Cheers,
> Mark
> 
> -----Original Message-----
> From: Mark Slee [mailto:mslee@facebook.com] 
> Sent: Wednesday, January 23, 2008 6:07 PM
> To: general@incubator.apache.org
> Cc: thrift@publists.facebook.com
> Subject: [PROPOSAL] Thrift
> 
> Hi all,
>  
> We've just posted the Apache Incubator proposal for Thrift onto the
> Wiki:
> http://wiki.apache.org/incubator/ThriftProposal
>  
> For those who prefer reading Wiki markup directly, it is copied below.
>  
> Cheers,
> Mark
>  
> = Thrift Proposal =
> 
> == Abstract ==
> Thrift is a framework for efficient cross-language data serialization,
> RPC, and server programming.
> 
> == Proposal ==
> Thrift is a software library and set of code-generation tools designed
> to expedite development and implementation of efficient and scalable
> backend services. Its primary goal is to enable efficient and reliable
> communication across programming languages by abstracting the portions
> of each language that tend to require the most customization into a
> common library that is implemented in each language. Specifically,
> Thrift allows developers to define datatypes and service interfaces in a
> single language-neutral file and generate all the necessary code to
> build RPC clients and servers.
> 
> == Background ==
> Thrift was initially developed at Facebook starting in 2006 to power RPC
> and data logging for a number of backend services for the site, such as
> Search and News Feed. The package was designed for open source, and was
> released in early 2007. Since then, a number of other developers have
> submitted patches to the project and become de facto owners of major
> parts. Support for many languages has been developed entirely outside of
> Facebook.
> 
> == Rationale ==
> The need for high performance, reliable communication across different
> programming languages seems to be growing more and more common in modern
> programming, particularly when writing software for the web.
> Historically, this problem has forced developers to standardize on one
> language/framework or adopt heavier-weight systems, such as CORBA or
> SOAP. These systems tend to make tradeoffs that aren't always ideal for
> the use case. SOAP, for example, may be ideal for calling across
> disparate web services, but is unnecessarily verbose for service calls
> on an intranet.
> 
> Most of these systems also require developers to learn the particulars
> of their type systems, especially when dealing with containers or
> objects. One of the primary goals of Thrift is to allow developers to
> program across languages while still using the standard idioms and style
> in each language. Custom type systems also makes code reuse more
> difficult. Thrift allows developers to avoid creating unnecessary
> wrapper interfaces by operating directly on native types.
> 
> == Initial Goals ==
> Though the bulk of Thrift's initial development is complete, there are
> still some large areas for future development. Some areas we hope to
> focus on in Apache:
> 
>  * Better log storage/replay
>  * Meta-data serialization
>  * Higher-performance serialization, standard C extension model across
> Python/PHP/etc.
>  * Extending the abstraction to a multi-client that can fan-out across
> multiple servers
> 
> == Current Status ==
> === Meritocracy ===
> Though initial development was done at Facebook, Thrift was intended to
> be released as an open source project from its inception. Since release,
> many developers have adopted the framework and submitted significant
> patches. Large portions of the codebase are now managed by those most
> familiar with and responsible for them. Any potentially controversial
> change is discussed on the public mailing list
> (http://lists.pub.facebook.com/mailman/listinfo/thrift/) and good
> suggestions are frequently implemented.
> 
> === Community ===
> Thrift is currently in use across a number of organizations, and we
> expect this to grow as Thrift becomes a relevant and useful tool for
> building more open source projects.
> 
> === Core Developers ===
> Thrift currently has developers across many organizations (e.g.
> Facebook, Powerset, ReCaptcha, AmieStreet), many of whom are
> contributors to other open source projects.
> 
> === Alignment ===
> Thrift is designed to integrate cleanly with other projects. We think
> this is a particularly good fit for Apache due to integration potential
> with other projects, specifically Hadoop/Hbase.
> 
> == Known Risks ==
> === Orphaned Products ===
> Thrift is already deployed into production at multiple large websites
> that are frequently iterating on the featureset. There's no realistic
> chance of it becoming orphaned.
> 
> === Inexperience with Open Source ===
> The project has already been open source for nearly a year and has
> attracted many developers already. Part of the reason to join Apache is
> to make the project work even better as open source by removing some
> obstacles, such as Facebook hosting the SVN, and putting the resources
> all in a truly open space, being able to have more committers, etc. Most
> of the core developers have a history of working with open source tools.
> 
> === Homogenous Developers ===
> The current set of developers work across a variety of organizations.
> Naturally, most are websites with significant backend structure (and
> hence a need for Thrift), but the problems they are solving are diverse,
> and many don't work in the same programming languages.
> 
> === Reliance on Salaried Developers ===
> Thrift is a "means to an end." None of the developers (to my knowledge)
> working on Thrift are salaried specifically to work on Thrift. Rather,
> Thrift is useful in building other projects, which may or may not be for
> salary. Realistically, it is likely that a decent portion of work on
> Thrift will be done by someone at a company, but not specifically tasked
> with working on Thrift. So long as the tool is relevant and useful, this
> should result in developers contributing time both at work and
> personally.
> 
> === Relationships with Other Apache Projects === Thrift has already been
> introduced into the Hbase project. (See
> https://issues.apache.org/jira/browse/HADOOP-2389) Since Thrift is a
> development tool, it is designed and well-suited for use in other
> projects. As a start, we definitely plan to continue integration work
> with Hbase.
> 
> === An Excessive Fascination with the Apache Brand === Thrift has
> already attracted a stable base of developers. The reasons for joining
> Apache are not to advertise the project, but rather to demonstrate the
> commitment to open source by divorcing the trunk from any one
> corporation and pursuing further integration with other Apache projects.
> 
> == Documentation ==
> Existing page:
> http://developers.facebook.com/thrift/
> 
> Mailing list (with archives):
> http://lists.pub.facebook.com/mailman/listinfo/thrift/
> 
> == Initial Source ==
> Currently hosted by Facebook:
> http://svn.facebook.com/svnroot/thrift/
> 
> == Source and Intellectual Property Submission Plan == All code
> currently hosted in the Facebook public SVN folder will be contributed.
> 
> == External Dependencies ==
> All dependencies (libevent, Boost) have Apache compatible licenses.
> 
> == Cryptography ==
> None
> 
> == Required Resources ==
> === Mailing lists ===
>  * thrift-dev
>  * thrift-private
> 
> === Subversion Directory ===
> https://svn.apache.org/repos/asf/incubator/thrift
> 
> We'd also be interested in using git to store the repo. Does apache have
> infrastucture set up to support that? It'd make it easier for
> non-committer developers to work on patches, checkpoint commits, etc.
> 
> === Issue Tracking ===
> Bugzilla Thrift
> 
> == Initial Committers ==
>  * Mark Slee (mcslee at facebook dot com)
>  * Aditya Agarwal (aditya at facebook dot com)
>  * Marc Kwiatkowski (marc at facebook dot com)
>  * David Reiss (david at facebook dot com)
>  * James Wang (jwang at facebook dot com)
>  * Chris Piro (cpiro at facebook dot com)
>  * Ben Maurer (bmaurer at andrew dot cmu dot edu)
>  * Kevin Clark (kevin at powerset dot com)
>  * Jake Luciani (jakers at gmail dot com)
> 
> == Affiliations ==
>  * People with Facebook email addresses - Facebook
>  * Ben Maurer - ReCaptcha
>  * Kevin Clark - Powerset
> 
> == Sponsors ==
> === Champion ===
>  * Doug Cutting
> 
> === Mentors ===
>  * Paul Querna
>  * Upayavira
> 
> === Sponsoring Entity ===
>  * Incubator
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [Thrift] Re: Re: [PROPOSAL] Thrift

[Upayavira <uv...@odoko.co.uk>]

On Fri, 2008-02-01 at 17:21 -0800, David Reiss wrote:
> Thanks for the explanations.  Maybe it is too early for me to start 
> evangelizing, but let me know if either of these factors makes a difference.
> 
> 1/ I don't think we would be putting any load on the Apache infrastructure 
> team.  As Matthieu said, it would take about five minutes for one of us to set 
> up the server.
> 
> 2/ It would be almost as easy to mirror the master branch of the repository 
> into Subversion, so there is no reason the latest and greatest Thrift code 
> could not be available with the rest of the Apache products.

As to evangelising, I'd say, come along, enter the world of the ASF,
join its infrastructure list, help out, get to know us, come to
ApacheCons and meet us (if you can). Evangelising will be much easier
then!

As to using git, I would personally have no problem with a developer (or
a group of developers) chosing to use git on top of SVN (assuming it
does not put undue load on our SVN servers, like some tools do).

I would probably feel uncomfortable with a situation where all devs were
_required_ to use git in order to participate in the project, as that
would effectively make it a core part of the project.

So (a) so long as all code resides in SVN and (b) no-one is required to
use git, nor prejudiced against for not using it, I would not have any
problems.

Regards, Upayavira

> Matthieu Riou wrote:
> > On Feb 1, 2008 4:48 PM, Upayavira <uv...@odoko.co.uk> wrote:
> > 
> >  >
> >  > On Fri, 2008-02-01 at 16:20 -0800, David Reiss wrote:
> >  > > J Aaron Farr wrote:
> >  > > > git could be an issue.
> >  > >
> >  > > Can you explain what the issue is with Git?  We have at least seven
> >  > > contributors (three at Facebook, four external) using git-svn right 
> > now,
> >  > and I
> >  > > know that at least a few of us would really like to use native Git as
> >  > the main
> >  > > repository for Thrift.  Paul Querna mentioned on the Thrift list that
> >  > Apache
> >  > > likes things to happen "in the open", but he said that others could
> >  > explain it
> >  > > better.
> >  >
> >  > I think the main issue is one of uniformity, not a technology. I'm quite
> >  > happy to believe that git has some significant advantages.
> >  >
> >  > However, the ASF has currently standardised on Subversion. It is where
> >  > _all_ of the ASF's code lies. If one ASF project chooses an alternative
> >  > source control, we no longer have all the code in one place.
> >  >
> >  > We already have this 'diversified' situation with wikis and with bug
> >  > tracking. We have two wikis (moin and confluence) and three bug trackers
> >  > (Jira/bugzilla/Scarab - although Scarab may have been shut down
> >  > already), and it certainly makes life harder in terms of maintenance.
> >  >
> >  > So, as an ASF infrastructure person, my first response to git would be
> >  > 'no', much like an accountant's answer would be 'no' when you ask them
> >  > for money.
> >  >
> >  > I think you should assume that you won't have git as a part of what you
> >  > get at Apache. You are welcome to enter the Apache world, and evangelise
> >  > as to why git would be good for the whole ASF, and it is certainly not
> >  > impossible that it could be adopted. However, if a project made
> >  > something like the installation and use of git a core part of their
> >  > proposal, you can be sure it wouldn't be accepted.
> >  >
> > 
> > +1
> > 
> > Said differently, I would love to use Bazaar at the ASF. Some others would
> > like Mercurial. You'd like Git. I bet we could even find a couple of people
> > who'd like to get back to CVS.
> > 
> > Also it would take me 5mn to setup a Bazaar repository on my machine and
> > share it with friends. In the context of the foundation (where the current
> > svn revision is 617723) it would probably take weeks to get something that
> > would fly, plus years of maintenance behind.
> > 
> > Cheers,
> > Matthieu
> > 
> > 
> >  >
> >  > I hope that makes it a little clearer. It isn't the easiest thing to
> >  > explain.
> > 
> > 
> >  > Regards, Upayavira
> >  >
> >  >
> >  >
> >  > ---------------------------------------------------------------------
> >  > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> >  > For additional commands, e-mail: general-help@incubator.apache.org
> >  >
> >  >
> > 
> _______________________________________________
> Thrift mailing list
> Thrift@publists.facebook.com
> http://lists.pub.facebook.com/mailman/listinfo/thrift


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Re: [Thrift] Re: Re: [PROPOSAL] Thrift

[David Reiss <dr...@facebook.com>]

Thanks for the explanations.  Maybe it is too early for me to start 
evangelizing, but let me know if either of these factors makes a difference.

1/ I don't think we would be putting any load on the Apache infrastructure 
team.  As Matthieu said, it would take about five minutes for one of us to set 
up the server.

2/ It would be almost as easy to mirror the master branch of the repository 
into Subversion, so there is no reason the latest and greatest Thrift code 
could not be available with the rest of the Apache products.

Thanks for your consideration!

--David

Matthieu Riou wrote:
> On Feb 1, 2008 4:48 PM, Upayavira <uv...@odoko.co.uk> wrote:
> 
>  >
>  > On Fri, 2008-02-01 at 16:20 -0800, David Reiss wrote:
>  > > J Aaron Farr wrote:
>  > > > git could be an issue.
>  > >
>  > > Can you explain what the issue is with Git?  We have at least seven
>  > > contributors (three at Facebook, four external) using git-svn right 
> now,
>  > and I
>  > > know that at least a few of us would really like to use native Git as
>  > the main
>  > > repository for Thrift.  Paul Querna mentioned on the Thrift list that
>  > Apache
>  > > likes things to happen "in the open", but he said that others could
>  > explain it
>  > > better.
>  >
>  > I think the main issue is one of uniformity, not a technology. I'm quite
>  > happy to believe that git has some significant advantages.
>  >
>  > However, the ASF has currently standardised on Subversion. It is where
>  > _all_ of the ASF's code lies. If one ASF project chooses an alternative
>  > source control, we no longer have all the code in one place.
>  >
>  > We already have this 'diversified' situation with wikis and with bug
>  > tracking. We have two wikis (moin and confluence) and three bug trackers
>  > (Jira/bugzilla/Scarab - although Scarab may have been shut down
>  > already), and it certainly makes life harder in terms of maintenance.
>  >
>  > So, as an ASF infrastructure person, my first response to git would be
>  > 'no', much like an accountant's answer would be 'no' when you ask them
>  > for money.
>  >
>  > I think you should assume that you won't have git as a part of what you
>  > get at Apache. You are welcome to enter the Apache world, and evangelise
>  > as to why git would be good for the whole ASF, and it is certainly not
>  > impossible that it could be adopted. However, if a project made
>  > something like the installation and use of git a core part of their
>  > proposal, you can be sure it wouldn't be accepted.
>  >
> 
> +1
> 
> Said differently, I would love to use Bazaar at the ASF. Some others would
> like Mercurial. You'd like Git. I bet we could even find a couple of people
> who'd like to get back to CVS.
> 
> Also it would take me 5mn to setup a Bazaar repository on my machine and
> share it with friends. In the context of the foundation (where the current
> svn revision is 617723) it would probably take weeks to get something that
> would fly, plus years of maintenance behind.
> 
> Cheers,
> Matthieu
> 
> 
>  >
>  > I hope that makes it a little clearer. It isn't the easiest thing to
>  > explain.
> 
> 
>  > Regards, Upayavira
>  >
>  >
>  >
>  > ---------------------------------------------------------------------
>  > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>  > For additional commands, e-mail: general-help@incubator.apache.org
>  >
>  >
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [Thrift] Re: Re: [PROPOSAL] Thrift

[Matthieu Riou <ma...@offthelip.org>]

On Feb 1, 2008 4:48 PM, Upayavira <uv...@odoko.co.uk> wrote:

>
> On Fri, 2008-02-01 at 16:20 -0800, David Reiss wrote:
> > J Aaron Farr wrote:
> > > git could be an issue.
> >
> > Can you explain what the issue is with Git?  We have at least seven
> > contributors (three at Facebook, four external) using git-svn right now,
> and I
> > know that at least a few of us would really like to use native Git as
> the main
> > repository for Thrift.  Paul Querna mentioned on the Thrift list that
> Apache
> > likes things to happen "in the open", but he said that others could
> explain it
> > better.
>
> I think the main issue is one of uniformity, not a technology. I'm quite
> happy to believe that git has some significant advantages.
>
> However, the ASF has currently standardised on Subversion. It is where
> _all_ of the ASF's code lies. If one ASF project chooses an alternative
> source control, we no longer have all the code in one place.
>
> We already have this 'diversified' situation with wikis and with bug
> tracking. We have two wikis (moin and confluence) and three bug trackers
> (Jira/bugzilla/Scarab - although Scarab may have been shut down
> already), and it certainly makes life harder in terms of maintenance.
>
> So, as an ASF infrastructure person, my first response to git would be
> 'no', much like an accountant's answer would be 'no' when you ask them
> for money.
>
> I think you should assume that you won't have git as a part of what you
> get at Apache. You are welcome to enter the Apache world, and evangelise
> as to why git would be good for the whole ASF, and it is certainly not
> impossible that it could be adopted. However, if a project made
> something like the installation and use of git a core part of their
> proposal, you can be sure it wouldn't be accepted.
>

+1

Said differently, I would love to use Bazaar at the ASF. Some others would
like Mercurial. You'd like Git. I bet we could even find a couple of people
who'd like to get back to CVS.

Also it would take me 5mn to setup a Bazaar repository on my machine and
share it with friends. In the context of the foundation (where the current
svn revision is 617723) it would probably take weeks to get something that
would fly, plus years of maintenance behind.

Cheers,
Matthieu


>
> I hope that makes it a little clearer. It isn't the easiest thing to
> explain.


> Regards, Upayavira
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

Re: [Thrift] Re: Re: [PROPOSAL] Thrift

[Upayavira <uv...@odoko.co.uk>]

On Fri, 2008-02-01 at 16:20 -0800, David Reiss wrote:
> J Aaron Farr wrote:
> > git could be an issue.
> 
> Can you explain what the issue is with Git?  We have at least seven 
> contributors (three at Facebook, four external) using git-svn right now, and I 
> know that at least a few of us would really like to use native Git as the main 
> repository for Thrift.  Paul Querna mentioned on the Thrift list that Apache 
> likes things to happen "in the open", but he said that others could explain it 
> better.

I think the main issue is one of uniformity, not a technology. I'm quite
happy to believe that git has some significant advantages.

However, the ASF has currently standardised on Subversion. It is where
_all_ of the ASF's code lies. If one ASF project chooses an alternative
source control, we no longer have all the code in one place.

We already have this 'diversified' situation with wikis and with bug
tracking. We have two wikis (moin and confluence) and three bug trackers
(Jira/bugzilla/Scarab - although Scarab may have been shut down
already), and it certainly makes life harder in terms of maintenance.

So, as an ASF infrastructure person, my first response to git would be
'no', much like an accountant's answer would be 'no' when you ask them
for money.

I think you should assume that you won't have git as a part of what you
get at Apache. You are welcome to enter the Apache world, and evangelise
as to why git would be good for the whole ASF, and it is certainly not
impossible that it could be adopted. However, if a project made
something like the installation and use of git a core part of their
proposal, you can be sure it wouldn't be accepted.

I hope that makes it a little clearer. It isn't the easiest thing to
explain.

Regards, Upayavira



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Subversion vs other source control systems

[Brian McCallister <br...@skife.org>]

FWIW, I quite like both git and mercurial, both give me a better workflow
than subversion for a lot of things I work on. Offline commits, local
branches, and sane merging are *huge*. The approach to distributed repos is
also very nice for folks who do want to maintain a fork elsewhere (forking
isn't evil, it is a very good reaction to needing something slightly
different which the majority (or the powerful) in the base project doesn't
want).

Looking forward to  trying svn 1.5 branch management, though :-) Being able
to repeatedly merge from a branch I didn't branch from will be *huge* (ie,
pull bug fixes from release branches without pulling cruft from trunk from
whence I branched).

I quite accept the practical side of saying "svn only" as long as no one
steps up to manage git or mercurial. Saying "though shalt use svn because it
is the blessed end-all" is BS. Subversion is great, and all, but it also
sucks. Some things suck less for different workflows, some things suck more.
For one-branch development, svn is awesome.

Saying we can have only one "because" is very weak. Can anyone cite specific
problems FreeBSD or Perl have had?

-Brian

Re: Subversion vs other source control systems

[Grzegorz Kossakowski <gk...@apache.org>]

Jukka Zitting pisze:
> 
> It would be cool to have a few such examples to gather more experience
> on the related workflows. Could we for example set up some git-svn
> mirrors of selected projects for people to play with? Github looks
> nice for such purposes, and I also have a spare server we could use if
> we want more control over the interaction with Apache svn.

+1 for mirroring some projects on GitHub. Personally, I'm interested in Cocoon project and has been 
trying to get Git import of it for some time but without any significant result. If there is any 
action on this, don't forget to send a message to this list.

> Jukka Zitting

Too bad I hadn't chance to meet you Jukka at hackathon... :-(

-- 
Best regards,
Grzegorz Kossakowski

Re: Subversion vs other source control systems

[Jukka Zitting <ju...@gmail.com>]

Hi,

On Wed, Apr 9, 2008 at 9:03 AM, Santiago Gala <sg...@apache.org> wrote:
> There is now a list to discuss this kind of things, infra-dev. I CC: it.
>  Please drop the email to general@incubator if you answer.

Thanks.

>  The workflow you do wih most dSCM tools is literally up to you. I have
>  prepared a refactoring for shindig
>  ( http://github.com/sgala/apache-incubator-shindig/commits/synd-rename-2
>  about a 60k global patch, 38 small commits with git) using git, so that
>  I can get familiar with advanced uses of git at the same time.

It would be cool to have a few such examples to gather more experience
on the related workflows. Could we for example set up some git-svn
mirrors of selected projects for people to play with? Github looks
nice for such purposes, and I also have a spare server we could use if
we want more control over the interaction with Apache svn.

BR,

Jukka Zitting

Re: Subversion vs other source control systems

[Santiago Gala <sg...@apache.org>]

There is now a list to discuss this kind of things, infra-dev. I CC: it.
Please drop the email to general@incubator if you answer.

El mar, 08-04-2008 a las 08:17 +0100, Danny Angus escribió:
> On Thu, Feb 14, 2008 at 12:37 PM, Santiago Gala <sg...@apache.org> wrote:
> 
> >  If I remember correctly, the policy was not to impose subversion, but to
> >  mandate end of life for CVS. If I remember correctly, this was due to
> >  security concerns, CVS requiring user accounts in the machine where the
> >  repository is stored while subversion does not. Also functionality. Also
> >  that having a lengthy transition was stressing infrastructure. I have
> >  been looking into mail archives but have not found a pointer yet.
> 
> That's also my recollection.
> 
> ...
> 
> >  I don't think centralization has ever been part of "the Apache way".
> 
> I think the cvs-svn experience, and the wiki experience, would suggest
> that we need to be mindful of the maintenance overhead of not
> centralising some practical things.
> 

I can't see any issue re: the cvs-svn experience and centralization:
both environments are clearly centralized, and the migration was done by
a small team, from a central repository to a central repository.

The moinmoin farms as also very centralized, more aking to vhosts than
to separate servers. I'm not really aware of the maintenance overhead of
the wikis, but I'm betting that it is not bigger for moinmoin than for
cwiki, (I think we have a number of hours donated for the maintenance of
cwiki/JIRA) which in addition is proprietary.

> But thats not the same as centralisation as a principle.
> 
> And as a final point, don't take this too seriously but... the ASF and
> "the Apache Way" has probably been shaped more than we would like to
> admit by the workflow imposed by CVS. SVN is very similar, but
> distributed source control has very different workflow which would
> either conflict with or change "the way" if adopted.
> 

The workflow you do wih most dSCM tools is literally up to you. I have
prepared a refactoring for shindig
( http://github.com/sgala/apache-incubator-shindig/commits/synd-rename-2
about a 60k global patch, 38 small commits with git) using git, so that
I can get familiar with advanced uses of git at the same time.

I am (anybody is) free to test it in this branch that I published. What
is more, everybody can look into the code with reasonable color diffs.
The tool is able to rebase the patch as new commits come in, and it can
merge changes inside the context of a file renamed in the first patch.
What it is more, I can (anybody can) "git diff --stat -p -M synd-rename
synd-rename-2" and see what changed between versions of the patch, which
already allowed me to detect a merge problem that I introduced when I
reordered the commits to get the patch series cleaner to look into.
github can't do that, but my local gitweb can

An extra goodie is that the git repo with the whole history of the
project is smaller (and way faster to access) than a single subversion
working copy. And this is true of every project I have tried with
git-svn.

You might tell me that I could have started a subversion branch to do
it, and I'd answer: why is it that nobody does it in the real world?
This is really where the workflow of subversion is hurting^Wshaping us.

Regards
Santiago

> d.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org

-- 
Santiago Gala
http://memojo.com/~sgala/blog/

Re: Subversion vs other source control systems

[Santiago Gala <sg...@apache.org>]

There is now a list to discuss this kind of things, infra-dev. I CC: it.
Please drop the email to general@incubator if you answer.

El mar, 08-04-2008 a las 08:17 +0100, Danny Angus escribió:
> On Thu, Feb 14, 2008 at 12:37 PM, Santiago Gala <sg...@apache.org> wrote:
> 
> >  If I remember correctly, the policy was not to impose subversion, but to
> >  mandate end of life for CVS. If I remember correctly, this was due to
> >  security concerns, CVS requiring user accounts in the machine where the
> >  repository is stored while subversion does not. Also functionality. Also
> >  that having a lengthy transition was stressing infrastructure. I have
> >  been looking into mail archives but have not found a pointer yet.
> 
> That's also my recollection.
> 
> ...
> 
> >  I don't think centralization has ever been part of "the Apache way".
> 
> I think the cvs-svn experience, and the wiki experience, would suggest
> that we need to be mindful of the maintenance overhead of not
> centralising some practical things.
> 

I can't see any issue re: the cvs-svn experience and centralization:
both environments are clearly centralized, and the migration was done by
a small team, from a central repository to a central repository.

The moinmoin farms as also very centralized, more aking to vhosts than
to separate servers. I'm not really aware of the maintenance overhead of
the wikis, but I'm betting that it is not bigger for moinmoin than for
cwiki, (I think we have a number of hours donated for the maintenance of
cwiki/JIRA) which in addition is proprietary.

> But thats not the same as centralisation as a principle.
> 
> And as a final point, don't take this too seriously but... the ASF and
> "the Apache Way" has probably been shaped more than we would like to
> admit by the workflow imposed by CVS. SVN is very similar, but
> distributed source control has very different workflow which would
> either conflict with or change "the way" if adopted.
> 

The workflow you do wih most dSCM tools is literally up to you. I have
prepared a refactoring for shindig
( http://github.com/sgala/apache-incubator-shindig/commits/synd-rename-2
about a 60k global patch, 38 small commits with git) using git, so that
I can get familiar with advanced uses of git at the same time.

I am (anybody is) free to test it in this branch that I published. What
is more, everybody can look into the code with reasonable color diffs.
The tool is able to rebase the patch as new commits come in, and it can
merge changes inside the context of a file renamed in the first patch.
What it is more, I can (anybody can) "git diff --stat -p -M synd-rename
synd-rename-2" and see what changed between versions of the patch, which
already allowed me to detect a merge problem that I introduced when I
reordered the commits to get the patch series cleaner to look into.
github can't do that, but my local gitweb can

An extra goodie is that the git repo with the whole history of the
project is smaller (and way faster to access) than a single subversion
working copy. And this is true of every project I have tried with
git-svn.

You might tell me that I could have started a subversion branch to do
it, and I'd answer: why is it that nobody does it in the real world?
This is really where the workflow of subversion is hurting^Wshaping us.

Regards
Santiago

> d.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org

-- 
Santiago Gala
http://memojo.com/~sgala/blog/


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Subversion vs other source control systems

[Danny Angus <da...@apache.org>]

On Thu, Feb 14, 2008 at 12:37 PM, Santiago Gala <sg...@apache.org> wrote:

>  If I remember correctly, the policy was not to impose subversion, but to
>  mandate end of life for CVS. If I remember correctly, this was due to
>  security concerns, CVS requiring user accounts in the machine where the
>  repository is stored while subversion does not. Also functionality. Also
>  that having a lengthy transition was stressing infrastructure. I have
>  been looking into mail archives but have not found a pointer yet.

That's also my recollection.

...

>  I don't think centralization has ever been part of "the Apache way".

I think the cvs-svn experience, and the wiki experience, would suggest
that we need to be mindful of the maintenance overhead of not
centralising some practical things.

But thats not the same as centralisation as a principle.

And as a final point, don't take this too seriously but... the ASF and
"the Apache Way" has probably been shaped more than we would like to
admit by the workflow imposed by CVS. SVN is very similar, but
distributed source control has very different workflow which would
either conflict with or change "the way" if adopted.

d.

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Subversion vs other source control systems

[Assaf Arkin <ar...@intalio.com>]

On 2/17/08, Noel J. Bergman <no...@devtech.com> wrote:
>
> But visibility of the content and process very much IS part of "the Apache
> Way."
>
> Most of the use cases mentioned so far for git, including some where
> people are using it on top of SVN with ASF projects, run counter to ASF
> principles.  It is *NOT* in our best interests and practices for people to
> work in private on bulk code, and periodically submit big changes.  We want
> those changes made in public view in Subversion branches where the Community
> can see the work in progress, not when it is complete.  We need to reeducate
> people who believe otherwise.
>
> That said, I am not saying that people can't use whatever SVN client(s)
> they want to use.  I am saying that (a) the ASF has a uniform source control
> infrastructure, which is currently based on SVN servers, and (b) our
> practices mean that development is done in public, not done in private and
> submitted en masse as a fait accompli.  These statements are independent of
> the SCM technology used by the ASF.


With all the recent interest in distributed version control, I decided to do
some research.  I looked at git, hg and bzr and nothing that I read out
there convinced me that any of them offers a significant advantage over SVN.

So I decided to try one.  The productivity gain was enough to win me over.
 My experience is that it works much better especially for projects that
involve a distributed community of developers.

DVC do not use the same terminology as SVN.  With SVN you check out code
into your local working copy, with DVC the working copy is a repository, so
checking out is effectively creating a branch.  Likewise, you do not commit
from working copy to central repository, but merge from your local
repository to a more authoritive one.

So I can see how it sounds like developers on DVC are working in the dark on
big changes outside of community visibility, but only because with SVN
branches tend to encapsulate large changes.  In DVC branching and merging
are done instead of checkout and commit, there's nothing anti-social about
this practice.


It's also only when you consider that every svn update and svn commit is
essentially a merge (in DVC terminology) that you realize how frequent
merges are, any why any small improvment on merge is a significant benefit.

My experience is mostly with small projects, and it does make a difference
even when working in small teams, so definitely something we should consider
for incubation projects.  In fact, I think it will be easier and lower risk
to start the journey to DVC there.


Assaf

Re: Subversion vs other source control systems

[Justin Erenkrantz <ju...@erenkrantz.com>]

On Feb 17, 2008 7:51 AM, Noel J. Bergman <no...@devtech.com> wrote:
> But visibility of the content and process very much IS part of "the Apache Way."
>
> Most of the use cases mentioned so far for git, including some where people are using it on top of SVN with ASF projects, run counter to ASF principles.  It is *NOT* in our best interests and practices for people to work in private on bulk code, and periodically submit big changes.  We want those changes made in public view in Subversion branches where the Community can see the work in progress, not when it is complete.  We need to reeducate people who believe otherwise.
>
> That said, I am not saying that people can't use whatever SVN client(s) they want to use.  I am saying that (a) the ASF has a uniform source control infrastructure, which is currently based on SVN servers, and (b) our practices mean that development is done in public, not done in private and submitted en masse as a fait accompli.  These statements are independent of the SCM technology used by the ASF.

+1.  -- justin

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Subversion vs other source control systems

[Justin Erenkrantz <ju...@erenkrantz.com>]

On Feb 18, 2008 1:01 PM, Robert Burrell Donkin
<ro...@gmail.com> wrote:
> the last time i tried SVK, changes would be needed to SVK before it
> could work with a repository as big as apache

FWIW, the partial svnsync changes that SVK would need are present in
1.5.  I don't know if the SVK community has picked up on that yet, but
SVN 1.5 clients/servers will support it.  -- justin

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Subversion vs other source control systems

[Robert Burrell Donkin <ro...@gmail.com>]

On Feb 18, 2008 2:08 PM, Daniel S. Haischt
<da...@googlemail.com> wrote:
> Seems like people weren't interested in SVK but solely in Git. Otherwise
> this thread would have come to an end pretty soon without the need of
> all the FUD cause I suggested/asked to use SVK some days ago already.

the last time i tried SVK, changes would be needed to SVK before it
could work with a repository as big as apache

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Subversion vs other source control systems

["Daniel S. Haischt" <da...@googlemail.com>]

Seems like people weren't interested in SVK but solely in Git. Otherwise
this thread would have come to an end pretty soon without the need of
all the FUD cause I suggested/asked to use SVK some days ago already.

It doesn't figure why infrastructure stuff needs to be discussed in
such a intensity on the incubator list anyway.

Just my two cents ...

Noah Slater wrote:
> 
> Sorry for butting in this discussion, but I would like to point out that this is
> only a problem for the standard Subversion client. As an SVK user (another
> Subversion client) I regularly make use of off-line commits, local mirroring and
> smart merges.
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Subversion vs other source control systems

[Noah Slater <ns...@bytesexual.org>]

>   Use case: work on apache project while on plane
>   -----------------------------------------------
>   * export list of jiras of your favorite ASF project into spreadsheet
>   * sync project repo to your laptop
>   * get on a plane for 14 hours
>   * slave away at the bug list, fixing a bunch
>     * create one patch per bug, with a good commit message, referring
>       to the bug report, and commit locally
>   * get off the plane
>   * get online
>   * sync project repo to your laptop
>     * resolve any conflicts
>   * for each bug report
>     * submit and commit the fix
>     * close the bug report
>
> This is easy to do with git. It's a small nightmare with SVN, especially
> if your project is a million lines of code.

Sorry for butting in this discussion, but I would like to point out that this is
only a problem for the standard Subversion client. As an SVK user (another
Subversion client) I regularly make use of off-line commits, local mirroring and
smart merges.

--
Noah Slater <http://bytesexual.org/>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Subversion vs other source control systems

[sebb <se...@gmail.com>]

[Apologies to incubator readers if you get this twice]

On 20/02/2008, Santiago Gala <sg...@apache.org> wrote:
>
> El mar, 19-02-2008 a las 23:06 -0500, Noel J. Bergman escribió:
> > Endre Stølsvik wrote:
> >
> > > I find the decision to use one single SVN repo for the entire
> > > organization's source pretty strange. I'd believe that one repo
> > > for every TLP
> >
> > Been there, done that, have the scars.
> >
>
> Possibly using several *centralized* repositories that can't merge. May
> we know more? If not, I call FUD ask the jury to ignore the
> statement. :)
>
> > > The only downside I see is a slight bit more configuration management
> >
> > Don't be so blithe about that.
> >
>
> I actually think management would be way smaller. And, what is more
> important, distributable per repository.
>

Even if a smaller repository causes less work, there will necessarily
be some overhead per different repository - e.g. upgrades.

Switching between different repositories to work on them will generate
some overhead (if only having to think about it).

Which is easier to manage: 30 accounts with various different banks,
or one bank account with 30 times the transactions?

The work is only distributable to the extent that there are multiple
people to whom to distribute it; and certain actions would likely
still need to be co-ordinated between them.

> > > and that copying/moving a file from one repo to another would not keep history
> >
> > Unacceptable to lose it, IMO.
> >
>
> Can be done without losing history. See separate email. And I have done
> the same test with hg (basically the same) and bazaar (which required
> some command line tweaking, but doable).
>
> > And you'd be surprised how often things move around.
> >
>
> If you take a look into the basic development model in the linux kernel,
> it means moving history between repositories continuously (say from am
> to net to linus,...) Every line of code is tracked while it moves, in
> fact when Linus merges from, say, the acpi tree, the commits remain
> identical.
>
> Regards
> Santiago (I add cc: and reply-to: community)

Thanks.

> >       --- Noel
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org

Re: Subversion vs other source control systems

[sebb <se...@gmail.com>]

[Apologies to incubator readers if you get this twice]

On 20/02/2008, Santiago Gala <sg...@apache.org> wrote:
>
> El mar, 19-02-2008 a las 23:06 -0500, Noel J. Bergman escribió:
> > Endre Stølsvik wrote:
> >
> > > I find the decision to use one single SVN repo for the entire
> > > organization's source pretty strange. I'd believe that one repo
> > > for every TLP
> >
> > Been there, done that, have the scars.
> >
>
> Possibly using several *centralized* repositories that can't merge. May
> we know more? If not, I call FUD ask the jury to ignore the
> statement. :)
>
> > > The only downside I see is a slight bit more configuration management
> >
> > Don't be so blithe about that.
> >
>
> I actually think management would be way smaller. And, what is more
> important, distributable per repository.
>

Even if a smaller repository causes less work, there will necessarily
be some overhead per different repository - e.g. upgrades.

Switching between different repositories to work on them will generate
some overhead (if only having to think about it).

Which is easier to manage: 30 accounts with various different banks,
or one bank account with 30 times the transactions?

The work is only distributable to the extent that there are multiple
people to whom to distribute it; and certain actions would likely
still need to be co-ordinated between them.

> > > and that copying/moving a file from one repo to another would not keep history
> >
> > Unacceptable to lose it, IMO.
> >
>
> Can be done without losing history. See separate email. And I have done
> the same test with hg (basically the same) and bazaar (which required
> some command line tweaking, but doable).
>
> > And you'd be surprised how often things move around.
> >
>
> If you take a look into the basic development model in the linux kernel,
> it means moving history between repositories continuously (say from am
> to net to linus,...) Every line of code is tracked while it moves, in
> fact when Linus merges from, say, the acpi tree, the commits remain
> identical.
>
> Regards
> Santiago (I add cc: and reply-to: community)

Thanks.

> >       --- Noel
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Subversion vs other source control systems

[sebb <se...@gmail.com>]

On 20/02/2008, Santiago Gala <sg...@apache.org> wrote:
>
> El mar, 19-02-2008 a las 23:06 -0500, Noel J. Bergman escribió:
> > Endre Stølsvik wrote:
> >
> > > I find the decision to use one single SVN repo for the entire
> > > organization's source pretty strange. I'd believe that one repo
> > > for every TLP
> >
> > Been there, done that, have the scars.
> >
>
> Possibly using several *centralized* repositories that can't merge. May
> we know more? If not, I call FUD ask the jury to ignore the
> statement. :)
>
> > > The only downside I see is a slight bit more configuration management
> >
> > Don't be so blithe about that.
> >
>
> I actually think management would be way smaller. And, what is more
> important, distributable per repository.
>

Even if a smaller repository causes less work, there will necessarily
be some overhead per different repository - e.g. upgrades.

Switching between different repositories to work on them will generate
some overhead (if only having to think about it).

Which is easier to manage: 30 accounts with various different banks,
or one bank account with 30 times the transactions?

The work is only distributable to the extent that there are multiple
people to whom to distribute it; and certain actions would likely
still need to be co-ordinated between them.

> > > and that copying/moving a file from one repo to another would not keep history
> >
> > Unacceptable to lose it, IMO.
> >
>
> Can be done without losing history. See separate email. And I have done
> the same test with hg (basically the same) and bazaar (which required
> some command line tweaking, but doable).
>
> > And you'd be surprised how often things move around.
> >
>
> If you take a look into the basic development model in the linux kernel,
> it means moving history between repositories continuously (say from am
> to net to linus,...) Every line of code is tracked while it moves, in
> fact when Linus merges from, say, the acpi tree, the commits remain
> identical.
>
> Regards
> Santiago (I add cc: and reply-to: community)

Thanks.

> >       --- Noel
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

RE: Subversion vs other source control systems

[Santiago Gala <sg...@apache.org>]

El mar, 19-02-2008 a las 23:06 -0500, Noel J. Bergman escribió:
> Endre Stølsvik wrote:
> 
> > I find the decision to use one single SVN repo for the entire 
> > organization's source pretty strange. I'd believe that one repo
> > for every TLP
> 
> Been there, done that, have the scars.
> 

Possibly using several *centralized* repositories that can't merge. May
we know more? If not, I call FUD ask the jury to ignore the
statement. :)

> > The only downside I see is a slight bit more configuration management
> 
> Don't be so blithe about that.
> 

I actually think management would be way smaller. And, what is more
important, distributable per repository.

> > and that copying/moving a file from one repo to another would not keep history 
> 
> Unacceptable to lose it, IMO.
> 

Can be done without losing history. See separate email. And I have done
the same test with hg (basically the same) and bazaar (which required
some command line tweaking, but doable).

> And you'd be surprised how often things move around.
> 

If you take a look into the basic development model in the linux kernel,
it means moving history between repositories continuously (say from am
to net to linus,...) Every line of code is tracked while it moves, in
fact when Linus merges from, say, the acpi tree, the commits remain
identical.

Regards
Santiago (I add cc: and reply-to: community)

> 	--- Noel
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org

RE: Subversion vs other source control systems

[Santiago Gala <sg...@apache.org>]

El mar, 19-02-2008 a las 23:06 -0500, Noel J. Bergman escribió:
> Endre Stølsvik wrote:
> 
> > I find the decision to use one single SVN repo for the entire 
> > organization's source pretty strange. I'd believe that one repo
> > for every TLP
> 
> Been there, done that, have the scars.
> 

Possibly using several *centralized* repositories that can't merge. May
we know more? If not, I call FUD ask the jury to ignore the
statement. :)

> > The only downside I see is a slight bit more configuration management
> 
> Don't be so blithe about that.
> 

I actually think management would be way smaller. And, what is more
important, distributable per repository.

> > and that copying/moving a file from one repo to another would not keep history 
> 
> Unacceptable to lose it, IMO.
> 

Can be done without losing history. See separate email. And I have done
the same test with hg (basically the same) and bazaar (which required
some command line tweaking, but doable).

> And you'd be surprised how often things move around.
> 

If you take a look into the basic development model in the linux kernel,
it means moving history between repositories continuously (say from am
to net to linus,...) Every line of code is tracked while it moves, in
fact when Linus merges from, say, the acpi tree, the commits remain
identical.

Regards
Santiago (I add cc: and reply-to: community)

> 	--- Noel
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

RE: Subversion vs other source control systems

["Noel J. Bergman" <no...@devtech.com>]

Endre Stølsvik wrote:

> I find the decision to use one single SVN repo for the entire 
> organization's source pretty strange. I'd believe that one repo
> for every TLP

Been there, done that, have the scars.

> The only downside I see is a slight bit more configuration management

Don't be so blithe about that.

> and that copying/moving a file from one repo to another would not keep history 

Unacceptable to lose it, IMO.

And you'd be surprised how often things move around.

	--- Noel



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Subversion vs other source control systems

[Santiago Gala <sg...@apache.org>]

El mar, 19-02-2008 a las 22:29 +0100, Endre Stølsvik escribió:
> Upayavira wrote:
> > Justin put it very well in a related thread elsewhere (permission
> > sought):
> 
> [ CHOP interesting adamant view from Justin ]
> (Where is "elsewhere", btw?)
> 

the discussion spread to a private list outside here. We should move
this kind of discussion to a different public list, I guess it is mostly
out of scope in general@incubator (except in the "what is the apache
way", probably) I will try to post a followup in community, again.

> What I find strange in all this is the view that ALL projects at Apache 
> would have to change to OtherSCM if one project would want that..
> 

I also find it strange. I guess it spreads from the fact that subversion
(or old cvs) can only preserve history easily when moving inside the
same repository.

I made an experiment, which I will publish in a blog entry, where I
"pulled" from repo2 into repo1 for two git repos. This is easy and
works, provided that there are no name collisions that are not supposed
to be merged together. If I have a hypothetical podling1 repo and
another hypothetical targetTLP1 repo, I could (say on graduation) do:

cd podling1
git-branch to_target1
git-checkout to_target1
mkdir target-tree
git mv * target-tree #"*" does not work but you get the idea...
git-commit -a -m "this is for targetTLP after graduation"
cd ../targetTLP1
git-branch merge_podling1
git-checkout merge_podling1
git-pull ../podling1 #it could be a remote repo too
...
git commit -a -m "merged podling1 in targettree"
gitk --all #to view the merged repos, it has a new "tree" in target-tree


And proceed moving code around or merging as appropriate. (Not sure how
would hg or bzr handle this use case). I don't know how this would work
in practice, there is a need to experiment this kind of things to find
corner cases and problems. But I think, as you comment in the following
paragraph, that it buys us lots of extra flexibility and scalability.

> Indeed, I find the decision to use one single SVN repo for the entire 
> organization's source pretty strange. I'd believe that one repo for 
> every TLP, for example, would be great (AFAIK, TLP-promotion can be 
> handled too with history preserved). This would help in every single 
> aspect in regard to the volume of source and activity, could use 
> multiple servers etc - and incidentally using another SCM for a 
> particular project wouldn't be that big a deal anymore. The only 
> downside I see is a slight bit more configuration management, and that 
> copying/moving a file from one repo to another would not keep history 
> that well. How often does this happen, though?

Actually, if you try the above as I have done with a couple of small
repos, it keeps the whole history, including moves, committer info, etc.
Typically modern SCM (this includes subversion FWIK) don't "version
files", but rather "store graphs of commits/changesets". This means that
pulling a commit from a different repository will go pulling parent
commits up to the first common commit or, lacking it, to the root of the
history.

Regards
Santiago


>    However, I'm no SVN expert, so I can easily have misunderstood 
> everything.
> 
> Endre.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Subversion vs other source control systems

[Upayavira <uv...@odoko.co.uk>]

On Tue, 2008-02-19 at 22:29 +0100, Endre Stølsvik wrote:
> Upayavira wrote:
> > Justin put it very well in a related thread elsewhere (permission
> > sought):
> 
> [ CHOP interesting adamant view from Justin ]
> (Where is "elsewhere", btw?)

Apache has a number of "internal" lists on which members communicate
amongst themselves regarding the organisation and operation of the
Foundation.

> What I find strange in all this is the view that ALL projects at Apache 
> would have to change to OtherSCM if one project would want that..

(a) we couldn't manage it otherwise, purely in terms of volunteer time
(b) we would have a disjoint set of the Foundation's core asset, which
might be acceptable temporarily, but would not as an ongoing situation.

> Indeed, I find the decision to use one single SVN repo for the entire 
> organization's source pretty strange. I'd believe that one repo for 
> every TLP, for example, would be great (AFAIK, TLP-promotion can be 
> handled too with history preserved). This would help in every single 
> aspect in regard to the volume of source and activity, could use 
> multiple servers etc - and incidentally using another SCM for a 
> particular project wouldn't be that big a deal anymore. The only 
> downside I see is a slight bit more configuration management, and that 
> copying/moving a file from one repo to another would not keep history 
> that well. How often does this happen, though?
>    However, I'm no SVN expert, so I can easily have misunderstood 
> everything.

The thing is, that we're working with an order of magnitude more
complexity here. Setting up a wiki, you'd think that was  relatively
simple task. However, once we'd set up MoinMoin wiki, we found it
couldn't handle the traffic, and entered upon a 2 month hacking bonanza
to get some kind of caching in front of it so that it would actually
stay up and respond in reasonable time. And that was only one of the
issues. We had similar issues in the early days of SVN, and we would hve
similar issues in the early days of _any_ new piece of technology that
is introduced here. That is why infra folks are resistant - they have,
by direct experience, knowledge of what it is like to change this kind
of stuff.

HTH.

Upayavira



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Subversion vs other source control systems

[Endre Stølsvik <En...@stolsvik.com>]

Upayavira wrote:
> Justin put it very well in a related thread elsewhere (permission
> sought):

[ CHOP interesting adamant view from Justin ]
(Where is "elsewhere", btw?)

What I find strange in all this is the view that ALL projects at Apache 
would have to change to OtherSCM if one project would want that..

Indeed, I find the decision to use one single SVN repo for the entire 
organization's source pretty strange. I'd believe that one repo for 
every TLP, for example, would be great (AFAIK, TLP-promotion can be 
handled too with history preserved). This would help in every single 
aspect in regard to the volume of source and activity, could use 
multiple servers etc - and incidentally using another SCM for a 
particular project wouldn't be that big a deal anymore. The only 
downside I see is a slight bit more configuration management, and that 
copying/moving a file from one repo to another would not keep history 
that well. How often does this happen, though?
   However, I'm no SVN expert, so I can easily have misunderstood 
everything.

Endre.

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Subversion vs other source control systems

[Upayavira <uv...@odoko.co.uk>]

On Tue, 2008-02-19 at 11:51 +0100, Endre Stølsvik wrote:
> Justin Erenkrantz wrote:
> > On Feb 18, 2008 10:48 AM, Santiago Gala <sg...@apache.org> wrote:
> >> outright FUD? Sorry but I don't think there is Fear, Uncertainty or
> >> Doubt in this thread. There are several testimonies of good experiences
> > 
> > I feel there has been lots of FUD and if you don't realize that, then
> > I recommend taking a step back.
> 
> Please define FUD for us, will you? Because I haven't seen one single 
> iota of FUD on this thread - it has stayed strangely on topic, with good 
> arguments from both sides, and not once has the discussion gone into 
> "SCM XYZ often ruins the code base by introducing strange bit 
> errors"-style "half-lies" which is what I associate with FUD.
>    A/k/a "The Microsoft Tactics" in regards to Linux.

I'm not going to argue whether there specifically is "FUD", but there is
_serious_ underestimation of what it takes to roll out something as
crucial as source control within an organisation the size of Apache, and
with a repository the size of Apache.

Justin put it very well in a related thread elsewhere (permission
sought):

                           - o -

"The JAMES PMC knows that if they want to run on apache.org, they have
to handle *all* of the list traffic - not just their list.  So far,
they've not made a request to do so.  In some cases, it doesn't have
to be total conversion - for example, in infra, we're very hopeful
that we can run Harmony in some cases where we run Java - but Harmony
is not yet capable of running Confluence, so we can't switch over.
But, for a SCM, it *must* be on a path towards total conversion -
nothing less is acceptable, IMO.  We will *not* have a fractured
repository system like FreeBSD or Perl.

"If a PMC asked to run their own individual SCMs, they'd simply be
turned down.  If we switch our SCM to anything else, *everything* must
switch over.  IMO, at this point, we simply do not have anything other
than a few people who may have used git a few times - but we certainly
don't have any folks who appear willing to step up and realistically
and soberly consider what it means to change *everything* over.
Compare and contrast our experience with Subversion and let that
*truly* sink in if you're even a bit flippant about what it means to
switch.  Converting from CVS to Subversion took *years* to accomplish
and it took a *lot* of us getting deep inside the SVN community and
codebase to make sure it'd work for us.  Converting to something else
would take a realistically long time as well with a concomitant set of
expectations that folks will actively improve the tool to meet our
requirements.  So far, all I'm seeing is a few people saying, "It'd be
nice if someone else converts the ASF to git."  Those comments are
completely irrational and misguided as to how we work.  If you're so
bent on getting us on another SCM, then join the infrastructure list
and start proving that it's better than SVN.

"FWIW, git and mercurial (mercurial is *far* better than git in my
experience; it's not even close, to be honest) do not scale well to
*really* *really* large repositories.  If you look at KDE's trial
migration to git (which Joe and myself and others are watching
closely), they are separating every KDE deliverable into a separate
git repository.  (That is, every KDE library gets its own git
repository - so kdelibs and kdedesktop are treated separately.)  KDE
is explicitly willing to lose history when they move things between
repositories.  I'm frankly not sure that we'd find that acceptable.
Mercurial has sketched out a concept of 'forests' (of related
repositories), but again they're not thinking in terms of anything
other than an individual codebase - certainly not 25GB+ and across 60+
TLPs.  And, AFAICT, the concept of 'forests' is sketchy and not a part
of the core Mercurial codebase (think svn:externals and you've got an
idea how they implemented 'forests').  Again, with those SCMs, they're
perfectly willing to sacrifice history as it moves across those small
repositories as cross-project history is not something they care to
support."

                          - o -

Now, that, in my impression, puts the situation very well. If we were to
switch to git, or anything else, there would be huge issues involved,
and would be probably years of work to manage the transition. If that is
what is generally wanted, then we need volunteers who will put
themselves behind the task. No small feat. I have seen such changes
happen at Apache - they can, but the issues involved from an
infrastructure point of view are invariably an order of magnitude (if
not two orders) harder than those you see on one's own, typically
smaller, installations.

Regards, Upayavira
 


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Subversion vs other source control systems

[Endre Stølsvik <En...@stolsvik.com>]

Justin Erenkrantz wrote:
> On Feb 18, 2008 10:48 AM, Santiago Gala <sg...@apache.org> wrote:
>> outright FUD? Sorry but I don't think there is Fear, Uncertainty or
>> Doubt in this thread. There are several testimonies of good experiences
> 
> I feel there has been lots of FUD and if you don't realize that, then
> I recommend taking a step back.

Please define FUD for us, will you? Because I haven't seen one single 
iota of FUD on this thread - it has stayed strangely on topic, with good 
arguments from both sides, and not once has the discussion gone into 
"SCM XYZ often ruins the code base by introducing strange bit 
errors"-style "half-lies" which is what I associate with FUD.
   A/k/a "The Microsoft Tactics" in regards to Linux.

Endre.


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Subversion vs other source control systems

[Justin Erenkrantz <ju...@erenkrantz.com>]

On Feb 18, 2008 10:48 AM, Santiago Gala <sg...@apache.org> wrote:
> outright FUD? Sorry but I don't think there is Fear, Uncertainty or
> Doubt in this thread. There are several testimonies of good experiences

I feel there has been lots of FUD and if you don't realize that, then
I recommend taking a step back.

> Not in my copies (I tested Gentoo linux amd64, subversion-1.4.6, and a
> different 1.4.3 Mandriva rpm). I guess they don't ship "contrib" stuff.
...
> Well, I tried svk, git, mercurial and bzr. I am even using darcs because
> of some openID code I track. I prefer git, even when forced to use
> git-svn, to svk. Still, I will try to look into svnmerge.py, I found it
> here http://www.orcaware.com/svn/wiki/Svnmerge.py

That's ancient.  svnmerge.py lives in the subversion codebase:

http://svn.collab.net/repos/svn/trunk/contrib/client-side/svnmerge/

In Ubuntu, it's part of subversion-tools package.  I don't profess to
know where your OS ships it, but Ubuntu has it available for one.  I
don't know how current that svnmerge.py is, but it's there...

> Linus Torvalds discusses extensively work flow processes in
> http://git.or.cz/gitwiki/LinusTalk200705Transcript , and I think he is
> mostly right in the fact that distribution is the way to go, and not
> just because of disconnected operation. In one of the projects I track
> and patch, I don't commit myself, but I have contributed a number of
> components and patches and I keep ongoing patches. I would never be able
> to use svnmerge.py without the ability to create branches or commit.

Linus has his own ideas how a projects should run which are not, uh,
quite compatible with how Apache projects operate.  In other words,
there is one VIP who cuts all releases or holds onto the 'official'
repository.  Distributed SCMs are often ideal for ego-centric open
source.  -- justin

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Subversion vs other source control systems

[Santiago Gala <sg...@apache.org>]

El dom, 17-02-2008 a las 17:24 -0800, Justin Erenkrantz escribió:
> On Feb 17, 2008 3:34 PM, Santiago Gala <sg...@apache.org> wrote:
> > Also: you keep a long term branch for doing some refactoring, and you
> > fix small bugs both in HEAD and in a release branch, merging and
> > backporting/forwardporting as you go. Again, something like git makes
> > the work simpler and keeps the disk requirements under control.
> 
> In an attempt to stop some of the outright FUD in this thread before
> it goes on to yet another mailing list...

outright FUD? Sorry but I don't think there is Fear, Uncertainty or
Doubt in this thread. There are several testimonies of good experiences
with git, and the only "downplay" of subversion has been the problems
with merging, which I think are real. I would only call FUD if there had
been mentions, say, to subversion corrupting repositories or similar,
and I think those times are far in the past. 


> 
> I've found that svnmerge.py (distributed with SVN) handles pretty much
> all of the branch/merge tracking capabilities that I personally care
> about.  (The drawback is that it isn't as efficient as we'd like, but

Not in my copies (I tested Gentoo linux amd64, subversion-1.4.6, and a
different 1.4.3 Mandriva rpm). I guess they don't ship "contrib" stuff.
Linus Torvalds discusses extensively work flow processes in
http://git.or.cz/gitwiki/LinusTalk200705Transcript , and I think he is
mostly right in the fact that distribution is the way to go, and not
just because of disconnected operation. In one of the projects I track
and patch, I don't commit myself, but I have contributed a number of
components and patches and I keep ongoing patches. I would never be able
to use svnmerge.py without the ability to create branches or commit.

> it's good enough.  The 1.5 stuff is *way* faster.)  From your
> statements, you probably haven't bothered to try svnmerge.py (usable
> with 1.4.x) or any of the new reintegrate merge stuff in 1.5.  It
> makes it pretty brain-dead simple to handle most branch-oriented
> merging cases.  There are a few pathological cases that don't work
> well, but that's 'reflective' merging which isn't the 95% use case -
> so it got punted to post-1.5.  (svnmerge.py is probably the 80% use
> case, with 1.5 merge tracking being 90%, and reflective merging being
> that last gap...)

> FWIW, for svn.apache.org, I have a feeling we'll probably be a tad
> aggressive on rolling out 1.5.
> (Besides merge tracking, there are a number of excellent features in
> 1.5: changelist support, interactive conflict resolution, read/write
> transparent proxies, integrated 'diff -x -p' support, substantial
> svnsync speed improvements, partial svnsync ability, etc.)  Note that
> nothing is stopping you from using svnmerge.py today.  If folks are
> going to complain about switching to another SCM because of a lack of
> decent merging, then they owe it to themselves to check out what
> Subversion can actually do rather than what they think it can do...
> -- justin

Well, I tried svk, git, mercurial and bzr. I am even using darcs because
of some openID code I track. I prefer git, even when forced to use
git-svn, to svk. Still, I will try to look into svnmerge.py, I found it
here http://www.orcaware.com/svn/wiki/Svnmerge.py 

Regards
Santiago

> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Subversion vs other source control systems

[Justin Erenkrantz <ju...@erenkrantz.com>]

On Feb 17, 2008 3:34 PM, Santiago Gala <sg...@apache.org> wrote:
> Also: you keep a long term branch for doing some refactoring, and you
> fix small bugs both in HEAD and in a release branch, merging and
> backporting/forwardporting as you go. Again, something like git makes
> the work simpler and keeps the disk requirements under control.

In an attempt to stop some of the outright FUD in this thread before
it goes on to yet another mailing list...

I've found that svnmerge.py (distributed with SVN) handles pretty much
all of the branch/merge tracking capabilities that I personally care
about.  (The drawback is that it isn't as efficient as we'd like, but
it's good enough.  The 1.5 stuff is *way* faster.)  From your
statements, you probably haven't bothered to try svnmerge.py (usable
with 1.4.x) or any of the new reintegrate merge stuff in 1.5.  It
makes it pretty brain-dead simple to handle most branch-oriented
merging cases.  There are a few pathological cases that don't work
well, but that's 'reflective' merging which isn't the 95% use case -
so it got punted to post-1.5.  (svnmerge.py is probably the 80% use
case, with 1.5 merge tracking being 90%, and reflective merging being
that last gap...)

FWIW, for svn.apache.org, I have a feeling we'll probably be a tad
aggressive on rolling out 1.5.
(Besides merge tracking, there are a number of excellent features in
1.5: changelist support, interactive conflict resolution, read/write
transparent proxies, integrated 'diff -x -p' support, substantial
svnsync speed improvements, partial svnsync ability, etc.)  Note that
nothing is stopping you from using svnmerge.py today.  If folks are
going to complain about switching to another SCM because of a lack of
decent merging, then they owe it to themselves to check out what
Subversion can actually do rather than what they think it can do...
-- justin

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Subversion vs other source control systems

[Santiago Gala <sg...@apache.org>]

El dom, 17-02-2008 a las 19:12 +0100, Leo Simons escribió:
> On Feb 17, 2008, at 4:51 PM, Noel J. Bergman wrote:
> > Most of the use cases mentioned so far for git, including some  
> > where people are using it on top of SVN with ASF projects, run  
> > counter to ASF principles.
> 
> Let me fix that:
> 
>    Use case: work on apache project while on plane
>    -----------------------------------------------
>    * export list of jiras of your favorite ASF project into spreadsheet
>    * sync project repo to your laptop
>    * get on a plane for 14 hours
>    * slave away at the bug list, fixing a bunch
>      * create one patch per bug, with a good commit message, referring
>        to the bug report, and commit locally
>    * get off the plane
>    * get online
>    * sync project repo to your laptop
>      * resolve any conflicts
>    * for each bug report
>      * submit and commit the fix
>      * close the bug report
> 
> This is easy to do with git. It's a small nightmare with SVN,  
> especially if your project is a million lines of code.
> 

A big +1 on this use case. Have you tried this one?

Also: you keep a long term branch for doing some refactoring, and you
fix small bugs both in HEAD and in a release branch, merging and
backporting/forwardporting as you go. Again, something like git makes
the work simpler and keeps the disk requirements under control.


> (you could substitute "while on plane" with "even if network craps  
> out at hackathon" or with "at a customer site with big firewall")
> 
> > I am saying that (a) the ASF has a uniform source control  
> > infrastructure, which is currently based on SVN servers, and (b)  
> > our practices mean that development is done in public, not done in  
> > private and submitted en masse as a fait accompli.  These  
> > statements are independent of the SCM technology used by the ASF.
> 
> Exactly!
> 

Agreed too.

> 
> cheers,
> 
> 
> - Leo
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

RE: Subversion vs other source control systems

["Noel J. Bergman" <no...@devtech.com>]

Leo Simons wrote:

> Noel J. Bergman wrote:
> > Most of the use cases mentioned so far for git, including some
> > where people are using it on top of SVN with ASF projects, run
> > counter to ASF principles.

> Let me fix that [...]

Fine, but again, the Incubator isn't where ASF Infrastructure decisions are
made.  You know where to go to discuss improvement and/or migration of ASF
source management.

> > I am saying that (a) the ASF has a uniform source control
> > infrastructure, which is currently based on SVN servers, and (b)
> > our practices mean that development is done in public, not done in
> > private and submitted en masse as a fait accompli.  These
> > statements are independent of the SCM technology used by the ASF.

> Exactly!

Good, because this is the only thing from this discussion that's in scope
for the Incubator.

	--- Noel



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Subversion vs other source control systems

[Leo Simons <ma...@leosimons.com>]

On Feb 17, 2008, at 4:51 PM, Noel J. Bergman wrote:
> Most of the use cases mentioned so far for git, including some  
> where people are using it on top of SVN with ASF projects, run  
> counter to ASF principles.

Let me fix that:

   Use case: work on apache project while on plane
   -----------------------------------------------
   * export list of jiras of your favorite ASF project into spreadsheet
   * sync project repo to your laptop
   * get on a plane for 14 hours
   * slave away at the bug list, fixing a bunch
     * create one patch per bug, with a good commit message, referring
       to the bug report, and commit locally
   * get off the plane
   * get online
   * sync project repo to your laptop
     * resolve any conflicts
   * for each bug report
     * submit and commit the fix
     * close the bug report

This is easy to do with git. It's a small nightmare with SVN,  
especially if your project is a million lines of code.

(you could substitute "while on plane" with "even if network craps  
out at hackathon" or with "at a customer site with big firewall")

> I am saying that (a) the ASF has a uniform source control  
> infrastructure, which is currently based on SVN servers, and (b)  
> our practices mean that development is done in public, not done in  
> private and submitted en masse as a fait accompli.  These  
> statements are independent of the SCM technology used by the ASF.

Exactly!


cheers,


- Leo


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

RE: Subversion vs other source control systems

["Noel J. Bergman" <no...@devtech.com>]

Santiago Gala wrote:

> Noel J. Bergman escribió:
> > No project was allowed to stay with CVS.  No project will be allowed to
> > use another source control system unless it is adopted at the ASF
> > level.  Source code is a critical, shared, public resource maintained
> > by the Foundation, not something whose storage is managed on a project
> > by project basis.  The Infrastructure Team maintains and protects that
> > shared resource on behalf of the Foundation.

> If I remember correctly, the policy was not to impose subversion, but to
> mandate end of life for CVS.

You remember incorrectly.  The mandate was to migrate from Infrastructure-managed CVS to Infrastructure-managed Subversion, not from CVS to the SCM of your choice.

> If I remember correctly, this was due to security concerns, CVS requiring
> user accounts in the machine where the repository is stored while subversion
> does not. Also functionality. Also that having a lengthy transition was
> stressing infrastructure. I have been looking into mail archives but have
> not found a pointer yet.

There were a variety of reasons, including the above, but none of that addresses your apparent belief that the ASF should support ad hoc and arbitrary selections of critical infrastructure by individual projects.

> - you are no longer considering the Foundation as an umbrella for the
>   projects, but as an entity with a life that, I see from your reaction,
>   needs to protect itself from the (some?) projects

That is an extreme interpretation.  I could as easily say that you are in favor of each project being able to maintain its own critical infrastructure on any servers anywhere with arbitrary security and community practices.  I don't believe that is your actual view, but I could take your words to say so.

> - The infrastructure team is a Police body ("to serve and protect")

Saying that ensuring availability and safety (from loss and/or tampering) is one of the goals we have with respect to our data is hardly the same as your claim.

> Information can be copied and still stays the same, trying to restrict
> it to a server is really futile and wasting.

I have no idea what you're talking about here.

> I don't think centralization has ever been part of "the Apache way".

But visibility of the content and process very much IS part of "the Apache Way."

Most of the use cases mentioned so far for git, including some where people are using it on top of SVN with ASF projects, run counter to ASF principles.  It is *NOT* in our best interests and practices for people to work in private on bulk code, and periodically submit big changes.  We want those changes made in public view in Subversion branches where the Community can see the work in progress, not when it is complete.  We need to reeducate people who believe otherwise.

That said, I am not saying that people can't use whatever SVN client(s) they want to use.  I am saying that (a) the ASF has a uniform source control infrastructure, which is currently based on SVN servers, and (b) our practices mean that development is done in public, not done in private and submitted en masse as a fait accompli.  These statements are independent of the SCM technology used by the ASF.

	--- Noel



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Subversion vs other source control systems

[Santiago Gala <sg...@apache.org>]

El mié, 13-02-2008 a las 18:28 -0500, Noel J. Bergman escribió:
> J Aaron Farr wrote:
> > J Aaron Farr wrote:
> >>> git could be an issue.
> > > Can you explain what the issue is with Git?
> > Leo already gave a decent explanation.
> > Basically, it comes down to two aspects:
> >   1) infrastructure support
> >   2) cultural bias
> 
> Only the first one is marginally correct, IMO.
> 
> Santiago wrote:
> > > 1. You have to use subversion.
> > Why? Has been a vote done? where? I vote +1 for git if a vote is still open.
> 
> No, there was no vote and is not vote, nor is there any choice. 
>  Subversion is one of the few things that the Board has mandated,
>  imposed on all projects.  Period.  Pretty much end of discussion.
> 
> No project was allowed to stay with CVS.  No project will be allowed to
>  use another source control system unless it is adopted at the ASF
>  level.  Source code is a critical, shared, public resource maintained
>  by the Foundation, not something whose storage is managed on a project
>  by project basis.  The Infrastructure Team maintains and protects that
>  shared resource on behalf of the Foundation.
> 

If I remember correctly, the policy was not to impose subversion, but to
mandate end of life for CVS. If I remember correctly, this was due to
security concerns, CVS requiring user accounts in the machine where the
repository is stored while subversion does not. Also functionality. Also
that having a lengthy transition was stressing infrastructure. I have
been looking into mail archives but have not found a pointer yet.

Funny enough, all people using distributed SCM quoted ease and
simplification of administration as one of the core advantages, be it
git, bazaar, mercurial or darcs.

If I read correctly your last two sentences, I see that
- you are no longer considering the Foundation as an umbrella for the
projects, but as an entity with a life that, I see from your reaction,
needs to protect itself from the (some?) projects
- The infrastructure team is a Police body ("to serve and protect")

Information can be copied and still stays the same, trying to restrict
it to a server is really futile and wasting. The only thing that
actually would need a "custody" would be a PGP-signed text document with
SHA1 of the release source and date. And I don't think it would be
signed by the infrastructure team, but by the three +1 voters of the
release in the PMC. And this "custody" can easily be achieved by
publishing in a multiply archived email list.

I don't think centralization has ever been part of "the Apache way".

Regards
Santiago

> 	--- Noel
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Subversion vs other source control systems

[Santiago Gala <sg...@apache.org>]

El jue, 14-02-2008 a las 14:32 +0100, Erik Abele escribió:
> On 14.02.2008, at 14:14, Santiago Gala wrote:
> 
> > ...
> > The typical workflow in distributed scm is that authoritative
> > repositories pull (as requested and after review) from non-official
> > ones, so typically security is easier: no longer lots of people with
> > write access, but only a handful, taking changesets from the rest  
> > of the
> > community.
> 
> Aye, and this is also the reason why it potentially conflicts with  
> the meritocratic model of the ASF; furthermore there are also legal  
> hurdles to cross etc.
> 

I can't see where are the legal or meritocratic problems, really.
Specially the legal ones. A changeset is a changeset, whereas it is
stored in subversion, several git repos or a patch in jira.

I can agree that some experimentation is needed to refine the work flows
and see how it works with our models, but denial will not help getting
work done in this area.

> In the end I think it's simply too early to discuss all this - let's  
> wait until some project comes up with a well-prepared and clearly  
> defined proposal to change their SCM. IMHO this is certainly not a  
> task for the Incubator or a podling...
> 

Neither is a task for the incubator PMC to freeze the new teams, and cut
off the fresh air from the ASF. Raising an expectation that you *can*
defy the powers-that-be here was my main aim in this whole thread. :)

> Cheers,
> Erik
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Subversion vs other source control systems

[Santiago Gala <sg...@apache.org>]

El jue, 14-02-2008 a las 14:45 +0100, Jochen Wiedmann escribió:
> On Thu, Feb 14, 2008 at 2:32 PM, Erik Abele <er...@codefaktor.de> wrote:
> 
> >  Aye, and this is also the reason why it potentially conflicts with
> >  the meritocratic model of the ASF; furthermore there are also legal
> >  hurdles to cross etc.
> >
> >  In the end I think it's simply too early to discuss all this - let's
> >  wait until some project comes up with a well-prepared and clearly
> >  defined proposal to change their SCM. IMHO this is certainly not a
> >  task for the Incubator or a podling...
> 
> Agreed. It's better to wait. Also note, that:
> 
> - For obvious reasons, git and other distributed VC systems are more suited
>   for larger projects with a real lot of contributors. Even in the case of the
>   top level projects, there aren't too many that qualify for that.

I don't see the "obvious reasons", of course excepting much better
performance of git. I mostly use bazaar for small projects, for instance
put /etc of a group of servers under version control, and have the
ability to commit remote configuration changes and then push to/pull
from the remote server. I think the smaller management overhead of
bazaar or git makes it easier than having to set up and protect svn
server and repositories.

> - Even now, it is possible to work with git, if you want to: See
> 
>     http://mail-archives.apache.org/mod_mbox/maven-dev/200709.mbox/%3C1B829E89-25ED-446D-B31D-A881692F949B@maven.org%3E
> 
>   I do not know how far Jason van Zyl's attempts have grown or not,

He is making basically the same points I tried to make, and with a lot
of enthusiasm too... I hope this will help convincing people to try any
of the tools.


> but the point
>   is that his intentions have been to gather experience. Anyone else is free to
>   do the same.


Well, I answered to Noel's:
> No, there was no vote and is not vote, nor is there any choice.
> Subversion is one of the few things that the Board has mandated,
> imposed on all projects.  Period.  Pretty much end of discussion.

because he was clearly implying that no, nobody is free to do the same.
Now at least I see that I'm not alone here. And hopefully people in
podlings will see that we are a bit less uniform and bureaucratic than
they were fearing. :)

Regards
Santiago

> 
> Jochen
> 
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Subversion vs other source control systems

[Jochen Wiedmann <jo...@gmail.com>]

On Thu, Feb 14, 2008 at 2:32 PM, Erik Abele <er...@codefaktor.de> wrote:

>  Aye, and this is also the reason why it potentially conflicts with
>  the meritocratic model of the ASF; furthermore there are also legal
>  hurdles to cross etc.
>
>  In the end I think it's simply too early to discuss all this - let's
>  wait until some project comes up with a well-prepared and clearly
>  defined proposal to change their SCM. IMHO this is certainly not a
>  task for the Incubator or a podling...

Agreed. It's better to wait. Also note, that:

- For obvious reasons, git and other distributed VC systems are more suited
  for larger projects with a real lot of contributors. Even in the case of the
  top level projects, there aren't too many that qualify for that.
- Even now, it is possible to work with git, if you want to: See

    http://mail-archives.apache.org/mod_mbox/maven-dev/200709.mbox/%3C1B829E89-25ED-446D-B31D-A881692F949B@maven.org%3E

  I do not know how far Jason van Zyl's attempts have grown or not,
but the point
  is that his intentions have been to gather experience. Anyone else is free to
  do the same.


Jochen



-- 
Look, that's why there's rules, understand? So that you think before
you break 'em.

 -- (Terry Pratchett, Thief of Time)

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Subversion vs other source control systems

[Erik Abele <er...@codefaktor.de>]

On 14.02.2008, at 14:14, Santiago Gala wrote:

> ...
> The typical workflow in distributed scm is that authoritative
> repositories pull (as requested and after review) from non-official
> ones, so typically security is easier: no longer lots of people with
> write access, but only a handful, taking changesets from the rest  
> of the
> community.

Aye, and this is also the reason why it potentially conflicts with  
the meritocratic model of the ASF; furthermore there are also legal  
hurdles to cross etc.

In the end I think it's simply too early to discuss all this - let's  
wait until some project comes up with a well-prepared and clearly  
defined proposal to change their SCM. IMHO this is certainly not a  
task for the Incubator or a podling...

Cheers,
Erik


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Subversion vs other source control systems

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Santiago Gala wrote:
> I'd say that if a project wants to have a distributed scm and makes a
> reasonable case of the reasons, they would ask for it to infrastructure.
> If infrastructure denies it and the project does not accept the
> reasoning or how it is exposed, we have a conflict. If there is a
> conflict the Board *has* to consider the issue. I'm not sure on how it
> is worded in the bylines.

Well, yes, board is the appeal of last resort.  But just like the board
rarely touches the third rail of making development decisions for a project,
they rarely make architectural decisions overriding infrastructure.

The right way is for infra to determine they won't do it unless ___ happens,
and appeal to the board to make ___ happen on behalf of the requester.

> While we typically value consensus a lot, we typically don't take
> bureaucratic answers as absolutes. Or at least that is how I remember
> the ASF used to be. :P

You can't have a less absolute bureaucratic result than bringing an issue
to the board ;-)

> The typical workflow in distributed scm is that authoritative
> repositories pull (as requested and after review) from non-official
> ones, so typically security is easier: no longer lots of people with
> write access, but only a handful, taking changesets from the rest of the
> community.

But there's a deep question of if this goes against the principals of the
meritocracy of peers that has worked so well for the ASF.  We don't and
wouldn't entertain such roles as code wrangler, project lead, etc.  It's
just not our ethos/social schema.

Bill

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Subversion vs other source control systems

[Santiago Gala <sg...@apache.org>]

El jue, 14-02-2008 a las 10:52 +0000, William A. Rowe, Jr. escribió:
> Janne Jalkanen wrote:
> >> No, there was no vote and is not vote, nor is there any choice.  
> >> Subversion is one of the few things that the Board has mandated, 
> >> imposed on all projects.  Period.  Pretty much end of discussion.
> > 
> > I would assume though that if there is enough interest among the 
> > community, the subject of supporting something like Git could be opened 
> > up with the Board, yes?
> 
> It's up to the infrastructure team to decide, the board is generally
> hands-off when it comes to their decisions for the foundation.
> 
> So it needs to be brought up to them.
> 

I'd say that if a project wants to have a distributed scm and makes a
reasonable case of the reasons, they would ask for it to infrastructure.
If infrastructure denies it and the project does not accept the
reasoning or how it is exposed, we have a conflict. If there is a
conflict the Board *has* to consider the issue. I'm not sure on how it
is worded in the bylines.

While we typically value consensus a lot, we typically don't take
bureaucratic answers as absolutes. Or at least that is how I remember
the ASF used to be. :P

Also, while all users have http://people.apache.org/~userid/ , a
git/bazaar/mercurial/darcs repo is only one scp away. I have set up cvs,
subversion, git and bazaar, and the last two were vastly easier to set
up and maintain. As I said, specially if ssh/sftp is there.

The typical workflow in distributed scm is that authoritative
repositories pull (as requested and after review) from non-official
ones, so typically security is easier: no longer lots of people with
write access, but only a handful, taking changesets from the rest of the
community.

Regards
Santiago

> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Subversion vs other source control systems

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Janne Jalkanen wrote:
>> No, there was no vote and is not vote, nor is there any choice.  
>> Subversion is one of the few things that the Board has mandated, 
>> imposed on all projects.  Period.  Pretty much end of discussion.
> 
> I would assume though that if there is enough interest among the 
> community, the subject of supporting something like Git could be opened 
> up with the Board, yes?

It's up to the infrastructure team to decide, the board is generally
hands-off when it comes to their decisions for the foundation.

So it needs to be brought up to them.



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Subversion vs other source control systems

[Janne Jalkanen <Ja...@ecyrd.com>]

> No, there was no vote and is not vote, nor is there any choice.   
> Subversion is one of the few things that the Board has mandated,  
> imposed on all projects.  Period.  Pretty much end of discussion.

I would assume though that if there is enough interest among the  
community, the subject of supporting something like Git could be  
opened up with the Board, yes?

/Janne, who does not really know how this bit of ASF works...

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Subversion vs other source control systems

["Daniel S. Haischt" <da...@googlemail.com>]

would SVK be an option? This would allow to re-use the already existing SVN
infrastracture.

No need for changes to the ASF infrastructure...

On Thu, Feb 14, 2008 at 1:55 PM, Santiago Gala <sg...@apache.org> wrote:
>
>  El jue, 14-02-2008 a las 12:37 +0100, Dirk-Willem van Gulik escribió:
>
> > On Feb 14, 2008, at 12:25 PM, Ross Gardler wrote:
>  >
>  > > Noel J. Bergman wrote:
>  > >> J Aaron Farr wrote:
>  > >>> J Aaron Farr wrote:
>  > >>>>> git could be an issue.
>  > >>>> Can you explain what the issue is with Git?
>  > >>> Leo already gave a decent explanation.
>  > >>> Basically, it comes down to two aspects:
>  > >>>  1) infrastructure support
>  > >>>  2) cultural bias
>  > >> Only the first one is marginally correct, IMO.
>  > >> Santiago wrote:
>  > >>>> 1. You have to use subversion.
>  > >
>  > >
>  > > Sorry, I've missed the thread that led to this, so sorry if I'm
>  > > repeating others.
>  > >
>  > > I understand that GiT can be used locally as a layer on top of SVN.
>  > > I believe this gives you most of the perceived benefits of GiT
>  > > locally without the need for a project itself to switch to GiT.
>  >
>  > I am a bit lost here as well -- what does GiT add to the processes/
>  > workflows common in the ASF ?
>  >
>
>  It adds:
>  - ability to have offline commits
>  - much faster repository diff, status, etc. that works offline
>  - (git-specific) ability to reorder and aggregate several private
>  commits to deliver a consistent patch. This can only be simulated with
>  other tools
>  - ability to publish (push/pull) branches easily for tests without
>  compromising the main line. Subversion branches, while easy to create,
>  are awful to maintain and rarely used.
>  - clean and remembered merges: patches with clear attribution that can
>  be merged multiple times which, again, makes easy maintenance of several
>  branches running in parallel.Backports, etc.
>
>
>
>  > One of the great things about GiT is that you can can have lots of
>  > parallel and non-linear merges (every developer their own branch; lots
>  > of people merging the same patch into different sequences) -- and as
>  > such I can see it being perfectly tuned for, say, Linux.
>  >
>
>  Precisely the fact that patches are accepted in just 'one' or 'a few'
>  points make invaluable having good maintenance of in-progress work.
>
>
>  > However in the ASF most groups work roughly along fairly linear lines;
>  > with 'one' or just a 'few' points at which a patch is accepted - and
>  > essentially few, or just one, merge point (or a single line of merge
>  > points when backported). Rarely do we merge multiple 'HEAD's.
>  >
>
>  Not in my experience, it is common to have in-progress work in parallel
>  with bugfixes, etc. subversion is awful for tracking multiple branches
>  in parallel, to the point that I have been using quilt for patch
>  management of top of subversion. This is clearly a kludge that reveals
>  the deficiencies of the workflow.
>
>  You see? "rarely do we merge multiple HEADs" is seen from the point of
>  view of the repository. If you have 10 developers working on patches,
>  you have 10 people merging continuously their branch with the "official"
>  one. Rarely applies only to the subversion repo.
>
>
>  > And I'd almost argue that SVN is a useful framework which helps us
>  > stay on the paved roads - where a single head progresses with group
>  > consensus and generally agreed merit.
>  >
>
>  I've seen plenty of times where having in-progress patches were
>  consistently conflicted by commits, which multiplied the work implied in
>  keeping them to the point of dropping them (personal). This is trivially
>  easy to do with bazaar or git, and I'm quite sure that darcs or
>  mercurial will offer the same comfort level.
>
>  At least for my development style, distributed SCM offers one order of
>  magnitude more comfortable environment than centralized SCM.
>
>  As for your concrete sentence, I'd say that if you need a technical tool
>  as a framework to impose a work flow, then the work flow is possibly
>  broken. If the work flow is sound, having a tool that eases the work
>  won't break it.
>
>  Regards
>  Santiago (who was working to deliver this and more info on technical
>  merits in the community@apache.org thread)
>
>
>
>  > Thanks,
>  >
>  > Dw
>  >
>  > ---------------------------------------------------------------------
>  > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>  > For additional commands, e-mail: general-help@incubator.apache.org
>
>
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>  For additional commands, e-mail: general-help@incubator.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Subversion vs other source control systems

[Santiago Gala <sg...@apache.org>]

El jue, 14-02-2008 a las 12:37 +0100, Dirk-Willem van Gulik escribió:
> On Feb 14, 2008, at 12:25 PM, Ross Gardler wrote:
> 
> > Noel J. Bergman wrote:
> >> J Aaron Farr wrote:
> >>> J Aaron Farr wrote:
> >>>>> git could be an issue.
> >>>> Can you explain what the issue is with Git?
> >>> Leo already gave a decent explanation.
> >>> Basically, it comes down to two aspects:
> >>>  1) infrastructure support
> >>>  2) cultural bias
> >> Only the first one is marginally correct, IMO.
> >> Santiago wrote:
> >>>> 1. You have to use subversion.
> >
> >
> > Sorry, I've missed the thread that led to this, so sorry if I'm  
> > repeating others.
> >
> > I understand that GiT can be used locally as a layer on top of SVN.  
> > I believe this gives you most of the perceived benefits of GiT  
> > locally without the need for a project itself to switch to GiT.
> 
> I am a bit lost here as well -- what does GiT add to the processes/ 
> workflows common in the ASF ?
> 

It adds:
- ability to have offline commits
- much faster repository diff, status, etc. that works offline
- (git-specific) ability to reorder and aggregate several private
commits to deliver a consistent patch. This can only be simulated with
other tools
- ability to publish (push/pull) branches easily for tests without
compromising the main line. Subversion branches, while easy to create,
are awful to maintain and rarely used.
- clean and remembered merges: patches with clear attribution that can
be merged multiple times which, again, makes easy maintenance of several
branches running in parallel.Backports, etc.


> One of the great things about GiT is that you can can have lots of  
> parallel and non-linear merges (every developer their own branch; lots  
> of people merging the same patch into different sequences) -- and as  
> such I can see it being perfectly tuned for, say, Linux.
> 

Precisely the fact that patches are accepted in just 'one' or 'a few'
points make invaluable having good maintenance of in-progress work. 

> However in the ASF most groups work roughly along fairly linear lines;  
> with 'one' or just a 'few' points at which a patch is accepted - and  
> essentially few, or just one, merge point (or a single line of merge  
> points when backported). Rarely do we merge multiple 'HEAD's.
> 

Not in my experience, it is common to have in-progress work in parallel
with bugfixes, etc. subversion is awful for tracking multiple branches
in parallel, to the point that I have been using quilt for patch
management of top of subversion. This is clearly a kludge that reveals
the deficiencies of the workflow.

You see? "rarely do we merge multiple HEADs" is seen from the point of
view of the repository. If you have 10 developers working on patches,
you have 10 people merging continuously their branch with the "official"
one. Rarely applies only to the subversion repo.

> And I'd almost argue that SVN is a useful framework which helps us  
> stay on the paved roads - where a single head progresses with group  
> consensus and generally agreed merit.
> 

I've seen plenty of times where having in-progress patches were
consistently conflicted by commits, which multiplied the work implied in
keeping them to the point of dropping them (personal). This is trivially
easy to do with bazaar or git, and I'm quite sure that darcs or
mercurial will offer the same comfort level.

At least for my development style, distributed SCM offers one order of
magnitude more comfortable environment than centralized SCM.

As for your concrete sentence, I'd say that if you need a technical tool
as a framework to impose a work flow, then the work flow is possibly
broken. If the work flow is sound, having a tool that eases the work
won't break it.

Regards
Santiago (who was working to deliver this and more info on technical
merits in the community@apache.org thread)

> Thanks,
> 
> Dw
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Subversion vs other source control systems

[Jukka Zitting <ju...@gmail.com>]

Hi,

On Tue, Feb 19, 2008 at 1:06 PM, Emmanuel Lecharny <el...@gmail.com> wrote:
> Endre Stølsvik wrote:
>  > Why should this discussion be moved into a Apache-private realm, and
>  > not just stay fully public, so that I can watch the proceedings? This
>  > is an interesting discussion.
>
>  Can we please keep the Incubator ML focused ???

I'm currently gathering interest [1] about starting an effort at
Apache Labs to further explore ideas related to dSCM at Apache. If
you're interested, you'll find us at labs@labs.apache.org.

[1] http://mail-archives.apache.org/mod_mbox/labs-labs/200802.mbox/%3c510143ac0802200413n59d27aa5h7c9bb12c3b5e001@mail.gmail.com%3e

BR,

Jukka Zitting

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Subversion vs other source control systems

[Emmanuel Lecharny <el...@gmail.com>]

Endre Stølsvik wrote:
>
> Why should this discussion be moved into a Apache-private realm, and 
> not just stay fully public, so that I can watch the proceedings? This 
> is an interesting discussion.

Can we please keep the Incubator ML focused ???



-- 
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Subversion vs other source control systems

[Endre Stølsvik <En...@stolsvik.com>]

Paul Querna wrote:
> Santiago Gala wrote:
>> El dom, 17-02-2008 a las 19:02 -0500, Noel J. Bergman escribió:
>>> No.  This is the wrong forum.  What we've said here is that there 
>>> won't be any deviation from the ASF infrastructure for source 
>>> control; changing ASF infrastructure is out of scope for the Incubator.
>>
>> I already tried to move the discussion to community@apache.org, where I
>> think it belongs, but people insists on answering here. Making requests
>> to a closed team
> 
> "Infrastructure" isn't a closed team by any means, and I am tired of 
> people propagating that bullshit.  Come help, and karma comes.
> 
>> in a private list does not accord with *our way of
>> working*, I think. And I don't think there is any need to use a private,
>> unarchived list for discussions on infrastructure improvements.
> 
> infrastructure is open to all committers.
> infrastructure-dev is open to all committers.
> infrastructure-private is open to all members.

Why should this discussion be moved into a Apache-private realm, and not 
just stay fully public, so that I can watch the proceedings? This is an 
interesting discussion.
   So far, Santiago has some pretty neat arguments going! :-)

Endre.

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Subversion vs other source control systems

[Roland Weber <os...@dubioso.net>]

Daniel Kulp wrote:
> On Monday 18 February 2008, Paul Querna wrote:
>>> in a private list does not accord with *our way of
>>> working*, I think. And I don't think there is any need to use a
>>> private, unarchived list for discussions on infrastructure
>>> improvements.
>> infrastructure is open to all committers.
>> infrastructure-dev is open to all committers.
>> infrastructure-private is open to all members.
>>
>> All of them are archived.
> 
> None of them are available to see at:
> http://mail-archives.apache.org/mod_mbox/

The EZMLM archives are available to every subscriber.
Send a mail to <listname>-help to get instructions.
There's probably also a way to access raw archives, I'm
sure the folks on infra can tell you how to get there.

The free-for-everyone archives on mail-archives.a.o
are obviously only for list where everyone is allowed
to see the messages, not for committers-only lists.
There is no archive of committers@a.o there either.

cheers,
   Roland


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Subversion vs other source control systems

[Paul Querna <ch...@force-elite.com>]

Daniel Kulp wrote:
> On Monday 18 February 2008, Paul Querna wrote:
>>> in a private list does not accord with *our way of
>>> working*, I think. And I don't think there is any need to use a
>>> private, unarchived list for discussions on infrastructure
>>> improvements.
>> infrastructure is open to all committers.
>> infrastructure-dev is open to all committers.
>> infrastructure-private is open to all members.
>>
>> All of them are archived.
>>
> 
> None of them are available to see at:
> http://mail-archives.apache.org/mod_mbox/
> 
> Thus, they look pretty private to me. 

They are not available on the public web interface, the archives are 
available to all committers on people.apache.org.

"private" is an interesting choice of words, but I personally don't 
consider them very private with 1600++ committers having access.

Should some or all of them be available on the web interface? I'm not 
sure, but bring it up on the infrastructure lists.

-Paul

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Subversion vs other source control systems

[Daniel Kulp <dk...@apache.org>]

On Monday 18 February 2008, Paul Querna wrote:
> > in a private list does not accord with *our way of
> > working*, I think. And I don't think there is any need to use a
> > private, unarchived list for discussions on infrastructure
> > improvements.
>
> infrastructure is open to all committers.
> infrastructure-dev is open to all committers.
> infrastructure-private is open to all members.
>
> All of them are archived.
>

None of them are available to see at:
http://mail-archives.apache.org/mod_mbox/

Thus, they look pretty private to me. 


-- 
J. Daniel Kulp
Principal Engineer, IONA
dkulp@apache.org
http://www.dankulp.com/blog

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Subversion vs other source control systems

[Paul Querna <ch...@force-elite.com>]

Santiago Gala wrote:
> El dom, 17-02-2008 a las 19:02 -0500, Noel J. Bergman escribió:
>> No.  This is the wrong forum.  What we've said here is that there won't be any deviation from the ASF infrastructure for source control; changing ASF infrastructure is out of scope for the Incubator.
> 
> I already tried to move the discussion to community@apache.org, where I
> think it belongs, but people insists on answering here. Making requests
> to a closed team

"Infrastructure" isn't a closed team by any means, and I am tired of 
people propagating that bullshit.  Come help, and karma comes.

> in a private list does not accord with *our way of
> working*, I think. And I don't think there is any need to use a private,
> unarchived list for discussions on infrastructure improvements.

infrastructure is open to all committers.
infrastructure-dev is open to all committers.
infrastructure-private is open to all members.

All of them are archived.

HTH,

-Paul

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Subversion vs other source control systems

[Andrew Savory <an...@luminas.co.uk>]

Hi,

On 2/20/08, Noel J. Bergman <no...@devtech.com> wrote:

> > > This is the wrong forum.  What we've said here is that there won't be any
> > > deviation from the ASF infrastructure for source control; changing ASF
> > > infrastructure is out of scope for the Incubator.
>
> > I already tried to move the discussion to community@apache.org, where I
> > think it belongs, but people insists on answering here.
>
> I understand, but that still doesn't make it an issue for the Incubator.

Actually, I'd expect the incubator to be exactly where such
discussions would crop up, as the new blood challenge the status quo
and seek to make sense of how things are done here. And, indeed, this
should be extremely valuable for the community as a whole, as it's a
chance to document our rationales, or to re-evaluate methodologies
that are rendered obsolete by newer technologies.

(Not that I think SVN is obsolete, but I do see some serious value in
reappraising the centralised vs. distributed model of development to
see what is possible within the Apache Way, or even if the Apache Way
should be updated.)


Andrew.

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

RE: Subversion vs other source control systems

["Noel J. Bergman" <no...@devtech.com>]

Santiago Gala wrote:

> > > - publishing lots of repositories helps surfacing patches that are
> > >   currently hidden until ready for sending/committing
> > The last one is almost antithetical to how we want people to work.
> Can you elaborate on how is publishing what currently is hidden
> "antithetical to how we want people to work"? I think that getting a
> clear idea on this is important, as I always thought the ASF was about
> transparency and not keeping information hidden.

Let us clarify, then.  I am saying that developers doing extensive work in their own repositories, and periodically merging bulk changes to the communal repository is antithetical to how we want people to work, which is to be working in the shared repository, on a frequent and fine-grained manner, even if in different branches.

> > > The inability of subversion to remember merged results makes working in
> > > a branch unpractical. Been there, done that, very tricky.
> > Raise any technical issues with the Subversion folks.
> huh? why?

Because you are attempting to raise a technical issue regarding our source control system, and they are the ones who would best respond to it.

> > This is the wrong forum.  What we've said here is that there won't be any
> > deviation from the ASF infrastructure for source control; changing ASF
> > infrastructure is out of scope for the Incubator.

> I already tried to move the discussion to community@apache.org, where I
> think it belongs, but people insists on answering here.

I understand, but that still doesn't make it an issue for the Incubator.

	--- Noel



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

RE: Subversion vs other source control systems

[Santiago Gala <sg...@apache.org>]

El dom, 17-02-2008 a las 19:02 -0500, Noel J. Bergman escribió:
> Santiago Gala wrote:
> > I think git-svn abuses the server a lot, as the subversion server is not
> > designed for copying of the whole history. 
> 
> AFAICS, that's an issue for the Infrastructure Team to address, not the Incubator.
> 
> > > Dw wrote:
> > > > I am a bit lost here as well -- what does GiT add to the processes/
> > > > workflows common in the ASF ?
> 
> > - faster commits, branch switching, pulls and pushs
> > - merges, good and persistent merges
> > - offline work, offline history diffs
> > - rebasing is not such a "feature", but it can be useful sometimes
> > - publishing lots of repositories helps surfacing patches that are
> >   currently hidden until ready for sending/committing
> 
> The last one is almost antithetical to how we want people to work.  The first few are something that you could raise with the Subversion folks on infra@.
> 

Can you elaborate on how is publishing what currently is hidden
"antithetical to how we want people to work"? I think that getting a
clear idea on this is important, as I always thought the ASF was about
transparency and not keeping information hidden. And I think it is in
scope, as the incubator is an important place for people to learn "our
ways".


> > The inability of subversion to remember merged results makes working in
> > a branch unpractical. Been there, done that, very tricky.
> 
> Raise any technical issues with the Subversion folks.
> 

huh? why?

> > Turning your "key poing" upside down: "We should not try to impose our
> > practices using a technological tool, specially when doing so impairs
> > development."
> 
> If there is a better SCM *for our way of working* raise that on infra@, too.
> 
> > people *against* changes in SCM is blaming a hypothetical introduction
> > of git of breaking the ASF practices
> 
> No.  This is the wrong forum.  What we've said here is that there won't be any deviation from the ASF infrastructure for source control; changing ASF infrastructure is out of scope for the Incubator.

I already tried to move the discussion to community@apache.org, where I
think it belongs, but people insists on answering here. Making requests
to a closed team in a private list does not accord with *our way of
working*, I think. And I don't think there is any need to use a private,
unarchived list for discussions on infrastructure improvements.


Regards
Santiago

> 
> 	--- Noel
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

RE: Subversion vs other source control systems

["Noel J. Bergman" <no...@devtech.com>]

Santiago Gala wrote:
> I think git-svn abuses the server a lot, as the subversion server is not
> designed for copying of the whole history. 

AFAICS, that's an issue for the Infrastructure Team to address, not the Incubator.

> > Dw wrote:
> > > I am a bit lost here as well -- what does GiT add to the processes/
> > > workflows common in the ASF ?

> - faster commits, branch switching, pulls and pushs
> - merges, good and persistent merges
> - offline work, offline history diffs
> - rebasing is not such a "feature", but it can be useful sometimes
> - publishing lots of repositories helps surfacing patches that are
>   currently hidden until ready for sending/committing

The last one is almost antithetical to how we want people to work.  The first few are something that you could raise with the Subversion folks on infra@.

> The inability of subversion to remember merged results makes working in
> a branch unpractical. Been there, done that, very tricky.

Raise any technical issues with the Subversion folks.

> Turning your "key poing" upside down: "We should not try to impose our
> practices using a technological tool, specially when doing so impairs
> development."

If there is a better SCM *for our way of working* raise that on infra@, too.

> people *against* changes in SCM is blaming a hypothetical introduction
> of git of breaking the ASF practices

No.  This is the wrong forum.  What we've said here is that there won't be any deviation from the ASF infrastructure for source control; changing ASF infrastructure is out of scope for the Incubator.

	--- Noel



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

RE: Subversion vs other source control systems

[Santiago Gala <sg...@apache.org>]

El dom, 17-02-2008 a las 10:58 -0500, Noel J. Bergman escribió:
> Dirk-Willem van Gulik wrote:
> > Ross Gardler wrote:
> > > I understand that GiT can be used locally as a layer on top of SVN.
> > > I believe this gives you most of the perceived benefits of GiT
> > > locally without the need for a project itself to switch to GiT.
> 
> The issue isn't git as an SVN client.  No one (as far as I know) cares what
> SVN client(s) you use, so long as they don't abuse our SVN server.
> 

I think git-svn abuses the server a lot, as the subversion server is not
designed for copying of the whole history. 

I agree that exporting svn to git/bazaar/mercurial, etc is a way
forward, but it will cause strain to the svn server, for sure. As seen
elsewhere, Jason took this path, and I'm actually using this technique
in a number of places, both with git-svn and bzr-svn. I will keep
reporting.

> > I am a bit lost here as well -- what does GiT add to the processes/
> > workflows common in the ASF ?
> 

I already answered to this one in the thread. 

- faster commits, branch switching, pulls and pushs
- merges, good and persistent merges
- offline work, offline history diffs
- rebasing is not such a "feature", but it can be useful sometimes
- publishing lots of repositories helps surfacing patches that are
currently hidden until ready for sending/committing

I hope helping each and every developer/contributor counts as helping
the ASF.

> > One of the great things about GiT is that you can can have lots of
> > parallel and non-linear merges (every developer their own branch;
> 
> > However in the ASF most groups work roughly along fairly linear lines;
> > with 'one' or just a 'few' points at which a patch is accepted - and
> > essentially few, or just one, merge point (or a single line of merge
> > points when backported). Rarely do we merge multiple 'HEAD's.
> 

huh? every "vendor" keeping patches against apache repositories is
merging often. I don't follow your reasoning, anybody keeping patches is
merging repeatedly against a moving HEAD (for active projects). In my
view, every developer that maintains patches is in effect having a
*private, unpublished* branch. With git and a setup like the one in
kernel.org, all those patches are suddenly public, visible. Think about
it.

> And most importantly, we want our development to be visible to the
> Community, not done in private and committed when finished.  Developers can
> always make more or less transient branches to work on code, still in public
> view, and merge back to shared locations.  The key point here that I believe
> you, I, William and others are all making isn't about technology, it is
> about practice.
> 

The inability of subversion to remember merged results makes working in
a branch unpractical. Been there, done that, very tricky.

Personal repositories can be kept in public, you just can look into the
different branches in http://git.kernel.org/?p=linux/kernel to see how a
number of those are updated a lot.

Turning your "key poing" upside down: "We should not try to impose our
practices using a technological tool, specially when doing so impairs
development."

> Now, if there is an SCM that substantially improves the ASF's ability to
> perform *our* practices, that is a separate discussion item.
> 

I'm quite sure currently any one of git, bazaar, mercurial or even darcs
would improve our practices.

Just to make sure, my view of the discussion: 

people *against* changes in SCM is blaming a hypothetical introduction
of git of breaking the ASF practices

I don't think the discussion is, and never was presented as:

evil revolutionaries wanting to break the practices by introduction of
sneaky "solipsistic" tools.

I don't think git will break ASF practices more than keeping quilt
patches, or several repositories, to survive "svn up" without nasty
conflicts.

Regards
Santiago

> 	--- Noel
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

RE: Subversion vs other source control systems

["Noel J. Bergman" <no...@devtech.com>]

Dirk-Willem van Gulik wrote:
> Ross Gardler wrote:
> > I understand that GiT can be used locally as a layer on top of SVN.
> > I believe this gives you most of the perceived benefits of GiT
> > locally without the need for a project itself to switch to GiT.

The issue isn't git as an SVN client.  No one (as far as I know) cares what
SVN client(s) you use, so long as they don't abuse our SVN server.

> I am a bit lost here as well -- what does GiT add to the processes/
> workflows common in the ASF ?

> One of the great things about GiT is that you can can have lots of
> parallel and non-linear merges (every developer their own branch;

> However in the ASF most groups work roughly along fairly linear lines;
> with 'one' or just a 'few' points at which a patch is accepted - and
> essentially few, or just one, merge point (or a single line of merge
> points when backported). Rarely do we merge multiple 'HEAD's.

And most importantly, we want our development to be visible to the
Community, not done in private and committed when finished.  Developers can
always make more or less transient branches to work on code, still in public
view, and merge back to shared locations.  The key point here that I believe
you, I, William and others are all making isn't about technology, it is
about practice.

Now, if there is an SCM that substantially improves the ASF's ability to
perform *our* practices, that is a separate discussion item.

	--- Noel



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Subversion vs other source control systems

[Dirk-Willem van Gulik <di...@webweaving.org>]

On Feb 14, 2008, at 12:25 PM, Ross Gardler wrote:

> Noel J. Bergman wrote:
>> J Aaron Farr wrote:
>>> J Aaron Farr wrote:
>>>>> git could be an issue.
>>>> Can you explain what the issue is with Git?
>>> Leo already gave a decent explanation.
>>> Basically, it comes down to two aspects:
>>>  1) infrastructure support
>>>  2) cultural bias
>> Only the first one is marginally correct, IMO.
>> Santiago wrote:
>>>> 1. You have to use subversion.
>
>
> Sorry, I've missed the thread that led to this, so sorry if I'm  
> repeating others.
>
> I understand that GiT can be used locally as a layer on top of SVN.  
> I believe this gives you most of the perceived benefits of GiT  
> locally without the need for a project itself to switch to GiT.

I am a bit lost here as well -- what does GiT add to the processes/ 
workflows common in the ASF ?

One of the great things about GiT is that you can can have lots of  
parallel and non-linear merges (every developer their own branch; lots  
of people merging the same patch into different sequences) -- and as  
such I can see it being perfectly tuned for, say, Linux.

However in the ASF most groups work roughly along fairly linear lines;  
with 'one' or just a 'few' points at which a patch is accepted - and  
essentially few, or just one, merge point (or a single line of merge  
points when backported). Rarely do we merge multiple 'HEAD's.

And I'd almost argue that SVN is a useful framework which helps us  
stay on the paved roads - where a single head progresses with group  
consensus and generally agreed merit.

Thanks,

Dw

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Subversion vs other source control systems

[Aidan Skinner <ai...@apache.org>]

On Thu, Feb 14, 2008 at 11:25 AM, Ross Gardler <rg...@apache.org> wrote:

>  I understand that GiT can be used locally as a layer on top of SVN. I
>  believe this gives you most of the perceived benefits of GiT locally
>  without the need for a project itself to switch to GiT.
>
>  Now, I've never tried this and don't know anyone who has, but thought
>  I'd flag it in case it is relevant.

My 2p:

I've been doing this recently with qpid, partly because I'm wrangling
a large merge at the moment (which it does better than straight svn)
and partly because it suits my typical workflow a bit better: cheap
local branching means I can hack on something, get interrupted, create
another branch to work on that interruption in isolation, commit that
to HEAD, rebase the branch from the first thing and pick up where I
left off without having to take intermediate patches, revert that out,
reapply etc which is what I did before.

The initial import is ridiculouisly slow if you take all the history
because the asf has one repo for all the projects and it looks at each
revision, but you can tell it to only pull history from a certain
point.

- Aidan
-- 
aim/y!:aidans42 g:aidan.skinner@gmail.com
http://aidan.skinner.me.uk/
"Almost everything is imitation... The most original writers borrowed
from one another." - Voltaire

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Subversion vs other source control systems

[Ross Gardler <rg...@apache.org>]

Noel J. Bergman wrote:
> J Aaron Farr wrote:
>> J Aaron Farr wrote:
>>>> git could be an issue.
>>> Can you explain what the issue is with Git?
>> Leo already gave a decent explanation.
>> Basically, it comes down to two aspects:
>>   1) infrastructure support
>>   2) cultural bias
> 
> Only the first one is marginally correct, IMO.
> 
> Santiago wrote:
>>> 1. You have to use subversion.


Sorry, I've missed the thread that led to this, so sorry if I'm 
repeating others.

I understand that GiT can be used locally as a layer on top of SVN. I 
believe this gives you most of the perceived benefits of GiT locally 
without the need for a project itself to switch to GiT.

Now, I've never tried this and don't know anyone who has, but thought 
I'd flag it in case it is relevant.

Ross


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Subversion vs other source control systems

["Noel J. Bergman" <no...@devtech.com>]

J Aaron Farr wrote:
> J Aaron Farr wrote:
>>> git could be an issue.
> > Can you explain what the issue is with Git?
> Leo already gave a decent explanation.
> Basically, it comes down to two aspects:
>   1) infrastructure support
>   2) cultural bias

Only the first one is marginally correct, IMO.

Santiago wrote:
> > 1. You have to use subversion.
> Why? Has been a vote done? where? I vote +1 for git if a vote is still open.

No, there was no vote and is not vote, nor is there any choice.  Subversion is one of the few things that the Board has mandated, imposed on all projects.  Period.  Pretty much end of discussion.

No project was allowed to stay with CVS.  No project will be allowed to use another source control system unless it is adopted at the ASF level.  Source code is a critical, shared, public resource maintained by the Foundation, not something whose storage is managed on a project by project basis.  The Infrastructure Team maintains and protects that shared resource on behalf of the Foundation.

	--- Noel



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [PROPOSAL] Thrift

[J Aaron Farr <fa...@apache.org>]

David Reiss <dr...@facebook.com> writes:

> J Aaron Farr wrote:
>> git could be an issue.
>
> Can you explain what the issue is with Git?

Leo already gave a decent explanation.

Basically, it comes down to two aspects:

  1) infrastructure support
  2) cultural bias

There's no "No git" rule that I know of, so in theory, it could be
possible.  In practice, you'll get some resistance.

One aspect of resistance will be from the infrastructure team.  SVN is
basically the "standard" here, we have experience with it and we can
support it well.  Due to painfully learned lessons, our infra team
(mostly volunteer) tends to be very conservative about adding new
tools to our stack.  That said, no one wants to arbitrarily stand in
the way of a project, so there's some give and take, some flexibility.
The point is, this is something the Thrift committers would have to
work out with the infra team.  I don't see it as a show stopper from
this respect, but I hope you understand why this could cause some
friction.

The second issue is cultural.  One concern we've had about distributed
version control is the lack of a central repository which _requires_
committers to cooperate and communicate.  This "deficiency" is seen as
a feature by many in the Apache community because it encourages people
to work closely together and it also makes clear which bits of code
are blessed by the community at large.

That said, the workflow you describe sounds great.  Many of us have
used distributed version control systems and there's been idle talk
about it now and then, so this attitude could change, particularly if
a project could demonstrate how to avoid the potential pitfalls.

Hope that clears things up a bit.

-- 
  J Aaron Farr     jadetower.com        [US] +1 724-964-4515 
    馮傑仁          cubiclemuses.com     [HK] +852 8123-7905  

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [PROPOSAL] Thrift

[Santiago Gala <sg...@apache.org>]

On Feb 2, 2008 2:48 PM, Leo Simons <ma...@leosimons.com> wrote:
> On Feb 2, 2008, at 1:20 AM, David Reiss wrote:
> > J Aaron Farr wrote:
> >> git could be an issue.
> >
> > Can you explain what the issue is with Git?
>
> Probably not very well :-). Basically, we know how to do the apache-
> style open source process using centralized version control, we don't
> quite know how to do it using (significantly) different version
> control models.
>
> That can (will?) change, but it probably can't change very quickly.
>
> > Let me say in closing, though, that I don't want this issue to hold
> > up the vote on Thrift.
>
> I think it's a good idea to treat it as a seperate topic.
>
> > I think that everyone involved with the project thinks that Apache
> > is the best place for it, and if the PMC says we have to use
> > Subversion, we will.
>
> Cool.
>
> 1. You have to use subversion.
>

Why? Has been a vote done? where? I vote +1 for git if a vote is still open.

> 2. You are cordially invited to engage within apache to see what we
> can do about modifying rule #1.
>

Can you elaborate on what "engage within apache" means in this
context? I have been "engaged within apache" for almost 8 years now,
including membership and being an officer for some time, and yet I
don't understand what "engage with apache" means. I don't even hope
new people will.

> For #2, I can immediately imagine some ways to use git-svn that are
> quite acceptable. I can also imagine some things that are probably
> not so easily acceptable. I can imagine a BoF session at the next
> ApacheCon about it :-)
>

This effectively means: you can use whatever you want, provided that
it is subversion.

But what concerns me most is that the Foundation is effectively
turning into a bureaucracy, where norms appear out of nowhere without
any justification.

I see no mention to community reasons here, and any resource based
reasons have tiny justification, specially when those are not even
stated. Infrastructure used to be a support for the projects, not the
other way around.

While I understand some of the practical reasons stated in this
thread, I don't understand the "legalist" note on it, neither the
normative answers ("who makes those norms"?). The ASF used to be a
loose community of projects, at least technically and codewise, and I
think what SCM is used is a very important technical decision for
project and community.

BTW, I'm copying community@apache.org, in an effort to keep a mostly
dead list going.

Regards,
Santiago


>
> cheers,
>
>
> - Leo, fan (but not active user) of git
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [PROPOSAL] Thrift

[Leo Simons <ma...@leosimons.com>]

On Feb 2, 2008, at 1:20 AM, David Reiss wrote:
> J Aaron Farr wrote:
>> git could be an issue.
>
> Can you explain what the issue is with Git?

Probably not very well :-). Basically, we know how to do the apache- 
style open source process using centralized version control, we don't  
quite know how to do it using (significantly) different version  
control models.

That can (will?) change, but it probably can't change very quickly.

> Let me say in closing, though, that I don't want this issue to hold  
> up the vote on Thrift.

I think it's a good idea to treat it as a seperate topic.

> I think that everyone involved with the project thinks that Apache  
> is the best place for it, and if the PMC says we have to use  
> Subversion, we will.

Cool.

1. You have to use subversion.

2. You are cordially invited to engage within apache to see what we  
can do about modifying rule #1.

For #2, I can immediately imagine some ways to use git-svn that are  
quite acceptable. I can also imagine some things that are probably  
not so easily acceptable. I can imagine a BoF session at the next  
ApacheCon about it :-)


cheers,


- Leo, fan (but not active user) of git


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Re: [PROPOSAL] Thrift

[David Reiss <dr...@facebook.com>]

J Aaron Farr wrote:
> git could be an issue.

Can you explain what the issue is with Git?  We have at least seven 
contributors (three at Facebook, four external) using git-svn right now, and I 
know that at least a few of us would really like to use native Git as the main 
repository for Thrift.  Paul Querna mentioned on the Thrift list that Apache 
likes things to happen "in the open", but he said that others could explain it 
better.

If the concern is that key developers would maintain their own repositories 
and exchange patches in private emails, I can assure you that this is not what 
we have in mind.  Perhaps it would help if I explained the sort of repository 
I am picturing.  (I am locally testing some hooks to implement this, so 
hopefully we can launch it in a trial mode as soon as I can get a machine.)
There would be once central repository that would track the trunk.  In 
addition, every committer would be able to post their own branches to the 
repository.  The preferred workflow would be for a committer to post a patch 
to a branch in the repo, then send out an email to the list like "hey guys, my 
patch for project space-age is on branch priv/dreiss/space-age.  Do you think 
this is ready to be merged into master?"  Then anyone could go to gitweb to 
look at the patch, pull the patch into their repo and hack on it, or download 
a tarball and test it out.  I think this is much less error prone than having 
to manually apply a patch sent over an email.  I think it even has the 
potential to be more open than Subversion.  If we encourage developers to 
continuously push their experimental work to the repository in branches, 
everyone could "follow along" and contribute.  I think this is a much better 
situation than the current case with Subversion where local changes that 
aren't ready to be merged into the main repository yet stay on developers' 
private machines.

I also have a set of scripts to allow non-committers to submit changes 
directly to the repository, tag the submissions, and email a list of 
committers.  There are two benefits of this.  The first is that it is a far 
less error prone way for patches to be submitted and applied.  The second is 
that non-committers would submit patches for consideration in almost the exact 
same way as committers.  This way, new committers wouldn't have to change 
their workflows at all, and we wouldn't have to worry about them making 
"newbie" mistakes, because they would just continue to work in the same way 
that led us to believe they would be responsible committers.

Well, this email is getting a bit long, so I'll cut myself off here.  Let me 
say in closing, though, that I don't want this issue to hold up the vote on 
Thrift.  I think that everyone involved with the project thinks that Apache is 
the best place for it, and if the PMC says we have to use Subversion, we will. 
  But please consider Git.  Thank you.

--David


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [PROPOSAL] Thrift

[Leo Simons <ma...@leosimons.com>]

On Jan 30, 2008, at 4:45 PM, J Aaron Farr wrote:
> "Mark Slee" <ms...@facebook.com> writes:
>> Anyone have feedback? If no objections are voiced, when would it be
>> appropriate for us to move forward with a VOTE thread on this?
>
> Sorry for not responding.  I flagged the email when I first saw it but
> didn't have time to respond.

Same here. I still don't have time but wish I did; I will probably have
some less irrelevant comment once I properly read up on what  
happened :-)

I think overall this looks cool. I think there'll be lots of interest.
There's a bunch of challenges from a "set up healthy diverse community"
perspective, but as an avid facebook user I would hope there's some idea
on your end as well on how to get a good community going!

cheers,

- Leo


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [PROPOSAL] Thrift

[J Aaron Farr <fa...@apache.org>]

"Mark Slee" <ms...@facebook.com> writes:

> Anyone have feedback? If no objections are voiced, when would it be
> appropriate for us to move forward with a VOTE thread on this?

Sorry for not responding.  I flagged the email when I first saw it but
didn't have time to respond.

Overall the proposal is solid and I think Thrift would be a great
Apache project.  The issues of committer diversity should be handled
during incubation.  I also agree with others that you'll find there's
really no need to introduce internal commit barriers.  This sort of
problem tends to work out on its own.  However, if there are real
concerns about this, it can done.

git could be an issue.

Finally, I'd love to help mentor this, but I'm already mentoring two
other projects.  I would like to at least lurk on the mailing lists.
I'm doing some Facebook app development now and I'd like to better
understand some of the code that's running behind those servers.

-- 
  J Aaron Farr     jadetower.com        [US] +1 724-964-4515 
    馮傑仁          cubiclemuses.com     [HK] +852 8123-7905  

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

RE: [PROPOSAL] Thrift

[Mark Slee <ms...@facebook.com>]

Hi everyone,

Unless my mail filters are playing tricks on me, haven't seen any
feedback on the incubator list since sending this proposal out last
week. Hopefully that's a good thing, meaning no one's opposed. =)

Anyone have feedback? If no objections are voiced, when would it be
appropriate for us to move forward with a VOTE thread on this?

Cheers,
Mark

-----Original Message-----
From: Mark Slee [mailto:mslee@facebook.com] 
Sent: Wednesday, January 23, 2008 6:07 PM
To: general@incubator.apache.org
Cc: thrift@publists.facebook.com
Subject: [PROPOSAL] Thrift

Hi all,
 
We've just posted the Apache Incubator proposal for Thrift onto the
Wiki:
http://wiki.apache.org/incubator/ThriftProposal
 
For those who prefer reading Wiki markup directly, it is copied below.
 
Cheers,
Mark
 
= Thrift Proposal =

== Abstract ==
Thrift is a framework for efficient cross-language data serialization,
RPC, and server programming.

== Proposal ==
Thrift is a software library and set of code-generation tools designed
to expedite development and implementation of efficient and scalable
backend services. Its primary goal is to enable efficient and reliable
communication across programming languages by abstracting the portions
of each language that tend to require the most customization into a
common library that is implemented in each language. Specifically,
Thrift allows developers to define datatypes and service interfaces in a
single language-neutral file and generate all the necessary code to
build RPC clients and servers.

== Background ==
Thrift was initially developed at Facebook starting in 2006 to power RPC
and data logging for a number of backend services for the site, such as
Search and News Feed. The package was designed for open source, and was
released in early 2007. Since then, a number of other developers have
submitted patches to the project and become de facto owners of major
parts. Support for many languages has been developed entirely outside of
Facebook.

== Rationale ==
The need for high performance, reliable communication across different
programming languages seems to be growing more and more common in modern
programming, particularly when writing software for the web.
Historically, this problem has forced developers to standardize on one
language/framework or adopt heavier-weight systems, such as CORBA or
SOAP. These systems tend to make tradeoffs that aren't always ideal for
the use case. SOAP, for example, may be ideal for calling across
disparate web services, but is unnecessarily verbose for service calls
on an intranet.

Most of these systems also require developers to learn the particulars
of their type systems, especially when dealing with containers or
objects. One of the primary goals of Thrift is to allow developers to
program across languages while still using the standard idioms and style
in each language. Custom type systems also makes code reuse more
difficult. Thrift allows developers to avoid creating unnecessary
wrapper interfaces by operating directly on native types.

== Initial Goals ==
Though the bulk of Thrift's initial development is complete, there are
still some large areas for future development. Some areas we hope to
focus on in Apache:

 * Better log storage/replay
 * Meta-data serialization
 * Higher-performance serialization, standard C extension model across
Python/PHP/etc.
 * Extending the abstraction to a multi-client that can fan-out across
multiple servers

== Current Status ==
=== Meritocracy ===
Though initial development was done at Facebook, Thrift was intended to
be released as an open source project from its inception. Since release,
many developers have adopted the framework and submitted significant
patches. Large portions of the codebase are now managed by those most
familiar with and responsible for them. Any potentially controversial
change is discussed on the public mailing list
(http://lists.pub.facebook.com/mailman/listinfo/thrift/) and good
suggestions are frequently implemented.

=== Community ===
Thrift is currently in use across a number of organizations, and we
expect this to grow as Thrift becomes a relevant and useful tool for
building more open source projects.

=== Core Developers ===
Thrift currently has developers across many organizations (e.g.
Facebook, Powerset, ReCaptcha, AmieStreet), many of whom are
contributors to other open source projects.

=== Alignment ===
Thrift is designed to integrate cleanly with other projects. We think
this is a particularly good fit for Apache due to integration potential
with other projects, specifically Hadoop/Hbase.

== Known Risks ==
=== Orphaned Products ===
Thrift is already deployed into production at multiple large websites
that are frequently iterating on the featureset. There's no realistic
chance of it becoming orphaned.

=== Inexperience with Open Source ===
The project has already been open source for nearly a year and has
attracted many developers already. Part of the reason to join Apache is
to make the project work even better as open source by removing some
obstacles, such as Facebook hosting the SVN, and putting the resources
all in a truly open space, being able to have more committers, etc. Most
of the core developers have a history of working with open source tools.

=== Homogenous Developers ===
The current set of developers work across a variety of organizations.
Naturally, most are websites with significant backend structure (and
hence a need for Thrift), but the problems they are solving are diverse,
and many don't work in the same programming languages.

=== Reliance on Salaried Developers ===
Thrift is a "means to an end." None of the developers (to my knowledge)
working on Thrift are salaried specifically to work on Thrift. Rather,
Thrift is useful in building other projects, which may or may not be for
salary. Realistically, it is likely that a decent portion of work on
Thrift will be done by someone at a company, but not specifically tasked
with working on Thrift. So long as the tool is relevant and useful, this
should result in developers contributing time both at work and
personally.

=== Relationships with Other Apache Projects === Thrift has already been
introduced into the Hbase project. (See
https://issues.apache.org/jira/browse/HADOOP-2389) Since Thrift is a
development tool, it is designed and well-suited for use in other
projects. As a start, we definitely plan to continue integration work
with Hbase.

=== An Excessive Fascination with the Apache Brand === Thrift has
already attracted a stable base of developers. The reasons for joining
Apache are not to advertise the project, but rather to demonstrate the
commitment to open source by divorcing the trunk from any one
corporation and pursuing further integration with other Apache projects.

== Documentation ==
Existing page:
http://developers.facebook.com/thrift/

Mailing list (with archives):
http://lists.pub.facebook.com/mailman/listinfo/thrift/

== Initial Source ==
Currently hosted by Facebook:
http://svn.facebook.com/svnroot/thrift/

== Source and Intellectual Property Submission Plan == All code
currently hosted in the Facebook public SVN folder will be contributed.

== External Dependencies ==
All dependencies (libevent, Boost) have Apache compatible licenses.

== Cryptography ==
None

== Required Resources ==
=== Mailing lists ===
 * thrift-dev
 * thrift-private

=== Subversion Directory ===
https://svn.apache.org/repos/asf/incubator/thrift

We'd also be interested in using git to store the repo. Does apache have
infrastucture set up to support that? It'd make it easier for
non-committer developers to work on patches, checkpoint commits, etc.

=== Issue Tracking ===
Bugzilla Thrift

== Initial Committers ==
 * Mark Slee (mcslee at facebook dot com)
 * Aditya Agarwal (aditya at facebook dot com)
 * Marc Kwiatkowski (marc at facebook dot com)
 * David Reiss (david at facebook dot com)
 * James Wang (jwang at facebook dot com)
 * Chris Piro (cpiro at facebook dot com)
 * Ben Maurer (bmaurer at andrew dot cmu dot edu)
 * Kevin Clark (kevin at powerset dot com)
 * Jake Luciani (jakers at gmail dot com)

== Affiliations ==
 * People with Facebook email addresses - Facebook
 * Ben Maurer - ReCaptcha
 * Kevin Clark - Powerset

== Sponsors ==
=== Champion ===
 * Doug Cutting

=== Mentors ===
 * Paul Querna
 * Upayavira

=== Sponsoring Entity ===
 * Incubator


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org