I propose that LyX adopts a direct-commit policy for developers who have
demonstrated that they know the rules AND are competent, AND can commit
time to work on LyX.
Each commit results in a diff sent to the list for post-festum review
mainly as a sanity check and such that Lars and others can continue to
know the code.
The main risks are:
- There will be a known problem which the developer does not have time
to fix until a week or two later. Then something happens, and it never
gets done
- A developer does dangerous changes because of lack of experience or
skill (no developer knows all platforms or all history)
- Others will have to spend a lot of time to clean up abandoned stuff,
because the original coder does not have time to fix it
To mitigate these risks, these principles should be adopted:
1) Only commit release quality stuff: It should compile, run, the code
should be maintainable, high quality, useful and portable.
2) Write concise and short patch summaries.
3) Commit early and often. When doing a sprint, commit each logical,
working change rather than one big commit at the end.
4) State when you have time to work on any issues that might appear. If
you know you wont have time in the near future to address issues, send
a patch to the list instead of committing directly.
If in doubt, send a patch instead.
Regards,
Asger
