[Libwebsockets] libwebsockets project direction and organisation (was: Lws admin)
haberlerm at gmail.com
Sun Oct 11 12:53:19 CEST 2015
good to hear everything's fine - somebody going under in work for a extended period of time is normal and nothing to excuse for
however, if this project is to be a relied-upon component for others in the future I think some organisational changes are warranted to aid development downstream, as well as reassuring the user base and aiding adoption - I am very wary of single points of failure in projects which we use in machinekit.io.
The key requirements to assure a robust future for this project IMO are:
- decouple the project trajectory from a single person's ability to contribute and maintain infrastructure.
- adopt and spell out a proven policy and process to support that, while giving clear rules to contributors and admins
- overhaul some parts of the project's infrastructure: mailing list, tracker, documentation + doc website
None of this is magic and I think the best route forward is copying a successful project's approach to the issue. Towards that end I suggest to clone the approach of the zeroMQ project. This has been very effective for zeroMQ as well as our project.
My recommendations from a organisational perspective are:
- adopt the 'Collective Code Construction Contract' (aka C.4.1) as laid out here: http://rfc.zeromq.org/spec:22
- set up a libwebsockets github organisation
- appoint at least one other maintainer as organisation owner
- have maintainers sign up project administrators as described in C4.1
To overhaul infrastructure:
- use github facilities to the fullest extent: organisation, issue tracker, github pages for website and documentation, gitter.im - the integration is hard to beat by self-hosting.
- Move issues to the github tracker, if possible importing the trac history. Then dump trac.
- switch the mailing list to a google group. I do not see the point of self-hosting anymore.
- move the website to github pages, and subject it to the C4.1 change process as any other parts of the project. Again, self-hosting is counterproductive as it deters contributions.
To start the process, use the github tracker: break it down into problem issues, and enable _other_ people to contribute to it by using the C4.1 process. There is NO point in amassing a huge 'todo list' which gets stuck in a manpower bottleneck because other people cannot effectively contribute.
For the general direction forward, I think again adopting the zeroMQ approach helps: the trajectory is a sequence of problem solutions. So each contribution MUST identify a problem (ideally by a test case if a bug), then post a solution as a PR. The merge closes the issue. Admins then are responsible for merging according to the C4.1 process; a release note can eventually automatically extracted from the closed issue descriptions. Having a significant number of admins helps getting merges done quickly, and lessens the load on everybody involved, which obviously is an issue.
I want to emphasize that adopting the C4.1 for machinekit has been very successful and needed only a short time span to get used to. Overall it has made machinekit a much more robust project than the precursor.
I would very much appreciate if we can set things in motion towards a robust future of the libwebsockets project.
ps: my own priorities are:
- getting the debian testing/unstable package updated
- eventually get in Python bindings - maybe work by Andrew Canaday can be brushed up and eventually integrated
> Am 11.10.2015 um 11:20 schrieb Andy Green <andy at warmcat.com>:
> Hi -
> I have been busy with paying work (ie not lws) for some months now. I'm sorry that has not been very graceful for lws.
> However at least for the next week, I am on holiday and have some time to catch up a bit.
> In particular I think I need to give up on lws trac and point people to github. The amount of spam that attracts is amazing, I don't have time to keep it from becoming a spampocalypse.
> In terms of features and functionality, it has been 5 years since I started lws and I think it's pretty complete. In fact considering nobody appears to be using the optional http2 support I added nearly a year ago, I think it's probably more than complete.
> Obviously there are still small bugs and improvements being found... but I would say it's in a mature state. Is there any stuff that we really ought to be adding to it, from where it is? I guess people will continue to send small, useful patches as recently... but in terms of structural changes or other large works?
> I updated appveyor to point to somewhere that has the openssl blob it wants, but he seems to have changed where makensis lives or the utility name changed... I have no idea what to do about fixing that windows-specific thing, so any help appreciated.
More information about the Libwebsockets