Release issueshttps://lab.civicrm.org/dev/release/-/issues2020-03-16T09:44:26Zhttps://lab.civicrm.org/dev/release/-/issues/14Document the process for pulling or skipping/missing releases2020-03-16T09:44:26ZhomotechsualDocument the process for pulling or skipping/missing releasesWhen we skip or pull a release we should have a policy that dictates followup notifications/communications.
Recent examples include 5.23 (WordPress) 5.23.1 (Joomla) and the remove/release of one of the earlier 5.x.x versions. We should ...When we skip or pull a release we should have a policy that dictates followup notifications/communications.
Recent examples include 5.23 (WordPress) 5.23.1 (Joomla) and the remove/release of one of the earlier 5.x.x versions. We should have a standard, transparent, open communication policy that announces these decisions and the reasons as soon as practicably possible after the decision is taken.
Currently there is no policy on this and the communication is spotty/unreliable. I'm willing to put my "money where my mouth is" on this and I'll volunteer to write short blog posts when this happens if it's useful - so I don't mind putting in the effort - I'd just like us to debate and agree a coordinated policy on this!https://lab.civicrm.org/dev/release/-/issues/13Please consider using CVE identifies for security issues2020-01-03T14:13:55ZDmitry SmirnovPlease consider using CVE identifies for security issuesInstead of vendor identifiers (e.g. `CIVI-SA-2019-24`) please consider using standard CVE identifies for security issues.
Here is some reasoning from the Debian Security Team:
> The good thing on having a CVE id for the vulnerabilities...Instead of vendor identifiers (e.g. `CIVI-SA-2019-24`) please consider using standard CVE identifies for security issues.
Here is some reasoning from the Debian Security Team:
> The good thing on having a CVE id for the vulnerabilities is helping
> other vendors to track the issues properly 'cross-vendor' in an unique
> way. If every upstream would use individual identifiers to track their
> vulnerabilities, this makes the work of downsteams security teams much
> harder. Nowdays MITRE has improved a lot on their processes on
> assigning CVEs, and good filled reports at https://cveform.mitre.org/
> get fastly assigned a CVE respectively (this somehow depends though on
> how good the report is done). I know some upstreams did in past make
> frustrating experiations, and do not want to try that out again.
See also [Debian Upstream Guide](https://wiki.debian.org/UpstreamGuide).
Thank you.https://lab.civicrm.org/dev/release/-/issues/125.20: open source compliance: non-free 'vendor/togos/gitignore'2020-01-07T08:34:12ZDmitry Smirnov5.20: open source compliance: non-free 'vendor/togos/gitignore'Release management should exercise more care in regards to Open Source compliance of the sub-vendored re-distributed components.
For instance, in release 5.20 `vendor/togos/gitignore` is a non-free component due to absence of licensing ...Release management should exercise more care in regards to Open Source compliance of the sub-vendored re-distributed components.
For instance, in release 5.20 `vendor/togos/gitignore` is a non-free component due to absence of licensing and copyright information.
https://github.com/TOGoS/PHPGitIgnore/issues/1https://lab.civicrm.org/dev/release/-/issues/10Security Releases - Update post-release communications workflow2019-11-27T23:11:00ZtottenSecurity Releases - Update post-release communications workflow__Synopsis__: When a new security release goes out, one may wish to notify as many users as possible. This requires communications across several different media. The aim of this issue is to define a smoother workflow for improved consis...__Synopsis__: When a new security release goes out, one may wish to notify as many users as possible. This requires communications across several different media. The aim of this issue is to define a smoother workflow for improved consistency.
__Target Media__:
The communications about a recent release may hit the following media:
* `chat.civicrm.org` (public groups) - "Town square", "dev", "product-maintenance"
* `chat.civicrm.org` (private groups) - "security", "ESR", "mergers"
* `latest.civicrm.org` - Versions listing (which feeds `civicrm.org/download` and in-app notices)
* `sourceforge.net` - Default download
* `civicrm.org` - Security advisories
* `civicrm.org` - Blog
* `civicrm.org` - "Security Notifications" mailing list
* `twitter.com` - `@civicrm` account
* `facebook.com` - CiviCRM group
__Considerations__:
* The broad communications for monthly-releases and security-releases are similar, but security-releases have the higher bar because they are more urgent, leading to more time-sensitivity and a longer list of media. Consequently, if we solve security-releases, then our monthly-releases can follow a simpler subset of the workflow.
* The list of media has tended to grow over time.
* The people who post to each medium has varied overtime.
* The knowledge/access of posting in different media are spread among different people.
* The best documents to refer people to are generally (a) the blog article and/or (b) the release-notes.
* The document [any-announce.md](https://lab.civicrm.org/dev/release/blob/master/doc/any-announce.md) proscribes some particular steps. It is slightly out-of-date, and includes a range of tasks which have (for at least... 5 years?) been split among different people.
* Today, the emotional experience of getting announcements is a bit like this: *You sign up for 3 channels, and then you don't see a notice on whichever one is your favorite, and someone tells you that you need to signup for more.*
* Today, the emotional experience of sending announcements is a bit like this: *You post a message to 5 channels, and then someone says that you didn't post to a 6th channel that you don't personally use.*
* It is conceivable to use a smaller list of feeds (like `latest.civicrm.org` and `release-notes`) to populate more channels automatically. This would require case-by-case technical implementation. Alternatively, for media where automation has poor cost/benefit, we can have a person responsible for each medium. This would likely create some lag (b/c it's hard to precisely coordinate timing across multiple continents). Any style of contribution (*automating a medium or standing sentry for a medium*) is useful.
__Proposal :one:__:
1. Team organization
1. There is a private MM group for people involved with release communications.
2. Rename the current `mergers` group to `releasers` or `release-team` or somesuch -- since this is a more accurate reflection of how the group works.
3. In the the GL project `dev/release`, add a wiki page with a list of media and the party responsible for each medium. Anyone added to this list must also be added to MM.
4. The MM channel has sticky link at the top to the wiki page.
2. For post-release communications, the workflow goes as follows:
1. Tarball and tag information goes up to `download.civicrm.org`, `sf.net`, `latest.civicrm.org`. The release is live.
2. The person who uploads then sends a notification to all `releasers` that the release is live.
3. Each person who signed up for release-comm's gets the ping and does thing their thing.
__Meta__
* If additional proposals are made, please give them an identifying code; and, if possible, include a summary in the description of this issue.
* Related: [Security Releases - Update pre-release communications workflow](https://lab.civicrm.org/dev/release/issues/11)https://lab.civicrm.org/dev/release/-/issues/2Brainstorm: Little Ideas for QA2018-04-19T03:15:34ZtottenBrainstorm: Little Ideas for QAThis issue is an experiment. The goal -- brainstorm for Little Ideas that will improve the quality-assurance regime. I'm not looking to replay past discussions -- if something was controversial before, it's probably still controversial. ...This issue is an experiment. The goal -- brainstorm for Little Ideas that will improve the quality-assurance regime. I'm not looking to replay past discussions -- if something was controversial before, it's probably still controversial. For purposes of this issue, humor me. Suppose there's a realistic budget -- like a week of senior developer/designer/documenter/administrator time. What process change could they perform that might make a dent at improving QA? Perhaps something that makes PR review more thorough? Or perhaps it improves engagement with RCs? Or perhaps it lowers the barrier to testing?
Please post one idea per comment. If you like or dislike an idea, put a thumbsup or thumbsdown emoji on the comment. To discuss the idea in more depth, ping the commenter on Mattermost (https://chat.civicrm.org under `dev`).
------
Emojis:
* :thumbsup_tone1: - Good idea. Simple, clear steps. Would probably improve quality. Achievable within budget.
* :thumbsdown_tone1: - Bad idea. Wouldn't improve quality.
* :8ball: - Don't really want to judge. It sounds good, but it's not simple enough or not clear enough or too long. Maybe if the idea was refined more.
* :baby_chick: - The comment is conversation.