On Sun, Mar 18, 2012 at 2:17 AM, Peter Stuge <pe...@stuge.se> wrote: > > Alon Bar-Lev wrote: > > I think you are trying to make opensc something it is not. > > I am not trying to do a single thing beyond pointing out that there > is alot of complaints and wasted time over no *actual* problem.
First I want to write that I have no intention to manage this project, just to provide my own view regarding the process. The fact that I fail to present my argument so you understand is my own failure. I have no words beyond what I already wrote, but I will try again. > > > 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. > 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, and only then continue, while doing about 10 times rebase and fix his 3 months old patch set. 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. Each commit is sent to the mailing list, so peers and guests can review changes and comment. As result of this post review, these people who are the trusted by the community and trust each other may progress much faster, even in the price of committing not-the-best solutions, while cooperating together based on each own free resources to achieve the-best solutions. Until now guests sent patches to mailing list for review, there was always the chance that the core developers missed specific patch or had no interest at that point in time. These patches were lost if the author did not resend it over and over until he got acknowledgment. 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. 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). > > That's true that it may eventually lead to more stable > > implementation, but the cost may be lack of progress, > > thus not able to achieve the stability goal as well. > > Quantity is IMO completely irrelevant without quality. Again, reality showed different behavior... There was a different process which worked and produced no less quality in releases. 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. > > 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. > > However, a proper build server with multiple platforms and > > configurations is something that is vary useful to have in > > order to test branches before merging. > > 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. > > 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. > > 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. As summary, Peter, I think you took software development trend to the extreme, this trend is far from being the only truth out there. 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. 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 think that core developers (and I am not arguing I am one of them) should have free access to repository, allowing them to progress the fastest they can, we (the community) should trust them to fix whatever issue they may cause, post review their changes and suggest alternatives. Becoming core developer should be an option for people who prove their ability, just like Andreas managed this in the past. Regards, Alon Bar-Lev. _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
