Skip to content
JanKusanagi edited this page Nov 2, 2016 · 4 revisions

Call for meeting

Friday 2016/10/21 at 20:00 UTC

Agenda

Feel free to add to this before the meeting!

  • Pump.io code development
    • Adding a blog/build system to http://pump.io
    • Adding an "Uptime service" to http://pump.io
    • Time-based releases
    • (If we have time) weird code in lib/ and test/
  • Community governance and sustainability
    • Node adoption (sponsoring, administering)
    • Adoption of non-node related websites (e.g. OpenFarmGame, ih8.it)
    • Governance (non-profit status/application)
    • Funding
  • Other stuff
    • T-shirt designs

Log

[13:04:17] <larjona> #############################################################

[13:04:17] <larjona> BEGIN LOG

[13:04:17] <larjona> #############################################################

[13:04:17] <larjona> Dear all, welcome to this pump.io community meeting!

[13:04:17] <larjona> Info URL:

[13:04:19] <larjona> https://github.com/pump-io/pump.io/wiki/Meeting-2016-10-28

[13:04:22] <larjona> If anybody wants their nick redacted just say here or direct message to me.

[13:04:24] <larjona> First, as always, roll call meanwhile people is coming. Who's here? Say hello!

[13:04:26] * larjona is here ;)

[13:04:29] <paroneayea> hi!

[13:04:46] <evanpro> Hello!

[13:04:49] <DNS> heya (:

[13:04:55] <evanpro> One thing -- I can only do 4-4:30 today

[13:05:28] <evanpro> Sorry to rush us but I have to get kids from school

[13:05:37] <evanpro> :shrug emoji:

[13:05:43] <larjona> ok!

[13:05:46] <strugee> heya!

[13:05:53] * strugee is here

[13:05:58] <strugee> evanpro: I assume it's 4 for you right now?

[13:05:58] <larjona> let's prioritize then

[13:06:04] <evanpro> Yes

[13:06:12] <larjona> TOPIC: Pump.io code development

[13:06:12] <larjona> Adding a blog/build system to http://pump.io

[13:06:12] <larjona> Adding an "Uptime service" to http://pump.io

[13:06:12] <larjona> Time-based releases

[13:06:12] <larjona> (If we have time) weird code in lib/ and test/

[13:06:19] <evanpro> OK

[13:06:24] <evanpro> Let's do this!

[13:06:38] <strugee> I have one to add to the code development items: doing a 2.0.0 release soon, followed by a 3.0.0

[13:06:46] <evanpro> OK!

[13:06:51] <evanpro> Let's do these in order

[13:07:00] <evanpro> larjona: can we start with the blog/build system?

[13:07:09] <larjona> all yours!

[13:07:16] <evanpro> Is the idea to put a blog on http://pump.io/ ?

[13:07:18] <strugee> neat-o

[13:07:19] <strugee> yeah

[13:07:27] <evanpro> I think there are a couple of systems to do that with Github pages

[13:07:31] <strugee> I think it'd be nice for release announcements, etc.

[13:07:46] <evanpro> Which would probably be the minimal difficulty

[13:07:48] <strugee> because right now the closest we have is the "pump.io" category on strugee.net/blog :P

[13:07:56] <strugee> evanpro: yeah, that's what I was thinking

[13:08:00] <evanpro> OK

[13:08:01] <strugee> stick to GitHub Pages

[13:08:04] <evanpro> I think this is a great idea

[13:08:16] <evanpro> But I wonder what the "build system" is

[13:08:24] <strugee> I've written my own static site engine that I prefer, if that's okay

[13:08:27] <evanpro> Is that just a page with all the various ways to install or download?

[13:08:30] <strugee> otherwise I'll have to learn Jekyll

[13:08:32] <evanpro> OF COURSE YOU HAVE

[13:08:37] <evanpro> B-)

[13:08:51] <strugee> evanpro: no no, the "build system" is for the site

[13:08:53] <evanpro> I'm happy with it if you're happy with it

[13:09:00] <evanpro> Oh, build = build the site

[13:09:04] <strugee> yep

[13:09:12] <strugee> evanpro: ikr :P

[13:09:20] <evanpro> Cool! How difficult is your site engine to use?

[13:09:27] <strugee> very easy

[13:09:43] <strugee> it's actutally extremely easy to reason about if you grok Unix pipes

[13:09:46] <strugee> lemme find an example

[13:09:59] <evanpro> It would be nice if having write access to the repo was enough to give you access to write to the blog

[13:10:13] <strugee> evanpro: yep, that's the way it works

[13:10:17] <evanpro> Perfect

[13:10:27] <evanpro> OK I say MAKE IT SO

[13:10:32] <evanpro> Should we vote?

[13:10:36] <strugee> I'd like to create a separate repo for the website though

[13:10:47] <evanpro> Oh

[13:10:55] <strugee> we can just do pump-io.github.com and keep the CNAME file pointing it to pump.io

[13:10:57] <evanpro> I don't know if that's a problem or not

[13:11:02] <strugee> shouldn't be

[13:11:04] <evanpro> OK, sounds good

[13:11:10] <evanpro> Let me know if I need to change the CNAME

[13:11:17] <strugee> will do but you shouldn't

[13:11:22] <evanpro> OK

[13:11:34] <strugee> shall we vote?

[13:11:35] <evanpro> So, does the blog engine have a name?

[13:11:40] <strugee> evanpro: Stratic

[13:11:49] <strugee> the STReaming stATIC site generator

[13:11:53] <larjona> my only concern is try not to duplicate info, so updating/modifyin is not a pain

[13:12:16] <strugee> larjona: what do you mean?

[13:12:16] <evanpro> So, all in favour of using Stratic to maintain the pump.io Web site? +1/-1/0

[13:12:16] <evanpro> +1

[13:12:22] <strugee> +1

[13:12:50] <larjona> I mean, not to publish things both in wiki /documentation/blog

[13:12:58] <strugee> larjona: gotcha

[13:13:15] <strugee> shouldn't be a problem

[13:13:18] <larjona> +1 for me

[13:13:54] <strugee> awesome

[13:14:00] <larjona> let's move?

[13:14:03] <strugee> yeah

[13:14:04] <evanpro> Great!

[13:14:18] <evanpro> Uptime service

[13:14:32] <evanpro> This would be something like the node uptime for pump?

[13:14:51] <strugee> actually before we do this one

[13:14:59] <evanpro> OK

[13:15:01] <strugee> can we discuss releases? since evanpro doesn't have a lot of time

[13:15:08] <evanpro> Sounds good

[13:15:12] <evanpro> Let's do it!

[13:15:16] <strugee> and I'd like to get that done

[13:15:18] <strugee> cool

[13:15:29] <strugee> so I have two distinct but related proposals

[13:15:59] <strugee> one is that I'd like to do a 2.0.0 release soon, even though we haven't finished everything we were wanting to get in there

[13:16:12] <strugee> e.g. Express 3.x -> Express 4.x

[13:16:45] <strugee> the reason being that I don't want to delay the release of the Express 2.x -> 3.x changes which are already finished

[13:16:52] <evanpro> Cool, that sounds good

[13:16:58] <strugee> the second is that I'd like to move to time-based releases, for similar reasons

[13:17:04] <strugee> basically just not delaying stuff

[13:17:07] <evanpro> OK

[13:17:11] <evanpro> But still sticking with Semver

[13:17:13] <strugee> so the proposal is that we'd release in 2-month cycles

[13:17:14] <evanpro> For versioning

[13:17:16] <strugee> evanpro: correct

[13:17:39] <strugee> the first of the two months would be just work on master

[13:17:47] <evanpro> I guess either a major or minor release?

[13:17:49] <strugee> halfway through the cycle we'd branch master and release that branch as a beta

[13:18:05] <strugee> then at the end of the cycle we'd release the beta branch as stable

[13:18:16] <strugee> evanpro: it'd depend on what made it in

[13:18:23] <evanpro> Right

[13:18:38] <strugee> either we could do major releases whenever we made a breaking change, or we could just wait to merge the breaking changes to master until we were ready

[13:18:47] <evanpro> Gotcha

[13:19:11] <evanpro> So I like this plan. It balances getting things done quickly and keeping things stable for users

[13:19:25] <strugee> generally I'm in favor of the former. I think it doesn't really matter how many major releases changes are spread out over, since there's the same amount of breakage to deal with

[13:19:27] <evanpro> Sticking with semver means the signals are always pretty clear as to compatibility

[13:19:29] <strugee> but I don't feel strongly

[13:19:56] <evanpro> OK

[13:20:11] <evanpro> We could also do plan A for now, and move to plan B when things get more regular

[13:20:16] <evanpro> We are doing a lot of changes right now

[13:20:18] <strugee> evanpro: sounds good

[13:20:59] <strugee> ok so let's vote: time-based releases, doing major releases whenever they're needed now, moving to a "wait to merge breaking changes" model later, when there's less churn

[13:21:01] <strugee> +1 for me

[13:22:01] <evanpro> +1

[13:22:42] <evanpro> OK, barring objections, that makes sense

[13:22:47] <evanpro> Let's keep going

[13:22:51] <strugee> ok

[13:23:00] <strugee> oh also evanpro

[13:23:04] <strugee> to be clear

[13:23:19] <evanpro> Can I bring up the node adoption? That's one of my big ones

[13:23:22] <strugee> 2.0.0 would be an exception, since we'd want to get that out faster

[13:23:25] <evanpro> It's skipping ahead

[13:23:30] <evanpro> strugee: yes I got that

[13:23:34] <strugee> evanpro: I have no objections

[13:23:35] <strugee> ok

[13:23:38] <strugee> just checking :)

[13:23:48] <evanpro> Awesome

[13:24:03] <strugee> larjona: hope ^^^ that's ok

[13:24:03] <evanpro> So I did an announcement after our last meeting and had great interest

[13:24:07] <larjona> yes

[13:24:11] <evanpro> 8 out of 20 servers are spoken for now

[13:24:20] <larjona> sorry I was afk for a minute

[13:24:24] <evanpro> I still need to send out papers and get things actually transferred

[13:24:26] <strugee> np

[13:24:29] <evanpro> But it's a good process

[13:24:45] <strugee> \o/ whoooo!

[13:24:47] <evanpro> My next steps are to do this, then make another call for adoption

[13:25:01] <evanpro> Unfortunately I have to boogie now

[13:25:16] <jxself> Am I part of that paper-sending process? I'm still waiting to hear back one way or the other.

[13:25:17] <evanpro> Sorry to buzz through this meeting so fast!

[13:25:17] <evanpro> jxself: yes

[13:25:23] <jxself> OK.

[13:25:37] <larjona> thanks evanpro!

[13:25:46] <evanpro> Thanks all!

[13:25:50] *** Parts: evanpro (*****) ()

[13:25:56] <strugee> great

[13:26:05] <strugee> that was productive, if brief :D

[13:26:53] <larjona> let's go on? I think we can talk about the uptime service? Or other topic?

[13:28:02] <strugee> sure

[13:30:59] <strugee> that's basically just running something similar to jpope's pump uptime service under http://pump.io, right?

[13:31:06] <larjona> So I asked some days ago about this, jpope's service broke and the domain expires; I researched a bit and found that "uptime" is unmaintained now, and I'm not sure which is the FaiF recommended service now.

[13:31:44] <strugee> righ

[13:31:45] <strugee> t

[13:33:06] <strugee> IIRC when I looked into Uptime it had some suggested alternatives, right?

[13:33:56] <strugee> as an aside, for anyone curious about how Stratic looks: https://github.com/strugee/strugee.github.com/blob/eb806ef29f4abf990ec3515d22a204d5ff63b613/gulpfile.js#L81 is what powers strugee.net/blog

[13:34:35] <larjona> strugee: not exactly, it points to http://www.supermonitoring.com/blog/the-updated-list-of-website-monitoring-services/ which is a collection of monitoring services (free and non free)

[13:35:08] <strugee> larjona: ah, that must be what I was remembering

[13:35:34] <larjona> So it's hard for me to decide among them, because I know none of them.

[13:37:05] <strugee> I haven't heard of most of them either

[13:37:21] <strugee> I may know another good list

[13:37:32] <strugee> please stand by

[13:39:44] <strugee> https://github.com/n1trux/awesome-sysadmin#monitoring

[13:46:47] <larjona> those look like "full feature solutions". I think we need only need a small thing. Well, I'll try to put some time this month into looking for something

[13:47:09] <jxself> Yes, something like Nagios is probably overkill. :)

[13:47:44] <strugee> hmm

[13:47:50] <strugee> none of those really look like what we want

[13:48:20] <jxself> Perhaps requirements need defining then...

[13:48:39] <strugee> yeah

[13:48:51] <strugee> we could also just keep using Uptime and fix it when it breaks...

[13:52:49] <strugee> http://www.phpservermonitor.org/ looks like what we want

[13:54:45] <strugee> wow, that actually looks perfect

[13:54:56] <jxself> I saw that earlier. Assuming that it doesn't require logging in to see status info.

[13:55:07] <jxself> I assume one of the requirements is public display of node status.

[13:55:28] <strugee> right

[13:55:48] <strugee> this looks pretty trivial to set up

[13:55:54] <strugee> so I might do that and see if it does what we need

[13:56:04] <strugee> even if it doesn't it's pretty close and probably easy to patch

[13:56:13] <larjona> thanks strugee

[13:56:25] <strugee> sure

[13:56:57] <larjona> Friends, I have to go soon. Any other topic?

[13:57:02] <strugee> me too

[13:57:03] <strugee> I don't think so

[13:57:25] <larjona> ok so let's finish the meeting

[13:57:37] <larjona> thanks everybody for attending and participating (or lurking)

[13:57:52] <strugee> thanks larjona!

[13:58:02] <larjona> A nice rabbit for you

[13:58:04] <larjona>

[13:58:04] <larjona> ((`\

[13:58:04] <larjona> ___ \ '--._

[13:58:04] <larjona> .' ' o )

[13:58:05] <larjona> / \ '. __.'

[13:58:07] <larjona> | / \ __

[13:58:09] <larjona> jgs {______-'__\

[13:58:11] <larjona>

[13:58:14] <larjona>

[13:58:16] <larjona>

[13:58:22] <larjona> #############################################################

[13:58:24] <larjona> END LOG

[13:58:27] <larjona> #############################################################

Clone this wiki locally