17:00:11 <djmitche> #startmeeting weekly
17:00:11 <bb-supy> Meeting started Tue Mar 14 17:00:11 2017 UTC and is due to finish in 60 minutes.  The chair is djmitche. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:11 <bb-supy> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:11 <bb-supy> The meeting name has been set to 'weekly'
17:00:24 <djmitche> #topic Introduction
17:00:26 <djmitche> https://titanpad.com/buildbot-agenda
17:00:32 <djmitche> Roll call!
17:00:37 <verm__> here!
17:00:50 <TheAssassin> uuugh titanpad :P
17:00:58 <skelly> here
17:01:27 <djmitche> cool cool
17:01:32 <tardyp> hello
17:01:36 <djmitche> #topic Development Week in Review
17:01:47 * djmitche waves - do you want to review thew week?
17:03:40 <tardyp> this was a quiet week again
17:04:19 <tardyp> a few fixes were merged, nothing fancy
17:04:36 <djmitche> #info quiet week - nothing fancy
17:04:56 <tardyp> the big thing of the week is trac2gh run
17:05:03 <djmitche> indeed!
17:05:06 <tardyp> which was kinda successful
17:05:08 <djmitche> #topic Trac to Github migration
17:05:10 <djmitche> do tell!
17:05:19 <verm__> is trac going to go away completely?
17:05:24 <tardyp> I did forget to filter the last milestones
17:05:39 <tardyp> verm__: no. we are still using its wiki, and we have the old bugs on it.
17:06:23 <verm__> any reason we can't move the old bugs, too?
17:06:26 <djmitche> #info Trac issues are migrated to Github
17:06:33 <skelly> there are a lot
17:06:34 <verm__> that way we can add perminant redirects from the old ticket urls to github
17:06:49 <verm__> and completely shut down the trac ticket system, much easier to maintain
17:06:49 <djmitche> yeah, the quantity's just too great, and most of them are not useful anymorie
17:06:52 <tardyp> verm__: there is no 1:1 mapping from ticket id to issue id
17:07:04 <verm__> i know that doesn't matter
17:07:20 <tardyp> the old data has few value, but I think is useful for archival
17:07:21 <verm__> you can remap the ticket #'s in ticket comments / descriptions though
17:07:23 <djmitche> tardyp: iirc the trac bugs got annotated with links to the github issues?
17:07:28 <tardyp> or if eight eventually revives
17:07:46 <tardyp> yes, but not in a way which makes it easy to do automatic redirect
17:08:09 <djmitche> I think that's enough
17:08:18 <djmitche> puppetlabs did a similar thing btw
17:08:25 <verm__> from trac?  i've done it before i was just hopping to turn off the trac tickets
17:08:28 <djmitche> migrated some of their bugs automatically, and put up a banner saying it had happened
17:08:38 <djmitche> verm__: the plan is to make them read-only
17:08:41 <verm__> just a big list of apache redirects
17:08:53 <tardyp> verm__: right
17:08:57 <verm__> djmitche: i know but we run a bunch of plugins and other things that are ticket-related those could be killed
17:09:01 <djmitche> even for the migrated issues, there are details left on trac (attachments)
17:09:27 <djmitche> that's probably still possible, right?
17:09:41 <tardyp> There is also stuff not migrated. like attachements
17:10:21 <verm__> oh, that sucks i had no idea attachments couldn't be migrated
17:10:21 <verm__> lame.
17:10:22 <tardyp> I have seen skelly and rutsky manually move some screenshots attachements. I dont know if all of them were migrated
17:10:30 <verm__> there goes that idea..
17:10:38 <skelly> I only saw one
17:10:40 <tardyp> verm__: there is no concept of attachments in github issues
17:10:48 <skelly> I failed to do it but rutsky was able to
17:10:56 <tardyp> the only thing is it does support inline  images via copy paste
17:11:15 <verm__> i see, tickets without attachments i've never heard of that before
17:11:36 <tardyp> github issues is very simplistic
17:11:37 <skelly> you can attach a few things
17:11:41 <djmitche> I think the idea is you can use gists or whatever
17:11:51 <djmitche> anyway
17:11:52 <skelly> images, Office stuff, txt, pdfs, and zip/gz
17:11:54 <rutsky> hi! congrats on transition - great work!
17:12:01 <djmitche> indeed :)
17:12:03 <verm__> gists can be deleted perminantly can't they?
17:12:20 <djmitche> dunno
17:12:23 <verm__> skelly: ah, that's cool then
17:12:25 <skelly> pretty sure
17:12:39 <skelly> c.f. https://help.github.com/articles/file-attachments-on-issues-and-pull-requests/
17:12:43 <verm__> i'm fairly certain they can which makes it bad for tickets since you lose history
17:12:51 <djmitche> so sub-question: do we still want to implement openID for trac logins?
17:13:21 <rutsky> it depends on how we will use trac
17:13:42 <tardyp> I think that could be useful, but not really mandatory
17:13:46 <rutsky> it has wiki pages with partly outdated info, that should mp go to docs
17:13:55 <tardyp> the problem is for the user migration
17:13:55 <djmitche> yeah
17:14:17 <djmitche> historically we probably had 5-10 people per month logging into trac, and probably only 5 ever edited anything but tickets
17:14:19 <tardyp> I have a mapping of trac id to github ids, which does not cover everybody
17:14:31 <tardyp> djmitche: right
17:14:39 <rutsky> for what trac is for now (not taking in account BB 0.8)?
17:14:43 <djmitche> so those 5 people can keep using their passwords
17:14:43 <tardyp> I edit the wiki when I release
17:14:47 <djmitche> rutsky: pretty much just wiki, yeah
17:14:54 <tardyp> and we have some of the doc that is still in the wiki
17:15:13 <tardyp> mostly edited by a handful of people
17:16:06 <tardyp> so I would prefer to use verm__ time to setup a banner about ticket migration rather than setup github login
17:16:06 <djmitche> so I think next steps:
17:16:11 <djmitche> yep
17:16:16 <djmitche> 1. make trac tickets read-only
17:16:34 <djmitche> 2. add a banner to all ticket views indicating we have moved to github and tickets remain for historical purposes
17:16:44 <djmitche> 3. disable any now-unnecessary plugins
17:16:49 <djmitche> am I missing something?
17:17:02 <verm__> we're stuck with the plugins probably since many of them modify the view
17:17:21 <djmitche> ah
17:17:23 <verm__> disabling ticket modification is easy just delete everyones permissions
17:17:51 <djmitche> 4. modify the main page to point to github issues too
17:18:31 <verm__> there are trac->github tools that transfer all the attachments and preserves date/times
17:18:51 <djmitche> too late :)
17:19:38 <skelly> I already labeled every issue (and closed ~40) so let's not import again ;)
17:19:54 <verm__> :(
17:20:00 <verm__> then let's set a date to sunset trac tickets eventually
17:20:07 <verm__> maintaining something we're never going to use again is terrible.
17:20:24 <djmitche> We should consider sunsetting trac entirely at that point
17:20:35 <verm__> i agree
17:20:39 <djmitche> I was thinking of spidering it and making a static copy
17:20:44 <skelly> 1 year from now?
17:20:46 <verm__> we can always make static copies of the tickets
17:20:48 <tardyp> so we will need to migrate the wiki
17:21:00 <djmitche> tardyp: yes
17:21:03 <tardyp> static copy of the tickets is fine for me
17:21:04 <verm__> if we only have a few editors i don't see a reason to keep the wiki, either
17:21:09 <djmitche> verm__: do you know of a trac wiki -> github wiki migrator?
17:21:14 <verm__> i can do that and put it on ftp.buildbot.net
17:21:36 <djmitche> I think we'd replace the existing site, so the same URLs continue to work
17:21:40 <djmitche> just served from static files
17:21:52 <djmitche> `wget -R` basically
17:21:53 <tardyp> yes
17:21:57 <verm__> djmitche: github uses markdown/rest there are quite a few converters
17:22:31 <djmitche> OK, let's agree to revisit this in a year, anyway
17:22:36 <tardyp> one benefit  of the migration is also to cleanup old stuff
17:22:44 <verm__> djmitche: I would do that with apache redirects but archives should go on the FTP
17:22:50 <djmitche> yes, this was a great way to close all those old tickets en masse
17:22:52 <tardyp> So I am not sure a fully automated migration of the wiki makes lot of sense
17:23:02 <djmitche> yeah
17:23:06 <verm__> well if we decide to do it automated there are tons of options
17:23:10 <verm__> also our regular documentation is reST
17:23:12 <djmitche> tardyp: maybe we just chip away at the wiki over the next yaer
17:23:16 <verm__> so it would make copy+pasting trivial into the docs
17:23:18 <skelly> check Google analytics and start at the top?
17:23:20 <rutsky> what about eight and their tickets?
17:23:39 <djmitche> rutsky: we have yet to really find a maintainer for eight
17:23:43 <verm__> we could import the trac wiki to a temp github wiki, move / delete what we want then move it to the main wiki area
17:23:49 <skelly> I vote open in github too
17:24:06 <djmitche> ^^ skelly regarding eight issues?
17:24:20 <skelly> yeah
17:24:38 <skelly> a canned message saying "need maintainer" would also be good
17:24:39 <djmitche> ok, let me see if I can wrangle the ideas floating around here :)
17:24:53 <skelly> I hope you don't want a hard 30 minute cutoff too
17:24:57 <djmitche> are we agreed on the 4 steps outlined above (tickets read-only, banners, etc.)?
17:25:15 <tardyp> agreed
17:25:21 <skelly> agreed
17:25:28 <verm__> agreed
17:25:32 <rutsky> agreed
17:25:37 <djmitche> #agreed on next steps for trac: tickets read-only, banner on tickets, banner on main page
17:25:38 <verm__> i will play around with converting the buildbot wiki
17:25:45 <verm__> and import it on my homedpage in github
17:25:56 <djmitche> and are we agreed vaguely we'd like to be totally off of trac at some point?
17:26:05 <verm__> yes please there is no point in keeping it
17:26:14 <verm__> if we decide to move back in the future we can, trivially
17:26:24 <tardyp> ok
17:26:34 <verm__> it is MUCH easier to move from gh->trac
17:26:34 <rutsky> but keeping old trac read-only static copy
17:26:48 <tardyp> on ftp
17:26:48 <djmitche> #agreed we would like to eventually move totally off of trac, but keeping the content available
17:27:02 <djmitche> I'd prefer original URLs over ftp, but we can argue about that in a year :)
17:27:08 <verm__> i wouldn't keep the old wiki around i would add redirects, do we need to keep it around? docs are an evolution
17:27:21 <verm__> djmitche: heh the original urls will be there just with a 302 to the ftp but yeah let's talk about it in a year
17:27:30 <djmitche> and last
17:27:43 <djmitche> what should we do with eight tickets? skelly says port to github
17:27:50 <djmitche> w/ "need maintainer" label
17:27:51 <skelly> I don't know about port
17:28:03 <skelly> there are a lot more
17:28:07 <djmitche> oh, sorry, I misinterpreted - what do you mean then?
17:28:16 <skelly> start fresh in GH
17:28:27 <djmitche> ah
17:28:38 <rutsky> I would prefer to leave them on Trac until maintainer appears
17:28:38 <tardyp> I could run the migration script without any filtering, and push everything to gh
17:28:40 <skelly> well, 38 in the 0.8.x milestone
17:28:41 <djmitche> so for the moment we'd just need an "eight" label (we have one, I think)
17:29:02 <tardyp> I think we should put it in a separate repository
17:29:08 <skelly> compared to 62 in the 0.9.+ milestone
17:29:13 <djmitche> that's starting to sound like a lot of work tardyp  :)
17:29:30 <tardyp> I'll open a buildbot_issue_archive, and run the script
17:29:37 <tardyp> that is not a lot of work
17:29:48 <djmitche> oh, but we already have an archive...
17:30:14 <skelly> er, ~400 in 0.9.+ milestone, I misinterpreted trac's numbering
17:30:27 <skelly> so, it's not crazy to port the 0.8.x tickets
17:30:28 <djmitche> my position is, eight is basically legacyware at this point, and without someone actively working on it, I don't think we should do much
17:30:31 <tardyp> I filtered the older bugs
17:30:43 <djmitche> how about, we can port teh 0.8.x bugs if there's someone who will tend them?
17:30:54 <skelly> I can quickly run through and label them
17:31:15 <skelly> "quickly", it'll take about an hour
17:31:19 <djmitche> ok
17:31:21 <djmitche> if you're willing :)
17:31:32 <djmitche> in that case I'd say use the same repo
17:31:39 <djmitche> unless we're going to fork an "eight" repo
17:32:01 <tardyp> maybe that is not a bad idea
17:32:25 <tardyp> github.com/buildbot/buildbot_eight
17:32:26 <skelly> makes it easier to do permissions
17:32:36 <skelly> can give someone write to that without affecting main buildbot
17:32:39 <djmitche> yeah
17:32:43 <tardyp> this allow us to support it if needed, and not bother the main nine dev
17:32:44 <skelly> though, there's still pypi
17:32:57 <djmitche> it does sort of promise more than we're willing to commit to though
17:33:03 <tardyp> we can create a buildbot_eight on pypi too
17:33:34 <tardyp> there is no promise on contrary
17:33:47 <verm__> why can't we just obsolete it and accept any (security / severe bug) issues?
17:33:47 <djmitche> yeah
17:33:57 <djmitche> verm__: I'm with you :)
17:34:00 <tardyp> we can just make it clear that this repository needs maintainer
17:34:05 <djmitche> let it quietly float off into history
17:34:06 <verm__> that way we have no unique branches, docs etc
17:34:11 <verm__> close all .8 tickets
17:34:29 <verm__> for ones we think are severe add a note that we will accept a fix
17:34:34 <verm__> otherwise tell them to use a new version
17:35:09 <tardyp> problem is you cannot customize the github pull request template for a branch
17:35:21 <djmitche> hm, true
17:35:24 <tardyp> if we do separate repo that fix this problem
17:35:45 <verm__> i think that's fine, i'm suggesting we only accept very few changes to it
17:36:04 <verm__> if we start to get too many tickets *then* we should make a seperate repo
17:36:05 <tardyp> for now, we dont accept any change until we find a maintainer
17:36:25 <verm__> i think we have a good solution if it becomes a problem so let's see if it will actually become a problem, first. :)
17:37:20 <tardyp> The thing is if we close trac, then we cannot use the migration script
17:37:38 <verm__> we can bring it up anytime
17:37:50 <tardyp> that's why I'd propose to run the migration on another repo, then archive trac bugs, then close trac bugs
17:38:00 <tardyp> in that case, this is fine
17:38:22 <tardyp> I got to go
17:38:29 <verm__> if that's all your worrying about then don't we can always bring it up
17:39:34 * djmitche in another meeting now btw, little less attentive
17:39:43 <tardyp> ok lets close
17:39:48 <skelly> any other topics?
17:39:49 <djmitche> proposals for summation of this topic?
17:40:00 <tardyp> we already have actions, we can decide next actions next week
17:40:34 <tardyp> I think we stick to the plan that you wrote for now, and we rediscuss next week the final shutdown plan
17:40:34 * rutsky afk
17:40:38 <djmitche> ok
17:40:41 * djmitche closes then
17:40:42 <djmitche> thanks all
17:40:59 <djmitche> #agreed will continue discussion of what to do with eight next week
17:41:00 <verm__> agreed
17:41:03 <djmitche> #endmeeting