Please use this topic to suggest agenda items for our weekly meetings.
This week we are schedule to have a Design/UX meeting followed by a the weekly DEV meeting.
For more information about our weekly meetings: https://backdropcms.org/news/meetings
Most helpful answers
I would like to talk about how to prevent this from happening again. It's understandable that it happened this time, but I think we should have a way to prevent this from happening again.
We identified this bug and had a fix all queued up in plenty of time, but because it was not RTBC the core committer was unaware of the problem prior to release and the known bug was included in the release.
https://github.com/backdrop/backdrop-issues/issues/5343
Ideally, if we find a bug caused by a commit that has not yet been released, there should be a way to flag that issue before the release goes out - so that either a fix is applied OR the offending commit is rolled back prior to the release.
Should this be a tag on Github. What could I have done to catch the core committers attention?
Comments
I would like to talk about how to prevent this from happening again. It's understandable that it happened this time, but I think we should have a way to prevent this from happening again.
We identified this bug and had a fix all queued up in plenty of time, but because it was not RTBC the core committer was unaware of the problem prior to release and the known bug was included in the release.
https://github.com/backdrop/backdrop-issues/issues/5343
Ideally, if we find a bug caused by a commit that has not yet been released, there should be a way to flag that issue before the release goes out - so that either a fix is applied OR the offending commit is rolled back prior to the release.
Should this be a tag on Github. What could I have done to catch the core committers attention?
I would also like to talk about our release process in a case like the one mentioned above.
We have a really problematic bug in the last release with simple fix ready to go. In a case like this, I think it would be nice to issue a quick simple bug-fix as quickly as possible, before most users even get to the update that will break their site. The longer we wait to update, the more people are effected and the more people are forced to implement two updates rather than just one.
Is there something we can do to make it easier to issue a "hot-fix" quickly?
Another topic for discussion:
How to deal with Backdrop projects, that aren't supposed to ever show up in the installer or on backdropcms.org? Means: projects that have to get installed differently.
Only a handful of projects are affected:
- drush
- brush
- bee
- phpcs sniffs (no repo yet)
What's the best way to handle that?
If they are in backdrop-contrib, they can't actually do a release. There seems to be an exception for drush, which doesn't show up in the installer, but brush does.
Bee seems to use the "pre-release" setting in Github - maybe for that reason.
I'm asking mainly because of the phpcs sniffs repo. Where to put it?
The first meeting this week will be the design meeting. Here are two issues that I think we should talk about in that meeting.
I'd like to talk more about the hidden path node issue. I've made progress and could use more feedback. https://github.com/backdrop/backdrop-issues/issues/4903
Also: Layout listing: Add help text, to explain how the order and grouping in that page works - https://github.com/backdrop/backdrop-issues/issues/4868
I would also like to talk about whether or not we should follow-up our prioritization discussions with a blog post like the one we did for 1.18.
https://backdropcms.org/news/help-wanted-finalizing-backdrop-cms-1180
I have a draft post started already.
ALSO - should we schedule some sprint days now. These seem to have helped in the past?
- - - - - - -
Finally, I have a draft blog post about telemetry ready to go, but I need feedback.
Another topic for discussion:
How to deal with Backdrop projects, that aren't supposed to ever show up in the installer or on backdropcms.org? Means: projects that have to get installed differently.
Only a handful of projects are affected:
What's the best way to handle that?
If they are in backdrop-contrib, they can't actually do a release. There seems to be an exception for drush, which doesn't show up in the installer, but brush does.
Bee seems to use the "pre-release" setting in Github - maybe for that reason.
I'm asking mainly because of the phpcs sniffs repo. Where to put it?