Hi all, > As we can see there is a general reluctance in taking voice in this > discussion. Probably because not many people want to volunteer to > "take the responsibility". A single leader is a good thing, because > he manages and takes care. If there is a general call for one leader, I could be that one, but it needs to clarify the implications (or the absence of implications). My reluctance is not due to the responsability in itslef, or the possible extra work it would generate, because as explained below it would not really generate more work on my side.
I've been surveying commits in the last years, mostly because I wanted to be sure that some components of Yade would keep being functional (I didn't completely succeed: Jerier's law disappeared for instance, but at least when somebody tried to simulate a triaxial test with capillary forces a few weeks ago, it worked as expected. Inversely, Janek saved time by not reviewing the commits, then his lattice beam model disappeared). As a matter of facts, surveying commits would not really be an additional task in comparison with the previous situation. I even expect that it will be easier than before (for a period at least), since Vaclav was by far the first contributor. Thanks to the commit survey, I have a _relatively_ wide vision of Yade (still, I totally ignore deb packaging, to name one thing) . There is another aspect to consider though (here comes the reluctance ;)). Vaclav has never officialy declared he wanted to lead developpement. As stated in his PhD thesis, he became a "de facto" lead developper, just because he took many initiatives and put a lot of energy in improving the code, doc, hosting, etc. If I were taking the "leadership" responsability at that point, it would be a different kind of leadership, not entirely based on achievements. Well... ok, I'm second commiter after Vaclav in recent years, which makes me sort of "de facto" new lead developper (although Anton is close behind), but I still have the impression that taking leadership now would be more a formal decision than a "de facto" thing. In last days, I've been wondering if this kind of leadership is really needed. Personaly, I'm inclined to answer "no". As Janek, I'm confident that nothing bad can happen. Version control, reg/check tests, buildbot, human review of commits, and a few devs frequently updating and running simulations makes it extremely difficult to silently break something; there is no absolute need to name a leader to avoid that. The messages on the list and some internal discussions in 3SR suggest, however, that some devs/users feel uneasy in this situation. If it can help to get them reassured, and if everybody agree, I can take the responsibility of keeping Yade in one piece. It means I keep reviewing commits and pointing out problems (provided nobody points them out faster than me...), in short I make sure that nothing stupid happens. It doesn't mean that I will work more on the code, that I will have visionary ideas each other day, or that I will have expertise on all aspects. Would it make people feel better? >> I suggest: >> * create a new team, something like yade-security, yade-approvers etc. >> * create a branch, owned by this team. >> * all commits to this new branch should be done by somebody from this team. > If you like this development mode, it makes you comfortable, and you > believe that this will make us more productive, then go for it. > We just need to complete the team. I would not anticipate problems before they occure at least once, so we don't generate extra maintainance work. The last five years experience showed that most developments are kept in house because everybody is so afraid to break something. If newcommers join the dev team and commit, I'll pay extra attention to their commits (in most cases, they will commit fresh files, inherently harmless). It should be enough for now, no? Or maybe, if possible in launchpad, we change commit rights so that they are not given to all members of yade-dev by default? Then one would have to first show up in the list and ask commit rights the first time, with a short explanation of what he/she plans to commit? >> Yade buildbot needs to control and compile each revision, making >> corresponding tests after compiling (like it is now). We should also >> care about adding some more additional tests to --checks section. > the automation already present in whole framework is already > very impressive. Adding more --checks will be very useful, no doubt > about that. Independently of Vaclav's retirement and future leadership, the buildbot is maintained by Remi (thanks a lot). I'm glad that lab. 3SR is providing this kind of support to Yade project, and I don't see it changing in the near future. We need more check-tests, indeed. > I think that one of most important things is keeping scripts up to > date, because that is what people are trying first when they install > yade. This is not fully automated, yet, to my knowledge. After changes in e.g. class-names, scripts will work (but they will give warnings). I think many scripts crash currently due to more fundamental changes which were more difficult to fix automatically. Cheers. Bruno
_______________________________________________ Mailing list: https://launchpad.net/~yade-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
