[PATCH] D10305: [Clang Static Analyzer] Bug identification

[Anna Zaks via cfe-commits]

zaks.anna added a comment.

> Should we require the generation of old hashes once a change is introduced, or should we expect users

>  who rely on old hash to maintain the old hash generation as an out of tree patch?


We should maintain the old hashes, at least for a while, if there are people who rely on them.

However, we should not treat every commit that changes the hash as creating a new hash that we have to maintain forever. We should determine the point when the newly developed hash is considered stable/good enough and commit to maintaining it at that time. The way I see it is that the experimental hashes could be committed, improved upon, and tested by various "consumers". After all the planned features are done and bugs are fixed, we can assume that the hash is no longer experimental.

We could have process around this as well if the community thinks it's useful. For example, adding experimental to the name of the hash until we commit to it if you think that people might get confused. Another thought would be to tie the hashes to the open source llvm releases, however, those are not very frequent.

> The hash calculation WILL change in the near future once we figured out how to identify checkers 

>  properly (but I think it will not make sense to rename the hash for this change). For this reason I think we > should mark this feature as experimental, until that change is introduced.


I agree.

If we plan on fixing the checker name problem soon, I think it's worthwhile waiting for it.
I did not have time to think about the issue much (I am traveling at a conference this week); however,  we can come up with a more flexible solution than just stripping out the package names. (We might also want to consider how checker plug-ins would work with this. Though, that is not critical.)

> What is the recommended way, to do that? Generating a comment to the plist?


That'd be hard to miss...


http://reviews.llvm.org/D10305