Python Briar Wrapper issueshttps://code.briarproject.org/briar/python-briar-wrapper/-/issues2019-12-14T21:31:15Zhttps://code.briarproject.org/briar/python-briar-wrapper/-/issues/4project requirements2019-12-14T21:31:15Zfphemeralproject requirements@nicoalt What would be your intended target interpreters?
With briar_repl I targeted Python3.6 and above, to enjoy f-strings and the asyncio syntax.
With the python death clock https://pythonclock.org/ in mind I would not consider pyth...@nicoalt What would be your intended target interpreters?
With briar_repl I targeted Python3.6 and above, to enjoy f-strings and the asyncio syntax.
With the python death clock https://pythonclock.org/ in mind I would not consider python2 at all.
But we could also target Python3.7 which is standard in debian buster and bring the amazing dataclasses.
What are your thoughts on this?https://code.briarproject.org/briar/python-briar-wrapper/-/issues/3Discussion of collaborative work flow for this project2019-12-14T20:47:07ZNicoDiscussion of collaborative work flow for this project@fphemeral From previous work in free and open source projects, I really liked the way of always doing merge request when working together on a project. What do you think about doing this for _briar-wrapper_, too? I currently see 4 optio...@fphemeral From previous work in free and open source projects, I really liked the way of always doing merge request when working together on a project. What do you think about doing this for _briar-wrapper_, too? I currently see 4 options:
1. always do merge requests and let them merge by other contributors
2. always do merge requests and wait for an OK by other contributors
3. always do merge requests, but sometimes merge it yourself
4. push directly to `master`
Personally, I'd prefer option 3, so that we always make merge requests to `master` and in general wait for an OK by other contributors, but also can merge it ourselves if it's only a little change.
What do you think about this?