Meetings/20140408: Difference between revisions
No edit summary |
(Moved Brazil item to top, edited text.) |
||
| Line 4: | Line 4: | ||
== Topics to discuss == | == Topics to discuss == | ||
=== Two conferences in Brazil === | |||
Anahuac de Paula Gil, podmin of DiasporaBR, wants to promote Diaspora at two forthcoming conferences. He has secured a booth for Diaspora FISL in May, and would like to know how he can best use this space to help the project. See a comment on https://joindiaspora.com/posts/3813341 and https://joindiaspora.com/posts/3849554 for more details. | |||
He'll be at the meeting to discuss this. | |||
=== FSSN === | === FSSN === | ||
| Line 12: | Line 18: | ||
It would be nice to have an official list of pods, fusion of podutime and the stats hub of Jason, on diasporafoundation.org. Who wants to work on that? Do we want it directly inside the website or in a subdomain? Which technology do we want to use? | It would be nice to have an official list of pods, fusion of podutime and the stats hub of Jason, on diasporafoundation.org. Who wants to work on that? Do we want it directly inside the website or in a subdomain? Which technology do we want to use? | ||
=== Release process === | |||
Suggestion to move into a mode of cutting a release candidate from develop (when agreed in a meeting), and then holding it in the RC branch until it can be merged to master. This would mean a release process where we don't have to freeze develop at all and can test the RC branch for as long as we want, cherry-picking individual fixes into it. | |||
=== Changelog for the develop branch === | === Changelog for the develop branch === | ||
| Line 17: | Line 27: | ||
It happened several times that a commit in the develop branch causes a regression, which is fixed in the develop branch before we release a new version. Should we add a changelog line about these kind of fix? People upgrading the stable branch don't need to know, it's only for people running the develop branch. Maybe a special section, which will be removed during the release process? | It happened several times that a commit in the develop branch causes a regression, which is fixed in the develop branch before we release a new version. Should we add a changelog line about these kind of fix? People upgrading the stable branch don't need to know, it's only for people running the develop branch. Maybe a special section, which will be removed during the release process? | ||
=== | === External communication === | ||
We don't have much external engagement at the moment. Jason is doing good work with the Twitter account, but that's about it. Should we be blogging and trying to engage press interest, etc, and if so, how should we go about this? Who would like to take part in this? | |||
We still have the 'Planet' referred to in various places (for example, the wiki) but it has never been set up. Is this something that we still desire, and if so how should we go about setting it up? | We still have the 'Planet' referred to in various places (for example, the wiki) but it has never been set up. Is this something that we still desire, and if so how should we go about setting it up? | ||
=== Communication through Diaspora HQ === | === Communication through Diaspora HQ === | ||
Revision as of 11:04, 8 April 2014
Time and date
Tuesday 8 April 2014, 7.30 PM UTC. #diaspora-meeting @ FreeNode.
Topics to discuss
Two conferences in Brazil
Anahuac de Paula Gil, podmin of DiasporaBR, wants to promote Diaspora at two forthcoming conferences. He has secured a booth for Diaspora FISL in May, and would like to know how he can best use this space to help the project. See a comment on https://joindiaspora.com/posts/3813341 and https://joindiaspora.com/posts/3849554 for more details.
He'll be at the meeting to discuss this.
FSSN
We have to talk about it.
Official list of pods
It would be nice to have an official list of pods, fusion of podutime and the stats hub of Jason, on diasporafoundation.org. Who wants to work on that? Do we want it directly inside the website or in a subdomain? Which technology do we want to use?
Release process
Suggestion to move into a mode of cutting a release candidate from develop (when agreed in a meeting), and then holding it in the RC branch until it can be merged to master. This would mean a release process where we don't have to freeze develop at all and can test the RC branch for as long as we want, cherry-picking individual fixes into it.
Changelog for the develop branch
It happened several times that a commit in the develop branch causes a regression, which is fixed in the develop branch before we release a new version. Should we add a changelog line about these kind of fix? People upgrading the stable branch don't need to know, it's only for people running the develop branch. Maybe a special section, which will be removed during the release process?
External communication
We don't have much external engagement at the moment. Jason is doing good work with the Twitter account, but that's about it. Should we be blogging and trying to engage press interest, etc, and if so, how should we go about this? Who would like to take part in this?
We still have the 'Planet' referred to in various places (for example, the wiki) but it has never been set up. Is this something that we still desire, and if so how should we go about setting it up?
Communication through Diaspora HQ
What kind of communication do we want through Diaspora HQ? Do we need more formal guidelines?