13:12:37 <pingou> #startmeeting pagure stakeholder meeting 13:12:37 <zodbot> Meeting started Fri Dec 7 13:12:37 2018 UTC. 13:12:37 <zodbot> This meeting is logged and archived in a public location. 13:12:37 <zodbot> The chair is pingou. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:12:37 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 13:12:37 <zodbot> The meeting name has been set to 'pagure_stakeholder_meeting' 13:12:39 <pingou> #meetingname pagure-stakeholder 13:12:39 <zodbot> The meeting name has been set to 'pagure-stakeholder' 13:12:40 <pingou> #meetingtopic Pagure development state and plans 13:12:43 <pingou> #info this meeting is recorded using zodbot's meetbot plugins and transcripts will be available at: https://meetbot.fedoraproject.org/ 13:12:51 <pingou> #topic rollcall & introduction 13:13:15 <Eighth_Doctor> .hello ngompa 13:13:16 <zodbot> Eighth_Doctor: ngompa 'Neal Gompa' <ngompa13@gmail.com> 13:13:23 <pingou> hm, zodbot doesn't seem to be able to change the topic, I'll have to check this later 13:13:29 <pingou> .hello2 pingou 13:13:30 <zodbot> pingou: pingou 'Pierre-YvesChibon' <pingou@pingoured.fr> 13:13:39 <Eighth_Doctor> yeah, I had that problem when I chaired the golang sig meeting too 13:13:39 <cverna> hello :) 13:13:49 <bkabrda> hi! 13:14:08 <pingou> #todo pingou figure out how zodbot can change the meeting topic 13:14:23 <bookwar> .hello bookwar 13:14:24 <pingou> #action pingou figure out how zodbot can change the meeting topic 13:14:25 <zodbot> bookwar: bookwar 'Aleksandra Fedorova' <alpha@bookwar.info> 13:14:29 <karsten> .hello karsten 13:14:30 <zodbot> karsten: karsten 'Karsten Hopp' <karsten@redhat.com> 13:14:47 <Son_Goku> .hello ngompa 13:14:47 <Son_Goku> yay, my IRC client is back 13:14:48 <zodbot> Son_Goku: ngompa 'Neal Gompa' <ngompa13@gmail.com> 13:15:08 <Son_Goku> Riot is too painful for these things :) 13:15:31 <pingou> do we want to do a little more friendly introduction than just stating names? :) 13:15:39 <Son_Goku> sure, why not :) 13:15:47 <pingou> I believe I know most folks, but I'm sure I don't know everyone :) 13:15:51 <pingou> I'll just start 13:16:28 <pingou> so pingou, lead developer on pagure, French (which explains the project name), paid by Red Hat to work on Fedora Infra :) 13:16:51 <Son_Goku> and rare breed of all-around French good guy :) 13:17:13 <pingou> beware there is a second one around ;-) 13:17:18 <cverna> I am Clément, I started contributing to pagure 3 years ago which lead me to get at Red Hat to on Fedora Infra :) and French too 13:17:24 <cverna> here it is :) 13:17:43 <Son_Goku> :D 13:17:49 <cverna> job* and work* for the missing words :P 13:18:02 <Son_Goku> xD 13:18:12 <bkabrda> I am Slavek, currently maintaining Red Hat internal instance of Pagure, which is in Beta stage. Have been working on it for about a year, so the same time I've been contributing upstream. 13:18:46 <bookwar> I am Aleksandra, started to work on Fedora and RHEL CI in August, paid by RH :) 13:19:34 <karsten> I'm Karsten, working on pagure upstream for Red Hat as well 13:20:13 <Son_Goku> I am Neal, I started contributing to Pagure this year after my long effort to get it packaged in Mageia. And then I packaged it for openSUSE. And took over Fedora and EPEL packaging for Pagure. I'm apparently everywhere now. :) 13:20:27 <lenka> Hi, I'm Lenka, do I belong to this meeting too? :) (confused beginner) 13:20:34 <fm-pagure> pagure.issue.new -- karsten opened a new ticket pagure#4106: "commit 7c5e53fe9a67623ccd627817935bf99722897dc1 breaks DB creation (vagrant install)" https://pagure.io/pagure/issue/4106 13:20:40 <pingou> lenka: you definitively do :) 13:20:56 <Son_Goku> I'm also somewhat infamous for having multiple nicks (Pharaoh_Atem, Son_Goku, King_InuYasha, Eighth_Doctor, ...) :) 13:21:46 <pingou> lcp: want to jump in? 13:21:46 <lcp> I'm Stasiek, I have no idea what I'm really doing here, contributed exactly once (but working on getting openSUSE to use pagure for stuff with ngompa I guess) 13:21:52 <lcp> I just did 13:21:57 <pingou> gmta :) 13:22:11 <Son_Goku> My interest started with making Pagure palatable to run for Mageia's software Git and moving our Dist-SVN to Dist-Git using Pagure :) 13:22:22 <Son_Goku> and now I dragged lcp for the ride :) 13:22:23 <lenka> ok :) Born in Czech, living near Barcelona, I'm working on Pagure command line interface tool, I named it cranc (crab in catalan), I work for third day here, paid by Outreachy :) And my mentor is Bookwar 13:22:30 <Son_Goku> oh nice 13:22:38 <Son_Goku> I didn't know someone was working on one, very cool! 13:22:53 <pingou> lenka: is it similar to pag or pag-off? 13:23:07 <lcp> I mean, after osc and trollo, I just assume everything gotta have cli interface 13:23:22 <fm-pagure> pagure.pull-request.flag.updated -- jenkins #1891 updated the flags on pagure#4105 with: "Build successful (commit: 36168f6b)" https://pagure.io/pagure/pull-request/4105 13:23:24 <cverna> lenka++ sounds cool 13:23:32 <lenka> pingou: uhh, I don't know what is pag and pag-off... 13:23:53 <Son_Goku> lenka: pingou's earlier proof of concept implementations of CLI tools using Pagure's API 13:23:59 <lenka> pingou: I want to do it in Click 13:24:00 <pingou> lenka: http://pagure.io/pag http://pagure.io/pag-off 13:24:29 <bookwar> pingou: the goal is to make it sort of like git command, git list prs, got approve pr 13:24:36 <lenka> ah yes, that was in Argparse? 13:24:45 <cverna> it would be awesome to give https://pagure.io/libpagure some love too 13:24:51 <pingou> bookwar: I think that was the idea of pag as well 13:24:58 <pingou> may be nice to combine effort on this 13:25:13 <bookwar> pingou: true, we'll look into it 13:25:21 <Son_Goku> bookwar, oh, so that would be extensible with purpose built modules and such? 13:25:29 * Son_Goku has worked a little bit with click before 13:25:36 <pingou> lenka: pag is click-based ;-) 13:25:57 <Son_Goku> canc is a fun name though :D 13:26:04 <pingou> and libpagure-based as well :) 13:26:06 <Son_Goku> *cranc 13:26:06 <lenka> pingou: ok, that I didn't know either ;) 13:26:13 <bookwar> Son_Goku: yes, the idea it to inject it in he fedpkg workflow of fedora package maintainer 13:26:21 <Son_Goku> is fedpkg click-based now? 13:26:28 <pingou> don't think so 13:26:33 <Son_Goku> I thought it was doing crimes against humanity with optparse? 13:26:43 <bookwar> :) 13:26:45 <pingou> likely still kinda is :) 13:26:56 <bkabrda> Son_Goku: hey, I just spit tea all over my monitor! 13:27:02 <Son_Goku> XD 13:27:11 <Son_Goku> fedpkg is easily the scariest CLI tool codebase I've ever seen 13:27:36 <Son_Goku> really powerful, but I don't want to be the poor guy integrating new functionality into it 13:27:48 <pingou> :) 13:27:58 <pingou> alright, let's move into 5.2 state :) 13:28:02 <pingou> #topic State of 5.2 13:28:05 <pingou> #link https://pagure.io/pagure/roadmap/5.2/ 13:28:30 <pingou> so the good news is that we are at 84%, with only 9 remaining tickets 13:28:51 <Son_Goku> I need to get my testing setup back up for validating the current state of git master for 5.2 13:28:57 <pingou> of which 3869, 3684, 1749 and 861 all have PRs 13:29:02 <Son_Goku> we caught a lot of weird quirks that way during 5.0 development 13:29:20 <fm-pagure> pagure.pull-request.new -- pingou opened pull request #4107 on pagure: Add support to download a commit or a tag as tarball https://pagure.io/pagure/pull-request/4107 13:29:27 <pingou> this is ^ 861 :) 13:29:46 <Son_Goku> why is there no test run? 13:29:59 <bkabrda> pingou: I'd love to get https://pagure.io/pagure/issue/4072 to 5.2, but I can't promise I'll find enough time, so I'd probably not advise adding it to the milestone unless someone else promises to work on that 13:29:59 <pingou> ? 13:30:06 <fm-pagure> pagure.pull-request.flag.added -- jenkins #1892 flagged pagure#4107 with "Build in progress (commit: 9b7aa5c9)" https://pagure.io/pagure/pull-request/4107 13:30:27 <pingou> bkabrda: at this point, unless someone has the time for it, I'd say: 5.3 13:30:38 <Son_Goku> pingou, oh, because no one opened it 13:30:43 <Son_Goku> and I just did, which kicked off a job 13:30:47 <bkabrda> pingou: agreed. I'll try to make it happen for 5.2, but we'll see 13:30:55 <pingou> Son_Goku: I just created the pr ;-) 13:30:56 <Son_Goku> did we fix this in master already? 13:31:00 <Son_Goku> ah 13:31:08 <pingou> Son_Goku: and yes, it should be fixed in master 13:31:35 <Son_Goku> the CI bits are one of the few things I can't test with my testing setup unfortunately 13:31:40 <pingou> https://pagure.io/pagure/issue/4089 this one annoys me a little (esp since I can't reproduce it locally) 13:32:52 <fm-pagure> pagure.issue.comment.added -- ngompa commented on ticket pagure#4072: "Running git hooks on server side" https://pagure.io/pagure/issue/4072#comment-545220 13:33:01 <pingou> outside of 4072 that bkabrda just pointed to, are there other issues we'd like to have in 5.2 which isn't listed there? 13:33:33 <bkabrda> pingou: https://pagure.io/pagure/issue/3971 could also be problem for people with latest gitolite3 13:33:56 <Son_Goku> pingou, still need to fix markdown to work with v3 13:34:11 <Son_Goku> unfortunately, people are now updating python-markdown packages to v3, which is breaking pagure completely 13:34:17 <bkabrda> but that issue already exists in 5.1 (I'm not hitting it ATM since I already dropped gitolite alltogether) 13:34:52 <pingou> Son_Goku: yeah, for this one I'd want to do it in 5.3 as it won't be a trivial fix I'm afraid 13:34:57 <fm-pagure> pagure.issue.comment.added -- ngompa commented on ticket pagure#3971: "BaseHook's creation of "update" hook breaks gitolite" https://pagure.io/pagure/issue/3971#comment-545221 13:35:19 <Son_Goku> pingou, you don't think we can get it into 5.2? 13:36:07 <pingou> Son_Goku: I doubt so 13:36:40 <cverna> do you know when is 5.2 planned/needed for ? 13:36:44 <pingou> I'd like for 5.2 to be out sometime next week, which gives us a week of buffer before the holidays 13:36:59 <fm-pagure> pagure.issue.comment.added -- bkabrda commented on ticket pagure#4072: "Running git hooks on server side" https://pagure.io/pagure/issue/4072#comment-545222 13:37:03 <pingou> we'd likely not deploy it before the holidays but at least it would be released 13:37:09 <cverna> I have more general proposal about version and release schedule, and would like to know how people feel about it. In the spirit of release small, release often what do you think about having a monthly release of pagure ? 13:37:28 <pingou> cverna: let's have a dedicated topic about this 13:37:33 <pingou> #topic pagure release cadence 13:37:48 <pingou> So cverna proposes a monthly release of pagure 13:37:57 <pingou> cverna: a .y release I guess? 13:38:10 <cverna> that would obviously mean that the scope of the releases would be smaller 13:38:33 <Son_Goku> but maybe that means we also don't need to maintain .y.z branches either 13:38:56 <pingou> Son_Goku: if we run into annoying bugs, we'll likely still want to do .z releases 13:39:02 <cverna> pingou: most of the time yes, but you can also work on bigger feature using feature flags 13:39:19 <pingou> I had a similar train of thoughts as cverna which was along the way of: 13:39:27 <pingou> .y release -> monthly 13:39:36 <pingou> .z release -> when needed (safe to upgrade to) 13:39:51 <pingou> .x release -> when necessary (hopefully not too often) 13:40:57 <cverna> that sounds sane to me 13:41:08 <Son_Goku> well, let's see here 13:41:16 <Son_Goku> what is the criteria for x.0.0 releases? 13:41:22 <Son_Goku> is that when we break everything? 13:41:24 <pingou> non-backward compatible 13:41:36 <Son_Goku> so we're effectively going SemVer? 13:41:37 <pingou> .y -> new feature (+bug fix) 13:41:42 <pingou> .z -> bug fix only 13:42:02 <pingou> it's a subset of semver because I don't like their 0... == things can break all the time 13:42:39 <pingou> for me if you're at 0.x, where x > 0 and has been for a while and introduce a non-backward compatible change -> bump to 1.x 13:42:58 <Son_Goku> ah 13:43:04 <pingou> pygit2 breaks often because they are still in 0. which means "beta" 13:43:10 <Son_Goku> :/ 13:43:12 <pingou> and they have been for *years* 13:43:18 <Son_Goku> so has libgit2 for that matter 13:43:22 <pingou> yup 13:43:58 <cverna> for people running their own version of pagure how does a monthly release candence feel ? 13:44:06 <cverna> s/version/instance 13:44:19 <pingou> my worry about the monthly cadence is: what if some tickets aren't closed by then? 13:44:32 <Son_Goku> so at least from a Mageia/openSUSE PoV, I don't have an issue with it for deployments 13:44:33 <pingou> do we postpone them or do we postpone the release? 13:44:36 <cverna> then you wait for another month :P 13:44:51 <Son_Goku> pingou, if it can be done within a week or so, slipping isn't the worst 13:44:52 <pingou> cverna: which? the ticket or the release? :) 13:45:06 <bkabrda> pingou: once the releases are strictly time-based, everyone just has to accept that not all features will get there 13:45:10 <cverna> pingou: in my opinion the ticket 13:45:11 <bookwar> pingou: release whatever is available as soon as it it works 13:45:27 <pingou> ahah, I see different opinion there :) 13:45:30 <bkabrda> that's the eternal time-based vs feature-based release battle :) 13:45:35 <pingou> yup :) 13:45:39 <Son_Goku> the only current problem right now is that I still need to get EPEL rebased to pagure 5.x 13:45:52 <bkabrda> TBH I'd much rather see time-based releases 13:46:02 <bkabrda> since they decrease risk of upgrade breakages 13:46:09 <Son_Goku> I'd like a more predictable upgrade schedule myself 13:46:31 <pingou> alright, so 13:46:36 <bkabrda> time-based releases also make people split features into multiple small incremental changes 13:46:43 <Son_Goku> well, no, not really 13:47:07 <Son_Goku> it just means that you have a timeline of what release it'll get in 13:47:27 <Son_Goku> GitLab does more or less the same thing 13:47:30 <pingou> #proposal: Let's try a strict time-based release cadence for pagure which we can always revisit in a few months if needed 13:47:57 <cverna> +1 13:48:04 <bkabrda> +1 13:48:29 <fm-pagure> pagure.pull-request.flag.updated -- jenkins #1892 updated the flags on pagure#4107 with: "Build successful (commit: 9b7aa5c9)" https://pagure.io/pagure/pull-request/4107 13:48:37 <pingou> I'm honestly 0 on this, I see + and - to both approach and I'll adjust to what the community prefers 13:49:15 <Son_Goku> My current concern is that I don't think it will help improve getting feature development done and released at all 13:49:19 <Son_Goku> it might actually make it worse 13:49:38 <pingou> how so? 13:49:45 <Son_Goku> there are still a lot of "table stakes" features that do require a big chunk of work to do to integrate 13:50:00 <Son_Goku> and time based releases penalizes development of heavier features 13:50:18 <pingou> we could then scope them as "the" feature for that month 13:50:35 <Son_Goku> if we do that, then maybe it'd work out 13:51:02 <Son_Goku> I'm concerned about things like LDAP auth, Git LFS support, and other bigger features people need/want that are "hard" to implement 13:51:13 <pingou> and we're not like the entire Fedora project, if we need to skip a release one month because we're working on a bigger change, I don't think we should be afraid of this 13:51:40 <cverna> I think it is ok for these feature to take more than a couple of releases before they land in 13:51:56 <pingou> agreed 13:52:18 <Son_Goku> cverna, as long as the features are going to get developed, I don't have a problem with time-based releases 13:52:30 <pingou> worst case, we have a small .y release 13:52:31 <Son_Goku> what I worry about is features that look like they'll take longer not getting developed at all 13:53:03 <pingou> Son_Goku: I'm not worried about the release cadence for these, I think it'll be more a question of priorities 13:53:06 <Son_Goku> I don't really have an issue with time-based releases otherwise 13:53:21 <Son_Goku> hell, I run a GitLab instance for $DAYJOB 13:53:33 <Son_Goku> I more or less live and die by it for that anyway 13:53:57 <Son_Goku> but I do think more frequent releases are necessary 13:54:13 <cverna> Son_Goku: ok I see your point, I think we need to be ok with saying we add this feature in this month release but there is a big chance that it will be released in the next one 13:54:15 <Son_Goku> especially as bugs are found and fixed in master and take a while to get rolled out to Fedora infra because they're not in a released version 13:54:52 <Son_Goku> but if we're mindful of this, then +1 13:54:54 <pingou> so that's a +1 with a: we'll have to be careful when planning large changes 13:54:56 <pingou> ? 13:54:58 <Son_Goku> yep 13:55:05 <pingou> cool 13:55:19 <pingou> lenka: any thoughts on this? 13:55:26 <pingou> karsten: ^ ? 13:55:42 <cverna> I think it is worth trying, and keep in mind that nothing is set in stones, so if that does not work we can look at how to improve :) 13:56:03 <Son_Goku> sure 13:57:07 <pingou> bookwar: you seemed to be more feature-based and time-based, with this discussion, what do you think of the current proposal? 13:57:22 <karsten> I think real planning will become harder as it will be easier to just delay features until next month if it isn't finished yet. But if we keep an eye on that, we can make it work 13:57:41 <karsten> +1 13:58:04 <Son_Goku> yep 13:58:08 <pingou> karsten: it's also my worry, I'll guess we'll have to learn to scope our releases properly and not plan too much 13:58:18 <Son_Goku> and it also means we might want feature months 13:58:34 <Son_Goku> where development is (primarily) focused on a feature to get it out the door 13:58:51 <Son_Goku> that's one of the tricks GitLab does to get stuff even done in the first place 13:59:08 <pingou> makes sense 13:59:32 <pingou> we're reaching the top of the hour 13:59:40 <pingou> having not heard any -1 13:59:42 <bookwar> i am for time-based, i think once we acknowledge it, it will be easier to comply with it 14:00:04 <pingou> and I count: 1:0, and 5:+1 14:00:08 <pingou> so I guess it's: 14:00:15 <pingou> #agreed Let's try a strict time-based release cadence for pagure which we can always revisit in a few months if needed 14:00:33 <pingou> this leads to, when/how do we want to release? 14:00:43 <pingou> start of the month? end of the month? middle of the month? 14:00:50 <Son_Goku> well, GitLab always does theirs on the 22nd of each month 14:00:58 <Son_Goku> so we could just pick a day and just say, it always happens then 14:01:20 <cverna> today is the 7th 14:01:31 <cverna> every 7th of the month ? 14:01:46 <pingou> want to release today or 5.2 in a month? 14:02:07 <Son_Goku> their process basically boils down to, get everything firmed up in the first two weeks, bugfixing and validating in prod in the third week, and release in the 22nd 14:02:12 <cverna> ha forgot about 5.2 :) 14:02:29 <bkabrda> let's do 5.2 after the christmas break 14:02:31 <bookwar> release 5.2 and start counting ) 14:02:51 <cverna> ah ah thought choice :) 14:02:57 <pingou> so 5.2 on January 7th, 5.3 on Feb 7th? 14:03:08 <cverna> +1 14:03:12 <bkabrda> +1 14:03:15 <bookwar> +1 14:03:19 <karsten> +1 14:03:25 <pingou> gives us 2 weeks to finish the features and bug fix 14:03:36 <Son_Goku> and that means we can get markdown fixed :) 14:03:43 <pingou> potentially ;-) 14:03:57 <Son_Goku> well, the issue is Mageia 7 freeze is in the beginning of 2019 14:04:08 <pingou> for how long? 14:04:23 <Son_Goku> a month, the plan is to release mga7 for FOSDEM 14:04:38 <pingou> is Mageia already using pagure? 14:04:59 <Son_Goku> the plan is to deploy pagure overlaid on our software git post mga7 release 14:05:08 <Son_Goku> because then we'll have a mageia release with pagure in the repos and all the dependencies working 14:05:27 <cverna> so you will be able to deploy 5.3 or 5.4 :) 14:05:41 <Son_Goku> I can ship updates for pagure once we have a release with pagure in it 14:06:00 <pingou> Son_Goku: can you get 5.1.3 in before the freeze? 14:06:04 <Son_Goku> it's already in now 14:06:21 <pingou> ok, so I'm confused :) 14:06:22 <Son_Goku> but again, this markdown v3 thing is a problem 14:06:33 <pingou> backport the fix once we have it? 14:06:44 <Son_Goku> if the code isn't too churny, sure 14:06:59 <Son_Goku> but also the rebase merging thing is highly desired 14:07:04 <Son_Goku> and that's the big feature of 5.2 :) 14:07:06 <pingou> yup 14:07:13 <pingou> one of the nice one :) 14:07:21 <Son_Goku> indeed 14:07:42 <Son_Goku> a *lot* of people asked me about that 14:07:51 <Son_Goku> especially since pagure had the ability to block non-ff merges 14:08:12 <pingou> I still think the release on the 7th make sense 14:08:16 <Son_Goku> yeah, that's fine 14:08:20 <pingou> what would be your counter-proposal? 14:08:23 <Son_Goku> 7th of this month or next month? 14:08:37 <pingou> next, I don't think we're ready to release today 14:08:41 <Son_Goku> then it works for me 14:08:52 <pingou> alright, so: 14:08:54 <Son_Goku> if we can somehow get markdown v3 compat fixed for 5.2, that works 14:09:21 <pingou> #agreed: Release 5.2 on January 7th and monthly on the 7th after that 14:09:33 <pingou> which means: beta release on the 1st, deployed to stg 14:09:40 <pingou> final release on the 7th 14:09:53 <Son_Goku> and that means fedora infra should upgrade in prod right after 14:10:01 <pingou> the beta for 5.2 will have to be before the christmas break 14:10:02 <Son_Goku> we should let it delay for so long like we did for 5.0 14:10:15 <Son_Goku> err should NOT 14:11:01 <pingou> it wasn't the usual way 14:11:16 <pingou> we're reaching the 1h into the meeting 14:11:18 <cverna> +1 for 1st in stg and release 7th 14:11:31 <pingou> do we want to look at 5.3 or next time? 14:12:02 * cverna is happy to continue 14:12:28 * pingou has more time as well 14:12:53 <Son_Goku> I can continue too 14:13:08 <Son_Goku> my hard stop is in an hour, so I've got time 14:13:23 <pingou> bkabrda: bookwar: karsten ? 14:13:40 <bkabrda> pingou: sorry, I currently have standup, but it's almost over, so I'm ok with going on 14:13:55 <karsten> yes, lets continue 14:14:08 <pingou> alright :) 14:14:15 <pingou> #topic Planning 5.3 14:14:18 <pingou> #link https://pagure.io/pagure/roadmap/5.3/ 14:14:19 <pingou> #link https://pagure.io/pagure/issues 14:15:09 <pingou> so I'm going to add https://pagure.io/pagure/issue/4072 for 5.3 14:15:16 <pingou> as we discussed earlier 14:15:26 <fm-pagure> pagure.issue.edit -- pingou edited the milestone fields of ticket pagure#4072 https://pagure.io/pagure/issue/4072 14:15:35 <pingou> I think https://pagure.io/pagure/issue/4065 could also go in 14:15:48 <fm-pagure> pagure.issue.comment.added -- ngompa commented on ticket pagure#4038: "RFE: configurable default branch in project view" https://pagure.io/pagure/issue/4038#comment-545228 14:15:49 <pingou> and 4064 (same issue PR vs ticket) 14:15:50 * Ark74 will check the log 14:15:56 <fm-pagure> pagure.issue.edit -- pingou edited the milestone fields of ticket pagure#4065 https://pagure.io/pagure/issue/4065 14:16:00 <fm-pagure> pagure.issue.edit -- pingou edited the milestone fields of ticket pagure#4064 https://pagure.io/pagure/issue/4064 14:16:11 <pingou> hi Ark74 14:16:17 <Ark74> hello! 14:16:32 <Ark74> didn't know there are meetings 14:16:37 <cverna> for next time it would be nice to have priorities, so we can add weight to issues within a milestone 14:16:48 <karsten> 3668 about markdown-3, too 14:17:17 <pingou> karsten: indeed, though Son_Goku would like it in 5.2, worst case it'll land earlier :) 14:17:44 <fm-pagure> pagure.issue.edit -- pingou edited the milestone fields of ticket pagure#3668 https://pagure.io/pagure/issue/3668 14:17:52 <fm-pagure> pagure.issue.tag.added -- pingou tagged ticket pagure#3668: RFE https://pagure.io/pagure/issue/3668 14:18:01 <pingou> Ark74: it was announced on the list :) 14:18:25 * Ark74 should subscribe to the list :P 14:18:44 <cverna> How much of man power do we have for 5.3 ? :P 14:18:49 * cverna ducks 14:19:07 <fm-pagure> pagure.issue.comment.added -- pingou commented on ticket pagure#3929: "Documentation links do not work" https://pagure.io/pagure/issue/3929#comment-545240 14:19:15 <pingou> cverna: the usual :) 14:19:22 * cverna can commit to a few issues 14:20:03 <bookwar> i have one issue which I very much care about - the history on pull-request updates, so I can compare two different versions of the same pull request, after I amended the pr. bkabrda we have a ticket for it, don't we? 14:20:36 <Son_Goku> oh, that would be nice 14:20:43 <fm-pagure> pagure.issue.tag.added -- pingou tagged ticket pagure#4106: bug https://pagure.io/pagure/issue/4106 14:20:44 <fm-pagure> pagure.issue.edit -- pingou edited the milestone fields of ticket pagure#4106 https://pagure.io/pagure/issue/4106 14:20:57 <fm-pagure> pagure.issue.tag.added -- pingou tagged ticket pagure#4104: bug and easyfix https://pagure.io/pagure/issue/4104 14:20:58 <fm-pagure> pagure.issue.edit -- pingou edited the milestone fields of ticket pagure#4104 https://pagure.io/pagure/issue/4104 14:21:15 <pingou> bookwar: that'll be a tough one though :/ 14:21:21 <pingou> but definitely would be nice 14:21:26 <bkabrda> bookwar: hmm, I think I have an issue in my downstream tracker, but I haven't opened an upstream one yet 14:21:37 <pingou> (and here I go adding a couple of tickets to 5.2 :() 14:21:57 <bookwar> Son_Goku: this is one is the big roadblocks for Pagure's world domination :) 14:22:05 <fm-pagure> pagure.issue.tag.added -- pingou tagged ticket pagure#4103: RFE https://pagure.io/pagure/issue/4103 14:22:06 <fm-pagure> pagure.issue.edit -- pingou edited the milestone fields of ticket pagure#4103 https://pagure.io/pagure/issue/4103 14:22:22 <Son_Goku> bookwar, a few folks had asked me about pagure compatibility with git-send-email and git-request-pull 14:22:25 <bookwar> i don't think we should schedule it for the next release, but at list start designing it maybe 14:22:36 <fm-pagure> pagure.issue.tag.added -- pingou tagged ticket pagure#4050: easyfix https://pagure.io/pagure/issue/4050 14:22:37 <fm-pagure> pagure.issue.edit -- pingou edited the milestone fields of ticket pagure#4050 https://pagure.io/pagure/issue/4050 14:22:58 <cverna> bookwar: +1 with starting to look at implementation details in the 5.3 timeline 14:23:13 <fm-pagure> pagure.issue.edit -- pingou edited the milestone fields of ticket pagure#4049 https://pagure.io/pagure/issue/4049 14:23:19 <fm-pagure> pagure.issue.edit -- pingou edited the milestone fields of ticket pagure#4039 https://pagure.io/pagure/issue/4039 14:23:45 <pingou> so we're already at 10 tickets for 5.3 14:23:58 <pingou> all tagged as RFEs 14:24:05 <cverna> also there is devconf.cz in the middle of 5.3 14:24:14 <pingou> (most of them pretty small ones though and few are likely going to land in 5.2) 14:24:22 <pingou> cverna: devconf and fosdem 14:24:34 <cverna> yes so I think 5.3 will be a small release 14:25:08 <pingou> bookwar: https://pagure.io/pagure/issue/392 https://pagure.io/pagure/issue/751 14:25:16 <pingou> and https://pagure.io/pagure/issue/2168 14:25:25 <pingou> all relates to showing more context in Prs 14:26:02 <Son_Goku> bookwar, hah, we do have an RFE for it: https://pagure.io/pagure/issue/15 14:26:12 <fm-pagure> pagure.issue.edit -- pingou edited the milestone fields of ticket pagure#4019 https://pagure.io/pagure/issue/4019 14:26:56 <fm-pagure> pagure.issue.edit -- pingou edited the milestone fields of ticket pagure#4055 https://pagure.io/pagure/issue/4055 14:27:05 <Son_Goku> pingou, it's been on your radar for literally years :P 14:27:18 <Son_Goku> this should probably be also marked as an RFE 14:27:23 <bookwar> pingou: maybe consider a more generic issue, like introduce the version of the pull request as an entity, so it can hold its own set of flags, can be represented in the ui and so on 14:27:28 <fm-pagure> pagure.issue.edit -- pingou edited the milestone fields of ticket pagure#4029 https://pagure.io/pagure/issue/4029 14:28:03 <Son_Goku> and maybe now with the consideration for time based releases, we should have milestone pools for stuff being prioritized 14:28:17 <fm-pagure> pagure.issue.edit -- pingou edited the milestone fields of ticket pagure#3999 https://pagure.io/pagure/issue/3999 14:28:47 <pingou> so we have now 10 RFEs and 4 bugs in for 5.3 14:28:51 <Son_Goku> for example, GitLab has a "Next 1-3 months", "Next 3-6 months", etc. for tackling RFEs 14:28:55 <Son_Goku> and bugs 14:29:00 <pingou> I think that's a reasonable amount to start with 14:29:17 <Son_Goku> that lets them see what to prioritize and identify for upcoming releases 14:29:28 <cverna> Son_Goku: +1 14:29:34 <pingou> interesting idea 14:29:49 <Son_Goku> so we might want to emulate that so that people also can see ideas that might be desirable and contribute to, as well 14:29:50 <pingou> cverna: you also wanted priorities, is the default set enough? 14:30:12 <Son_Goku> if a feature gets done sooner, it can be integrated sooner :) 14:30:22 <pingou> clearly 14:30:35 <cverna> what is the default set :P ? 14:30:41 <pingou> low, normal, high 14:30:43 * cverna can remember 14:30:47 <cverna> can't* 14:30:52 <cverna> yes that works 14:31:16 <pingou> Son_Goku: https://pagure.io/pagure/roadmap 14:31:26 <pingou> cverna: priorities available 14:31:28 <Son_Goku> nice 14:31:56 <cverna> pingou++ 14:32:35 <pingou> I've also added the 5.4 14:33:16 <fm-pagure> pagure.issue.comment.added -- ngompa commented on ticket pagure#15: "pull-request/email integration" https://pagure.io/pagure/issue/15#comment-545264 14:33:50 <pingou> alright, so I think we're set for 5.3 for now 14:34:03 <pingou> #topic coming 3 months planning 14:34:19 <pingou> do we have any tickets we know we'll want in the coming 3 months/releases? 14:34:30 <Son_Goku> LDAP auth support :) 14:34:34 <pingou> I propose: https://pagure.io/pagure/issue/3811 14:34:52 <Son_Goku> I propose: https://pagure.io/pagure/issue/2938 14:34:53 <pingou> I had a start with the ldap support but the code I pulled from (ipsilon) is gplv3 14:35:15 <Son_Goku> isn't there a python module for ldap that you could use? 14:35:15 <fm-pagure> pagure.issue.edit -- pingou edited the milestone fields of ticket pagure#3811 https://pagure.io/pagure/issue/3811 14:35:41 <pingou> there is but it doesn't do everything, ipsilon uses it 14:35:44 <fm-pagure> pagure.issue.edit -- pingou edited the milestone fields of ticket pagure#2938 https://pagure.io/pagure/issue/2938 14:36:13 <pingou> ftr, I consider the "coming X months" milestone to be more flexible than when we assign to a specific release 14:36:20 <Son_Goku> that's the point ;) 14:36:43 <Son_Goku> those milestones are more about a pool of prioritized things to accomplish eventually 14:37:07 <Son_Goku> pingou, there's also quite a few complaints about the emails we send: https://pagure.io/pagure/issues?status=Open&search_pattern=email 14:37:48 <Son_Goku> readability, lack of emoji characters, and lack of HTML emails 14:38:18 <pingou> I find the text-based emails to be a feature not a bug :-p 14:38:30 <Son_Goku> pingou, I think it's more of a preference 14:38:37 <fm-pagure> pagure.issue.edit -- pingou edited the milestone fields of ticket pagure#3586 https://pagure.io/pagure/issue/3586 14:38:41 <Son_Goku> I know for me it actually makes it difficult to read some messages on some projects 14:38:49 <Son_Goku> so I'd propose this for prioritization: https://pagure.io/pagure/issue/3615 14:39:01 <Son_Goku> and maybe suggest that we make this a switch for users to toggle 14:39:06 <pingou> 6 months? 14:39:39 <cverna> +1 14:40:11 <fm-pagure> pagure.issue.comment.added -- pingou commented on ticket pagure#3525: "Pull Request: "Files changed" doesn't show all changes" https://pagure.io/pagure/issue/3525#comment-545278 14:40:14 <fm-pagure> pagure.issue.edit -- pingou edited the milestone fields of ticket pagure#3615 https://pagure.io/pagure/issue/3615 14:40:39 <pingou> https://pagure.io/pagure/issue/3525 I think this one got fixed by bkabrda when we changed the ordering of the commits when calculating diffs 14:40:48 <fm-pagure> pagure.issue.edit -- pingou edited the milestone fields of ticket pagure#3605 https://pagure.io/pagure/issue/3605 14:40:56 <fm-pagure> pagure.pull-request.comment.added -- ngompa commented on PR #4107 on pagure https://pagure.io/pagure/pull-request/4107#comment-70497 14:41:04 <bkabrda> pingou: yeah, that seems likely 14:41:24 <fm-pagure> pagure.pull-request.comment.added -- ngompa commented on PR #4107 on pagure https://pagure.io/pagure/pull-request/4107#comment-70498 14:41:49 <fm-pagure> pagure.issue.comment.added -- pingou commented on ticket pagure#3605: "PR link in a fork returns wrong URL when PR already exists" https://pagure.io/pagure/issue/3605#comment-545282 14:42:16 <pingou> I think this one is no longer valid: https://pagure.io/pagure/issue/3605 14:42:59 <Son_Goku> I'm pretty sure that's been fixed 14:43:14 <pingou> with the rewrite of our markdown integration, maybe we could look into: https://pagure.io/pagure/issue/3477 ? 14:43:30 <Son_Goku> yeah, definitely 14:43:46 <fm-pagure> pagure.issue.edit -- pingou edited the milestone fields of ticket pagure#3477 https://pagure.io/pagure/issue/3477 14:43:47 <fm-pagure> pagure.issue.comment.added -- pingou commented on ticket pagure#3477: "Don't expand #nnn to ticket links when already inside a link" https://pagure.io/pagure/issue/3477#comment-545283 14:44:01 <fm-pagure> pagure.issue.edit -- pingou edited the milestone fields of ticket pagure#3522 https://pagure.io/pagure/issue/3522 14:44:31 <fm-pagure> pagure.issue.edit -- pingou edited the milestone fields of ticket pagure#3476 https://pagure.io/pagure/issue/3476 14:44:54 <fm-pagure> pagure.issue.edit -- pingou edited the milestone fields of ticket pagure#3392 https://pagure.io/pagure/issue/3392 14:45:10 <fm-pagure> pagure.issue.edit -- pingou edited the milestone fields of ticket pagure#3391 https://pagure.io/pagure/issue/3391 14:45:23 <fm-pagure> pagure.issue.edit -- pingou edited the milestone fields of ticket pagure#3391 https://pagure.io/pagure/issue/3391 14:45:49 <fm-pagure> pagure.issue.edit -- pingou edited the milestone fields of ticket pagure#3350 https://pagure.io/pagure/issue/3350 14:45:57 <Son_Goku> I'm pretty sure the unicode filename thing should be fixed on python 3 hosted instances of pagure 14:46:26 <pingou> Son_Goku: https://pagure.io/pagure/issue/3298 afaik, I was never able to reproduce this one 14:47:17 <fm-pagure> pagure.issue.edit -- pingou edited the milestone fields of ticket pagure#2874 https://pagure.io/pagure/issue/2874 14:47:18 <fm-pagure> pagure.issue.comment.added -- pingou commented on ticket pagure#2874: "Merges commitmsg failed with `permission denied for relation pull_request_comments`" https://pagure.io/pagure/issue/2874#comment-545295 14:47:31 <fm-pagure> pagure.issue.comment.added -- pingou commented on ticket pagure#4072: "Running git hooks on server side" https://pagure.io/pagure/issue/4072#comment-545299 14:47:41 <Son_Goku> pingou, I don't think I can reproduce this anymore either 14:47:47 <Son_Goku> at least not since I deployed 5.0 stable 14:48:13 <fm-pagure> pagure.issue.edit -- pingou edited the milestone fields of ticket pagure#2759 https://pagure.io/pagure/issue/2759 14:48:25 <fm-pagure> pagure.issue.comment.added -- ngompa commented on ticket pagure#3298: "Users listed as global admins can't create groups or repos (pagure-git 37d153c)" https://pagure.io/pagure/issue/3298#comment-545301 14:48:26 <pingou> Son_Goku: Insufficient Data? 14:48:30 <Son_Goku> yep 14:48:35 <fm-pagure> pagure.issue.edit -- pingou edited the close_status and status fields of ticket pagure#3298 https://pagure.io/pagure/issue/3298 14:48:40 <fm-pagure> pagure.issue.comment.added -- pingou commented on ticket pagure#3298: "Users listed as global admins can't create groups or repos (pagure-git 37d153c)" https://pagure.io/pagure/issue/3298#comment-545303 14:49:23 <Son_Goku> how do you set close status? 14:49:48 <Son_Goku> I never figured out how to do that from the UI 14:49:51 <pingou> either at the top right or using the comment and close under the comment box 14:50:12 <pingou> Son_Goku: you have to create the different close_status in the settings of the project first 14:50:22 <Son_Goku> ah 14:50:25 <fm-pagure> pagure.issue.tag.added -- pingou tagged ticket pagure#3919: bug https://pagure.io/pagure/issue/3919 14:50:26 <fm-pagure> pagure.issue.edit -- pingou edited the milestone fields of ticket pagure#3919 https://pagure.io/pagure/issue/3919 14:50:43 <pingou> so we have 15 tickets for 5.3 14:50:46 <pingou> 1 for 5.4 14:50:57 <pingou> 10 roughly schedule in the coming 3 months 14:51:01 <pingou> 2 in the coming 6 months 14:51:13 <pingou> (and still 11 tickets for 5.2) 14:51:56 <cverna> yeah might be a few 5.2 slipping into 5.3 14:52:16 <pingou> and vice-versa :) 14:52:34 <cverna> :) 14:52:51 <fm-pagure> pagure.pull-request.comment.added -- pingou commented on PR #4105 on pagure https://pagure.io/pagure/pull-request/4105#comment-70499 14:53:05 <fm-pagure> pagure.git.receive -- pingou pushed 1 commit to pagure (master) https://pagure.io/pagure/branch/master 14:53:06 <fm-pagure> pagure.pull-request.comment.added -- pingou commented on PR #4105 on pagure https://pagure.io/pagure/pull-request/4105#comment-70500 14:53:07 <fm-pagure> pagure.pull-request.closed -- pingou merged pull request #4105 on pagure https://pagure.io/pagure/pull-request/4105 14:53:28 <pingou> I think we should stop the meeting here 14:53:41 <cverna> yep :) 14:53:46 <pingou> we have organized the project a little more cleanly 14:53:54 <pingou> we have a good set of tickets for 5.2 and 5.3 14:54:09 <pingou> I'll try to send a summary of the meeting to the list 14:54:27 <cverna> thanks pingou for chairing and organizing 14:54:31 <pingou> and I was thinking we may want to add a blob to the documentation about the release process/cadence 14:54:37 <pingou> and versioning policy 14:54:44 <bookwar> pingou: newbie question - which list is it? :0 14:54:50 <pingou> pagure-devel :) 14:54:58 <Son_Goku> and we should try to do these meetings maybe more frequently than when we release :) 14:55:02 <pingou> bookwar: https://lists.pagure.io/archives/list/pagure-devel%40lists.pagure.io/ 14:55:10 <Son_Goku> I'd say every two weeks is probably a good checkpoint 14:55:20 <Son_Goku> if every week would be too hard 14:55:25 <pingou> Son_Goku: I'd like us to use the list a little more 14:55:41 <pingou> so might be worth to do monthly meeting like the day after the release (so the 8th) 14:55:43 <bookwar> pingou: thanks 14:55:43 * cverna just subscribed to THE list 14:56:07 <pingou> and do list-based checkup half-way through the release 14:56:15 <pingou> so around the 22nd 14:56:53 <fm-pagure> pagure.git.receive -- pingou pushed 4 commits to pagure (filter_close_status) https://pagure.io/pagure/branch/filter_close_status 14:56:54 <fm-pagure> pagure.pull-request.comment.added -- pingou commented on PR #4097 on pagure https://pagure.io/pagure/pull-request/4097#comment-70501 14:56:57 <fm-pagure> pagure.issue.comment.added -- sharkcz commented on ticket pagure#3605: "PR link in a fork returns wrong URL when PR already exists" https://pagure.io/pagure/issue/3605#comment-545313 14:57:41 <fm-pagure> pagure.pull-request.flag.added -- jenkins #1893 flagged pagure#4097 with "Build in progress (commit: f6cc186b)" https://pagure.io/pagure/pull-request/4097 14:57:43 <fm-pagure> pagure.issue.comment.added -- pingou commented on ticket pagure#3605: "PR link in a fork returns wrong URL when PR already exists" https://pagure.io/pagure/issue/3605#comment-545314 14:57:44 <Son_Goku> pingou, so I'm also hoping to try to get pagure into openSUSE Leap 15.1 14:58:24 <pingou> I think we all deserve a coffee break so I'm going to close the meeting 14:58:26 <pingou> #endmeeting