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.
Received on Tue Nov 18 2014 - 12:21:37 CET
This archive was generated by hypermail 2.3.0
: Tue Nov 18 2014 - 12:24:08 CET