You are viewing a plain text version of this content. The canonical link for it is here.
Posted to community@apache.org by Jeff Hammerbacher <ha...@cloudera.com> on 2010/09/13 00:51:36 UTC
"Forking is a Feature" reactions?
Hey,
I just read the thoughtful piece by Anil Dash at
http://dashes.com/anil/2010/09/forking-is-a-feature.html. I don't really
agree or disagree with his points, but it's an interesting take on the value
of distributed version control and the evolution of how open source
communities get work done.
I tried to find the official position of the ASF on this topic, but
unfortunately, the "How it Works" links are broken on the site (see
http://issues.apache.org/jira/browse/INFRA-2981).
I did find, in the "glossary", a section on "Revolution":
> **In the Apache environment, some communities may decide to permit (or
> encourage) *revolutions* as ways of reconciling differences, particularly
> code changes which have been blocked on a particular branch by a veto.
> Originally described by James Duncan Davison in his 'Rules for
> Revolutionaries,' the concept has been adopted, formally or informally, by
> at least one Apache project<http://www.apache.org/foundation/glossary.html#Project>.
> Essentially, a revolution occurs when a group of committers decides to fork
> the current main branch in order to work on problematic code or concepts.
> This permits them to pursue it without disturbing the evolutionary work on
> the main branch. A revolutionary branch may eventually be merged back into
> the main branch, die out, split completely and become a new main branch, or
> may absorb the current main branch into itself (essentially no different
> than the first option). See the 'Rules for Revolutionaries<http://incubator.apache.org/learn/rules-for-revolutionaries.html>'
> and compare *evolution*<http://www.apache.org/foundation/glossary.html#Evolution>
> .
In the Apache Hadoop project, we've adopted the potential for revolutions,
which we manage as Subversion branches. Unfortunately, maintaining a
Subversion branch is expensive, and merging it back into trunk can be quite
difficult.
For projects which have sanctioned "revolutions", it may be useful to allow
them to use git or another dvcs as the primary version control system.
Similarly, for projects with several large commercial backers, each
maintaining their own patch sets or source repositories (e.g. Apache Hadoop,
with Yahoo, Cloudera, and soon, Facebook working separately), a distributed
version control system could be useful.
I'd love to hear the reactions of other ASF members to the piece. I'd also
love to be directed to previous discussions on the topic, as I know that
adopting git for some projects has been discussed previously.
Thanks,
Jeff
Re: "Forking is a Feature" reactions?
Posted by Ross Gardler <rg...@apache.org>.
On 13/09/2010 11:21, Isabel Drost wrote:
> On Sun, 12 Sep 2010 Jeff Hammerbacher<ha...@cloudera.com> wrote:
>> I'd love to hear the reactions of other ASF members to the piece. I'd
>> also love to be directed to previous discussions on the topic, as I
>> know that adopting git for some projects has been discussed
>> previously.
>
> IIRC there should be some discussions on the archive of the infra and
> community mailing lists that were caused back when the read-only git
> mirrors were set-up.
>
> However I agree it would be nice to have one page that summarises the
> results of these discussions - especially the problems that various
> people saw. That way re-checking from time to time whether these
> might be resolvable by additional tooling or a use of git different
> from how it was discussed on the lists becomes easier.
ComDev would be happy to publish on their blog.
Ross
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: "Forking is a Feature" reactions?
Posted by Davanum Srinivas <da...@gmail.com>.
Please see/join infra-dev@ mailing list for details:
http://mail-archives.apache.org/mod_mbox/www-infrastructure-dev/
that's where most of this was discussed.
thanks,
dims
On Mon, Sep 13, 2010 at 6:21 AM, Isabel Drost <is...@apache.org> wrote:
> On Sun, 12 Sep 2010 Jeff Hammerbacher <ha...@cloudera.com> wrote:
>> I'd love to hear the reactions of other ASF members to the piece. I'd
>> also love to be directed to previous discussions on the topic, as I
>> know that adopting git for some projects has been discussed
>> previously.
>
> IIRC there should be some discussions on the archive of the infra and
> community mailing lists that were caused back when the read-only git
> mirrors were set-up.
>
> However I agree it would be nice to have one page that summarises the
> results of these discussions - especially the problems that various
> people saw. That way re-checking from time to time whether these
> might be resolvable by additional tooling or a use of git different
> from how it was discussed on the lists becomes easier.
>
> Isabel
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: community-unsubscribe@apache.org
> For additional commands, e-mail: community-help@apache.org
>
>
--
Davanum Srinivas :: http://davanum.wordpress.com
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: "Forking is a Feature" reactions?
Posted by Jeff Trawick <tr...@gmail.com>.
On Wed, Sep 15, 2010 at 5:45 AM, Santiago Gala <sa...@gmail.com>wrote:
> BTW, on an unrelated subject: what was going on in the development of
> the Apache httpd server the week before 2001-9-11, i.e. 2001-9-03
> through 10? Yes, I mean the week before 9/11 I'm doing some statistics
> about OS projects, and this week is an outlier re: relation between
> commits and list traffic for the httpd server. Any clue?
>
nada over Labor Day weekend then afterwards an uncommon amount of naval
gazing around the 2.0/STATUS file as well as a surprising-in-hindsight
concentration of core devs on httpd 1.3
(haven't looked at dev@, just
http://mail-archives.apache.org/mod_mbox/httpd-cvs/200109.mbox/date)
Re: "Forking is a Feature" reactions?
Posted by Eric Evans <ee...@rackspace.com>.
On Thu, 2010-09-16 at 15:09 -0400, Justin Edelson wrote:
> > Git-svn is awesome (I use it), but since a Git merge cannot be
> > represented in Subversion, you aren't able to safely pull/merge/push
> > with other Git repos. It basically becomes a very fancy patch
> > manager when used this way.
>
> AFAICT, the way you workaround this is to work in a different branch
> than the one connected to svn (typically master). The master branch of
> my git repository which is connected to svn.apache.org is basically
> pristene - whenever I'm ahead of trunk, it is because I'm about to
> commit something. If I'm working on something significant, I branch,
> work on the branch, and then remerge (and delete the branch). That
> branch can be pushed and pulled.
Right, as long as you can maintain a linear stream of changesets that
apply on top of trunk, you're good. However, if your branch has been
merged with another, then you will not be able to dcommit after merging
that on to trunk. See the CAVEATS section of git-svn(1) for a more.
This is why I called it a patch manager, because it isn't useful for
collaborating with other Git users.
--
Eric Evans
eevans@rackspace.com
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: "Forking is a Feature" reactions?
Posted by Justin Edelson <ju...@gmail.com>.
On 9/16/10 10:34 AM, Eric Evans wrote:
> On Thu, 2010-09-16 at 09:31 -0400, Justin Edelson wrote:
>> I can say with some confidence that without the git svn workflow, I
>> would not be an Apache committer. I would have done exactly what I'd
>> done for years prior - svn export from a tag, svn import, and patch.
>> Maybe re-export and reapply my patches when a new release came out
>> (but that was a pain in the ass, so didn't happen that frequently).
>> But submitting my patches back was frequently too difficult because
>> they were against a tag, not trunk. And even if they were against
>> trunk, they were against trunk at a certain revision, which inevitably
>> was not HEAD.
>
> Git-svn is awesome (I use it), but since a Git merge cannot be
> represented in Subversion, you aren't able to safely pull/merge/push
> with other Git repos. It basically becomes a very fancy patch manager
> when used this way.
AFAICT, the way you workaround this is to work in a different branch
than the one connected to svn (typically master). The master branch of
my git repository which is connected to svn.apache.org is basically
pristene - whenever I'm ahead of trunk, it is because I'm about to
commit something. If I'm working on something significant, I branch,
work on the branch, and then remerge (and delete the branch). That
branch can be pushed and pulled.
I can't say that I have exercised this fully and I don't claim to be a
git expert, so YMMV.
Justin
>
>> Adopting git/git svn did a lot of things, but mostly it gave me the
>> ability to contribute back my patches while proceeding with
>> development of a branched version containing my full patch set. For
>> the project, this lead to smaller, easier to understand patch
>> submissions(and, eventually, a new committer!).
>>
>> IMHO, I think the subject of the original blog post in this thread is
>> just wrong. Forking isn't a feature. Merging is a feature.
>
> Good point.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: "Forking is a Feature" reactions?
Posted by Eric Evans <ee...@rackspace.com>.
On Thu, 2010-09-16 at 09:31 -0400, Justin Edelson wrote:
> I can say with some confidence that without the git svn workflow, I
> would not be an Apache committer. I would have done exactly what I'd
> done for years prior - svn export from a tag, svn import, and patch.
> Maybe re-export and reapply my patches when a new release came out
> (but that was a pain in the ass, so didn't happen that frequently).
> But submitting my patches back was frequently too difficult because
> they were against a tag, not trunk. And even if they were against
> trunk, they were against trunk at a certain revision, which inevitably
> was not HEAD.
Git-svn is awesome (I use it), but since a Git merge cannot be
represented in Subversion, you aren't able to safely pull/merge/push
with other Git repos. It basically becomes a very fancy patch manager
when used this way.
> Adopting git/git svn did a lot of things, but mostly it gave me the
> ability to contribute back my patches while proceeding with
> development of a branched version containing my full patch set. For
> the project, this lead to smaller, easier to understand patch
> submissions(and, eventually, a new committer!).
>
> IMHO, I think the subject of the original blog post in this thread is
> just wrong. Forking isn't a feature. Merging is a feature.
Good point.
--
Eric Evans
eevans@rackspace.com
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: "Forking is a Feature" reactions?
Posted by Justin Edelson <ju...@gmail.com>.
On 9/15/10 7:18 PM, Ross Gardler wrote:
>
> In my opinion the above statements are absolutely correct. That is, the
> vast majority of local modifications never make it anywhere near project
> maintainers.
>
> GIT does not, and will not, change this on its own - it's a cultural
> issue not a tools issue.
In my personal experience, what git *does* change is that it makes it
more likely that those local modifications will be maintained in
relation to the ongoing development of the project (i.e. "trunk").
Because git allows for multiple remotes to be tracked, the downstream
user is able to keep their patch set (or multiple patch sets) up to date
by continuously merging changes from the central trunk.
I can say with some confidence that without the git svn workflow, I
would not be an Apache committer. I would have done exactly what I'd
done for years prior - svn export from a tag, svn import, and patch.
Maybe re-export and reapply my patches when a new release came out (but
that was a pain in the ass, so didn't happen that frequently). But
submitting my patches back was frequently too difficult because they
were against a tag, not trunk. And even if they were against trunk, they
were against trunk at a certain revision, which inevitably was not HEAD.
Adopting git/git svn did a lot of things, but mostly it gave me the
ability to contribute back my patches while proceeding with development
of a branched version containing my full patch set. For the project,
this lead to smaller, easier to understand patch submissions(and,
eventually, a new committer!).
IMHO, I think the subject of the original blog post in this thread is
just wrong. Forking isn't a feature. Merging is a feature.
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: "Forking is a Feature" reactions?
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: Ross Gardler <rg...@apache.org>
> To: community@apache.org
> Sent: Wed, September 15, 2010 7:18:17 PM
> Subject: Re: "Forking is a Feature" reactions?
>
> On 15/09/2010 19:32, Tony Finch wrote:
> > On Wed, 15 Sep 2010, Santiago Gala wrote:
> >> On Wed, Sep 15, 2010 at 8:04 AM, Dirk-Willem van Gulik
> >> <di...@webweaving.org> wrote:
> >>>
> >>> Especially as the pattern seems to be conductive to personal
> >>> gratification** more than community; and leads to patchcollections
> >>> which are the work of love of a single person quite easily. And that
> >>> seems to cause fragmentation on an end to end level. I.e. rather than
> >>> scratching your own itch - and solving it at a product level - you
> >>> create a small alternate reality in which you nullify the issue, in
> >>> which you isolate - and then welcome people on your island - but
> >>> you've not made the world a slightly easier place. Somehow it feels as
> >>> if there is some driver lacking, some positive need to have
> >>> communities collaborate.
> >>
> >> What makes you think that without github people effectively tries to
> >> get patches "upstream"? IMO, most of may patches have remained forever
> >> in my HD until I deleted or a crash destroyed them.
> >
> > Right. In my experience a lot of places that deploy open source software
> > will fix little niggles (gaps in functionality / integration impedance
> > mismatches / whatever) in an expedient manner. They are often reluctant
> > to expose their changes because they are too specific or scruffy.
>
> I don't work with a single team of developers, I work with hundreds
> of teams spread across the UK. I mention this because I suspect this
> gives me a broader personal experience of the realities of open source
> ***use*** than the majority of folk here.
>
> In my opinion the above statements are absolutely correct. That is, the
> vast majority of local modifications never make it anywhere near project
> maintainers.
>
> GIT does not, and will not, change this on its own - it's a cultural
> issue not a tools issue.
Sorta begs the question of whether such changes *should* be published.
> >> Github puts a *public* **indexable** fork one click away. It gives you
> >> a backup, so that there is incentive to have all your microchanges up
> >> asap.
> >
> > Right, and it seems to be encouraging people to make their previously
> > private patches public. I agree with you that dirkx is observing a problem
> > that was always there but previously less visible.
>
> Whilst I agree, I do not believe GIT will help change this. As a project
> maintainer I am unlikely to monitor X branches of my code, I'm going to
> expect people to tell me the patches I should consider. However, in this
> situation GIT does help due to its (allegedly) superior merge handling.
Merging aside, you raise a very good point. Just about every project I've
ever seen at Apache could use more *attention* - that is the scarce resource
that individuals try hard to protect. Fortunately it's not a conservative
resource, in that if a project is successful in bringing in new people,
the amount of attention they can bring to the project as a group increases.
It doesn't always work out that way, some committers demand more attention
than others do, but the gist of it is that overall it's better to have
"too many" committers than to not have enough. That is why the Incubator
likes to see growth and diversity in its podling's committer base.
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: "Forking is a Feature" reactions?
Posted by Ross Gardler <rg...@apache.org>.
On 15/09/2010 19:32, Tony Finch wrote:
> On Wed, 15 Sep 2010, Santiago Gala wrote:
>> On Wed, Sep 15, 2010 at 8:04 AM, Dirk-Willem van Gulik
>> <di...@webweaving.org> wrote:
>>>
>>> Especially as the pattern seems to be conductive to personal
>>> gratification** more than community; and leads to patchcollections
>>> which are the work of love of a single person quite easily. And that
>>> seems to cause fragmentation on an end to end level. I.e. rather than
>>> scratching your own itch - and solving it at a product level - you
>>> create a small alternate reality in which you nullify the issue, in
>>> which you isolate - and then welcome people on your island - but
>>> you've not made the world a slightly easier place. Somehow it feels as
>>> if there is some driver lacking, some positive need to have
>>> communities collaborate.
>>
>> What makes you think that without github people effectively tries to
>> get patches "upstream"? IMO, most of may patches have remained forever
>> in my HD until I deleted or a crash destroyed them.
>
> Right. In my experience a lot of places that deploy open source software
> will fix little niggles (gaps in functionality / integration impedance
> mismatches / whatever) in an expedient manner. They are often reluctant
> to expose their changes because they are too specific or scruffy.
I don't work with a single team of developers, I work with hundreds of
teams spread across the UK. I mention this because I suspect this gives
me a broader personal experience of the realities of open source
***use*** than the majority of folk here.
In my opinion the above statements are absolutely correct. That is, the
vast majority of local modifications never make it anywhere near project
maintainers.
GIT does not, and will not, change this on its own - it's a cultural
issue not a tools issue.
>> Github puts a *public* **indexable** fork one click away. It gives you
>> a backup, so that there is incentive to have all your microchanges up
>> asap.
>
> Right, and it seems to be encouraging people to make their previously
> private patches public. I agree with you that dirkx is observing a problem
> that was always there but previously less visible.
Whilst I agree, I do not believe GIT will help change this. As a project
maintainer I am unlikely to monitor X branches of my code, I'm going to
expect people to tell me the patches I should consider. However, in this
situation GIT does help due to its (allegedly) superior merge handling.
Problem is we are still waiting for the contributor to be confident
enough to say "look at my code it is great". So we've won almost nothing
by moving to GIT. Unless...
>> IMO, the main differente between distributed and centralized SCM is that
>> centralized SCM people views my work as "dirty" working copy, while
>> distributed SCM people views it as commits pending integration in my
>> repository...
>
> I have been quite impressed by the culture of code review on the git
> mailing list, and the way they use the tools to improve patchsets before
> integration.
I can't comment on this, but it sounds like you are saying that there
are cultural models that work. I'd like to hear more about them, but I
guess getting through the noise of a discussion on this list will
discourage anyone with the necessary experience spending time on trying
to communicate the lessons to be learned.
Ross
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: "Forking is a Feature" reactions?
Posted by Tony Finch <do...@dotat.at>.
On Wed, 15 Sep 2010, Santiago Gala wrote:
> On Wed, Sep 15, 2010 at 8:04 AM, Dirk-Willem van Gulik
> <di...@webweaving.org> wrote:
> >
> > Especially as the pattern seems to be conductive to personal
> > gratification** more than community; and leads to patchcollections
> > which are the work of love of a single person quite easily. And that
> > seems to cause fragmentation on an end to end level. I.e. rather than
> > scratching your own itch - and solving it at a product level - you
> > create a small alternate reality in which you nullify the issue, in
> > which you isolate - and then welcome people on your island - but
> > you've not made the world a slightly easier place. Somehow it feels as
> > if there is some driver lacking, some positive need to have
> > communities collaborate.
>
> What makes you think that without github people effectively tries to
> get patches "upstream"? IMO, most of may patches have remained forever
> in my HD until I deleted or a crash destroyed them.
Right. In my experience a lot of places that deploy open source software
will fix little niggles (gaps in functionality / integration impedance
mismatches / whatever) in an expedient manner. They are often reluctant
to expose their changes because they are too specific or scruffy.
> Github puts a *public* **indexable** fork one click away. It gives you
> a backup, so that there is incentive to have all your microchanges up
> asap.
Right, and it seems to be encouraging people to make their previously
private patches public. I agree with you that dirkx is observing a problem
that was always there but previously less visible.
> IMO, the main differente between distributed and centralized SCM is that
> centralized SCM people views my work as "dirty" working copy, while
> distributed SCM people views it as commits pending integration in my
> repository...
I have been quite impressed by the culture of code review on the git
mailing list, and the way they use the tools to improve patchsets before
integration.
Tony.
--
f.anthony.n.finch <do...@dotat.at> http://dotat.at/
HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7,
DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR
ROUGH. RAIN THEN FAIR. GOOD.
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: "Forking is a Feature" reactions?
Posted by Santiago Gala <sa...@gmail.com>.
On Wed, Sep 15, 2010 at 8:04 AM, Dirk-Willem van Gulik
<di...@webweaving.org> wrote:
>
> On 13 Sep 2010, at 19:29, Ben Hyde wrote:
>
>> On Sep 13, 2010, at 7:37 AM, Sam Ruby wrote:
>>> I just can't resist the opportunity to fork this discussion:
>>>
>>> http://intertwingly.net/blog/2010/09/13/One-True-Way
>>
>> tee hee
>>
>> have we pushed the apache way pages to git hub yet?
>
> That would be a complex message :)
>
> While github itself - and its ecosystem/people interaction is really interesting and innovative* - the associated habits around 'git' are not always. Or rather - its conductive ness to having large pseudo branches (really just large patches batched up some what) is not.
>
> Especially as the pattern seems to be conductive to personal gratification** more than community; and leads to patchcollections which are the work of love of a single person quite easily. And that seems to cause fragmentation on an end to end level. I.e. rather than scratching your own itch - and solving it at a product level - you create a small alternate reality in which you nullify the issue, in which you isolate - and then welcome people on your island - but you've not made the world a slightly easier place. Somehow it feels as if there is some driver lacking, some positive need to have communities collaborate.
>
> I am quite worried (and in equal parts intrigued) whether we're creating a new type of entropy with a different type of 'bit rot'.
What makes you think that without github people effectively tries to
get patches "upstream"? IMO, most of may patches have remained forever
in my HD until I deleted or a crash destroyed them.
Github puts a *public* **indexable** fork one click away. It gives you
a backup, so that there is incentive to have all your microchanges up
asap.
The work of picking up valuable patches from draft changes or even
stupid ones remains in who is going to obtain value from them, i.e.,
the integrator. A number of times I have kept my patch and applied it
to a custom package for years because the process to get it into
upstream was too draining on my energy. With github at least people
can find it via google, or I can refer to people contacting me to it
years after the fact...
The fragmentation that you appreciate in github is so because you can
see it. We have the same fragmentation, only it is hidden in private
working copies across the world. IMO, the main differente between
distributed and centralized SCM is that centralized SCM people views
my work as "dirty" working copy, while distributed SCM people views it
as commits pending integration in my repository...
BTW, on an unrelated subject: what was going on in the development of
the Apache httpd server the week before 2001-9-11, i.e. 2001-9-03
through 10? Yes, I mean the week before 9/11 I'm doing some statistics
about OS projects, and this week is an outlier re: relation between
commits and list traffic for the httpd server. Any clue?
Regards
Santiago
>
> Dw.
>
> *: though lack some of the (i)CLA cleanness which is troubling me.
> **: speaking purely from what drives me personally to put stuff there - along with the avoidance of having to collaborate with people to spare/save energy - making me care more about my code - as opposed to a product for society.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: community-unsubscribe@apache.org
> For additional commands, e-mail: community-help@apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: "Forking is a Feature" reactions?
Posted by Isabel Drost <is...@apache.org>.
On Wed, 15 Sep 2010 Dirk-Willem van Gulik <di...@webweaving.org> wrote:
> *: though lack some of the (i)CLA cleanness which is troubling me.
Maybe it's instructive to have a look at how patch origin cleanness and
signoff (similar, though not (i)CLA) is dealt with at the Linux Kernel
project:
http://www.youtube.com/fosdemtalks#p/u/0/LLBrBBImJt4 (at about minute
21:30)
Isabel
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: "Forking is a Feature" reactions?
Posted by Santiago Gala <sa...@gmail.com>.
On Wed, Sep 15, 2010 at 5:15 PM, Joe Schaefer <jo...@yahoo.com> wrote:
> ----- Original Message ----
>
>> From: Torsten Curdt <tc...@vafer.org>
>> To: community@apache.org
>> Sent: Wed, September 15, 2010 11:10:21 AM
>> Subject: Re: "Forking is a Feature" reactions?
>>
>> >> Everyone else gets a "working
>> >> copy" and is expected to create a patch (or patches) and then work to
>> >> convince a committer to apply them.
>> >
>> > That's not the Apache model, fwiw. Collaboration means you work as equals,
>> > committer status or not.
>>
>> Hm? Reality check?
>>
>> Usually patches only get applied if committers think they are good
>> enough and worthy to apply. Not every patch gets applied no matter
>> what.
>
> And how is that dependent on the version control tool? See, it isn't.
> It's a function of the community's value system.
It is not dependent of the tool, but of the distributed vs centralized
paradigm. In a distributed paradigm, your repository is "central" only
if a sizeable number of developers consider it so. I.e. going from
centralized to distributed removes the power site which is the central
repository with its users/passwords, etc. and turns the choice of a
central site or a set of those into a social problem.
>
>> >> A distributed version control system is a measure toward eliminating
>> >> that have/have not distinction; it reduces the barrier to contribution.
>> >
>> > No it doesn't.
Yes it does ;)
>>
>> I could create the longest thread on this list by saying "Yes, it does!"
>> ...but maybe let's say - that's what people call a difference in opinion ;)
>
> That shouldn't prevent more knowledgable people from correcting you tho.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: community-unsubscribe@apache.org
> For additional commands, e-mail: community-help@apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: "Forking is a Feature" reactions?
Posted by Santiago Gala <sa...@gmail.com>.
On Thu, Sep 16, 2010 at 5:14 PM, Dirk-Willem van Gulik
<di...@webweaving.org> wrote:
>
> On 15 Sep 2010, at 16:38, Torsten Curdt wrote:
>
>>>> Usually patches only get applied if committers think they are good
>>>> enough and worthy to apply. Not every patch gets applied no matter
>>>> what.
>>>
>>> And how is that dependent on the version control tool? See, it isn't.
>>> It's a function of the community's value system.
>>
>> In his repository he can just commit.
>
> And hence there is no penalty to do so - the only social capital involved is your own. There is no need to consider a wider range of use cases. You are an isolated artisan.
>
>> Whether that gets merged to the
>> "official" repository is a different question. And only for *that* it
>> is the same value system.
>
> I guess for me this is the story of the very competent Artisan; the amazing artist and all the works of incredible sophistication we got to see until the mid 1700's. Which did allow others to stand on the sholders of prior workers and mentors - but rarely gave whole ecosystems a boost. Even the building of cathedrals had this temporal dynamic - and few are 'integrated'.
>
This was mostly because an architect needed to spend a substantial
part of her life just to visit, say, Cordoba and learn from the
Mosque, or Reims, or whatever place. And also because reproduction of
text or figures was lowres and damned expensive.
git puts your forks in open sight, a person can get familiar with the
status of the whole network of forks or, say, bottle.py in a matter or
hours or a few days at most: http://github.com/defnull/bottle/network
In most projects I've seen most "forks" are just for small patches or
adjustments, and the maintainer can monitor them and pick up good
patches even without fetch requests, specially when suggested by third
party users...
I mean the technology makes mucho more easy to compare cathedrals now
than it was in the middle ages...
> While leading to a certain time of innovation - the industrial revolution and the internet today provides us with a different type of amplifier - which goes way beyond mere communication - it is furthering a different quality.
>
> And I certainly believe that a certain cost/pressure to make your contributions cleaner & wider usable is helpful as for social cohesion and leads to better build foundations.
>
> Dw
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: community-unsubscribe@apache.org
> For additional commands, e-mail: community-help@apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: "Forking is a Feature" reactions?
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
On 15 Sep 2010, at 16:38, Torsten Curdt wrote:
>>> Usually patches only get applied if committers think they are good
>>> enough and worthy to apply. Not every patch gets applied no matter
>>> what.
>>
>> And how is that dependent on the version control tool? See, it isn't.
>> It's a function of the community's value system.
>
> In his repository he can just commit.
And hence there is no penalty to do so - the only social capital involved is your own. There is no need to consider a wider range of use cases. You are an isolated artisan.
> Whether that gets merged to the
> "official" repository is a different question. And only for *that* it
> is the same value system.
I guess for me this is the story of the very competent Artisan; the amazing artist and all the works of incredible sophistication we got to see until the mid 1700's. Which did allow others to stand on the sholders of prior workers and mentors - but rarely gave whole ecosystems a boost. Even the building of cathedrals had this temporal dynamic - and few are 'integrated'.
While leading to a certain time of innovation - the industrial revolution and the internet today provides us with a different type of amplifier - which goes way beyond mere communication - it is furthering a different quality.
And I certainly believe that a certain cost/pressure to make your contributions cleaner & wider usable is helpful as for social cohesion and leads to better build foundations.
Dw
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: "Forking is a Feature" reactions?
Posted by Torsten Curdt <tc...@apache.org>.
>> Usually patches only get applied if committers think they are good
>> enough and worthy to apply. Not every patch gets applied no matter
>> what.
>
> And how is that dependent on the version control tool? See, it isn't.
> It's a function of the community's value system.
In his repository he can just commit. Whether that gets merged to the
"official" repository is a different question. And only for *that* it
is the same value system.
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: "Forking is a Feature" reactions?
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: Torsten Curdt <tc...@vafer.org>
> To: community@apache.org
> Sent: Wed, September 15, 2010 11:10:21 AM
> Subject: Re: "Forking is a Feature" reactions?
>
> >> Everyone else gets a "working
> >> copy" and is expected to create a patch (or patches) and then work to
> >> convince a committer to apply them.
> >
> > That's not the Apache model, fwiw. Collaboration means you work as equals,
> > committer status or not.
>
> Hm? Reality check?
>
> Usually patches only get applied if committers think they are good
> enough and worthy to apply. Not every patch gets applied no matter
> what.
And how is that dependent on the version control tool? See, it isn't.
It's a function of the community's value system.
> >> A distributed version control system is a measure toward eliminating
> >> that have/have not distinction; it reduces the barrier to contribution.
> >
> > No it doesn't.
>
> I could create the longest thread on this list by saying "Yes, it does!"
> ...but maybe let's say - that's what people call a difference in opinion ;)
That shouldn't prevent more knowledgable people from correcting you tho.
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: "Forking is a Feature" reactions?
Posted by Torsten Curdt <tc...@vafer.org>.
>> Everyone else gets a "working
>> copy" and is expected to create a patch (or patches) and then work to
>> convince a committer to apply them.
>
> That's not the Apache model, fwiw. Collaboration means you work as equals,
> committer status or not.
Hm? Reality check?
Usually patches only get applied if committers think they are good
enough and worthy to apply. Not every patch gets applied no matter
what.
>> A distributed version control system is a measure toward eliminating
>> that have/have not distinction; it reduces the barrier to contribution.
>
> No it doesn't.
I could create the longest thread on this list by saying "Yes, it does!"
...but maybe let's say - that's what people call a difference in opinion ;)
cheers
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: "Forking is a Feature" reactions?
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
On 15 Sep 2010, at 16:50, Santiago Gala wrote:
> distributed SCM along those last 5 years or so) can keep the illusion
> that a technical solution (called "centralization" here) can keep an
> organization together more than a set of core values can.
No sorry - we are arguing (or at least I am) that a certain tool jives better with a certain set of core values than another.
Dw.
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: "Forking is a Feature" reactions?
Posted by Rich Bowen <rb...@rcbowen.com>.
On Sep 15, 2010, at 11:50 AM, Santiago Gala wrote:
> I see the "dscm is an unsuitable workflow for collaborative
> development" meme as this: a meme.
I don't see it as unsuitable. I see it as different. It's different in
a lot of ways, but is neither better nor worse. The insistence that
it's better is no less annoying than the insistence that it's worse. A
lot of my personal resistance to git has been, since the beginning,
that people have told me I'm an idiot for using svn. That kind of
persuasion hasn't been persuasive.
Now that I've used git, it seems like just a different way of doing
the same thing. And not different in ways that I found appealing. Just
different. So I had to learn how to do exactly the same things in new
ways. This didn't seem like progress to me.
I've read dozens of articles about how it's so much better, including
several by you, Santiago, and while I follow your reasoning, it didn't
coincide with my experience in the real world. And, yes, I did use
github, and I simply don't agree that using a website to manage my
code is somehow more wonderful than using svn command-line tools. The
reality was that, as a creature of habit, moving my stuff to a web-
centric interface, made me forget about the project that I was working
on. Fortunately, every time I read something about the superiority of
github - which is about once a week - I'm reminded that it's out there.
--
Rich Bowen
rbowen@rcbowen.com
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: "Forking is a Feature" reactions?
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: Torsten Curdt <tc...@vafer.org>
> To: community@apache.org
> Sent: Wed, September 15, 2010 2:16:42 PM
> Subject: Re: "Forking is a Feature" reactions?
>
> > To try to put my finger on the key distinction I've seen, a "centralized"
> > workflow puts demands on people to "make promises" up front.
>
> Not necessarily. Enough people start playing with something. Just to
> see if it works. All that happens on their local system though. I have
> never seen a project where everyone is having his/her own svn branch
> just committing away all experiments.
I didn't mean to imply that using svn guarantees success. Far from
it, success at Apache is pretty challenging for Incubating projects.
>
> > IOW before
> > you start that work on a snazzy new feature, you have to explain to people
> > what you're doing and why, and to set expectations for the final outcome.
> > That's because they will be exposed to your work whether they like it or
> > not, because it all gets thrown onto the commit list.
>
> Only if you actually have the right to commit. Which is exactly one of
> the points mentioned before.
Well if someone shows up on a dev list and says all those things, and has
a little bit of an early implementation to review, seems to me they should
be allowed to work directly in the svn repo. Yes, it involves someone
"promising" to do something, and the community actually making a minor
bet on their success. Gradually people learn from the experience, and
if it's a positive one they continue to make collective bets on that person's
work product. If it doesn't work out the committer disappears and nothing
much is lost. I don't see what the big deal is about "right to commit"
as if it's inherently something difficult to obtain. It shouldn't be that
way (PMC membership can be another story however, but that's not tied
to any vc tool). It's just the "right" to do some work on the project
where full access to the vc tool is appropriate.
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: "Forking is a Feature" reactions?
Posted by Torsten Curdt <tc...@vafer.org>.
> To try to put my finger on the key distinction I've seen, a "centralized"
> workflow puts demands on people to "make promises" up front.
Not necessarily. Enough people start playing with something. Just to
see if it works. All that happens on their local system though. I have
never seen a project where everyone is having his/her own svn branch
just committing away all experiments.
> IOW before
> you start that work on a snazzy new feature, you have to explain to people
> what you're doing and why, and to set expectations for the final outcome.
> That's because they will be exposed to your work whether they like it or
> not, because it all gets thrown onto the commit list.
Only if you actually have the right to commit. Which is exactly one of
the points mentioned before.
> In a decentralized workflow you don't need to do that, in fact you can
> keep your branch entirely to yourself and only reveal the work once it's
> completed.
Just like the uncommitted changes in your local svn repo ...especially
if you are not a committer.
...but could we maybe just end this thread? At least I don't see
anything useful coming out of this.
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: "Forking is a Feature" reactions?
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: Joe Schaefer <jo...@yahoo.com>
> To: community@apache.org
> Sent: Wed, September 15, 2010 12:05:27 PM
> Subject: Re: "Forking is a Feature" reactions?
>
> ----- Original Message ----
>
> > From: Santiago Gala <sa...@gmail.com>
> > To: community@apache.org
> > Sent: Wed, September 15, 2010 11:50:34 AM
> > Subject: Re: "Forking is a Feature" reactions?
> >
> > On Wed, Sep 15, 2010 at 5:23 PM, Joe Schaefer <jo...@yahoo.com>
>wrote:
> > (...)
> > > It does give me pause because I believe there's an important role for a
> > > set of central services for projects (and for societies in general). As
> > > far as Apache goes, it's a virtual organization whose roots lie in the
> > > stuff we have stored in various datacenters. Nevertheless there is a
> > > palpable sense of what it means to "do work at Apache", and part of that
> > > illusion is provided by our centralization. I do wonder how we'd manage
> > > to maintain that illusion if we completely decentralized our core
> workflows.
> > >
> >
> > It is amazing how you (and I mean a big y'all of people negating
> > distributed SCM along those last 5 years or so) can keep the illusion
> > that a technical solution (called "centralization" here) can keep an
> > organization together more than a set of core values can.
>
> It comes from experience with dealing with younger projects in the
> Incubator that are not so enthralled with svn's workflows, and the
> social problems that seem to result from those attitudes. Eric is
> a relatively new committer at Apache and he still talks about his
> role as being like a "gatekeeper". That's not something he picked
> up from us.
To try to put my finger on the key distinction I've seen, a "centralized"
workflow puts demands on people to "make promises" up front. IOW before
you start that work on a snazzy new feature, you have to explain to people
what you're doing and why, and to set expectations for the final outcome.
That's because they will be exposed to your work whether they like it or
not, because it all gets thrown onto the commit list. IME it is a rare
human being that can follow through on a promise made to another over the
net. It's part of what makes Apache people so special ;-).
In a decentralized workflow you don't need to do that, in fact you can
keep your branch entirely to yourself and only reveal the work once it's
completed. If committers work this way from the get-go by using git-svn,
they tend not to look for such pre-agreements from each other, hoping for
review on the backend. And the idea that a big lump of code dcommitted
in rapid succession reveals the same amount of information as it would
have if the commits were subject to review in real time really doesn't
do justice to the whole concept of peer review, especially the lightweight
manual inspection of the commit messages. Yes you have all the tools to
make sense of everything save for one key aspect: the evolution of time.
And that lightweight evaluation that comes from reading and following up
to commit messages is really a big part of how Apache projects that are
operating well do function. Yes we can automate per-commit testing
with buildbot and hudson, but testing alone won't create a community
that places a paramount importance on constructive and timely peer review.
OTOH when non-committers take part in the review process, I really have no
concerns about the health of a project from an Apache standpoint, git usage
notwithstanding.
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: "Forking is a Feature" reactions?
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: Eric Evans <ee...@rackspace.com>
> To: community@apache.org
> Sent: Wed, September 15, 2010 2:30:25 PM
> Subject: Re: "Forking is a Feature" reactions?
>
> On Wed, 2010-09-15 at 10:19 -0700, Joe Schaefer wrote:
> > > I do not view myself as a gatekeeper, and more importantly, that is
> > > not a role I desire (for myself or anyone else). However, I'm not
> > > self-deluded enough to believe that because I aspire to lofty
> > > ideals, that I somehow do not possess access to a controlled
> > > resource _that others do not_.
> >
> > Then perhaps your portrayal of the typical role for an Apache
> > committer was "exaggerated for effect".
>
> I had thought I was precise in my wording, and I've reread my messages
> to this thread, can you point me at the alleged exaggeration? Or is it
> that you in general object to the term "gatekeeper" in reference to the
> relationship between someone who possess access rights to a controlled
> resource, and someone who does not.
You could just as easily describe committers here as "stewards" or
"facilitators" which would be far more apropo of what we try to
teach people about committership. Gatekeeper is about as loaded
as calling them traffic cops, so yeah it's objectionable when applied
to Apache people.
>
> > When the day comes that most of our patch submissions to jira are
> > git-formatted (and hence incompatible with svn) I will be far more
> > receptive to the idea that svn is a greater barrier to community
> > participation than svn is.
^^^
Sorry I meant to write git there. See
http://stackoverflow.com/questions/708202/git-format-patch-to-be-svn-compatable
AIUI compatibility is a feature that will be included in svn 1.7. Contrary
to the opinions of some the git folks and the svn folks do collaborate on
feature sets.
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: "Forking is a Feature" reactions?
Posted by Eric Evans <ee...@rackspace.com>.
On Wed, 2010-09-15 at 10:19 -0700, Joe Schaefer wrote:
> > I do not view myself as a gatekeeper, and more importantly, that is
> > not a role I desire (for myself or anyone else). However, I'm not
> > self-deluded enough to believe that because I aspire to lofty
> > ideals, that I somehow do not possess access to a controlled
> > resource _that others do not_.
>
> Then perhaps your portrayal of the typical role for an Apache
> committer was "exaggerated for effect".
I had thought I was precise in my wording, and I've reread my messages
to this thread, can you point me at the alleged exaggeration? Or is it
that you in general object to the term "gatekeeper" in reference to the
relationship between someone who possess access rights to a controlled
resource, and someone who does not.
> When the day comes that most of our patch submissions to jira are
> git-formatted (and hence incompatible with svn) I will be far more
> receptive to the idea that svn is a greater barrier to community
> participation than svn is.
Umm... what?
> > If anything, my interest in a decentralized version control system
> > is to even the playing field, remove obstacles, and empower
> > contributors.
> Sure, but you have to ask yourself why it is that Apache committers
> tend to make a *lot* more noise about this than our contributors do.
> I suspect the motivation is more "because git is so powerful" than the
> more idealistic notion that "git levels the playing field". But I
> commend your idealism nonetheless.
Maybe the barrier to having yourself heard is even greater than code
contribution, or maybe it's more intimidating. Maybe it is because
committers (those with the respective access rights on svn.apache.org),
are the ones saddled with coordinating contributions in patch form from
multiple sources. Maybe it's because "Git is so powerful" and they want
to leverage that power (is that wrong?).
--
Eric Evans
eevans@rackspace.com
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: "Forking is a Feature" reactions?
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: Eric Evans <ee...@rackspace.com>
> To: community@apache.org
> Sent: Wed, September 15, 2010 1:02:17 PM
> Subject: Re: "Forking is a Feature" reactions?
>
> On Wed, 2010-09-15 at 09:05 -0700, Joe Schaefer wrote:
> > > It is amazing how you (and I mean a big y'all of people negating
> > > distributed SCM along those last 5 years or so) can keep the
> > > illusion that a technical solution (called "centralization" here)
> > > can keep an organization together more than a set of core values
> > > can.
> >
> > It comes from experience with dealing with younger projects in the
> > Incubator that are not so enthralled with svn's workflows, and the
> > social problems that seem to result from those attitudes. Eric is
> > a relatively new committer at Apache and he still talks about his
> > role as being like a "gatekeeper". That's not something he picked
> > up from us.
>
> I'm going to work really hard at not being offended by this.
>
> I do not view myself as a gatekeeper, and more importantly, that is not
> a role I desire (for myself or anyone else). However, I'm not
> self-deluded enough to believe that because I aspire to lofty ideals,
> that I somehow do not possess access to a controlled resource _that
> others do not_.
Then perhaps your portrayal of the typical role for an Apache committer
was "exaggerated for effect". When the day comes that most of our
patch submissions to jira are git-formatted (and hence incompatible with
svn) I will be far more receptive to the idea that svn is a greater barrier
to community participation than svn is.
> If anything, my interest in a decentralized version control system is to
> even the playing field, remove obstacles, and empower contributors.
Sure, but you have to ask yourself why it is that Apache committers tend
to make a *lot* more noise about this than our contributors do. I suspect
the motivation is more "because git is so powerful" than the more idealistic
notion that "git levels the playing field". But I commend your idealism
nonetheless.
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: "Forking is a Feature" reactions?
Posted by Eric Evans <ee...@rackspace.com>.
On Wed, 2010-09-15 at 09:05 -0700, Joe Schaefer wrote:
> > It is amazing how you (and I mean a big y'all of people negating
> > distributed SCM along those last 5 years or so) can keep the
> > illusion that a technical solution (called "centralization" here)
> > can keep an organization together more than a set of core values
> > can.
>
> It comes from experience with dealing with younger projects in the
> Incubator that are not so enthralled with svn's workflows, and the
> social problems that seem to result from those attitudes. Eric is
> a relatively new committer at Apache and he still talks about his
> role as being like a "gatekeeper". That's not something he picked
> up from us.
I'm going to work really hard at not being offended by this.
I do not view myself as a gatekeeper, and more importantly, that is not
a role I desire (for myself or anyone else). However, I'm not
self-deluded enough to believe that because I aspire to lofty ideals,
that I somehow do not possess access to a controlled resource _that
others do not_.
If anything, my interest in a decentralized version control system is to
even the playing field, remove obstacles, and empower contributors.
--
Eric Evans
eevans@rackspace.com
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: "Forking is a Feature" reactions?
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: Santiago Gala <sa...@gmail.com>
> To: community@apache.org
> Sent: Wed, September 15, 2010 11:50:34 AM
> Subject: Re: "Forking is a Feature" reactions?
>
> On Wed, Sep 15, 2010 at 5:23 PM, Joe Schaefer <jo...@yahoo.com> wrote:
> (...)
> > It does give me pause because I believe there's an important role for a
> > set of central services for projects (and for societies in general). As
> > far as Apache goes, it's a virtual organization whose roots lie in the
> > stuff we have stored in various datacenters. Nevertheless there is a
> > palpable sense of what it means to "do work at Apache", and part of that
> > illusion is provided by our centralization. I do wonder how we'd manage
> > to maintain that illusion if we completely decentralized our core
workflows.
> >
>
> It is amazing how you (and I mean a big y'all of people negating
> distributed SCM along those last 5 years or so) can keep the illusion
> that a technical solution (called "centralization" here) can keep an
> organization together more than a set of core values can.
It comes from experience with dealing with younger projects in the
Incubator that are not so enthralled with svn's workflows, and the
social problems that seem to result from those attitudes. Eric is
a relatively new committer at Apache and he still talks about his
role as being like a "gatekeeper". That's not something he picked
up from us.
>
> While I agree that changing tools, like changing stylesheets or
> electing a new board, changes an organization, I don't believe at all
> in "subversion" or even in "centralized SCM" as a shared ASF value.
Good because although some people may think that, I'm not one of them.
The tool we use is serving the org well and that is my overriding
concern. The jury's still out on whether migrating wholesale to git
instead of just providing git mirrors is actually in the org's best
interests.
> The license, the belief in collective decision making, our history,
> etc. are central. Not the technology we use for SCM. We already
> changed from cvs to svn and our world stayed reasonably similar.
Well svn was billed as a better version of cvs. It's not like the
workflow changed much between them.
> I see the "dscm is an unsuitable workflow for collaborative
> development" meme as this: a meme.
>
> You can think of git as just a local backup for your changes and a
> tool for patch handing like quilt blended together. This is often how
> I think about it when I'm using "git svn" for legacy subversion sites
> like the ASF. If you add github for a public remote backup this would
> be similar to having a quilt setup exported as a public share in one
> of those cloud backups... only with standardized and very efficient
> transfers
AIUI github already carries our mirrors, so we're already *doing* that.
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: "Forking is a Feature" reactions?
Posted by Santiago Gala <sa...@gmail.com>.
On Wed, Sep 15, 2010 at 5:23 PM, Joe Schaefer <jo...@yahoo.com> wrote:
(...)
> It does give me pause because I believe there's an important role for a
> set of central services for projects (and for societies in general). As
> far as Apache goes, it's a virtual organization whose roots lie in the
> stuff we have stored in various datacenters. Nevertheless there is a
> palpable sense of what it means to "do work at Apache", and part of that
> illusion is provided by our centralization. I do wonder how we'd manage
> to maintain that illusion if we completely decentralized our core workflows.
>
It is amazing how you (and I mean a big y'all of people negating
distributed SCM along those last 5 years or so) can keep the illusion
that a technical solution (called "centralization" here) can keep an
organization together more than a set of core values can.
While I agree that changing tools, like changing stylesheets or
electing a new board, changes an organization, I don't believe at all
in "subversion" or even in "centralized SCM" as a shared ASF value.
The license, the belief in collective decision making, our history,
etc. are central. Not the technology we use for SCM. We already
changed from cvs to svn and our world stayed reasonably similar.
I see the "dscm is an unsuitable workflow for collaborative
development" meme as this: a meme.
You can think of git as just a local backup for your changes and a
tool for patch handing like quilt blended together. This is often how
I think about it when I'm using "git svn" for legacy subversion sites
like the ASF. If you add github for a public remote backup this would
be similar to having a quilt setup exported as a public share in one
of those cloud backups... only with standardized and very efficient
transfers
Regards
Santiago
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: "Forking is a Feature" reactions?
Posted by Sam Ruby <ru...@intertwingly.net>.
On Wed, Sep 15, 2010 at 12:50 PM, Niclas Hedhman <ni...@hedhman.org> wrote:
> On Wed, Sep 15, 2010 at 11:23 PM, Joe Schaefer <jo...@yahoo.com> wrote:
>> I can appreciate that, but the stock answer to that is "just give them
>> commit". High barriers to committership is not what Apache is about.
>
> You may be interested to learn that the Open Participation Software
> for Java (htttP;//wiki.ops4j.org) was created with a "Wiki brought to
> coding" and "No barrier" attitude, as a result of what we perceived as
> "high barriers" at ASF.
Ex. cell. ent.
For some projects, the barriers to entry at the ASF are too high. I
can live with that.
For some projects, the barriers to entry at the ASF are too low. I
can live with that too.
I hope that projects that are a perfect match to the ASF find a good
home here. I hope that the projects which are not a good match to the
ASF find what they need.
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: "Forking is a Feature" reactions?
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wed, Sep 15, 2010 at 11:23 PM, Joe Schaefer <jo...@yahoo.com> wrote:
> I can appreciate that, but the stock answer to that is "just give them
> commit". High barriers to committership is not what Apache is about.
You may be interested to learn that the Open Participation Software
for Java (htttP;//wiki.ops4j.org) was created with a "Wiki brought to
coding" and "No barrier" attitude, as a result of what we perceived as
"high barriers" at ASF.
We are still uncertain about the community dynamics over time (people
tend to code more and debate less), and right now there is a
discussion whether GitHub will lower or raise that said barrier,
Cheers
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java
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: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: "Forking is a Feature" reactions?
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: Eric Evans <ee...@rackspace.com>
> To: community@apache.org
> Sent: Wed, September 15, 2010 11:13:15 AM
> Subject: Re: "Forking is a Feature" reactions?
>
> On Wed, 2010-09-15 at 07:32 -0700, Joe Schaefer wrote:
> > > With a centralized vcs, a select group of privileged individuals
> > > are given access, they are the gate keepers.
> >
> > Eh, no. That's exactly how Linux works, with people having protective
> > attitudes towards their own trees: git only makes that mode of working
> > easier. Here a committer's job is to *facilitate* inclusive work, not
> > prevent it.
>
> I don't think the Linux work-flow is a particularly good example for
> anything other than Linux. The problem set certainly doesn't map well
> to any of the projects I work on.
>
> > > Everyone else gets a "working copy" and is expected to create a
> > > patch (or patches) and then work to convince a committer to apply
> > > them.
> >
> > That's not the Apache model, fwiw. Collaboration means you work as
> > equals, committer status or not.
>
> I agree with the sentiment, but the choice of distributed vs.
> centralized vcs is a technical one. You can be as open and inclusive
> with contributors as you want, without commit access they're relegated
> to a second-class work-flow.
I can appreciate that, but the stock answer to that is "just give them
commit". High barriers to committership is not what Apache is about.
>
> > > A distributed version control system is a measure toward
> > > eliminating that have/have not distinction; it reduces the barrier
> > > to contribution.
> >
> > No it doesn't. The learning curve alone is a barrier to its adoption.
> > It just means you have the same access to the history as anyone else,
> > and can develop on branches with far greater ease. Github is the
> > great new thing here, not git itself. If github were open source we'd
> > probably be using it at Apache already in some form.
>
> I disagree, Github adds a lot of value, but I'm thinking in terms of the
> differences between distributed vs. centralized systems. The argument is
> the same with or without Github, and could likewise include Mercurial,
> Bazaar, etc.
>
> > > Instead of a working copy you get a full working repository.
> > > Contributors can have long running branches where they work on
> > > large features while easily keeping in sync with upstream
> > > changes. And when the contributor repos are public, others can
> > > follow their progress and provide feedback and collaborate.
> > >
> > > If useful changesets that are languishing in random repositories
> > > and are not making it upstream, that is a social problem, not a
> > > technical one.
> >
> > Yes, but that just begs the point: this thread is about the social
> > implications of the choice of vc tool, and the aforementioned author
> > of the blog post seems to think forking in all its forms is a good
> > idea for societies. Somehow I doubt that's the case.
>
> It doesn't frighten me.
It does give me pause because I believe there's an important role for a
set of central services for projects (and for societies in general). As
far as Apache goes, it's a virtual organization whose roots lie in the
stuff we have stored in various datacenters. Nevertheless there is a
palpable sense of what it means to "do work at Apache", and part of that
illusion is provided by our centralization. I do wonder how we'd manage
to maintain that illusion if we completely decentralized our core workflows.
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: "Forking is a Feature" reactions?
Posted by Eric Evans <ee...@rackspace.com>.
On Wed, 2010-09-15 at 07:32 -0700, Joe Schaefer wrote:
> > With a centralized vcs, a select group of privileged individuals
> > are given access, they are the gate keepers.
>
> Eh, no. That's exactly how Linux works, with people having protective
> attitudes towards their own trees: git only makes that mode of working
> easier. Here a committer's job is to *facilitate* inclusive work, not
> prevent it.
I don't think the Linux work-flow is a particularly good example for
anything other than Linux. The problem set certainly doesn't map well
to any of the projects I work on.
> > Everyone else gets a "working copy" and is expected to create a
> > patch (or patches) and then work to convince a committer to apply
> > them.
>
> That's not the Apache model, fwiw. Collaboration means you work as
> equals, committer status or not.
I agree with the sentiment, but the choice of distributed vs.
centralized vcs is a technical one. You can be as open and inclusive
with contributors as you want, without commit access they're relegated
to a second-class work-flow.
> > A distributed version control system is a measure toward
> > eliminating that have/have not distinction; it reduces the barrier
> > to contribution.
>
> No it doesn't. The learning curve alone is a barrier to its adoption.
> It just means you have the same access to the history as anyone else,
> and can develop on branches with far greater ease. Github is the
> great new thing here, not git itself. If github were open source we'd
> probably be using it at Apache already in some form.
I disagree, Github adds a lot of value, but I'm thinking in terms of the
differences between distributed vs. centralized systems. The argument is
the same with or without Github, and could likewise include Mercurial,
Bazaar, etc.
> > Instead of a working copy you get a full working repository.
> > Contributors can have long running branches where they work on
> > large features while easily keeping in sync with upstream
> > changes. And when the contributor repos are public, others can
> > follow their progress and provide feedback and collaborate.
> >
> > If useful changesets that are languishing in random repositories
> > and are not making it upstream, that is a social problem, not a
> > technical one.
>
> Yes, but that just begs the point: this thread is about the social
> implications of the choice of vc tool, and the aforementioned author
> of the blog post seems to think forking in all its forms is a good
> idea for societies. Somehow I doubt that's the case.
It doesn't frighten me.
--
Eric Evans
eevans@rackspace.com
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: "Forking is a Feature" reactions?
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: Eric Evans <ee...@rackspace.com>
> To: community@apache.org
> Sent: Wed, September 15, 2010 10:18:46 AM
> Subject: Re: "Forking is a Feature" reactions?
>
> On Wed, 2010-09-15 at 08:04 +0200, Dirk-Willem van Gulik wrote:
> > Especially as the pattern seems to be conductive to personal
> > gratification** more than community; and leads to patchcollections
> > which are the work of love of a single person quite easily. And that
> > seems to cause fragmentation on an end to end level. I.e. rather than
> > scratching your own itch - and solving it at a product level - you
> > create a small alternate reality in which you nullify the issue, in
> > which you isolate - and then welcome people on your island - but
> > you've not made the world a slightly easier place. Somehow it feels as
> > if there is some driver lacking, some positive need to have
> > communities collaborate.
>
> I believe you have this backward; distributed version control systems
> are more conducive to community than their centralized counterparts.
>
> With a centralized vcs, a select group of privileged individuals are
> given access, they are the gate keepers.
Eh, no. That's exactly how Linux works, with people having protective attitudes
towards their own trees: git only makes that mode of working easier. Here a
committer's job is to *facilitate* inclusive work, not prevent it.
> Everyone else gets a "working
> copy" and is expected to create a patch (or patches) and then work to
> convince a committer to apply them.
That's not the Apache model, fwiw. Collaboration means you work as equals,
committer status or not.
> A distributed version control system is a measure toward eliminating
> that have/have not distinction; it reduces the barrier to contribution.
No it doesn't. The learning curve alone is a barrier to its adoption.
It just means you have the same access to the history as anyone else,
and can develop on branches with far greater ease. Github is the great
new thing here, not git itself. If github were open source we'd probably
be using it at Apache already in some form.
> Instead of a working copy you get a full working repository.
> Contributors can have long running branches where they work on large
> features while easily keeping in sync with upstream changes. And when
> the contributor repos are public, others can follow their progress and
> provide feedback and collaborate.
>
> If useful changesets that are languishing in random repositories and are
> not making it upstream, that is a social problem, not a technical one.
Yes, but that just begs the point: this thread is about the social implications
of the choice of vc tool, and the aforementioned author of the blog post
seems to think forking in all its forms is a good idea for societies.
Somehow I doubt that's the case.
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: "Forking is a Feature" reactions?
Posted by Eric Evans <ee...@rackspace.com>.
On Wed, 2010-09-15 at 08:04 +0200, Dirk-Willem van Gulik wrote:
> Especially as the pattern seems to be conductive to personal
> gratification** more than community; and leads to patchcollections
> which are the work of love of a single person quite easily. And that
> seems to cause fragmentation on an end to end level. I.e. rather than
> scratching your own itch - and solving it at a product level - you
> create a small alternate reality in which you nullify the issue, in
> which you isolate - and then welcome people on your island - but
> you've not made the world a slightly easier place. Somehow it feels as
> if there is some driver lacking, some positive need to have
> communities collaborate.
I believe you have this backward; distributed version control systems
are more conducive to community than their centralized counterparts.
With a centralized vcs, a select group of privileged individuals are
given access, they are the gate keepers. Everyone else gets a "working
copy" and is expected to create a patch (or patches) and then work to
convince a committer to apply them.
A distributed version control system is a measure toward eliminating
that have/have not distinction; it reduces the barrier to contribution.
Instead of a working copy you get a full working repository.
Contributors can have long running branches where they work on large
features while easily keeping in sync with upstream changes. And when
the contributor repos are public, others can follow their progress and
provide feedback and collaborate.
If useful changesets that are languishing in random repositories and are
not making it upstream, that is a social problem, not a technical one.
--
Eric Evans
eevans@rackspace.com
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: "Forking is a Feature" reactions?
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
On 13 Sep 2010, at 19:29, Ben Hyde wrote:
> On Sep 13, 2010, at 7:37 AM, Sam Ruby wrote:
>> I just can't resist the opportunity to fork this discussion:
>>
>> http://intertwingly.net/blog/2010/09/13/One-True-Way
>
> tee hee
>
> have we pushed the apache way pages to git hub yet?
That would be a complex message :)
While github itself - and its ecosystem/people interaction is really interesting and innovative* - the associated habits around 'git' are not always. Or rather - its conductive ness to having large pseudo branches (really just large patches batched up some what) is not.
Especially as the pattern seems to be conductive to personal gratification** more than community; and leads to patchcollections which are the work of love of a single person quite easily. And that seems to cause fragmentation on an end to end level. I.e. rather than scratching your own itch - and solving it at a product level - you create a small alternate reality in which you nullify the issue, in which you isolate - and then welcome people on your island - but you've not made the world a slightly easier place. Somehow it feels as if there is some driver lacking, some positive need to have communities collaborate.
I am quite worried (and in equal parts intrigued) whether we're creating a new type of entropy with a different type of 'bit rot'.
Dw.
*: though lack some of the (i)CLA cleanness which is troubling me.
**: speaking purely from what drives me personally to put stuff there - along with the avoidance of having to collaborate with people to spare/save energy - making me care more about my code - as opposed to a product for society.
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: "Forking is a Feature" reactions?
Posted by Ben Hyde <bh...@pobox.com>.
On Sep 13, 2010, at 7:37 AM, Sam Ruby wrote:
> I just can't resist the opportunity to fork this discussion:
>
> http://intertwingly.net/blog/2010/09/13/One-True-Way
tee hee
have we pushed the apache way pages to git hub yet?
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: "Forking is a Feature" reactions?
Posted by Sam Ruby <ru...@intertwingly.net>.
On Mon, Sep 13, 2010 at 6:21 AM, Isabel Drost <is...@apache.org> wrote:
> On Sun, 12 Sep 2010 Jeff Hammerbacher <ha...@cloudera.com> wrote:
>> I'd love to hear the reactions of other ASF members to the piece. I'd
>> also love to be directed to previous discussions on the topic, as I
>> know that adopting git for some projects has been discussed
>> previously.
>
> IIRC there should be some discussions on the archive of the infra and
> community mailing lists that were caused back when the read-only git
> mirrors were set-up.
>
> However I agree it would be nice to have one page that summarises the
> results of these discussions - especially the problems that various
> people saw. That way re-checking from time to time whether these
> might be resolvable by additional tooling or a use of git different
> from how it was discussed on the lists becomes easier.
I just can't resist the opportunity to fork this discussion:
http://intertwingly.net/blog/2010/09/13/One-True-Way
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: "Forking is a Feature" reactions?
Posted by Isabel Drost <is...@apache.org>.
On Sun, 12 Sep 2010 Jeff Hammerbacher <ha...@cloudera.com> wrote:
> I'd love to hear the reactions of other ASF members to the piece. I'd
> also love to be directed to previous discussions on the topic, as I
> know that adopting git for some projects has been discussed
> previously.
IIRC there should be some discussions on the archive of the infra and
community mailing lists that were caused back when the read-only git
mirrors were set-up.
However I agree it would be nice to have one page that summarises the
results of these discussions - especially the problems that various
people saw. That way re-checking from time to time whether these
might be resolvable by additional tooling or a use of git different
from how it was discussed on the lists becomes easier.
Isabel
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: "Forking is a Feature" reactions?
Posted by Nick Burch <ni...@apache.org>.
On Sun, 12 Sep 2010, Jeff Hammerbacher wrote:
> I'd love to hear the reactions of other ASF members to the piece. I'd
> also love to be directed to previous discussions on the topic, as I know
> that adopting git for some projects has been discussed previously.
At the moment, many ASF projects publish a read-only git repo at
<http://git.apache.org/>, for those who wish to work locally with git.
However, offial commit is restricted to svn
The issue here isn't technical, it's social. How do people know where to
send patches? How do we do IP clearance on git pushed or pulled patches?
What happens when a committer pulls a patch from someone with an icla, but
that person's patch includes patches from others who don't have one? How
do potential users avoid the confusion that github used to present of
never being able to tell which of the 50 forks is the one they want? How
do we keep discussions coming back to the mailing list, where everyone can
see and participate, rather than having them splinter off into hidden
groups?
(And probably a few other questions that were raised during the last
couple of barcamp and mailing list discussions on the topic, which I have
now forgotten...)
It's now been a year or so since the git mirrors went up. At the time, we
didn't have answers to these problems, which is why they were read only.
However, the world has moved on since then. Perhaps git tooling has
improved to solve some of these? Perhaps now more people use git, some
things have been solved by a general societal change of git users? I'm
certainly looking forward to a productive Git debate at the apache retreat
this weekend, and again at the barcamp at ApacheCon in November :) If you
can suggest good answers to any of these problems (or the ones I've
forgotten...), then I'm sure everyone will be keen to hear!
Nick
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: "Forking is a Feature" reactions?
Posted by Paul Querna <pa...@querna.org>.
On Sun, Sep 12, 2010 at 3:51 PM, Jeff Hammerbacher <ha...@cloudera.com> wrote:
> Hey,
>
> I just read the thoughtful piece by Anil Dash at
> http://dashes.com/anil/2010/09/forking-is-a-feature.html. I don't really
> agree or disagree with his points, but it's an interesting take on the value
> of distributed version control and the evolution of how open source
> communities get work done.
>
> I tried to find the official position of the ASF on this topic, but
> unfortunately, the "How it Works" links are broken on the site (see
> http://issues.apache.org/jira/browse/INFRA-2981).
>
> I did find, in the "glossary", a section on "Revolution":
>>
>> In the Apache environment, some communities may decide to permit (or
>> encourage) revolutions as ways of reconciling differences, particularly code
>> changes which have been blocked on a particular branch by a veto. Originally
>> described by James Duncan Davison in his 'Rules for Revolutionaries,' the
>> concept has been adopted, formally or informally, by at least one Apache
>> project. Essentially, a revolution occurs when a group of committers decides
>> to fork the current main branch in order to work on problematic code or
>> concepts. This permits them to pursue it without disturbing the evolutionary
>> work on the main branch. A revolutionary branch may eventually be merged
>> back into the main branch, die out, split completely and become a new main
>> branch, or may absorb the current main branch into itself (essentially no
>> different than the first option). See the 'Rules for Revolutionaries' and
>> compare evolution.
>
> In the Apache Hadoop project, we've adopted the potential for revolutions,
> which we manage as Subversion branches. Unfortunately, maintaining a
> Subversion branch is expensive, and merging it back into trunk can be quite
> difficult.
>
> For projects which have sanctioned "revolutions", it may be useful to allow
> them to use git or another dvcs as the primary version control system.
>
> Similarly, for projects with several large commercial backers, each
> maintaining their own patch sets or source repositories (e.g. Apache Hadoop,
> with Yahoo, Cloudera, and soon, Facebook working separately), a distributed
> version control system could be useful.
I don't view those large external patch sets as a positive thing for
health of an Apache project, or for the average consumer/user of the
project. I don't view this as a good reason to promote git.
As Sam mentions in his blog post he linked in the thread[1], I also
use git every day for most non-ASF projects. I don't find git itself
innovative for my use cases, I find github innovative. I am far more
interested in figuring out better ways of combining issue tracking,
code review, and pull requests, than any desire to ease the pain of a
large external patch. Large external patchsets are bad. They
shouldn't be the reason we move to another VC.
I think we should look more critically at the flows that github is
promoting, and look at how we could apply those; regardless of weither
it used svn, git, hg or even bazzar.
[1] - http://intertwingly.net/blog/2010/09/13/One-True-Way
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org