Meetings/20140408: Difference between revisions

From diaspora* project wiki
No edit summary
No edit summary
Line 48: Line 48:


Clear the milestone: https://github.com/diaspora/diaspora/issues?milestone=9&state=open, then feature freeze for one to two weeks, then reevaluate and release if it's good.
Clear the milestone: https://github.com/diaspora/diaspora/issues?milestone=9&state=open, then feature freeze for one to two weeks, then reevaluate and release if it's good.
=== Release candidate ===
We don't think we're here yet to confidently deliver RCs, but agree that it's the preferable release process. We will reevaluate this at some later point.
== IRC Logs ==
== IRC Logs ==

Revision as of 20:21, 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?

What did we decide?

Time and date

We want to reevaluate the meeting schedule. While we want to keep the interval, every second week of the month, we'll send a poll around to find a new day and/or time.

FISL

Next release

Clear the milestone: https://github.com/diaspora/diaspora/issues?milestone=9&state=open, then feature freeze for one to two weeks, then reevaluate and release if it's good.

Release candidate

We don't think we're here yet to confidently deliver RCs, but agree that it's the preferable release process. We will reevaluate this at some later point.

IRC Logs