15:00:00 <bowlofeggs> #startmeeting FESCO (2019-01-07)
15:00:01 <zodbot> Meeting started Mon Jan  7 15:00:00 2019 UTC.
15:00:01 <zodbot> This meeting is logged and archived in a public location.
15:00:01 <zodbot> The chair is bowlofeggs. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:01 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:01 <zodbot> The meeting name has been set to 'fesco_(2019-01-07)'
15:00:02 <bowlofeggs> #meetingname fesco
15:00:02 <zodbot> The meeting name has been set to 'fesco'
15:00:04 <bowlofeggs> #chair nirik, bowlofeggs, jforbes, zbyszek, tyll, sgallagh, contyk, mhroncok, otaylor
15:00:04 <zodbot> Current chairs: bowlofeggs contyk jforbes mhroncok nirik otaylor sgallagh tyll zbyszek
15:00:06 <bowlofeggs> #topic init process
15:00:12 <sgallagh> .hello2
15:00:13 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
15:00:15 <jforbes> .hello2
15:00:16 <zodbot> jforbes: jforbes 'Justin M. Forbes' <jforbes@redhat.com>
15:00:24 <mhroncok> .hello2
15:00:26 <zodbot> mhroncok: Sorry, but you don't exist
15:00:35 <mhroncok> zodbot: yeah, I know
15:00:36 <contyk> .hello psabata
15:00:39 <zodbot> contyk: psabata 'Petr Šabata' <psabata@redhat.com>
15:00:42 <mhroncok> .hello2 churchyard
15:00:43 <nirik> morning
15:00:43 <zodbot> mhroncok: Sorry, but you don't exist
15:00:50 <bowlofeggs> mhroncok: you might be able to use .hello churchyard
15:00:52 <bowlofeggs> (no 2)
15:00:54 <tyll> .hello till
15:00:55 <zodbot> tyll: till 'Till Maas' <opensource@till.name>
15:00:56 <mhroncok> .hello churchyard
15:00:58 <zodbot> mhroncok: churchyard 'Miro Hrončok' <mhroncok@redhat.com>
15:01:02 <mhroncok> magic
15:01:09 <contyk> and there are I thought you were just the product of my imagination
15:01:10 <bowlofeggs> i think hello2 only works if your IRC and FAS are the same
15:01:14 <bowlofeggs> haha
15:01:27 <otaylor> .hello2
15:01:28 <zodbot> otaylor: otaylor 'Owen Taylor' <otaylor@redhat.com>
15:01:59 <bowlofeggs> cool we have quorum
15:02:06 <bowlofeggs> let's get this party started
15:02:12 <bowlofeggs> we can party like it's 2019
15:02:30 <bowlofeggs> #topic #2021 F30 Change: Migrate Python-based Nautilus extensions to
15:02:31 <bowlofeggs> Python 3
15:02:33 <bowlofeggs> .fesco 2021y
15:02:33 <zodbot> bowlofeggs: Error: '2021y' is not a valid integer.
15:02:35 <bowlofeggs> haha
15:02:39 <bowlofeggs> .fesco 2021
15:02:41 <zodbot> bowlofeggs: Issue #2021: F30 Change: Migrate Python-based Nautilus extensions to Python 3 - fesco - Pagure.io - https://pagure.io/fesco/issue/2021
15:02:48 <sgallagh> Are we reviewing OpenSSL code now?
15:02:50 <sgallagh> :-P
15:03:34 <mhroncok> huh a postman. give me 2 mins
15:03:48 <sgallagh> So, am I right in the summary that what we're actually being asked is "Is it okay if functionality is dropped if we cannot migrate some of the extensions?"
15:03:51 <bowlofeggs> haha
15:04:02 <bowlofeggs> sgallagh: i think that's the current questio
15:04:04 <bowlofeggs> n
15:04:27 <bowlofeggs> and i am fine with dropping functionality for plugins that don't migrate to python 3
15:04:30 <bowlofeggs> they've had 10 years
15:04:32 <jforbes> sgallagh: Yes, it seems that way, but the biggest risk is also to user installed extensions that can't be fixed in packages anyway
15:04:41 <otaylor> Definitely think that we can't block progress to python3 on some extension that was done years ago, is barely maintained or unmaintained, and we have no idea how many people are using.
15:05:00 <jforbes> I am under the intentionally naive assumption that maintained packages are maintained
15:05:19 <otaylor> jforbes: I mean upstream
15:05:19 * nirik is +1 to the change. time marches on.
15:05:29 <bcotton> jforbes++
15:05:29 <zodbot> bcotton: Karma for jforbes changed to 2 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
15:05:42 <zbyszek> sorry
15:05:46 <bowlofeggs> proposal: Accept the proposed change
15:05:51 <contyk> +1
15:05:53 <otaylor> +1
15:05:53 <mhroncok> back
15:05:56 <sgallagh> Was advance warning given to extension maintainers about Python 3 support going away?
15:05:57 <jforbes> +1
15:05:59 <sgallagh> otaylor: ^^
15:05:59 <bowlofeggs> zbyszek: we're on https://pagure.io/fesco/issue/2021
15:06:07 <zbyszek> I voted in the ticket
15:06:12 <zbyszek> Still +1
15:06:36 <nirik> +1 (but yeah, direct mail to maintainers would be good)
15:06:36 <mhroncok> +1 on the change
15:06:47 <mhroncok> not sure if the wording there needs to change a bit
15:06:49 <bowlofeggs> sgallagh: lots of discussion has happened on the devel list for years about python 2 going away
15:07:20 <sgallagh> bowlofeggs: In Fedora in general, but I'm wondering if GNOME did the same on their end
15:07:23 <tyll> +1 in general, but IMHO it would be nice if the extension maintainers would be provided a test command to check if their extensions are python3 ready or maybe a test build (COPR) to check it
15:07:25 <otaylor> sgallagh: I'm not aware of such notice - I think this change proposal could be considered to be such notice - I presume the change owners will reach out when doing rebuilds. I don't think that a multi-cycle process is necessary.
15:07:56 <bowlofeggs> sgallagh: oh you mean upstream, gotcha
15:08:21 <sgallagh> I'm mostly just hesitating because I don't like putting people into "A lack of planning on our part now constitutes an emergency on yours" situations.
15:08:35 <bowlofeggs> ok i count +8
15:08:58 <bowlofeggs> holy crap, do we have all 9 of us today?
15:09:11 <zbyszek> sgallagh: the Change page is essentially 6 months of advance notice.
15:09:13 <sgallagh> I'm a symbolic 0 vote, I guess.
15:09:20 <bowlofeggs> cool
15:09:32 <sgallagh> zbyszek: Isn't this for F30, which hits Freeze in like two months?
15:09:39 <sgallagh> Feature Freeze, I mean
15:09:45 <bowlofeggs> #agree APPROVED (+8, 1, -0)
15:10:01 <sgallagh> Almost to the day, in fact.
15:10:15 <jforbes> sgallagh: I don't think it is possible for someone to maintain a python anything and not have known that python 2 was going away, and python 3 was a thing which might require some changes... For a very long time
15:10:30 <mhroncok> the contingency plan is: Continue shipping builds of nautilus-python based on Python 2.
15:10:31 <bowlofeggs> do we want to stay on this topic longer, since we have a vote?
15:10:33 <sgallagh> jforbes: The vote is done.
15:10:41 <bowlofeggs> (long agenda today)
15:10:42 <sgallagh> I specifically said I wasn't voting against
15:10:42 <mhroncok> I think we are good, in worst case, they will just roll it back
15:11:10 <zbyszek> sgallagh: a fix to make an extension usable at all would be considered a fix, so it can be pushed in at any point, even after branching.
15:11:29 <bowlofeggs> #topic #2027 RFC: Module lifecycles
15:11:31 <bowlofeggs> .fesco 2027
15:11:32 <zodbot> bowlofeggs: Issue #2027: RFC: Module lifecycles - fesco - Pagure.io - https://pagure.io/fesco/issue/2027
15:11:40 <zbyszek> It's more like 4-5 months, but I still think that's plenty of time to do soem python2→3 porting.
15:12:38 <mhroncok> 2027 is fresh, wasn't able to read it all yet
15:12:58 <mhroncok> (at least for me I mean)
15:13:57 <contyk> not super fresh but considering the holidays...
15:13:58 <otaylor> It seems like asamalik is looking more for feedback than a vote of approval?
15:14:16 <contyk> indeed
15:14:28 <bowlofeggs> in general i'm fine with the EOL being specified by date and release (which i think is the proposal), but yeah i'm not sure where that data should be stored
15:14:38 <bowlofeggs> there is an FPDC project by cverna that's intended to replace PDC
15:14:47 <bowlofeggs> that might be a good place to store that info
15:15:02 <otaylor> I think that the more that is in dist-git, and the less that is magically updated by releng via ticket, the better
15:15:07 * nirik nods. noted that in the ticket
15:15:11 <tyll> I would prefer it to be stored in something that has a nice API instead of just GIT
15:15:19 <mhroncok> git is a nice API
15:15:43 <mhroncok> better to store it in GIT and build a different API ont op of that
15:15:44 * asamalik peeks in and waves
15:15:46 <bowlofeggs> i don't have strong feelings on git vs. http API
15:15:48 <mhroncok> rather than magic
15:15:52 <contyk> I don't like the idea of storing exact dates because they're not set in stone
15:16:02 <nirik> well, we already use pdc for data today...
15:16:13 <otaylor> So that's my concern about FPDC - it's not self service (if it's like PDC), and it's not stored "with the code"
15:16:27 <asamalik> yeah I'm proposing either a date or a Fedora release (or nothing)
15:16:32 <zbyszek> I like the idea of storing the data in dist git.
15:16:34 <tyll> mhroncok, you cannot do easily access the information in reverse, i.e. give me everything that is EOL with F30 with GIT but need to fetch every repo and look there
15:16:37 <jforbes> There is the question of "what if fedora release slips past module EOL" which I think the answer is module EOL also slips
15:16:41 <tyll> this is not a nice API
15:16:48 <contyk> note we can store it directly in modulemd
15:16:58 <zbyszek> We can always build indexes on top of dist git, to provide a nice and quick API.
15:17:02 <asamalik> jforbes: yes
15:17:07 <otaylor> asamalik: The interaction of dates with fedora releases is a bit unclear to me - but I should probably comment on that in your issue
15:17:48 <bowlofeggs> otaylor: i find that self-service argument compelling. i dislike how much we lost when we switched away from pkgdb
15:17:53 <nirik> if we are suggesting moving everything from PDC to git and scrapping all the FPDC work, I'd really perfer a larger discussion on that... like with the people doing the fpdc work at least
15:18:09 <asamalik> otaylor: the idea was that you either want it to go EOL with a particular Fedora release regardless of a date, before a particular date regardless of what release that would be
15:18:14 <mhroncok> if I have a package from a module installedd and the nodule goes EOL mid release, what actually happens?
15:18:28 <nirik> where would you put in dist-git the current releases, current devel releases?
15:18:45 <jforbes> mhroncok: you no longer have any security coverage
15:18:47 <bowlofeggs> ah, but tyll's counter argument about querying for "what is EOL with F30" is also compelling
15:18:47 <contyk> mhroncok: EOL means you're not getting any more updates
15:19:26 <tyll> zbyszek, we could but nobody is building these indexes... we lost them already for orphaned/retired pkgs when pkgdb was removed for example
15:19:31 <otaylor> asamalik: More like what happens if your module stream goes eol during a release - what is the user experience? Presumably the *default* stream of a release can't go eol. I'm not sure I have well formulated questions at this point :-)
15:19:54 <mhroncok> that
15:20:08 <asamalik> otaylor: I'd like it to make it so that this can't happen
15:20:10 <bowlofeggs> what if FPDC was the thing that built the index that zbyszek proposed?>
15:20:18 <contyk> should we give it another week? so that everyone has enough time to read it
15:20:25 <mhroncok> please
15:20:30 <asamalik> contyk: +1
15:20:39 * nirik would like to get FPDC folks to chime in.
15:20:55 <contyk> nirik: can you ping them in the ticket?
15:21:02 <nirik> sure.
15:21:14 <otaylor> nirik: I think there's some distinction between distro level metadata - and metadata about individual packages and modules - in terms of what works well.
15:21:20 <nirik> (tickets aren't great for discussion tho, but I can and we can spill over to a list)
15:21:46 <nirik> I don't know off the top of my head what pdc data we are currently using.
15:21:51 <bowlofeggs> contyk: +1
15:22:28 <otaylor> nirik: If they are supportive about putting this data into the FPDC, I'd like to hear about what the maintainer experience is around updating it (and viewing it!)
15:23:11 <bowlofeggs> any objections to deferring a week?
15:23:23 <jforbes> none here
15:23:39 <nirik> yes, please defer
15:23:42 <bowlofeggs> ok, let's move on
15:23:49 <bowlofeggs> #topic #2028 RFC: Stream branch ownership for packages & modules
15:23:51 <bowlofeggs> .fesco 2028
15:23:52 <zodbot> bowlofeggs: Issue #2028: RFC: Stream branch ownership for packages & modules - fesco - Pagure.io - https://pagure.io/fesco/issue/2028
15:23:59 <contyk> same thing here, I guess
15:25:20 <bowlofeggs> contyk: you think we should defer to next week you mean/
15:25:32 <contyk> bowlofeggs: yeah
15:25:38 <contyk> I filed them together
15:25:49 <contyk> would be strange if people read one and not the other :)
15:26:24 <mhroncok> I tend to share otaylor's concerns form the ticket
15:26:51 <contyk> the proposal is that you become a maintainer of the package as soon as you use it
15:27:01 <contyk> there's no "time passes" between the second and the third bulletpoints
15:27:11 <nirik> yeah, discoverability is not good here with current setup... but that could be of course improved.
15:27:27 <bowlofeggs> yeah i think i also find otaylor's comment compelling. "explicit is better than implicit" -zen of python
15:27:41 <nirik> I guess bugs and such would always be filed on the module, not on the specific rpms?
15:28:04 <contyk> I think we need to allow both
15:28:09 <mhroncok> CVE's for example are filled on rpms and the "main admin" of the component is assigned
15:28:37 <mhroncok> or at least that is what happened this time with python-django
15:28:45 <nirik> so then how do we know...
15:29:06 <otaylor> contyk: I think I might have a different perspective, since it's much more reasonalbe to "cherry-pick versions" for a module deployed as a flatpak, rather than one installed directly via rpms onto a system
15:29:18 <tyll> nirik, how do users know that they need to file a bug for the module instead of the package?
15:29:38 <jforbes> So, would that main that it is the rpm admin's responsibility to make sure that module maintainers are aware of CVEs? That seems sub-optimal
15:29:44 <nirik> not sure. ;) I guess they don't currently
15:30:04 * nirik wishes we had branch ownership back
15:30:07 <contyk> otaylor: I understand, but I also wouldn't expect people maintaining stream branches if they're not delivering them anywhere
15:30:09 <otaylor> contyk: In the direct-install case, sharing a package between different modules has to be rare
15:30:34 <contyk> otaylor: agreed
15:31:05 <otaylor> contyk: At some point, there was an idea that we'd be moving much of fedora to stream branches, as I recall
15:31:35 <mhroncok> nirik: +1
15:31:49 <contyk> I think the scenarios here are a) the package is also delivered as ursine, in which case it has a primary maintainer, b) the package is only delivered in modules, one or more, in which case there's no primary maintainer
15:32:12 <contyk> and c), the package isn't delivered anywhere at the moment but could be adopted by someone; it probably isn't maintained at all
15:32:36 <tyll> contyk, the package could also be retired (at least in the ursine case, not sure how this works for modules)
15:32:36 <nirik> for b and c how can we tell who should deal with issues on it?
15:32:56 <zbyszek> I wonder if we could treat case b the same as a, i.e. ask people to requests ACLs if they put the package in a stream and want to help maintain in
15:32:57 <mhroncok> b) the package is only delivered in modules, one or more, in which case there's no primary maintainer - why not?
15:33:17 <contyk> nirik: for b, you could look up what modules include the component and... pick one? I don't know
15:33:23 <contyk> nirik: for c, it's effectively orphaned, I'd say
15:33:56 <mhroncok> (this is getting nowhere, next week?)
15:34:01 <nirik> do we expect users to do that? or maintainers?
15:34:07 <nirik> yeah, we can punt
15:34:36 <contyk> next week :)
15:34:42 <zbyszek> +1
15:34:57 <tyll> +1
15:34:58 <jforbes> +1
15:35:13 <bowlofeggs> +1
15:35:18 <otaylor> +1 next week - I think there's a lot to discuss and related to the other ticket we've punted.
15:35:23 <bowlofeggs> cool, let's move on
15:35:44 <bowlofeggs> #topic #2033 F30 Change: Deprecate Sonatype OSS Parent
15:35:46 <bowlofeggs> .fesco 2033
15:35:47 <zodbot> bowlofeggs: Issue #2033: F30 Change: Deprecate Sonatype OSS Parent - fesco - Pagure.io - https://pagure.io/fesco/issue/2033
15:36:14 <bowlofeggs> should we discuss these java changes as a group?
15:36:23 <zbyszek> please
15:36:24 <bowlofeggs> or just go through each?
15:36:24 * nirik nods.
15:36:29 <mhroncok> group please
15:36:37 <jforbes> This is one of several tickets tied together by sgallagh's comment in https://pagure.io/fesco/issue/2036
15:37:07 <sgallagh> Yeah, I realize the current policy is to do the virtual Provides, but as no tools currently exist to read them, it seems wasteful to me.
15:37:08 <bowlofeggs> sgallagh: i don't personally mind the virtual provides
15:37:19 <otaylor> bowlofeggs: It seems to me that the actual discussion is almost entirely about deprecated() and https://docs.fedoraproject.org/en-US/packaging-guidelines/deprecating-packages/
15:37:32 <contyk> mizdebsk says the java sig will use these
15:37:38 <mhroncok> sgallagh: tool sbroken shouldn't block this
15:37:40 <sgallagh> Yeah, I think it's fine to declare all these packages deprecated and find ways to avoid adding new content with them
15:37:41 <mhroncok> *tools
15:37:57 <sgallagh> But I think growing the repodata for zero benefit is ridiculous
15:38:02 <mhroncok> FedoraReview is getting new devs and this might be solved soon
15:38:04 <sgallagh> Our repodata is already far too large
15:38:23 <bowlofeggs> sgallagh: aren't we talking about relatively little data here in these proposals though?
15:38:28 <sgallagh> mhroncok: I'd rather that we maintain this deprecation data in a separate source (maybe FPDC?)
15:38:32 <zbyszek> sgallagh: the few deprecated() lines are hardly measurable compared to the total size
15:38:41 <bowlofeggs> i'd think just a few tens of bytes per package?
15:39:14 <sgallagh> For today, sure.
15:39:26 <mhroncok> proposal...
15:39:33 <zbyszek> sgallagh: so you want to reject a proposal that builds on existing tooling in favour of something which is currently in early development?
15:39:39 <sgallagh> If this remains the policy (particularly as the Python2->3 migration happens... or Golang changes...) isn't it going to grow?
15:39:41 <contyk> deprecated packages won't be kept forever, so there's that ;)
15:39:49 <sgallagh> zbyszek: No, you misunderstand.
15:39:51 <mhroncok> we approve as is, sgallagh to porpose laternate solution for deprecated() later, we can fix the packages thta provide deprecated() once the new thing is agreed
15:40:00 <nirik> mhroncok: +1
15:40:03 <sgallagh> mhroncok: I'm fine with that. +1
15:40:06 <tyll> mhroncok, +1
15:40:07 <bowlofeggs> mhroncok: +1
15:40:07 <otaylor> contyk: There doesn't seem to be any mechanism/plan to remove deprecated packages :-)
15:40:15 <zbyszek> +1 too
15:40:21 <mhroncok> +1 obviously
15:40:23 <otaylor> mhroncok: +1
15:40:24 <sgallagh> mhroncok: Though I'd really like to ask for a hard sunset date on these
15:40:27 <contyk> +1
15:40:31 <jforbes> +1 as well
15:40:40 <bowlofeggs> cool, that's +9 i think
15:40:42 * nirik would prefer working with FPC to change this, since they approved it...
15:40:52 <bowlofeggs> do we want to count that vote for all teh java packages?
15:40:53 <zbyszek> sgallagh: that's also allowed in the FPC guidelines, you can Provides: deprecated() = YYYYMMDD
15:41:05 <bowlofeggs> all the java tickets i mean?
15:41:08 <jforbes> bowlofeggs: my vote would apply to all of them
15:41:09 <sgallagh> bowlofeggs: Yes
15:41:12 <bowlofeggs> cool
15:41:13 <nirik> yep
15:41:19 <zbyszek> yes
15:41:24 <mhroncok> yes
15:41:26 <bowlofeggs> #action sgallagh will propose a new way to deprecate packages
15:41:27 * sgallagh loathes bit-rotting packages.
15:41:36 <bowlofeggs> #agreed APPROVED (+9, 0, -0)
15:41:50 <bowlofeggs> ok, i'm going to skip the other java topics
15:41:53 <bowlofeggs> moving along…
15:42:02 <bowlofeggs> #topic #2038 Rebase of systemd in F29
15:42:04 <bowlofeggs> .fesco 2038
15:42:06 <zodbot> bowlofeggs: Issue #2038: Rebase of systemd in F29 - fesco - Pagure.io - https://pagure.io/fesco/issue/2038
15:42:21 <contyk> let's see what 241 brings
15:42:51 <mhroncok> I'd very much liek to have it in rawhide ofr at least a few weeks
15:42:54 <contyk> I'm glad the regressions were identified before we acked it
15:43:08 <mhroncok> new regressions can be found in 241
15:43:14 <contyk> yep
15:43:35 <sgallagh> I feel like the experience we saw with 240 is pretty strong evidence that a blanket approval should *not* be granted, honestly.
15:43:41 <mhroncok> I don't mind updating it in F29 if it's handled very carefully, having it in rawhide for some time is IMHO a must
15:43:50 <otaylor> I'm not specifically against this, since I think zbyszek is in the best position to judge his own package, but I'm *generally* against rebases of major system components for stable releases, since it's only a matter of time until we screw up and cause huge problems for our users and we don't have the mechanisms in place to catch/recover from that
15:44:14 <sgallagh> It's too critical of a system
15:44:18 <zbyszek> mhroncok: waiting in rawhide was always the plan
15:44:22 <sgallagh> I'm fine with systemd maintainers coming and asking for rebases, but I don't think I want to pre-approve them.
15:44:42 <jforbes> sgallagh: +1
15:44:43 <sgallagh> (sorry if that went through twice; I'm getting frequent disconnects today and I wasn't sure if it sent)
15:44:52 <bowlofeggs> i'm actually ok with the proposal despite the risk, because i care more about it being backwards compatible and zbyszek documented the various incompatibilites and workarounds for all of them
15:44:55 <mhroncok> (sgallagh: BTW current rawhide has 17 deprecated() packages, 7 have python2 in the name)
15:45:07 <zbyszek> otaylor: the problem is that we don't have enough man power to usefully backport fixes to previous Fedora releases
15:45:16 <zbyszek> Or to put it differently,
15:46:13 <zbyszek> I think the time spent to backport patches would be better spent using the same version in multiple Fedora releases and spending more time on testing that one version.
15:46:26 <contyk> +1
15:46:35 <otaylor> zbyszek: I wonder if those fixes actually matter that much? Generally, once someone gets f29 working, it's working.
15:46:36 <contyk> well, sort of
15:46:49 <contyk> as long as all the versions are backwards compatible
15:47:08 <bowlofeggs> i haven't personally be experiencing issues i know of with systemd in f29
15:47:10 <jforbes> zbyszek: I can completely sympathize with that. Though a rebase has to be treated a bit differently than a regular update.  On the kernel side, we do a test day for rebases. It actually gets a decent amount of traction, and helps. 4.19 excluded, where we had low turnout for some reason
15:47:58 <mhroncok> test day, maybe even promoted on Fedora magazine and social media migth be a great idea for this
15:47:59 <otaylor> zbyszek: I'm  not saying that each fix isn't important to some group of people, but there's a real risk/benefit tradeoff
15:48:58 <jforbes> mhroncok: Yes, promoting the test day made a huge difference in turnout. sumantro is a huge help in coordinating all of that
15:49:24 <zbyszek> I guess I should talk with sumantro if organizing something like this for systemd would make sense
15:50:13 * nirik nods
15:50:24 <jforbes> It may, or may not. On the kernel side, we have a lot of hardware that wouldn't get tested otherwise, but it has been more useful than just updates-testing.
15:50:29 <mhroncok> zbyszek: can we deffer to deicsion after this is in rawhide?
15:50:50 <bowlofeggs> the kernel also has an easy way to boot the old one when there's a problem (though i've never needed to use it)
15:51:10 <jforbes> true
15:51:25 <zbyszek> mhroncok: yeah, let's defer for now
15:51:30 * sgallagh has needed that feature on numerous occasions
15:51:36 <bowlofeggs> cool, anyone opposed to deferral/
15:51:39 <bowlofeggs> ?
15:51:42 <sgallagh> Though, admittedly, not in the last year or two
15:51:51 <bowlofeggs> well i should s/never/never on fedora/
15:52:06 * bowlofeggs runs gentoo at home too and has made plenty of non-bootable kernels there haha
15:52:43 <bowlofeggs> ok, let's move on
15:52:54 <sumantro> zbyszek, I am all game :)
15:52:56 <bowlofeggs> though deffering so much stuff only makes next week's meeting longer ☺
15:53:09 <bowlofeggs> #topic #2045 Unresponsive maintainer: Pradeep Kilambi
15:53:11 <bowlofeggs> .fesco 2045
15:53:12 <zodbot> bowlofeggs: Issue #2045: Unresponsive maintainer: Pradeep Kilambi - fesco - Pagure.io - https://pagure.io/fesco/issue/2045
15:53:19 <zbyszek> sumantro: thanks, let's talk later
15:53:54 <sumantro> zbyszek, sure :)
15:54:02 <sgallagh> OK, we gave Pradeep some extra time and no response.
15:54:14 <sgallagh> +1 to proceed with the non-responsive maintainer process
15:54:16 <bowlofeggs> i'm +1 to accept the ticket
15:54:19 <contyk> +1
15:54:23 <zbyszek> +1
15:54:27 <jforbes> +1
15:54:33 <mhroncok> +1
15:54:34 <tyll> +1
15:54:38 <nirik> so... what exactly does that mean here?
15:54:47 <nirik> reassign just this one package?
15:55:08 <bowlofeggs> nirik: yeah i think that's what's being asked for. i guess we could consider orphaning his packages too?
15:55:35 <nirik> right, if they are not responsive at all.... all their other packages are likely not attended either
15:55:39 <mhroncok> orphan it all
15:55:39 <mhroncok> (if there are more packages actually)
15:55:53 <contyk> feels like it's a request to trigger the process, so all of it, yes
15:55:57 <nirik> they have 14 packages
15:56:13 <nirik> well, I guess they aren't poc on all.
15:56:16 <bowlofeggs> proposal: orphan all of pradeep's packages
15:56:20 <mhroncok> +1
15:56:22 <nirik> anyhow, +1 to reassign this one and orphan the rest.
15:56:28 <contyk> bowlofeggs: +1
15:56:45 <jforbes> +1 seems improbable that a maintainer is unresponsive for just one package
15:56:50 <contyk> nirik: the reporter said they weren't interested in maintaing it
15:57:10 <contyk> or... not that either
15:57:15 <contyk> it's not what they are pursuing
15:57:21 <bowlofeggs> contyk: the reporter did ask for commit access in their initial post
15:57:25 <zbyszek> https://src.fedoraproject.org/user/pkilambi shows one commit in February and one in July
15:57:48 <bowlofeggs> though i guess we could orphan it too if the reporter doesnt' want it
15:57:53 <bowlofeggs> i see that they said that in a later comment
15:57:57 <zbyszek> No, the reported asked for access
15:58:27 <mhroncok> zbyszek: "As I said, I'm really only looking to push an update here, not ownership per se. "
15:58:31 <bowlofeggs> we could give it tot he reporter anyway under the "you touched it last!" rule
15:58:50 <mhroncok> it's easier to orphan the package if the reporter doesn't want it
15:58:53 <bowlofeggs> well if they don't want it, let's just orphan it too then
15:58:54 <nirik> but of course without a point of contact it will get retired. ;)
15:59:05 <bowlofeggs> proposal: orphan all of pradeep's packages, including this one
15:59:09 <mhroncok> it doesn't involve releng tickets
15:59:09 <mhroncok> I say we give it to them and say tehy are free to ropahn it
15:59:15 <sgallagh> Well, without a POC it'll be in the nag-list and someone will either pick it up or it'll die.
15:59:16 <zbyszek> +1
15:59:20 <nirik> +1
15:59:23 <sgallagh> +1
15:59:28 <mhroncok> +1 (whatever)
15:59:33 <bowlofeggs> haha
15:59:39 <jforbes> +1
15:59:47 <contyk> +1 still
16:00:07 <bowlofeggs> otaylor, tyll: ?
16:01:00 <otaylor> bowlofeggs: I don't feel I have a great sense of the unmaintained package process, at this point, so would rather abstain +0
16:01:05 <bowlofeggs> ok
16:01:38 <zbyszek> Yeah, looking at the various packages of pkilambi, there has been no significant activity since 2 years ago
16:01:45 <bowlofeggs> #agree orphan all of pradeep's packages, including this one (+7, 0, -0)
16:02:03 <bowlofeggs> #topic #2047 Need +1: policy change re. module default stream changes & Fedora Changes
16:02:05 <bowlofeggs> .fesco 2047
16:02:07 <zodbot> bowlofeggs: Issue #2047: Need +1: policy change re. module default stream changes & Fedora Changes - fesco - Pagure.io - https://pagure.io/fesco/issue/2047
16:02:07 <zbyszek> wait, no
16:02:12 <bowlofeggs> zbyszek: ?
16:02:21 <zbyszek> that's not what I voted for
16:02:39 <bowlofeggs> zbyszek: ah i guess it was ambiguous whether we were voting on my proposal or mhroncok's
16:02:42 <zbyszek> the proposal was to give the one package and oprhan the others
16:02:42 <bowlofeggs> ok
16:02:52 <mhroncok> revote?
16:02:57 <zbyszek> please
16:03:06 <bowlofeggs> #topic #2045 Unresponsive maintainer: Pradeep Kilambi
16:03:08 <bowlofeggs> .fesco 2045
16:03:11 <zodbot> bowlofeggs: Issue #2045: Unresponsive maintainer: Pradeep Kilambi - fesco - Pagure.io - https://pagure.io/fesco/issue/2045
16:03:15 <bowlofeggs> i dont' feel strongly about which proposal we use
16:03:30 <bowlofeggs> shall we do a vote on mhroncok's instead?
16:03:34 <bowlofeggs> i'd +1 it too
16:03:49 <zbyszek> Maybe let's instead vote which one peoople prefer?
16:03:52 <contyk> that person doesn't seem to be interested, they just wanted that one update; no reason to force it
16:03:59 <contyk> so what's the proposal we're voting on now?
16:04:09 * nirik can be +1 to either.
16:04:23 <bowlofeggs> is anyone against either?
16:04:32 <contyk> +1 to orphan all, +0 to ownership transfer + orphaning
16:04:32 <jforbes> zbyszek: I think the real question is which does the ticket filer prefer?
16:04:47 <bowlofeggs> the ticket filer said they don't want it
16:04:53 <jforbes> I am +1 to either
16:04:54 <bowlofeggs> so it might be weird for us to give it to them anyway
16:04:56 <nirik> we could also just ask them.
16:05:00 <zbyszek> jforbes: yeah, so maybe let's keep the current vote and ask the ticket filer if the want the package
16:05:07 <jforbes> zbyszek: sure
16:05:14 <zbyszek> bowlofeggs: OK, sorry for the noise ;)
16:05:28 <bowlofeggs> zbyszek: so does that mean the count is correct? you are +1 to the proposal i wrote?
16:05:34 <zbyszek> yes
16:05:36 <bowlofeggs> ok cool
16:05:46 <bowlofeggs> #topic #2047 Need +1: policy change re. module default stream changes & Fedora Changes
16:05:48 <bowlofeggs> .fesco 2047
16:05:49 <zodbot> bowlofeggs: Issue #2047: Need +1: policy change re. module default stream changes & Fedora Changes - fesco - Pagure.io - https://pagure.io/fesco/issue/2047
16:05:53 <jforbes> +1
16:06:09 <contyk> +1, voted in the ticket
16:06:11 <nirik> so... this was filed what... 7 hours ago?
16:06:19 <jforbes> nirik: yes
16:06:28 <sgallagh> We have +6 in the ticket
16:06:32 * nirik reads it, since I was asleep when it was filed.
16:06:35 <jforbes> was reading it this morning, surprised it was already on the agenda
16:06:57 <sgallagh> With jforbes's +1, it is technically at the fast-track approval state, unless anyone wants to argue
16:07:14 <nirik> I would like to add a "must mail devel-announce any default module changes in rawhide"
16:07:22 <bowlofeggs> we have +6 in ticket
16:07:32 <mhroncok> if I let's say update some package in rawhide
16:07:36 <tyll> nirik, I would prefer a release not entry as well
16:07:44 <tyll> *release note entry
16:07:44 <bowlofeggs> nirik: i added it to the agenda because zbyszek requested it to be added on devel list
16:07:44 <mhroncok> I'm not requested to do either announce e-mail or release notes
16:08:09 <mhroncok> I don't understand's why this has stronger requirements
16:08:25 <zbyszek> tyll: Dunno, it seems like another source of noise. Basically what mhroncok says.
16:08:30 <contyk> I'd like to leave that to the maintainer
16:08:38 <bowlofeggs> yeah we dont' require that for normal packages when they change typically
16:08:51 <nirik> well, you are when libraries update...
16:09:19 <mhroncok> we could say:s tandard rules apply
16:09:24 <mhroncok> as if you update stuff in rawhide
16:09:25 <nirik> I guess I am thinking of the case of no default -> default some module... and it breaking packages
16:09:26 <otaylor> a list of modules that changed default streams is also possible to generate programatically
16:10:07 <contyk> there's no difference between going from ursine to modular and stream A to stream B
16:10:09 <nirik> perhaps we could add that to the rawhide / branched compose reports?
16:10:10 <bowlofeggs> zbyszek: you wanted us to discuss this today rather than vote in ticket - anything in particular you wanted to discuss?
16:10:14 <contyk> packages are being replaced by other packages
16:10:21 <zbyszek> otaylor: yeah, we could that up on a web page somewhere from a cron job or fpdc or whatever
16:10:46 <nirik> the reports makes the most sense to me...
16:10:53 <nirik> but then it would only be when it changes.
16:10:56 <zbyszek> bowlofeggs: no special reason, people started voting on the ticket and it seems rather straightforward, I thought we could tick it off.
16:11:06 <tyll> doesn't changing a default stream mean major changes? Otherwise the changes would stay in the same stream? AFAIK bigger changes to ursine pkgs are also mentioned in the release notes
16:11:22 <tyll> (even if it is not a change)
16:11:36 <contyk> tyll: it may, it may not
16:11:45 <contyk> tyll: the proposal is to let the maintainer decide whether it's change-worthy
16:11:58 <zbyszek> contyk: +1
16:12:32 <zbyszek> We always have trouble getting the release notes compiled. I don't want to add even more work to this area.
16:12:38 <tyll> contyk, the question is whethere it is not significant enough for release notes
16:13:04 <mhroncok> I don't think we need to invent new set of rules
16:13:19 <mhroncok> standard rules apply, don't they?
16:13:24 <mhroncok> we could say...
16:13:30 * nirik is ok with that to start with, if it turns out that causes problems we can always revisit
16:14:01 <mhroncok> Imagine you are updating the version in rawhide and act accordingly. This can involve a Fedora Change or an e-mail to announce etc, as the packager desires.
16:14:46 <bowlofeggs> yeah i dont' think we need a different policy for modules than regular packages here for now
16:14:50 * zbyszek notes that what mhroncok said is generally compatible with what contyk said
16:15:10 <contyk> bowlofeggs: hopefully ever
16:15:13 <contyk> it's still just packages
16:15:43 <bowlofeggs> so should we just vote on accepting the ticket, or does someone have a specific proposal?
16:16:40 <bowlofeggs> proposal: accept the ticket
16:16:43 <zbyszek> +1
16:16:52 <mhroncok> +1 as voted in the ticket
16:16:56 <jforbes> +1
16:16:57 <tyll> 0
16:17:18 <contyk> +1
16:17:23 <nirik> alright, +1
16:17:39 <otaylor> +1  (as on the ticket)
16:17:48 <bowlofeggs> sgallagh: ?
16:18:00 <sgallagh> +1
16:18:07 <sgallagh> Sorry, attention got split at the hour.
16:18:13 <bowlofeggs> #agree ACCEPTED (+8, 1, -0)
16:18:24 <bowlofeggs> #topic Next week's chair
16:18:26 <bowlofeggs> #action NAME will chair next meeting
16:18:34 <bowlofeggs> haha i copied the action
16:18:43 <bowlofeggs> NAME will do it
16:18:47 <jforbes> Thanks NAME
16:18:49 <contyk> NAME++
16:18:51 <sgallagh> I haven't done it in a while
16:18:54 * nirik will likely not be here next week.
16:19:00 <bowlofeggs> #action sgallagh will chair next meeting
16:19:04 <bowlofeggs> thanks!
16:19:08 <contyk> I'll be absent too
16:19:11 <bowlofeggs> #topic Open Floor
16:19:13 <contyk> sgallagh++
16:19:13 <zodbot> contyk: Karma for sgallagh changed to 5 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
16:19:14 <sgallagh> I'll be absent the week after next
16:19:18 <sgallagh> (traveling to DevConf.cz)
16:19:25 * nirik too
16:19:37 <contyk> so, mattdm posted the council hackfest report
16:19:42 <contyk> https://lists.fedoraproject.org/archives/list/council-discuss@lists.fedoraproject.org/thread/GOUIBXVVVSE33ZMGV6JNFZIR6K5WZMG7/
16:19:57 * nirik has marked that to reply to.
16:20:30 <contyk> I'm mentioning that because we agreed we need to review all Fedora services and see which of them could potentially be moved elsehwere or replaced by something else
16:20:44 <contyk> this is just to know where we are at this point
16:21:17 <contyk> it's up to us + infra to produce a list of everything we run in Fedora and whether it's replacable or not
16:21:29 <contyk> and possibly how much effort it takes to run it ourselves
16:21:38 <contyk> how should we approach this?
16:22:15 <contyk> (it's the "#topic Infrastructure" section)
16:23:01 <jforbes> I think we should open a ticket for ideas and discuss next week.
16:23:17 <contyk> sounds good
16:23:20 <jforbes> Give us some time to think about the approach
16:23:55 <contyk> I will file a ticket then
16:24:12 <tyll> Some kind of shared document (maybe in Gobby) with an initial list from infra would be great
16:24:59 * nirik finds this confusing.
16:25:18 <bowlofeggs> yeah i'm not really sure what it's asking us to do actually
16:25:27 <bowlofeggs> it doesn't really mention fesco
16:25:59 <nirik> well, I am not clear on what the council is asking infrastructure either
16:26:01 <contyk> fesco's involvment is really limited
16:26:04 <tyll> bowlofeggs, it says so in the fake IRC meeting log
16:26:09 <bowlofeggs> the bit about github is also a little strange, mostly because people have been using github anyway so it doesn't seem like a departure from what already was the case
16:26:31 <mhroncok> #action contyk, FESCo to work with Infra to examine current
16:26:31 <mhroncok> applications and determine: 1. which applications can be moved out of
16:26:31 <mhroncok> the datacenter immediately or in the short term, 2. Which applications
16:26:31 <mhroncok> have industry-standard open source or proprietary alternatives that we
16:26:32 <mhroncok> could move to.
16:26:32 <mhroncok> it does here
16:26:41 <nirik> replacing all our services and moving everything doesn't sound like a efffective way to free up any time for infrastructure.
16:26:42 <contyk> bowlofeggs: we're just acknowledging the reality here
16:27:07 <contyk> nirik: it might in the long term -- but who knows
16:27:18 <contyk> assessing what we have right now is the first step to find out
16:27:33 <bowlofeggs> tyll: ah i see that now
16:27:34 * nirik thinks moving to proprietary solution is a horrible bad idea.
16:28:04 * mhroncok nods
16:28:07 <contyk> :)
16:28:21 <mhroncok> I mean, I use github daily
16:28:37 <nirik> anyhow, I plan to reply to the council thread we can go from there.
16:28:44 <mhroncok> but taking anything we have in Fedora and replacing it by whatever proprietary thing, taht's not good
16:28:57 <contyk> we're not suggesting that
16:30:02 <contyk> I'll file the ticket for gathering ideas regarding the infra assessment
16:30:07 * zbyszek has to run. See you all next week.
16:30:19 <bowlofeggs> cool
16:30:23 <bowlofeggs> anything else for open floor?
16:31:02 <mhroncok> anything I need to learn / setup / whatever as a fesco newbie?
16:31:11 <tyll> the idea is to allow to use non-FLOSS services and hosted services when it is better and allows to reduce the load from Infra
16:31:25 <tyll> e.g. using Openshift to avoid maintaining bare-metal hardware
16:31:26 <contyk> mhroncok: you need to install this proprietary blob...
16:31:42 <bowlofeggs> mhroncok: mostly just watch the fesco ticket queue - we try to vote in ticket when possible
16:32:00 <bowlofeggs> otaylor, mhroncok: have you been added to the fesco mailing list?
16:32:19 <otaylor> bowlofeggs: No
16:32:21 <nirik> tyll: well, we do use openshift on our own bare metal... so that means moving to a hosted one?
16:32:36 <mhroncok> contyk: I was kinda expecting that
16:33:08 <mhroncok> bowlofeggs: nothing happened, no mailing list, no badge (!) :D
16:33:27 <bowlofeggs> i don't seem to have ACLs to add you guys to that list. nirik can you do that?
16:33:31 <mhroncok> BTW I've deleted the content form the FESCo wiki page, as it was old and that was confusing
16:33:34 * nirik can do mailing list, fesco pagure group
16:33:48 <tyll> nirik, yes, this is an idea so Infra does not need to spend time on maintaining Openshift but can focus on workloads that are more specific to Fedora (and running Openshift is something that a team focused on running Openshift can probably do more efficient)
16:33:52 <bowlofeggs> i think there is a badge for fesco too
16:34:00 <bowlofeggs> maybe file a ticket with commops abotu that
16:34:08 <mhroncok> bowlofeggs: I can file that badge :D
16:34:19 <bowlofeggs> #action nirik will add otaylor and mhroncok to the fesco list and group
16:34:20 <mhroncok> I mean award
16:34:27 <bowlofeggs> :)
16:34:27 <nirik> tyll: well, we run openshift a specific way... not having access to update and manage objects and permissions would be anoying
16:34:47 <nirik> and maintaining rhel7 is... not too much work really
16:34:55 <contyk> nirik: let's include all that info in the report :)
16:35:02 <mhroncok> I think that's mostly the call fo infra + releng
16:35:19 <mhroncok> I don't know how fesco can say anything here. we can certainly have opinions, but at the end...
16:36:18 <contyk> fesco is just a middle man between infra and the council here
16:36:31 <mhroncok> ack
16:36:39 <bowlofeggs> anything else for open floor?
16:36:52 <bowlofeggs> is everyone good with this time slot?
16:37:21 <contyk> yes
16:37:23 <mhroncok> perfect for me
16:37:37 <bowlofeggs> closing in 120 seconds, exactly
16:37:54 <contyk> let's count down
16:37:55 <otaylor> works for me
16:38:19 <mhroncok> see you next week and I'll read the contyk's tickets until that
16:39:37 <bowlofeggs> #endmeeting