Just a general remark on style guides. The guide should be followed for all submissions but deviation is allowed as long as it can be justified or it is clear that it makes sense.
Given that getting sbase to the point of usability is a difficult and time consuming task especially with the existing manpower I'd like to see people focus on fixing bugs, integrating it into an existing distribution (Alpine Linux or sabotage?) and implementing missing tools and features. Reworking sbase to fit these guidelines is time consuming and not sure it is worth the effort at this point. All new code submissions should follow the guide as close possible. We can periodically sweep through sbase and fix these things but there are more important tasks to focus on at present. Most of the people who contribute to sbase come from a Plan9 or BSD or similar background and already are familiar with most of the style guidelines we are proposing here. The important consequence is that they will often _design_ things differently or in a simpler manner. This approach to solving problems cannot be put down in a guide and it is far more important in my view than bitching about inconsistencies in syntax. Including STYLE in sbase can help contributors to get more familiar with the accepted style and rather focus on the semantic level when dealing with patches on the mailing list. For this reason, I'd like to propose inlining the patches as opposed to attaching them as that makes it easier to comment inline. You can still save it in a file and apply it with git am so it doesn't really add any burden on the maintainer.
