<snip>
Trinity does not have a regular "maintenance
point release" schedule to
publicly prove that bugs are being seriously quashed or to keep Trinity in
the news. Bug quashing (maintenance point releases) are a huge public
relations benefit and are, for the most part, painless. For a small
project like Trinity, a dozen or two bug fixes could constitute a
maintenance bug release and keep Trinity in the news every two months.
This is a good idea!
Slavek, if you are reading this do you think the infrastructure is in
place for either you or a small team to handle cherry-picking patches from
the main GIT branch on a regular basis? I don't know if you would be
able/willing to commit to doing something like this, but we obviously do
have a need for it.
Even better would be if we could set a fixed step-by-step
cherry-pick/build/verify procedure (e.g. on the Wiki) and get another
developer or two involved in the process. This should get easier after
R14 is released as we won't be working around the significant renaming
between the SRU and master branches.
Thoughts?
Tim