No worries, I'm also not in a rush to change anything, so we can give this
discussion the space and time it deserves. If you want me to weigh in on
any issue you open on GitHub, just @fmeum.
An additional argument in favor of a delayed publication could be that
sometimes completely unrelated upstr
Many thanks Fabian
and sorry for the delay - unfortunately I'm not really able to free up
as much time as necessary for any OSS stuff right now
On 2021-05-03, Fabian Meumertzheim wrote:
> The behavior you are observing has only become the standard somewhat
> recently [1], which is also why I had
Hi,
The behavior you are observing has only become the standard somewhat
recently [1], which is also why I had decided to point it out before we
performed the integration [2].
Let me first confirm the facts: It is correct that OSS-Fuzz will
automatically open the Monorail bugs to the public rough
Voting takes three days or less if we decide we need an emergency release
for a security issue for example. In reality, it can take weeks for a
release manager to volunteer for a given component, review code, PRs,
Jiras, an so on, before going through all the hoops to create a release
candidate and
Hi (Fabian)
by now we've resolved the first issues detected by ClusterFuzz (and I
forgot to credit it OSS Fuzz in Compress, my bad). What we observed is
that the issues became public automatically once the patch fixing the
issue was merged into master and ClusterFuzz reran the test. In the case
of
