Publish release lifecycle, support duration and security reports

[samuelcolvin]

I'm about to start a new project (an open source event/ticketing platform) I obviously want to use aiohttp but I have a few questions/requests about long term support and security.

It's particularly relevant in this project as I hope the platform will run for the client for years without significant maintenance from me or any sysadmin.

Could aiohttp publish a life-cycle for major releases: eg. how long they will be fully supported for, how long critical security issues will be fixed for?

Also, as per #2751 it would be good if aiohttp had an official procedure for reporting security issues and stated how we will deal with them.

I guess in summary I'm asking for a simplified version of https://docs.djangoproject.com/en/2.0/internals/security/. Is this possible?

[asvetlov]

Are you asking about a email to send found security problems? Or LTS burden etc?

[samuelcolvin]

Ideally we would:

• add to the docs a way to report security problems, perhaps security@aiohttp.org which goes to you and perhaps other trusted aiohttp maintainers.
• publish how long major versions will be supported. Eg. 1 year, so v3 will be supported until February 2019.
• have an "announce" mailing list for release notices and warnings only.

[asvetlov]

Sorry for a pause. I'll keep it on my radar.

1. security email looks very easy technically.
2. A commitment for major version support is more questionable. a. Should we keep the support of 3.x after 4.0 release? b. For what time period? c. How bug fixes from master should go to latest supported 3.x d. I have a vision how CPython works with these question but ideas from aiohttp community and especially from aiohttp committers are very valuable and important.
3. We have https://groups.google.com/forum/#!forum/aio-libs but even I has stopped to publish announcements because the procedure is too boring. Should we automate it? How? Ideas?

[samuelcolvin]

1

great

2

I think 2 months of support (security bugs only) for an old major version after a new major version is released is sufficient, maybe others need longer?

Personally I think after a major version is released and stable nothing new should be released for that major version except critical operational bugs and security bugs. I should be able to merge and deploy a new minor version once tests pass with no more thinking. New features in minor releases just cause confusion. I guess this is how many projects treat patch releases.

3

I'm not really sure, personally I watch this repo closely and that plus pyup is sufficient. I started thinking about this after noticing how django released 2.0.3, I wondered how aiohttp would react to security problem like this or more serious (eg. like the apache struts problem which caused equifax's downfall).

Perhaps https://groups.google.com/forum/#!forum/aio-libs for anything critical and/or urgent is sufficient.

[webknjaz]

3

CI can send an email there on tag

[asvetlov]

Yes, I understand it. Automating several boring things is in my todo list.

[asvetlov]

The biggest problem is backporting bug-fixes from master to the latest release and LTS release. Let's assume we now have 3.1 as latest, the master branch is for upcoming 3.2, LTS is not defined yet but following my logic it should be 2.X (2.3.Y as the latest release for 2.3 line).

Let's assume PR-XXX from master should be backported to 3.1 and PR-YYY is very critical, it should be backported to 3.1 and 2.X as well.

How should the procedure be?

In CPython we manage it by adding github labels to PR: "need backport to 3.6" and "need backport to 2.7". On PR merging a smart bot creates two PRs with cherry-picking already squashed-and-merged PR into 3.6 and 2.7 branch. If the bot fails it reports by messages in parent PR with ask for creating these PRs by hand. I love this bot, hope to setup something similar for aiohttp but now we have no such tool.

As the first step we can add github labels and ask PR author for making a PR for backporting. Now I do backporting myself but it is boring. The contributor should have instructions for backport PR making. I suggest adding a section to https://docs.aiohttp.org/en/stable/contributing.html for backporting procedure. We can add a link to the section when asking for backport PR.

P.S. aiohttp 3.X has a strong commitment to not break existing public API in next 3.Y releases (but deprecate the API parts if needed). It is not documented properly yet but pronounced on this issue tracker only. What is a public API is a good question, I assume it is documented API. We can stabilize our public API vision during aiohttp 3.X life cycle. aiohttp 4.0 has a freedom for dropping all deprecations except the latest release (as Django do).

P.P.S. We have no LTS yet, let's no speculate how it should look like until going close to aiohttp 4.0 release but concentrate on backporting from mater into the latest releases version.

Thoughts?

[webknjaz]

I think it's a good idea to enforce PR authors to backport their code into stable branches. Of course this should be documented and a note added to PR template. I suggest whenever author identifies that code should be backported it's up to them to create a sibling PRs. Otherwise, maintainers should ask them to create additional PR. I guess all PRs should be merged altogether when all of them are ready, not just main one. But review could be done w/o having existing backport PRs.

[Mariatta]

@asvetlov is the backporting workflow here pretty much the same as CPython? Do you do squash commit, and then backport that to at least one or more branches? If so, maybe we can think of customizing cherry_picker. This is a command line script that simplifies the backporting process. Currently it has hardcoded values and assuming CPython's repo. We might be able to customize by creating a configuration file. The bot (@miss-islington) uses cherry_picker as a dependency internally.

Anyways, the topic of automating backport process is big and if needed I can open another issue just for that discussion.

[asvetlov]

@Mariatta thanks for the suggestion, I like it. Yes, aiohttp workflow is very similar to CPython. We do squash commits on merging.

I use cherry_picker in CPython hacking, customizing it for aiohttp sounds like a very good idea. Agree, the tool should be customizable (e.g. read a config file from repo instead of hardcoded values) to easy adoption the tool not to aiohttp only but to other aio-libs projects.

It is a good step on aiohttp automatization. Do you suggest cherry_picker forking or adding config file support to upstream project?

P.S. I've started with experimenting with github bot for aio-libs (inspired by CPython bots) but I'm still on very early stage. Wheels are rolling slowly, you know.

[Mariatta]

Sounds great! :)

Do you suggest cherry_picker forking or adding config file support to upstream project?

I personally prefer the upstream cherry_picker be updated to support custom configuration, so it can work for other projects with similar workflow. We are already considering adding some sort of config file for a different reason (see https://github.com/python/core-workflow/issues/107). So it's a matter of expanding the scope of things to configure.

I've started with experimenting with github bot for aio-libs (inspired by CPython bots) but I'm still on very early stage. Wheels are rolling slowly, you know.

No problem, I understand. CPython's bots took about a year to reach the current stage, where everything is smooth and automated.

I'm also reducing my time spending contributing to open source for the next two months. So while I'm probably one of the best person to help with cherry_picker and bots, I won't start anything until 2 months from now 😥 sorry..

[asvetlov]

@Mariatta do you remember why CPython enforces replacement # with GH- in commit messages. It is annoying when I press Merge button. I want to figure out is it required for aiohttp or not? I want to add bots and automation, need to think about issues/PRs titling more careful than now.

[Mariatta]

That is indeed annoying (even to me) but you don't need it for aiohttp. It is needed for CPython because of b.p.o. In bpo, it (wrongly) auto-links #123 to bugs.python.org/isssue1234 instead of to GitHub PR 123.

[asvetlov]

Got it. Maybe I need another PR for cherry_picker to override this replacement by config setting.

[Mariatta]

Ok. I think it can be configurable, but if possible for CPython, it will always be replaced with GH-, regardless what the config says.

[webknjaz]

@asvetlov Another idea for contacting the team securely is to use keybase.io.

As an example, npmjs now uses a separate identity/account there allowing to advertise a public key and allowing users to send them e2e encrypted messaged with ease: https://keybase.io/npmregistry / https://blog.npmjs.org/post/172999548390/new-pgp-machinery

[asvetlov]

Interesting