12:02:09 <kshlm> #startmeeting Weekly Community Meeting 2016-11-16 12:02:09 <zodbot> Meeting started Wed Nov 16 12:02:09 2016 UTC. The chair is kshlm. Information about MeetBot at http://wiki.debian.org/MeetBot. 12:02:09 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 12:02:09 <zodbot> The meeting name has been set to 'weekly_community_meeting_2016-11-16' 12:02:20 <kshlm> #topic Rollcall 12:02:40 <ndevos> hello _o/ 12:02:43 <kshlm> I'll wait for a couple of minutes for people to come in. 12:02:50 <kshlm> ndevos, \o 12:02:55 * skoduri is here 12:03:05 <kshlm> It's been a loooooooooooooooooooooong time since you were here. 12:03:08 * Saravanakmr here 12:03:20 * sanoj is here 12:03:41 <kshlm> There still no updates or topics in the agenda other than those that I put in. 12:03:42 * msvbhat is partially here 12:03:49 <ndevos> kshlm: heh, yes, moving apartments and travelling made it difficult to join 12:04:14 <kshlm> ndevos, Did you shift cities? Or just apartments. 12:04:37 <ndevos> kshlm: cities, from Zaandam to Amsterdam, but its only a few kilometers 12:05:14 * atinm is lurking 12:05:16 <kshlm> Why Amsterdam? Didn't you want to move to Barcelona?;) 12:05:42 <ndevos> Barcelona is nice too, but moving there is a little more complicated 12:05:45 <kshlm> ndevos, If you have updates to add for 3.8, please add them to the etherpad. 12:06:10 * ndevos looks for the etherpad 12:06:25 <kshlm> The etherpad is still at https://public.pad.fsfe.org/p/gluster-community-meetings 12:06:32 <kshlm> It might move next week. 12:06:59 * sankarshan is lurking 12:08:01 <kshlm> Okay let's start. 12:08:14 <kshlm> Just 2 topics for the day! 12:08:33 <kshlm> #topic Next weeks host 12:08:43 <kshlm> Any volunteers want to handle next weeks meeting? 12:09:19 <nigelb> I'll volunteer 12:09:27 <kshlm> nigelb, Cool! 12:09:36 <kshlm> Thanks. 12:09:45 <kshlm> #info nigelb will host the next meeting 12:10:06 <kshlm> nigelb, Please add your updates for the week to the etherpad. 12:10:10 * rafi is here 12:10:27 <kshlm> Onto the next topic. 12:10:34 <kshlm> Open floor has just 1 topic. 12:10:53 <kshlm> #topic FSFE etherpad replacement 12:11:01 <kshlm> This is the only thing on the agenda. 12:11:40 <kshlm> Saravanakmr, sent out a call for collecting all the lost and forgotten pads. 12:11:54 <kshlm> He also collected some pads himself. 12:12:01 <kshlm> We need to archive them. 12:12:10 <Saravanakmr> #link http://www.gluster.org/pipermail/gluster-devel/2016-November/051450.html 12:12:16 <kshlm> We already have an archive plan. 12:12:23 <kshlm> So we are good there. 12:12:37 <kshlm> Saravanakmr, Do you need help with the archiving? 12:12:43 <ndevos> do we have other options listed/gathered already? 12:13:14 <Saravanakmr> kkeithley mentioned about beta.etherpad.org 12:13:17 <kshlm> ndevos, We had a list built in a previous meeting. 12:13:50 <kshlm> https://github.com/gluster/glusterfs/wiki/Community-Meeting-2016-11-02 12:13:59 <kshlm> There is a list in this archive. 12:14:11 <kshlm> https://github.com/ether/etherpad-lite/wiki/Sites-that-run-Etherpad-Lite is a proper list. 12:14:24 <kshlm> Saravanakmr, That was mentioned in the earlier meeting as well. 12:14:43 * kkeithley _o/ 12:14:54 <kshlm> The only thing is that beta.etherpad.org can reset without notice. 12:15:00 <kshlm> Hey kkeithley! 12:15:06 <Saravanakmr> kkeithley, can comment :) 12:15:53 <kkeithley> I don't really know anything other than (beta.)etherpad.org is run by rackspace. 12:16:09 <Saravanakmr> kshlm, I remember https://hackmd.io suggested by post-factum 12:16:17 <kkeithley> who have a decent track record, and good mojo in the FOSS community. 12:16:47 <kshlm> kkeithley, They have this notice on every new pad 'IMPORTANT: Pads are frequently destroyed on this server as we use it to test new stuff. You should host your own Etherpad instance' 12:17:09 <kkeithley> yes, I'm aware of those messages. ;-) 12:17:26 <Saravanakmr> kshlm, but I don't remember beta.etherpad.org mentioned by kkeithley. kkeithley correct me if I am wrong. 12:17:43 <kshlm> Saravanakmr, Thanks for bringing up hackmd. 12:17:52 <kshlm> I tried it out last week. Looks good. 12:18:02 <kshlm> https://hackmd.io/CYIwZsCcxQtMAmMlYBYDGICGtIFYB2AZlgDYsAGSAgUwRqKzCKA=?both was an instance I created. 12:18:23 <kkeithley> ??? not sure what you're asking 12:20:16 <kshlm> hackmd looks good. 12:20:46 <kshlm> But doesn't have proper author names or colours like etherpad. 12:20:55 <kshlm> And I don't know how robust it is. 12:21:07 <nigelb> we don't really need it anymore. 12:21:11 <nigelb> We just want something real-time. 12:21:17 <jdarcy> Looks good, but (a) is it open source and (b) how do we know it won't go away next week? 12:21:31 <kkeithley> let's not overthink this 12:21:50 <kshlm> MIT licenses. 12:22:09 <kshlm> I really want a markdown editor. 12:22:19 <kshlm> That's the only bad thing with etherpad. 12:22:32 <nigelb> Let's say we'll try hackmd for the next meeting and see how it goes? 12:22:35 <kshlm> Markdown would make exporting to the wiki so much easier. 12:22:47 <nigelb> I'll send around a link before the meeting so we can add topics for next week. 12:22:49 <kshlm> nigelb, I'm up for it. 12:23:07 <Saravanakmr> we are moving away from FSFE as it is closing down - I think we should go for reliable one. Is hackmod one? 12:23:33 <kshlm> nigelb, I'm supposed to create the next weeks pad after this meeting. But I don't mind if you do it. 12:23:59 <nigelb> we're also moving away from overdependence on etherpads. 12:24:09 <nigelb> so if the next service goes away, we'll have all our data in wiki. 12:24:21 <jdarcy> That's the main thing. 12:24:53 <jdarcy> We can use whatever we want for ephemeral stuff, but stuff-of-record needs to live in *one* reliable place. 12:24:53 <nigelb> the etherpad will be only for during-meeting collaboration or for pre-meeting collaboration (I'm for moving that to the wiki too) 12:25:34 <kshlm> jdarcy, That is our plan. Etherpad only for realtime. After the realtime interaction is done, archive. 12:26:50 <kshlm> Okay. So do we all agree on using hackmd for next week? 12:27:05 <nigelb> +1 from me. 12:28:52 <kshlm> Since we have no opposition, let's go ahead with this. 12:29:19 <kkeithley> +1 12:29:19 <kshlm> #agreed Trial hackmd for collaboration for next meeting. 12:29:27 <kshlm> And that's it. 12:29:37 <kshlm> We have no more topics to discuss. 12:29:43 <kshlm> This is a big open floor now. 12:29:50 <kshlm> #topic Open Floor 12:30:10 <nigelb> I have a topic that I'd like to get everything to think about. 12:30:20 <kshlm> nigelb, Go ahead. 12:30:23 <atinm> When is 3.9 release announcement is getting out? 12:30:29 <nigelb> (I'm not looking for answers, mostly a bit of thought so we can nail it down later) 12:30:44 <nigelb> What DONE look like for a release? 12:30:57 <kshlm> atinm, Neither of the 3.9 maintainers are here. You'll need to ask them. 12:31:07 <atinm> kshlm, hmm ok! 12:31:12 <nigelb> Is it release when we have a git tag? When we have packages built? When the blog post is out? When we have the upgrade guide ready? 12:31:27 <nigelb> We may want to nail this down when we agree on dates for 3.10, for instance. 12:31:41 <ndevos> nigelb: +bugs closed 12:31:42 <nigelb> So if we want all these steps complete by date X, tagging may need to happen a week before, etc. 12:32:02 <nigelb> ndevos: yeah, I was just throwing out ideas for us to think about. 12:32:09 <nigelb> I'm sure there's more steps. 12:32:15 <ndevos> actually, all should be on http://gluster.readthedocs.io/en/latest/Contributors-Guide/GlusterFS-Release-process/ 12:32:27 <kshlm> For me at least, a release is done once I've tagged and sent the announcement. 12:32:44 <kshlm> I would like it to be just that. 12:32:55 <nigelb> Yes, but that's from a release manager point of view. 12:32:57 <kshlm> But as a community, we wait till pacakges are available for users. 12:33:05 <nigelb> But from a project point of view, we want to make sure everyone can consume it first. 12:33:06 <kshlm> And then send the announcement. 12:33:18 <nigelb> So that when we announce a blog post, we're ready for users to test things out, etc. 12:33:35 <nigelb> Anyway, my point is when we define a date, the date should be for when *all* the steps are done. 12:33:39 <nigelb> Not just tagging. 12:33:47 <kshlm> At the point of tagging, I expect the release to have been well tested with RCs. 12:33:48 <ndevos> depending on the distribution, it may take a while before packages are available (on the mirrors) 12:34:04 <nigelb> sure, so we may have to tag a few days before planned release date. 12:34:06 <kkeithley> static analysis has been offline for a while. (always good to know that people are looking at it regularly) I've restarted it. That's cppcheck, clang-compile, clang-analyze, and coverity. 12:34:14 <kkeithley> oops 12:34:32 <nigelb> Heh, it's cool. I'm done with my topic. 12:35:22 <kshlm> nigelb, Till now, we've considered the release date to be the date of tagging. 12:35:24 <ndevos> yes, everyone is (or should be) aware that the packages are available a couple of days after the schedule on the website 12:35:37 <kshlm> The announcement comes out a few days later once pacakges are available. 12:35:57 <nigelb> I know, that's why I brought this up. 12:35:57 <ndevos> we probably should add a note on https://www.gluster.org/community/release-schedule/ about that though 12:36:05 <kshlm> We should begin using proper terms to make things clear. 12:36:24 <kshlm> The release date is the date of announcement. 12:36:32 <kshlm> The freeze date is the date of tagging. 12:36:39 <kkeithley> There's a README on d.g.o. about the fact that packages may take a few days to land. That's not the case this time though 12:37:09 <kshlm> kkeithley, How old is that note? We now almost always only announce after those pacakges land. 12:38:08 <nigelb> I know that's what we normally do. I'm asking that we formalize our release process to define as a release as not when "our work is done", but when "our users can consume the release". 12:38:25 <kkeithley> freeze, release, GA. To me the release is when the tag is made, the jenkins release job runs, and the tar.gz lands on bits.gluster.org. My 2¢ worth 12:39:08 <nigelb> Do we use the term GA for gluster at all? 12:39:12 <ndevos> to me too, the release is a tag, the announcement for General Availability comes after that 12:39:19 <kkeithley> The fact that we don't send the announcement email until after packages land on d.g.o is a detail. Again, my 2¢ worth 12:39:46 <kkeithley> sometimes the email gets sent before all the packages land. 12:40:23 <kkeithley> Well, formally, I think it's when the tag is made. 12:40:27 <ndevos> and packages in distributions (and add-on repos) may get available even later 12:40:51 <nigelb> That's not an excuse to not think of users point of view. 12:41:02 <kkeithley> Community Packages are a convenience thing that is done by the community. The tar.gz is the thing. 12:41:08 <kkeithley> the main thing 12:41:18 <ndevos> +1 to kkeithley 12:41:58 <ndevos> in Fedora packages need to be in the testing repo a couple of days 12:42:10 <kkeithley> which is not to say that community packages can't or shouldn't be streamlined. But they are not — per se — the product. 12:42:32 <nigelb> Do we expect our users to consume the tar.gz or the packages? 12:42:36 <ndevos> the packages from the CentOS Storage SIG mostly get tested by someone else, and depending on their availability/responsiveness it takes a few days or longer 12:43:01 <ndevos> I have no idea how often the Arch packager does the updates 12:43:45 <kkeithley> users is too nebulous. Some users are the packages that make official packages. Others are sysadmins running glusterfs in production. Others are tinkerers dabbling with the latest bits. 12:43:56 <kkeithley> s/packages/packagers/ 12:44:11 <ndevos> also, not all versions are suitable to distributions, 3.0 being a Short-Term-Maintenance version, should maybe not get included in distributions at all 12:44:28 <ndevos> s/3.0/3.9/ 12:45:14 <nigelb> Again, this is something to think about before we decide things for 3.10. 12:47:12 <kkeithley> let's not overthink it. ATM building packages depends on volunteers <cough> having time to build them. 12:48:07 <ndevos> and policies of the different distributions before packages are made available in stable/update repositories 12:48:13 <kkeithley> "holding" the "release" until packages are available could mean that "officially" releasing gets held up for an arbitrarily long time. 12:49:05 <Saravanakmr> Release is always for users - so packages must land before announcement? atleast it must land on Fedora / Centos? 12:49:20 <nigelb> We get to define the bare minumum we want. 12:49:34 <nigelb> At least we have RPM packages ready? 12:49:45 <Saravanakmr> ..and other distribution may follow - I agree with nigelb here 12:49:47 <kkeithley> IMO, packages are a convenience. 12:50:00 <kshlm> I agree with kkeithley. 12:50:03 <kkeithley> this isn't Fedora, or CentOS, or RHEL. We don't have the resources they have 12:50:07 <kshlm> Our release is the tagging + tarball. 12:50:28 <kshlm> We should be announcing after that. 12:51:03 * kkeithley wonders what happens when he gets hit by a bus 12:51:10 <ndevos> I also agree that tagging+tarball is our release, we should not depend on any distribution before announcing it 12:51:14 <kshlm> We could have another announcment later, stating that packages have been built. 12:51:16 <nigelb> Eg: Postgresql release anouncement - https://www.postgresql.org/about/news/1712/ 12:51:34 <kkeithley> kshlm's suggestion is a good one 12:51:39 <nigelb> We're server software installed and maintained in production by sysadmins. 12:51:50 <nigelb> No sysadmin worth their salt are going to use tar balls if they can help it. 12:52:20 <ndevos> there are certaiin times that a distribution (like Fedora) does not accept updates, or they do not get signed+pushed, we shoud not depend on their schedule or (vulunteer) admins 12:52:43 <nigelb> Again, I'm not saying that *all* distributions need to get gluster packages before our announce. 12:53:14 <ndevos> we do not control *any* distribution, waiting on a single one might give us delays we can not predict 12:53:40 <sankarshan> (also, as I understand, you/nigelb aren't saying that Gluster *has* to adopt this. rather - what are the challenges to address should it choose to) 12:54:09 <kkeithley> well, RPMs for Fedora 26 are probably there now, but for F25 they're stuck in bodhi until they get pushed to the Updates-Testing repo. 12:54:30 <nigelb> Yes. 12:54:37 <kkeithley> where they will be for 7-14 days before I can push them to Updates, and then, as is happening now, they're frozen until F25 GA. 12:54:47 <ndevos> I do not think the PostgreSQL announcement mentions distributions that include the packages either? 12:54:51 <kkeithley> so "waiting for RPMs" means what exactly? 12:54:55 <nigelb> scroll down to downloads? 12:54:59 <kshlm> That Postgres announcement is really good. They don't link to actual packages, rather to a download page explaining how they can get them. 12:55:18 <ndevos> nigelb: those packages are not in the distribution, but on their download page? 12:55:48 <nigelb> Yes, that's right. They control them. I'm *not* saying we should do that. 12:55:58 <nigelb> This conversation isn't about packages. 12:56:10 <nigelb> This conversation is about defining what "done" looks like for a release. 12:56:16 <nigelb> We got sidetracked by packages. 12:56:39 <kkeithley> no, it's about what constitutes _our_ release. And packages are being suggested as a gating factor to announce the release 12:57:13 <nigelb> I listed quite a few things. 12:57:18 <nigelb> packages was *one* of them. 12:57:19 <ndevos> imho, "done" would be "tag, tarball, close bugs" 12:57:36 <nigelb> More important than packages are upgrade guide, known bugs, release blog post, closing bugs. 12:57:38 <kkeithley> And I'm suggesting they should not be a gating factor. 12:58:08 <nigelb> My point was if we say we're going to release on 1st Jan. 12:58:24 <kkeithley> I agree with ndevos 12:58:25 <nigelb> By 1st Jan, we should have the upgrade guide ready, bugs closed, blog post primed to go, etc. 12:59:02 <kkeithley> Those are great, except for the etc. part. ;-) 12:59:23 <ndevos> I'm also not sure if users really care that much about a set date 12:59:24 <nigelb> so, my point was to get that etc populated with a well defined list 12:59:35 <nigelb> with a thought about consumers/users. 13:00:14 <ndevos> http://gluster.readthedocs.io/en/latest/Contributors-Guide/GlusterFS-Release-process/ contains all the steps, just no estimation of time needed 13:00:54 <ndevos> it can probably improve, but I have not heard of any user that wants the release on the date that we have on the website now 13:01:04 <nigelb> YES. Which is what I'd like to do. So we'd have to tag + build tarballs by X date if we want everything by Y date. 13:01:31 <nigelb> There's no harm in sticking to our commitments, when we can. 13:01:37 <kkeithley> well, so we set a date. We decided we're have date-driven releases. And then we miss every milestone. 13:01:47 <kkeithley> But I digress. 13:02:00 <ndevos> users would like to see packages after the announement has gone out, but at least for the CentOS Storage SIG they can get convinced to do some testing before the packages are marked stable 13:02:16 <nigelb> Sorry to eat up all the time in this. 13:02:29 <nigelb> I really hoped to take 2 mins and then bring this up as a mailing list thread. 13:02:44 <kkeithley> Once we have automated package building up and running then I think we can make it a gating factor for announcing a release. 13:02:50 <kshlm> nigelb, We didn't have anything else to discuss. 13:02:58 <kkeithley> Until then—— 13:03:20 <kkeithley> also longevity had been offline (semi-intentionally) for a while. It's back now, now with sharding enabled, and statedumps. 13:03:21 <kshlm> Do we want to continue this discussion on the mailing lists? 13:03:29 <ndevos> what I'd like to know, is what is the advantage to set a date, who needs to have releases on a very well planned/fixed schedule and can not wait for a few days? 13:03:51 <kshlm> We're out of time. 13:04:43 <ndevos> sure, an email to the mailinglist is fine, but I'd appreciate a statement of the problem that needs addressing, and not just 'it looks nice' :) 13:06:00 <kshlm> nigelb, Since intended to take this onto the mailing lists, can you do it now? 13:06:07 <ndevos> most releases are done by volunteers in their spare time, so if there is a good reason to get it more strict and give the volunteers a little more stress, then we need to have a good reason 13:06:08 <kshlm> (or later after the meeting) 13:06:22 <nigelb> Yeah, I'll take it to the mailing list during the week. 13:06:32 <kshlm> nigelb, Thanks. 13:06:38 <kshlm> I'll end the meeting on this. 13:06:52 <kshlm> No significant announcements to make this week. 13:07:10 <kshlm> Thank you all for attending. 13:07:13 <kkeithley> ? except 3.9 is released? 13:07:38 <kshlm> kkeithley, we're not clear yet on what released means. So I'm skipping it. 13:07:44 <kkeithley> lol 13:07:45 <kshlm> #endmeeting