Re: [VOTE] Open this list
"Andrew C. Oliver" <[EMAIL PROTECTED]> writes: [...] > Please state your view Excerpts from Stephano Mazzocchi's announcement: -- [...] This mail list will be closed to committers only, the citizens of the Apache Software Foundation, and will serve as the place to talk about the future of the foundation. [...] If you wished there was more synergy between the various ASF communities, show us how you'd make it happening. On community@apache.org is where discussions about new projects creations (like Apache Commons, Apache Incubator, Apache Graveyard) will take place. community@apache.org will be where the 'architecture', the 'development' of the foundation itself is done. [...] So, we give you the opportunity to participate in the making of the future of the foundation, but no complaints will be accepted if what comes up doesn't fit your needs or doesn't make you happy and you didn't participate in its process. -- I don't see how any of the above is better accomplished by opening up this list. > and vote your conscience. I would have preferred to see discussion of a PROPOSAL to subvert Stephano's announcement, but maybe I missed that discussion. > View 1: Open the list completely, anyone can subscribe, post and read > the archive -1 > View 2: Keep the list open only to committers, members and invitees > (highly contributive developers and users) so far as posting goes, > however allow anyone to read or view the archive (and include an archive > such as MARC, etc. -0 >View 3: Close the list to all except members and committers. +1 -- Joe Schaefer
idiot.html Re: [VOTE] Open this list
Steven Noels <[EMAIL PROTECTED]> writes: [...] > http://jakarta.apache.org/site/idiot.html What is the point of that url? Do other ASF projects (php?) have similar links on their support site? -- Joe Schaefer
Re: idiot.html
Sam Ruby <[EMAIL PROTECTED]> writes: > Joe Schaefer wrote: > > > >>http://jakarta.apache.org/site/idiot.html > > > > What is the point of that url? Do other ASF projects (php?) > > have similar links on their support site? > > No, I think that's unique. > > It is a long story, and has everything to do with one individual. If it doesn't reflect the attitude of the jakarta community, but instead represents the views of one individual, then doesn't the page belong in his subdirectory? I dunno, something like http://jakarta.apache.org/site/jon/idiot.html might be more appropriate. -- Joe Schaefer
Re: idiot.html
"Martin van den Bemt" <[EMAIL PROTECTED]> writes: > Please see http://jakarta.apache.org/site/love.html as an > alternative... For the sake of argument, you may assume I have looked at every document in the http://jakarta.apache.org/site/ directory. If you don't see what I'm driving at yet, I encourage you to post the url of a similar document anywhere else in the ASF (outside of the jakarta family, of course). -- Joe Schaefer
Re: idiot.html
Sam Ruby <[EMAIL PROTECTED]> writes:
> It has been pointed out that Jakarta committers have had very little
> exposure to ASF members. Don't judge Jakarta committers by the
> actions of the few ASF members that have cared enough to participate.
I'm not judging the jakarta committers, certainly not negatively.
I'm just trying to get some feeling for what the problems are,
how they are resolved in different developer communities.
[...]
> Here's an exercise for you: find a similar document created by a
> non-ASF member.
That's trivial- google("Smoothwall"). You can get the gist of
their contempt for their "free" userbase just by reading
http://www.smoothwall.co.uk/support/
--
Joe Schaefer
Re: idiot.html
"Andrew C. Oliver" <[EMAIL PROTECTED]> writes: [...] > >should the apache web sites contain 'professional' (as in 'professionalism') > >content? if so, does this page apply? > > > > > As long as 'professional' != stodgy then okay. But I'll let *you* > remove it while I stand behind Sam and use him as a blast shield. (who > mentioned he'd be standing right behind you fa behind you) With all due respect, you might be safer standing behind Jon than Sam. What's the point of local governance if the governing bodies are incapable of dealing with trivial issues like this one? -- Joe Schaefer
Re: idiot.html
robert burrell donkin <[EMAIL PROTECTED]> writes: > one of the continual battles we've had at jakarta is policing the > mailing list and general in particular. > > people wanting to join a mailing list from the jakarta list have to go > through two pages to get the actual lists in order to try to reduce > the need for people to police the list guidelines. but this doesn't > seem to be enough. we still get people posting who haven't taken the > time or effort to read what's been created to help them. > > jon started taking a lot of the responsibility for policing very soon > after the change from [EMAIL PROTECTED] to [EMAIL PROTECTED] he started off > with elan and humour but over the years his responses got shorter and > more curt as it became a chore. hence the jon.html which had to be > used when people took it too personally. > > one problem which has become apparent over the last year or so is that > jakarta lists are very widely mirrored - including onto news. this > means that people post to our lists never having read the list > guidelines or (as has happened in a couple of cases) not even > realizing that they are on a mailing list. Thanks alot for taking the time to dispassionately explain the situation *such as it is*. It's exactly the kind of answer I was hoping for. Unfortunately I don't know what sort of magic is required to make everybody happy, but I do know there are other online developer communities that have experienced similar growing pains. It might not hurt to survey some prior art; IME perl's p5p developer list is exceptionally well-managed. I don't have first-hand experience with the php developer community, but from my distant vantage point, they seem to be managing their growth pretty well (at least angst-free). -- Joe Schaefer
Re: [VOTE] Openness
Marc Slemko <[EMAIL PROTECTED]> writes: > VOTE 1: would you like to make it possible for non-committers to > read this mail list thru a web archive? > >[ ] +1 yes, let's make it readable >[X] 0 don't know/don't care >[ ] -1 no, let's keep it private > > VOTE 2: would you like to make it possible for non-committers to > fully subscribe to this mail list? > >[ ] +1 yes, let's open it to everyone >[ ] 0 don't know/don't care >[X] -1 no, let's keep it for committers only > > and invitees (contributors). > > While every list is its own community, this "community" is supposed to > be a subset of a bigger community, and I think having it restricted to > people involved in the community helps accomplish that. If > "committers" is too narrow a set, then it can be opened up to > something wider but still less than "anyone". Restricting it after > the fact seems like an ugly game. > > The point is you can't join the community by joining "community", you > have to be part of the community to join "community". My sentiments exactly. +1 -- Joe Schaefer
Re: [important proposal] Cocoon as official Apache project
Stefano Mazzocchi <[EMAIL PROTECTED]> writes: [ I want to preface my comments by first thanking you for [EMAIL PROTECTED] Secondly, at the moment I'm inclined to affirm your proposal, but I need to develop some guiding criterion on which to base a vote. I don't want to be in a position where I feel obligated vote "+1" on every similar request, especially when I have no feeling for how many of them are coming :-) ] [...] > Unfortunately, the ASF members thought that the same model could well > apply to projects which did not release software directly (unlike HTTPD > did) and decided to use the same model for jakarta and xml (which don't > release software directly, but add another level of indirection with > subprojects). Can you describe the current release process for cocoon, emphasizing the problems with the current system? Is there a public document that chronicles the issues? [...] > In order to avoid stupid PMC elections, I'll be in favor of having the > PMC composed by *all* committers that ask to be part of it. This to > imply that committers and legal protector share the same duties and > priviledges. How many cocoon committers are there right now? [...] > 3) what does it mean for Cocoon? > > Being a project allows us to host several different incubation-stage > efforts underneath. Cocoblog, wyona, forrest, cocoon-related IDE > plugins could be possible additions. Of course, with the idea of > promoting them as top-level projects when they are successful from a > community perspective. How will the cocoon PMC be better positioned to address the needs of such "subprojects" than the current jakarta/xml PMC? How do you foresee cocoon's PMC addressing the current troubles with subproject releases? [...] > 5) isn't this unfair against the other sub-projects that remain > contained, therefore with less visibility? > > I don't know. Here I'm just stating the intention to move Cocoon to > top-level and I know the ASF board is very open to projects willing to > move out of their containers. > > But the ASF will *NOT* force projects to take this action. If other > communities feel they should deserve top-level projects, they should > make a proposal like this and ask the board instead of complaining > with us that we do it. Among jakarta/xml projects, how widespread is the desire to abandon the container PMC? Have there been other reorganization attempts in the past? -- Joe Schaefer
Re: [important proposal] Cocoon as official Apache project
[Not Cc'd to Apache Cocoon ] Stefano Mazzocchi <[EMAIL PROTECTED]> writes: [...] > Also, note that community@ is *NOT* asked to vote but only Cocoon > committes. I copied community@ to let people know the process is > underway and I wanted to do it in a very open way. Whew- That's a relief! I didn't catch the CC: to cocoon-dev in your original post. [...] > > > > How many cocoon committers are there right now? > > > As you can see from http://xml.apache.org/cocoon/who.html there are: > > 19 active committers >5 inactive committers > 14 emeritus committers > > see the page for a definition of their status and their names. Thanks for the link. Prior to posting, I did try looking for this info myself on the xml.apache.org site. There seems to be a link loop though: http://xml.apache.org/whoweare.html -> /roles.html -> /whoweare.html ... I got frustrated after a few cycles, so I figured it's just easier to ask :-) [...] > Hope this helps. It did. Thanks again. -- Joe Schaefer
Re: Rules for Revolutionaries
Stefano Mazzocchi <[EMAIL PROTECTED]> writes: [...] > I believe it was a mistake to allow two different > codebases to share the same name. I'm not convinced that "having two codebases" is necessarily a mistake. So far the discussion here seems to have centered around the concerns of the existing tomcat developers. I'd like to know what the tomcat users (ie. the future tomcat developers) think of the 3.x/4.x division. -- Joe Schaefer
Re: Rules for Revolutionaries
Rodent of Unusual Size <[EMAIL PROTECTED]> writes: > Joe Schaefer wrote: > > > > Stefano Mazzocchi <[EMAIL PROTECTED]> writes: > > > > > I believe it was a mistake to allow two different > > > codebases to share the same name. > > > > I'm not convinced that "having two codebases" is > > necessarily a mistake. > > it's not the multiple codebases that's the issue; it's > that they both had the same name and both continued > active development. > > as a counterexample, both httpd 1.3 and 2.0 were in > concurrent active development for a long time. 1.3 > development slowed down, and when 2.0 was finally > released, 1.3 went into a sort of maintenance mode -- > meaning that bugfixes and minor backported features > can show up in it, but nothing that doesn't also > appear in 2.0 at the same time. AIUI, Sun's code contribution (that resulted in the tomcat 3.x series) interrupted prior tomcat development at the asf. That initital work was eventually resumed and became Catalina -> tomcat 4. httpd started with the NCSA code and worked from there. I don't think the situations are similar enough to warrant a straightforward comparison. In theory, perl development has multiple concurrent release branches- the 5.5, 5.6, and 5.8 lines are (somewhat) independently maintained (much of the community friction around tomcat's 3.3/4.0 reminds me of perl 5.5/5.6 circa April 2000). Although the current release is 5.8.0, the next scheduled release was supposed to be 5.6.2. It's not likely to happen because there isn't much mindshare left for maintaining/improving the 5.6.x line. Most perl developers are busy working on 5.8, 5.9 or parrot. -- Joe Schaefer
Re: suggestion for news...
"Andrew C. Oliver" <[EMAIL PROTECTED]> writes: > Not meaning to embarrass anyone, but I suggest not writing "news" on > any "news" pages like this: > > http://jakarta.apache.org/site/news.html#1106.1 > > The Commons CLI team is proud to announce Commons CLI 1.0, the first > official release of this Commons component. Binary and source > distributions are available here > <http://jakarta.apache.org/builds/jakarta-commons/release/commons-cli/v1.0/>. > More information about Commons CLI can be found on the project home page > <http://jakarta.apache.org/commons/cli/>. > > The reason being is that its mirrored and carried throughout. Reading > thiswhat is the Commons CLI? Why do I care it has a new > release...what is in the new release (okay its 1.0 so maybe thats > okay).. CLI makes me think of Common Language Interface. Sure there > are links but it might be just what someone who gets it in syndication > needs, but they won't know based on this blurb and they'll rpobably miss it. > > Just a suggestion talk amongst yourselves... That's not a suggestion, it's a subjunctive rant. How should the announcement read? Also, what is the relevance of this issue to [EMAIL PROTECTED] -- Joe Schaefer
Re: [proposal] creation of communitity.apache.org
"Andrew C. Oliver" <[EMAIL PROTECTED]> writes:
> > The ASF I wish to be a part of is one and/or create is one that
> > tolerates differences in points of view or approach to solving
> > problems.
>
> +1 - These are the words of wisdom and they are delicious.
+1 as well. IMO it's a well-informed position:
google("reactance" "cognitive dissonance" "social comparison")
Food for thought.
--
Joe Schaefer
Re: [proposal] creation of communitity.apache.org
Justin Erenkrantz <[EMAIL PROTECTED]> writes: > --On Monday, December 2, 2002 8:39 AM +0100 Nicola Ken Barozzi > <[EMAIL PROTECTED]> wrote: > > > I don't think we are talking about complete personal websites with > > blogs and such, with rants and honeymoon pictures, but about some > > pages that explain what the person does, who he is, and not much > > more. > > Of course we are. We're saying that anyone can post whatever they > want on their apache.org site. That's what I'm against. I don't > want people posting their honeymoon pictures or their Beanie Babies > collection. But, as soon as we say, 'you can post whatever you > want,' that's what is going to happen. Saying otherwise is foolish. Color me foolish then. I just can't wait to have my very own dot on Stephano's cool SVG image. > Unfortunately, Roy's site is sort of an example of what I don't want > to see. However, what I believe Sam hasn't realized is that Roy > *just* moved his site there from the UCI servers while he looks for a > new home for his web site. (Roy will correct me if I'm wrong.) I > trust Roy not to post anything inappropriate, so I'm not going to > complain because I believe it's temporary. Yet, not every committer > has earned my trust in the way Roy has. If your description is accurate, I see Roy's behavior here as completely consistent with Jon's placement of an idiot.html url within the Jakarta community documents. Is this the Apache Way? -- Joe Schaefer
Re: "as well as the critical notion of imagined community"... :-)
Ben Hyde <[EMAIL PROTECTED]> writes: [...] > That paper references a lot of obviously hard won models of what > community is, so now I'm going to have to go read a mess of stuff. Definitely interesting reading. > I find it's amazingly rare to find anything about community that isn't > moronic, simplistic, or romantic. Or worse argues that community is > just another victim of modern life. I think quite the contrary that > the net is a typhoon of community building. There was a great PBS special on Benjamin Franklin a few weeks ago. While quoting Franklin may be "hitting below the belt" to an American, his brilliant speech to rescue the signing of the US Constitution is certainly worth a read. Here's a url describing the particulars (the actual speech is linked within the main text): http://www.pbs.org/benfranklin/l3_citizen_founding.html -- Joe Schaefer
Re: email notification done...sorta
"Noel J. Bergman" <[EMAIL PROTECTED]> writes: [...] > I was going to reply that perhaps the choice of usemodwiki was a good > one as a turnkey thing, but perhaps not the best choice for the long > term due to the lack of competent Perl programmers willing to > contribute. At the moment, Danny Angus and Rick Bowen are the two > who've stepped forward, and both of them have other primary > involvements, not to mention this being the first week that many > people are back from spending time with family. I was/am also planning to help, and I did look over the usemodwiki source to get acquainted with it. However, I don't have any experience with wikis, nor with RSS, so I also need to bring myself up to speed on the technology- according to *my own* (free) timetable. Part of that learning process is simply watching how experienced people operate, and then trying to mimic their behavior. Or not, as the case may be. > On the other hand, we've a lot more competent server-side Java > contributors. Right. To my knowledge, there are only a dozen or so active committers that work on perl-related ASF projects. -- Joe Schaefer
Re: Open community (was ... secret discussions ...)
Joshua Slive <[EMAIL PROTECTED]> writes: > On Tue, 28 Jan 2003, Sander Striker wrote: > > community@ is the only ASF wide list that is opt-in and not bound to > > a certain topic (like infrastructure@ for example). committers@ always > > reaches _all_ committers if they want to participate or not. So that > > list is not an option. > > The fact that it is the only ASF-wide list for discussion seems to be an > argument for opening it, not closing it. We did NOT vote to close the list. We voted to limit access to committers AND INVITED participants. If Andrew does not wish to INVITE Tim's participation, it is _Andrew_ who is blocking Tim's access here. -- Joe Schaefer
Re: You can at.....
Dirk-Willem van Gulik <[EMAIL PROTECTED]> writes: > So I'll do the deed - any objections to inviting Tim in here ? Feel free > to drop Tim of the Cc to preserve dignity/privacy. I wouldn't mind if you also forget to unsubscribe him after this discussion ends. -- Joe Schaefer
Re: You can at.....
Dirk-Willem van Gulik <[EMAIL PROTECTED]> writes: > On 28 Jan 2003, Joe Schaefer wrote: > > > Dirk-Willem van Gulik <[EMAIL PROTECTED]> writes: > > > > > So I'll do the deed - any objections to inviting Tim in here ? Feel free > > > to drop Tim of the Cc to preserve dignity/privacy. > > > > I wouldn't mind if you also forget to unsubscribe him after this > > discussion ends. > > Nope; I do not think that that was the pattern agreed to for this list > (though this list can change the rules any time they can get consensus > over it) - once invited in, is invited in as part of the [EMAIL PROTECTED] Even better! -- Joe Schaefer
Re: You can at.....
Steven Noels <[EMAIL PROTECTED]> writes: > Dirk-Willem van Gulik wrote: > > > So I'll do the deed - any objections to inviting Tim in here ? > > As the factual proposer: sure! Noone objects to Tim's invitation. I personally would like to ensure that since he's here now, he can also expect to stay here as long as he likes. I'm glad to relearn that our prior vote already established that. -- Joe Schaefer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[NOTICE] compromised jira passwords
Hello Apache community@ [1], As you are probably aware we have been working to restore services that have been compromised by a very targetted attack against Apache's jira installation. The good news is that jira is back online, with bugzilla and confluence soon to follow [2]. The bad news is that the hacker was able to rejigger jira's code to sniff any cookies and passwords sent to the server between April 6 and April 9. If you used jira at all this week, including via IDE's that interface via SOAP, it is IMPERATIVE that you take time to immediately reset your jira password, and possibly your ldap password if those match up. If you have admin privs in jira your password was reset by us, so you'll need to use the password reset form in jira to regain access. To have a reset password mailed to your contact information in jira, visit https://issues.apache.org/jira/secure/ForgotPassword!default.jspa When you do login to jira be sure to double-check your contact info. To change your ldap password login to people.apache.org and run /usr/sbin/passwd, or else visit https://svn.apache.org/change-password . Thanks for your patience and diligence in this matter. A blog post will be forthcoming which will provide details of the attack and what we have done to mitigate future hack attempts. [1] feel free to forward this note to any other apache mailing list, public or private. [2] at this time we do not believe the hacker compromised the confluence and bugzilla installs, but we are awaiting confirmation from our admins before bringing those back online. - To unsubscribe, e-mail: community-unsubscr...@apache.org For additional commands, e-mail: community-h...@apache.org
Re: "Forking is a Feature" reactions?
- Original Message > From: Eric Evans > 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-unsubscr...@apache.org For additional commands, e-mail: community-h...@apache.org
Re: "Forking is a Feature" reactions?
- Original Message > From: Torsten Curdt > 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-unsubscr...@apache.org For additional commands, e-mail: community-h...@apache.org
Re: "Forking is a Feature" reactions?
- Original Message > From: Eric Evans > 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-unsubscr...@apache.org For additional commands, e-mail: community-h...@apache.org
Re: "Forking is a Feature" reactions?
- Original Message > From: Santiago Gala > 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 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-unsubscr...@apache.org For additional commands, e-mail: community-h...@apache.org
Re: "Forking is a Feature" reactions?
- Original Message > From: Joe Schaefer > 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 > > 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 >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-unsubscr...@apache.org For additional commands, e-mail: community-h...@apache.org
Re: "Forking is a Feature" reactions?
- Original Message > From: Eric Evans > 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-unsubscr...@apache.org For additional commands, e-mail: community-h...@apache.org
Re: "Forking is a Feature" reactions?
- Original Message > From: Eric Evans > 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-unsubscr...@apache.org For additional commands, e-mail: community-h...@apache.org
Re: "Forking is a Feature" reactions?
- Original Message > From: Torsten Curdt > 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-unsubscr...@apache.org For additional commands, e-mail: community-h...@apache.org
Re: "Forking is a Feature" reactions?
- Original Message > From: Ross Gardler > 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 > >>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-unsubscr...@apache.org For additional commands, e-mail: community-h...@apache.org
