14:34:33 #startmeeting Fedora DotNet (2018-10-18) 14:34:33 Meeting started Thu Oct 18 14:34:33 2018 UTC. 14:34:33 This meeting is logged and archived in a public location. 14:34:33 The chair is Rhea. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:34:33 Useful Commands: #action #agreed #halp #info #idea #link #topic. 14:34:33 The meeting name has been set to 'fedora_dotnet_(2018-10-18)' 14:34:38 #meetingname dotnet 14:34:38 The meeting name has been set to 'dotnet' 14:34:40 #nick dotnet 14:34:52 #topic Packaging progress / Open Floor discussion 14:34:55 .hello tmds 14:34:56 tmds: tmds 'Tom Deseyn' 14:34:58 .hello aslice 14:34:59 aslice: aslice 'Andrew Slice' 14:35:09 .hello omajid 14:35:10 omajid: omajid 'Omair Majid' 14:35:37 #chair omajid tmds aslice dseefeld crummel 14:35:37 Current chairs: Rhea aslice crummel dseefeld omajid tmds 14:36:21 So last time we were talking about CI 14:36:52 I guess that it's safe to say that CI with Rawhide is too much trouble to maintain and it wouldn't really be CI by definition but basically manual work... 14:38:00 Rhea: can you elaborate more on the context of CI? if it's just building .net core, for example, historically rawhide has not been too painful 14:38:39 thinking back, i dont think too many builds have failed where the failure was rawhide-specific 14:38:56 Well, we don't have an image, so I would have to maintain one if we wanted it... And I don't have resources to spare for that. 14:39:13 ah. okay, so by CI you meant something in your qe framework. got it. 14:39:13 The problem is with maintaining the rawhide image itself, not with ci builds. 14:39:26 i see. okay. please ignore what i csaid, then. 14:39:28 said* 14:40:23 Every update would be manual, so at least once a month... and it doesn't matter what kind of infrastructure it would be. 14:40:53 Unless you want a ... `dnf upgrade` in every CI build (which i bet would break every build haha) 14:41:45 yeah, that seems like it would cause problems 14:42:34 The next best thing to do is imho keeping it on the latest released version, i.e. right now that would be F29 already 14:44:02 yeah, looking at our F28 Dockerfile it doesn't seem like we're doing anything crazy so we can probably keep on top of the latest released version pretty easily 14:46:33 When we're done with all the chaos we had this week I'd really like to look into CI for various things that were on my backlog for a while... so expect me bugging you omajid aslice tmds about that in near future :) 14:46:57 * omajid would be happy to help 14:47:09 crummel: do you have anything to bring up today, any issues or progress to talk about? 14:48:47 I don't think we have much. Davis merged the PR for 2.2 preview 3 so we'll be testing that out and hopefully have it tagged for you soon 14:49:46 is this something we want to make avaiable to users (for playing around with, it's not stable/final)? 14:51:09 i definitely dont want to put it in https://copr.fedorainfracloud.org/coprs/g/dotnet-sig/dotnet/ but if there's a need to, we could put it in some beta copr channel? 14:51:14 omajid: hmm... only as separate copr repo, I wouldn't want to mix it with stable to be honest. 14:51:19 Haha same thoughts 14:51:21 agreed :) 14:51:58 otherwise i can do builds in my not-meant-for-public-consumption copr repo for testing 14:52:07 I personally, as a user, am after stable things. However Fedora does have a lot of tinkers who like the latest bleeding edge so dunno.. 14:54:11 omajid: so yeah up to you, I'm not against it being in... `@dotnet-sig/dotnet-preview` or -beta ? 14:54:31 If you want to build it regardless, and it's a question of where... 14:54:48 okay, let me think about it a bit more 14:55:16 If we do go this way I'll include reference on the dev portal, etc... 14:56:46 okay. i will get back to you about this. 14:57:37 Anyone got anything else to add, something to talk about? :) 14:58:09 * aslice shakes his head. 14:58:12 not from our side 14:58:45 there's one thing i want to bring up. not expencting an answer, but just to raise awareness 14:58:56 Bring it! O_O 14:58:57 what's our stable native/unmanaged api? 14:59:38 the context here is that some programs (looking at https://github.com/Samsung/netcoredbg for now) might want to link against coreclr 15:00:12 and for that, it would be useful to know if coreclr has a public api/abi that they will keep stable (at least within a release) 15:00:48 otherwise, for tools like this, everytime we update .net core, we would have to rebuild these programs to make sure they continue working 15:01:45 just something to think about. 15:01:45 ok, that makes sense. I'm not sure what the story is there, I will bring this to Lee and the others and see what they say. 15:02:48 Kinda brings me to... I need to fire up slack. 15:02:59 the other aspect to that quesiton is: if there is a stable public api, do we want to publish them at some well known paths? like /usr/include/coreclr.h or something? 15:05:22 Okay, I'll bring that up too, maybe I should make a CoreCLR issue for it 15:08:27 omajid: thoughts on creating the issue right away? 15:08:36 And to continue discussion there 15:08:51 sure, i can file an issue 15:09:36 Okay o.o 15:09:45 Anything else anyone? 15:10:28 nothing else form me 15:10:55 #endmeeting