Hi Alberto, > I think it's mostly because of the usual reasons in opensource projects. > Core developers are overloaded, and in what little time they have they > prefer to code (understandable, but same self-defying issues in OpenWRT).
IMHO this summarizes the current situation quite nicely and I'd say I agree with it completely. Note that we're trying to slowly dig ourselves out of the hole we made ourselves over the years but it requires time and dedication. I for example would love to lean back a bit and start caring more about community matters and communication but before I can do that, we need to find some more people compensate the missing developer time. > IMHO The only way we can get over this situation is if current core > developers start giving others responsibility over some parts of the > LEDE system/infrastructure, This is what we're trying to do with the Wiki atm. On the infrastructure administration side, I am glad that Ted helps me with handling things and for the wiki hosts we handed administration access directly to the wiki moderators to minimize friction. > put down some decent documentation about > current state of affairs in LEDE programs (what they do now and what > they should do) That is sorely lacking atm ... > and guidelines for checking contributions (mostly for > people that must check if the patch/PR is valid). ... and I partly agree here as well. I would be interested in a more contributor oriented insight at this point. For example it took me a while to realize that being on Github suddenly means that people edit C code via the web interface without any means to syntax / compile / run test their changes or to sign off their commits. The problem of such unsuitable contributions can be tackled from different angles, first by improving documentation and enable people to do better changes in less time and second by lowering the entry barriers somewhat (while increasing developer workload), for example by stating that a "Signed-off-by" in the PR description alone is enough and requiring the developer doing the merge to copy the signoff into the commit. One should keep in mind though that lowering the contribution quality requirements increases the individual workload even more, at least in the short term, until the increased contribution-friendliness eventually leads to more man power in the long run. > I'm taking the linux kernel as a model where things are split up in > subsystems and each subsystem has one or more mantainers. Yes it is not > a headless commune, but it isn't a nazi-like authoritarian regime either > (even if Torvalds likes to shout at people). The Linux kernel is a good goal for a distributed and delegated development model but one must keep the very high entry barrier in mind - it is hard to write kernel code, most people working on it already are professionals, there are no real bug trackers or easy web based pull request choices available and the main contribution channel is very active mailing lists, forcing potential contributors to send proper changes from the get-go. All that is making it easier (or in the case of the Kernel possible at all) for the developers to cope with the steady stream of incoming patches. As a somewhat related anecdote, people already neglected LEDE because it requires real names and sign-offs in its Github pull requests - deeming it a too high burden to invest time. Such contributors would never be able to contribute anything to the Linux kernel. > That way you can have a person that has commit access but can only > commit stuff of his subsystem, and core devs only need to look at stuff > filtered by others (or not if they don't have time). Personally I'd like to move away from the fixed role of core developers but I agree that some kind of multi-tiered system is likely unavoidable. > This is the only way you can have more people in that checks incoming > code and core devs can be less overloaded and can actually take > decisions for the project where needed, or put down developer > documentation (what we have is very outdated and partial). I agree. > I understand that people have a life and all, but a project like this > cannot run headless forever because the 2-3 people that have access are > busy. Solution -> more people with access, each to specific areas. Agreed, we just need volunteers with a somewhat proven track record at this stage. Personally I see no problem with letting more people push directly. > Really, there are already quite a few large-ish and not-so-large PRs > rotting on Github, you can't afford to let them sit there for too long > or the people will lose interest in sending them, and think you are the > same as OpenWRT. Which brings me to another yet unsolved point. There are large PRs (think the Mikrotik changes) which are unsuitable for inclusion as-is, yet too worthwhile to be left rotting. Maturing such change series takes time and needs to be happen in a dedicated staging tree, this is something we simply lack the man power to do atm. That would be another useful area to have some help in - having one or more persons who are able to incorporate requested feedback into otherwise orphaned PRs to shape them up for inclusion. > The same about that guy from a wifi community asking the state of > affairs. You can't let that go unanswered. Bad PR will add up and again > people will think you are the same as OpenWRT. I am not sure what you refer to here exactly. > Sadly I can only take seriously community-oriented roles atm as I'm not > a true programmer (I'm a junior Java developer tho), but with decent > documentation and guidelines for checking patches I can help out with > the PRs about new device support. The help you provide, the effort you already put into cleaning up packages and your participation in the discussions are much appreciated already as this is exactly the kind of involvement the project needs to survive in the long run. ~ Jo _______________________________________________ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev