Alon Bar-Lev wrote: > I will try again. Thanks! It really helps!
> > > The bureaucracy and lack of flexibility will inhibit contributions > > > and healthy *SMALL* community. > > > > What bureaucracy do you mean? Requiring no build failure and review > > in gerrit? I think those are acceptable requirements. They're also > > not exactly unique for OpenSC. > > Yes. That's exactly what I mean. Sure it is not exactly unique for > OpenSC, just that you compare it to different kind of dynamics, > different stability requirement and different amount of available > resources. Do you think they are unacceptable requirements? I don't. > > What lack of flexibility do you mean? Anyone in the whole world can > > clone the gerrit repo, make changes, and push them back to gerrit > > for review. > > Right, then wait 3 months in order to have his changes reviewed and > discussed, If review takes 3 months then I guess that's the pace of development for the project? Note that in addition to anyone being able to contribute changes it's also possible for anyone to contribute review. > and only then continue, Can always continue. But yes of course if there are significant discussions to be had before any code can be written then that code has to wait until that discussion is done. I don't think this scenario is very likely. And even if it would happen, I think that some code would be a great way to spark discussion. It is however important to remember that the code at that stage serves primarily as inspiration for the discussion. Just because some code was written doesn't mean that it should go into the main repository. > while doing about 10 times rebase and fix his 3 months old patch > set. As I've written several times I'm not sure about the current gerrit configuration. It's also possible to configure gerrit for different workflows than the current one, specifically the requirements that changes must be fast-forward. There are both pros and cons with requiring fast-forward, as I've discussed in other messages. The other options clearly allow more flexibility but that's not neccessarily a good thing. > Look, the model should be entirely different for small projects > without much resources, something that is more similar to what > we had before. > > There are 3, 4 or 5 core developers, they can do whatever they like, > commit, revert, fix - anything. In practise this is the case for all users in the integrators group in gerrit. > Each commit is sent to the mailing list, so peers and guests can > review changes and comment. This is of course also configurable in gerrit. > progress much faster, even in the price of committing not-the-best > solutions, Do you find this a desirable quality for a security-related project? > The guests' process can be replaced by the gerrit solution, which is > superior. Instead of sending patches to mailing list use the gerrit > interface to keep track and review. This is a great improvement, > which is unrelated to core developers process. Yes they are somehow separate processes, but they can still share infrastructure and workflow without issues. > What I basically saying is that in utopia you may be right, however, > the reality requires flexibility, especially when the numbers are low > (core developers, community size, allocated resources). I don't think I've advocated against flexibility, but I will if it means compromising on quality. Note that I'm not contributing much code, only speaking my mind on my preferences. > What the "new" process provides is a stable branch [most chances] at > every given time - this is its advantage and is suitable for software > that should be released in very short cycles, this is not the case of > this project. I don't know that gerrit is unsuitable even if longer cycles tend to be the norm. > > > Until now I did not notice gerrit to be so good solution > > > that all other methods should be dropped for of it. > > > > I'm afraid I don't understand what exactly you mean by this. Gerrit > > helps track patches. I'm not sure that the current configuration is > > completely ideal, but it is also not in any way causing a critical > > problem for further development. > > No, I meant there are other alternatives and solution for software > development. gerrit way (or patch way) is one of them. I don't rule > out the others just because the current trend of developing the Linux > kernel uses one. The point about gerrit is not that it is trendy, the point is that it adds fantastic functionality. > > Of course there is no replacement for testing, but I really can not > > agree if you are arguing that being unable to extend jenkins is a > > critical problem for further development. > > No, I am arguing that it is more important than the whole patch > method for core developers. Hmm? Can you be a bit more specific? Sorry, but I don't understand exactly. > > > I quite miss the previous method in which people could work on this > > > project progressing (and may do mistakes), but invest their time in > > > proactive way. > > > > What is stopping that? Please be specific. > > Just look at the history, see how we cooperated in partial solutions, > reaching gradually to complete solution within the tree during periods > of weeks and different developers for separate issues. This can be done with git and gerrit as well. I would even argue that it is *easier* using these tools than the ones used before. But indeed I am experienced with them, and in the projects where I've helped and followed while they were introduced, there was always a certain amount of friction and a learning curve. But after a little while everyone is so far very happy with the change. > > > I don't think that in current process I [or anyone similar] could have > > > contributed whatever I've done before, so I don't think it is going to > > > a good place. > > > > Why not? Please be specific. > > I tried to explain above. Thanks for taking the time! It really helped understand what you mean! > As summary, Peter, I think you took software development trend to > the extreme, this trend is far from being the only truth out there. Um, I only try to explain how and why life with git and gerrit is really great. They are awesome tools. Not because they are trendy, but because of their functionality. > People tend to be productive in flexible environments. The state of > the OpenSC project is far from benefit from this approach mostly > because of lack of resources. I think it's a good idea to consider the gerrit submit policy configuration. Other projects have decided on cherry-pick, which does bring more flexibility but may not really be desirable for security software. > And even in this extreme world... there are core developers, see > how Linus commits whatever he likes directly into Linux tree > without "proper" review. I don't think the kernel uses gerrit. And of course all projects have direct committers. > I think that core developers (and I am not arguing I am one of them) > should have free access to repository, They do have this when they're in the integrator group in gerrit. //Peter _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
