Just a FYI, after talking with Ryan further, I did mis-interpret his statement as sarcastic when he didn't mean it that way. So with that, I'm sorry for taking up your time reading this. This will hopefully be the last e-mail on this thread.
Regards Teravus On Tue, Oct 20, 2009 at 7:04 AM, Teravus Ovares <tera...@gmail.com> wrote: > My message was in response to your sarcastic comment, > "Thanks for all the information -- it makes one feel in the loop an > having a voice." > > My point was that you're calling us on keeping people out of the loop > when you don't also keep people in the loop. I've been a part of the > dev mailing list for some time now. The dev list hasn't been asked to > vote on the people who have commit on the realXtend server. > > A fork in git is an action that allows you to keep your own copy that > you distribute. Where you get your copy from is really irrelevant in > a distributed source control management system. The point is.. you > manage what goes in to your copy and what doesn't. This establishes > that you have control over that 'fork'. Once again, you can't > claim that you don't have control over Taiga. You can choose to > merge or not. You can even knit pick specific commits. > > "Also, since we have no reX-specific modification, it's more like an > svn:external" > Does that mean that you're no longer using Ogre mesh in the realXtend Server? > >>No, we use a web of trust system, ie. each current contributor gets to >> decide on their own who gets commit access to SVN -- if we used git >> even that distinction would become meaningless. > > We accept patches the same way. The patches are reviewed by a core > member, and committed as is appropriate. > For example: here's a recent patch by Snowcrash that was committed by dahlia: > http://opensimulator.org/viewgit/?a=commit&p=opensim&h=182693628ca1b81c90f3f0296418437eda406bb5 > > >> I think this is a case of not understanding what I'm talking about. >> It's also not the first time you've done that to attack me publicly >> even though you have my IM. > > I'm not attacking you publicly. I'm simply saying that I don't think > it's fair for you to call OpenSimulator core on 'keeping people out of > the loop' when you're not 100% 'community inclusive'. Come back and > make that claim when you are. > > >> You seem to have profoundly misunderstood my words yet again. I'm not >> sure where you get "negative" from... > It's possible. However, when I receive advice like > >>In that case, unless core is comprised of lawyers, or confidential >>legal advice is being directly quoted, it might be healthier to >>discuss in public -- at least so it's readable by those who have a >>stake in the community. > >>Every community/OSS book that mentions private lists for limited use, >>in the next breath cautions against over-use. > > in an e-mail thread where you exclaim > > " > Fourthly, the email is not just about one mailing list, it's about the > entire concept of a monolithic core in open source, especially given > we're on a DVCS like git. If core is not interested in examining > itself as it grows, then so be it. > " > > Is it any wonder that I interpret the next statement, "Thanks for all > the information -- it makes one feel in the loop an > having a voice.", sarcastically? > > Regards > > Teravus > > > On Tue, Oct 20, 2009 at 6:29 AM, Ryan McDougall <sempu...@gmail.com> wrote: >> On Tue, Oct 20, 2009 at 12:36 PM, Teravus Ovares <tera...@gmail.com> wrote: >>> You seem to have some negative feelings about us. You have your own >> >> You seem to have profoundly misunderstood my words yet again. I'm not >> sure where you get "negative" from... >> >>> fork though that you manage.. called Taiga. Are you saying that >> >> Taiga is comprised of OpenSim (although we now track JHurliman's >> branch of ScienceSim), cable beach, and ModreX. >> >> Given JHurliman's branch of opensim is a temporary git branch, calling >> it a fork is quite a stretch. In fact it's quite my point that "fork" >> is meaningless with DVCS. >> >> Also, since we have no reX-specific modification, it's more like an >> svn:external. >> >>> you involve the community for all decisions about Taiga including who >>> gets commit rights? I seriously doubt it. >> >> No, we use a web of trust system, ie. each current contributor gets to >> decide on their own who gets commit access to SVN -- if we used git >> even that distinction would become meaningless. >> >> Ie, if you want commit access -- let me know, I'll set you up asap. >> >>> This is a case of the pot calling the kettle black. >> >> I think this is a case of not understanding what I'm talking about. >> It's also not the first time you've done that to attack me publicly >> even though you have my IM. >> >>> Regards >>> >>> Teravus >> >> Cheers, >> >>> >>> On Tue, Oct 20, 2009 at 5:30 AM, Ryan McDougall <sempu...@gmail.com> wrote: >>>> On Tue, Oct 20, 2009 at 12:21 PM, Dr Scofield <drscofi...@xyzzyxyzzy.net> >>>> wrote: >>>>> >>>>> Ryan McDougall wrote: >>>>>> On Tue, Oct 20, 2009 at 8:27 AM, Frisby, Adam <a...@deepthink.com.au> >>>>>> wrote: >>>>>>> I disagree. >>>>>>> >>>>>>> * Commit Rights - those discussions cannot occur in public (although >>>>>>> the discussion archives are open to committers after being invited), >>>>>>> the reason for this is no-one can be frank & honest without hurting >>>>>>> people's feelings. >>>>>> >>>>>> Firstly, I did waive discussion for commit access. I also waive money >>>>>> and legal matters. >>>>>> >>>>>> Secondly, I disagree with the logic of the link, as it's premised >>>>>> entirely on being honest might hurt someone's feelings. Honesty is not >>>>>> a function of secrecy. >>>>> >>>>> i think honesty can be a facilitated by a discussion remaining >>>>> confidential. >>>>> >>>>>> And the case of "there was a long drawn out >>>>>> discussion about me in which I was not able to represent my myself" >>>>>> causing hurt feelings is not considered. >>>>> >>>>> i can see that point, but i can also see the points made by adam >>>>> respectively >>>>> the points made in the F/OSS guidebook --- in balance (my personal one) >>>>> i'd >>>>> rather have core committers discuss whether i should have voting rights >>>>> in private. >>>>> >>>>>> >>>>>> Thirdly, I don't think snowcrash thing is about giving him commit >>>>>> access. I don't think things are as neatly compartmentalized as is >>>>>> told (though I could be wrong, it's hard to guess from a secret >>>>>> mailing list). >>>>> >>>>> no, you are right on that one. it's a discussion about our understanding >>>>> of >>>>> licensing issues and whether there is indeed an issue here or not. >>>> >>>> In that case, unless core is comprised of lawyers, or confidential >>>> legal advice is being directly quoted, it might be healthier to >>>> discuss in public -- at least so it's readable by those who have a >>>> stake in the community. >>>> >>>> Every community/OSS book that mentions private lists for limited use, >>>> in the next breath cautions against over-use. >>>> >>>>> re compartmentalized: they are, at least we try very hard to. >>>>> >>>>> DrS >>>>> -- >>>>> dr dirk husemann ---- virtual worlds research ---- ibm zurich research lab >>>>> SL: dr scofield ---- drscofi...@xyzzyxyzzy.net ---- http://xyzzyxyzzy.net/ >>>>> RL: h...@zurich.ibm.com - +41 44 724 8573 - >>>>> http://www.zurich.ibm.com/~hud/ >>>> >>>> Thanks for all the information -- it makes one feel in the loop an >>>> having a voice. >>>> >>>> Cheers, >>>> _______________________________________________ >>>> Opensim-dev mailing list >>>> Opensim-dev@lists.berlios.de >>>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>>> >>> _______________________________________________ >>> Opensim-dev mailing list >>> Opensim-dev@lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev@lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > _______________________________________________ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev