[0:18:40] "This whole commit access issue" ?
Status: Abandoned
Brought to you by:
mdbesten
Menu
▾
▴
And most of the time what happens is that you make that class too small because it is really hard to know if a person is smart or not. And even if you make it too small, you will have problems. So, this whole commit access issue, which some companies are able to ignore by just giving everybody commit access, is a huge psychological barrier and causes endless hours of politics in most open source projects....
I actually don't get the "whole commit access issue", the psychological barrier thing, and the politics pbs...
I think what he means by psycholigical side is the effect on the person if they have that right or not. If the person is intelligent he will have the commit privilege on the server, if he's not .. he won't...
So a person who doesn't have that right will have a psychological issues... this will disappear with a distributibve system.. '' Everybody has commit access. You can do whatever you want to your project. You just get your own branch. You do great work or you do stupid work. Nobody cares. It’s your copy. It’s your branch. And later on, if it turns out you did a good job, you can tell people''
i think what he means by political problems, the way that the head of the enterprise should organize who will have the right to commit or not (in the case of SVN system)... the organization of circle of trust.. and how to choose the good network and telling the others you don't deserve this commit access ...
in a distributive system this commit access will vanish .. but other political problems appear ...
and i think the question of one of the audience is very clever.. when he asks whether the distributed model simply shifted the political questions of access rather than eliminated them... and i have to agree with his question because the access issue was centralized to the whole system, no it's centralized to each developper .. and and the head of the enterprise will choose in both cases the same trust network or team to pull from them ...
Yeah, I think what he means is that you have to give "commit access" (the right to acess the repository, the central server) to people who you think can contribute to the project. As he says, there is a high asymetry of information because you don't know whether the person you give the rights will effectively make something useful or not.
In order to avoid "noises" (bad development, useless code, etc) you tend to limit commit access and end up giving too small space to people who are then not contribute to the project in a productive manner, or at least the best they could.
Also, as najosf said, giving rights or refusing to give them is likely to affect people's behavior. An individual not given the right to contribute without an intermediary checking what he did might feel angry that you do not consider him/her as smart enough.
The last thing is about politics. Its is true that this system of delegation of acess rights creates problems for thehead of the project who has to explain his/her decisions to the contributors and to manage their ego. However, I think that what he means by political issues also extends to the strategy of the contributors who can be more motivated to "seduce" the head of the project rather than contribute efficiently. That's what I think "politics" means. The contributors are more active in their political game than in the development of the software.
I have yet to watch the video entirely so I didn't listen to the question about this specific part.
But, if i understand what Linus said about "other political problems', then those should be easier to solve and the decisions should be easier to justify. In the case of distributed source management, the political problem switches from commit access to "which version to use". In my opinion, this problem is smaller. As he explained, in a centralized system you have to give commit access given a high asymetry of information and this is likely to make people mad because you give the rights before knowing is people work well. In a distributed one, everybody has commit access and when the time to choose which version to use comes, you should only have to refer to "objective" criteria such as the simplicity of the code or its performance. What I see immediatly is that you get rid of the asymetry of information, what you use to rate people's work is their code on their branch that is shared to all users. I think this is more objective than with a centralized system and it also reduces greatly the "political problems". You don't really have to justify your choices and people can't fool you if you're competent enough with coding. This might also allow cross moderation as the head who's the dictator can be challenged with purely technical arguments.
Ok. Now I've found the question. The advantage of distributed system is that the decision process is decentralized. Instead of having to give rights to each developers and check their work, you let people you trust do it for you. So you have less work to do personally and you delegate these tasks to people you trust. Id say this reduces the decision problems and allows to create this network of trust. But, at the same time, it can make the delegation of power more crucial. As the head, if someone you trust resigns or isn't good enough, it could be a problem. Even if you appoint someone else to do the job, it could take a lot of time for him/her to understand and work efficiently with the developers under him/her. Also, if you gain time by getting rid of the problem of rights allocation, it is possible that adding intermediary slows down the whole development. If each intermediary you trust and their network of trust have to check the code, test it and centralize each developer's work, it could be slower than having to manage everything by yourself.
With a centralized Source Code Mangement system, "commit access" basically means "authorization to modify the source code".
So with a centralized SCM, the question is "Who should be authorized to modify the source code". Linus answers : "only smart people".
In companies the solution that is often chosen is to give commit access to all the developers. All developers are authorized to insert their modifications in the code, and they deal with the related issues collectively.
In open source projects, you obviously cannot do that, because too many people working on the source code simultaneously would always break things up. So you have to go for the "restricted commit access" solution : you only give access to a limited number of people, who will therefore become the core of the project. This people will have to deal with integrating the changes from occasional developers who do not have commit access : they are at the center of the diagram we were shown during the last class.
The "politics" and "psychological" barrier in open source projects are, I think, related to the fact that there is a "core", or an "elite" explicitly characterized by the "commit access" privilege, and there are tensions between this elite and the rest of the community. For instance there can be arguments when a core developer refuses to integrate (precisely, to commit) a modification that is suggested by an occasional developer. As roomhm has just said, another topic for arguments and politics can also precisely be about whom these commit access rights should be given to.
With a distributed SCM, "commit" is something slightly different. It does not modify anything that is not on your own machine, but simply saves your current work and identifies it with a unique version number. Then other people can access it if they want to test your version of the software. This operation is called a "pull", you pull one or several versions from someone, you can test them, and then what you usually do is try to merge the latest of these versions with your own latest version.
Thanks for all your clarifications.
I understand that with a distributed system the choice of the "best" code committed might be made with more objective criterias.
But again, this network of trust he talks about, isn't it another way to create tensions and politics issues among people inside the network and outside of it ?
Cause I guess he choses people he trusts and they might not be so many.
Isn't it an issue ? or is there something I still don't get or did I mix it all up ? :)
> Cause I guess he choses people he trusts and they might not be so many.
YES! And that's the point actually. Of course the head of the project is still somehow a dictator who makes choices how he wants. But, as he has less choices to make (his network of trust being composed of 10-15 people at max) he can make them more "wisely". He might also have more freedom to actually decide who to choose.
That's how I see it at least. In my view, the objective criteria are usefull to choose which version to use not really for the choice of your network of trust.
Also, the choice of the network of trust is only important for the head of the project as everybody has access to the files. When you decide which "branch", which modifications to implement, you either choose yourself thanks to objective criteria or you delegate this task to your network of trust. Think of it as a choice of personal friends. When you decide who will be your friend it's not based on objective criteria, it's more likely because you get along and think that person is smart and interesting which is totally subjective :)
nothing to add maybe we should close the topic except if you have another question kawther?