Tracking important issues

2020-09-23 Thread Kurt Roeckx

I would like to have a system so that we can tag issues as
important. But I think they fall in a few categories:
- Features for the next minor/major release (so 3.1 or 4.0)
  that we find important. I've created a new milestone for that: (Post 3.0.0)

  We've also had a Post 1.1.1 milestone, but that seems to be just
  things that didn't block the 1.1.1 release, maybe some more
  things can be moved over.

  I suggest we do not add all feature requests to the new
  milestone, so that we can have some kind of overview.
- Features we want in before beta 1: The 3.0.0 beta1 milestone
- Bugs that need to get fixed before the 3.0.0 release: 
  currently using the 3.0.0 milestone
- Important bugs that affect the stable releases. I've started
  tagging bugs that have "triaged: bug" also with the branches
  that are affected. But that doesn't say how important it is.
  I have 2 proposals for that:
  - Create a milestone for them, like 1.1.1-stable. In cases we
have multiple supported branches, we can add for instance a
3.0-stable and use the oldest branches that's a affected
as the target. This would at least match what we do now
with the "3.0.0" milestone.
  - Create a label for the severity. I'm not sure we need things
like "severity: minor", but it might be useful too.



2020-09-23 Thread Dr Paul Dale
I’m seeing quite a bit of activity going on which isn’t related to the 3.0beta1 
We’re well past the cutoff date announced for new features in the code.

Should we be limiting the “new” stuff going in?

I’m fine with bug fixes, they make sense.  I’m fine with the list of beta1 pull 
requests continuing.
It’s the rest that is more concerning.

Does anyone else have a similar view?

Dr Paul Dale | Distinguished Architect | Cryptographic Foundations 
Phone +61 7 3031 7217
Oracle Australia