12:01:05 <vpavlin> #startmeeting Env and Stacks (2014-11-26)
12:01:05 <zodbot> Meeting started Wed Nov 26 12:01:05 2014 UTC.  The chair is vpavlin. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:01:05 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
12:01:05 <vpavlin> #meetingname env-and-stacks
12:01:05 <zodbot> The meeting name has been set to 'env-and-stacks'
12:01:05 <vpavlin> #chair pkovar tjanez samkottler bkabrda hhorak juhp ncoghlan vpavlin sicampbell
12:01:05 <zodbot> Current chairs: bkabrda hhorak juhp ncoghlan pkovar samkottler sicampbell tjanez vpavlin
12:01:11 <vpavlin> Hi all:)
12:01:13 <nphilipp> hi
12:01:20 <hhorak> Hi!
12:01:21 <bkabrda> hey
12:01:38 <vpavlin> #topic init process
12:02:21 <vpavlin> #topic Follow-ups
12:03:27 <vpavlin> So...anything to this topic? hhorak?
12:04:20 <hhorak> I have some news about elections, but I'll cover that in "Election planning" later
12:05:20 <vpavlin> ok, anybody has any follow up for anything? Or we can just move to the next topic
12:05:29 <ncoghlan> looking back at https://lists.fedoraproject.org/pipermail/env-and-stacks/2014-November/000604.html
12:05:41 <ncoghlan> main thing seems to be how we want to break the task list down
12:06:19 <ncoghlan> for now, I only have draft notes under my user space
12:06:48 <ncoghlan> oh, nvm
12:07:04 <ncoghlan> those minutes actually do contain a decision, and i just fail at reading comprehension :)
12:07:27 <ncoghlan> it's the Projects/Project_NAME layout
12:07:34 <vpavlin> ncoghlan: oh do they? :)
12:07:46 <ncoghlan> heh, maybe that's the follow-up
12:08:12 <vpavlin> I think that was just suggestion - we haven't voted (if that's important enough to be voted about:) )
12:08:24 <hhorak> ncoghlan: I think it is fine to move the page from your namespace under Env&Stacks' Projects/... even if it is not ready yet..
12:08:45 <vpavlin> ncoghlan: Could you share a link?
12:08:54 <vpavlin> (to your draft)
12:09:02 <ncoghlan> OK, I'll move it to Env_and_Stacks/Projects/Project_UserLevelPackageManagement
12:09:21 <ncoghlan> LINK: https://fedoraproject.org/wiki/User:Ncoghlan/User_level_package_management
12:09:30 <vpavlin> #link https://fedoraproject.org/wiki/User:Ncoghlan/User_level_package_management
12:09:49 <ncoghlan> I started out writing some notes on the language specific repositories work bkabrda has been doing
12:10:05 <vpavlin> ok, great
12:10:09 <ncoghlan> but it kinda morphed once I started asking "Why is that topic interesting?"
12:10:48 <ncoghlan> which actually made for a better doc I think - starting with the problem description
12:10:57 <bkabrda> yeah, I still have on my todo list to actually deploy the built devpi. I had to work hard on new devassistant release, so I had no time to do that unfortunately... I'll try to get some more help from folks in my team, maybe we'll find some spare cycles to finally do that
12:12:19 <vpavlin> #info ncoghlan started with a draft for a "User Level Package Management" topic
12:12:19 <vpavlin> #info bkabrda plans to deploy devpi
12:12:26 <ncoghlan> heh, I just realised
12:12:38 <vondruch> hi
12:12:42 <vpavlin> vondruch: hi
12:12:48 <ncoghlan> the whole reason I *started* on the wiki page was to put the IP address of the experimental devpi server somewhere people could find it
12:12:58 <ncoghlan> and it's not on the page
12:13:27 <bkabrda> ncoghlan: :) do you have it or do you want me to send it to you?
12:13:34 <ncoghlan> bkabrda: I have it
12:13:38 <bkabrda> ok
12:13:58 <ncoghlan> just got sidetracked from "document the experiment" to "define the problem we're trying to solve"
12:14:00 <vpavlin> ncoghlan, bkabrda: Can you share it here so that it's in meeting logs also
12:14:15 <vpavlin> ncoghlan: Which is not bad thing
12:14:47 <hhorak> ncoghlan: never mind, we should touch that topic anyway :)
12:14:47 <ncoghlan> aye - just need to remember to go back and create the page with more details on the devpi prototype
12:15:30 <bkabrda> vpavlin: it's 209.132.184.166, but as I've noted, nothing is there ATM
12:15:57 <vpavlin> So I guess we could move to the next topic (as we are discussing it already..)
12:16:01 <ncoghlan> it's a RHEL7 system, bkabrda and I have root access
12:16:35 <vpavlin> #info devpi instance wil be here: 209.132.184.166 (nothing is there ATM)
12:16:54 <vpavlin> #topic Language specific repositories
12:17:34 <ncoghlan> as noted earlier, my initial attempt at writing this up morphed into the broader topic of user level package management
12:18:14 <ncoghlan> but I'll go back and also create a more detailed description of the pilot and what we'd like to get out of it
12:18:38 <ncoghlan> I think it's a good way to see what we'd like the developer experience to be
12:19:09 <vpavlin> #action ncoghlan to describe the devpi pilot and what we'd like to get out of it
12:19:18 * vpavlin nods
12:20:11 <ncoghlan> Matt Miller also pinged me to let me know the koji devs have been looked at the possibility of building non-RPM content
12:20:20 <vondruch> I somehow missing the point ... speaking of Ruby developers, they can use upstream packages
12:20:35 <vondruch> so what do you want to achieve?
12:20:45 <ncoghlan> 2 main things from my perspective:
12:21:01 <ncoghlan> - prebuilt binaries for specific Fedora versions
12:21:07 <ncoghlan> (and likely EPEL as well)
12:21:14 <vondruch> what does it mean to build non rpm concent? is it like I'll take upstream gem, unpack it and pack it again? what is the benefit?
12:21:39 <vondruch> ncoghlan, what is binary in your terminology?
12:21:46 <ncoghlan> - phased review of packages on their way into Fedora (i.e. initial review wouldn't need rebuilding)
12:22:01 <ncoghlan> vondruch: things like Python wheel files
12:22:07 <vpavlin> vondruch: benefit is that it will be built in trusted environment (Koji) and can be signed by trusted authority (Fedora)
12:22:08 <bkabrda> vondruch: Python now has a binary package format, so we can prebuild stuff like DB connectorts
12:22:11 <ncoghlan> which have the C extensions prebuild
12:22:55 <ncoghlan> going back to the koji question, the first thing they're actually looking at is supporting Java JAR files
12:23:32 <vpavlin> #info Koji devels are looking into building non-RPM content (Java jars in the first place)
12:23:47 <vondruch> vpavlin, ok, you have signed gems, and where are your users?
12:24:09 <mclasen> vondruch: it sprinkles magical packaging dust :-)
12:24:09 <ncoghlan> vondruch: people like me who won't deploy to production from a non-curated source
12:24:46 <vondruch> ncoghlan, ok ... you are one user ... and how it will work with upstream projects?
12:24:53 <ncoghlan> we have to do that curation work anyway, and doing it upstream in Fedora benefits the whole Fedora/RHEL/CentOS ecosystem
12:25:02 <ncoghlan> vondruch: same way distro packaging does
12:25:09 <vondruch> ncoghlan, how you will convince majority of upstream project to star using ours repository instead of rubygems.org
12:25:10 * mclasen thinks funneling all the worlds software through koji is futile
12:25:17 <ncoghlan> vondruch: except without the need to write a spec file
12:25:32 <vpavlin> vondruch: as ncoghlan says - devel will probably use upstream pkgs, but for production systems you want more RCM magic around - reproducibility, tracebility...
12:25:47 <ncoghlan> vondruch: no, people still publish to pypi/rubygems/cpan/etc as normal
12:26:21 <vondruch> vpavlin, typacal ruby upstream project has in their gemfile "source 'rubygems.org'"
12:26:45 <ncoghlan> as a *consumer* of gems (etc), I need to do licensing reviews and basic security reviews before I deploy software
12:27:00 <ncoghlan> and I also need to build any binary extensions
12:27:01 <vondruch> so you suggest for production environment, people will suddenly rewrite it to somethign.fedoraproject.org and everything will suddenly break?
12:27:05 <vondruch> I cant imagine that
12:27:32 <ncoghlan> vondruch: this is to increase iteration speed for organisations that won't install from non-curated sources
12:27:47 <vondruch> ncoghlan, so you suggest that we will release in the will another copies of gem packages, which has nothing to do with upstream packages?
12:27:52 <ncoghlan> vondruch: it's not aimed at folks that are comfortable downloading arbitrary software from the internet
12:28:02 <ncoghlan> yes, they will be rebuilds
12:28:11 <ncoghlan> published by the Fedora project
12:28:14 <ncoghlan> not by upstream
12:28:26 <vondruch> ncoghlan, don't we have already enough questions "red hat has uncecure packages, because rails 3.2.8 contains security flaw which was fixed in version 3.2.14"
12:28:57 <ncoghlan> I don't see the connection
12:29:09 <ncoghlan> that's folks not understanding our backport policy
12:29:25 <ncoghlan> this will just be upstream packages
12:29:46 <vondruch> ncoghlan, there is canonical source of gems, which is rubygems.org the package may look like rails-3.2.8.gem
12:30:09 <vondruch> and we will release the gem with the same name, but potentially different content, be it timestamps for example
12:30:18 <vondruch> this is wrong
12:30:32 <ncoghlan> then we don't do it for Ruby
12:30:45 <vondruch> :))
12:30:47 <ncoghlan> Python has support for redistributors in its versioning scheme now
12:31:37 <vondruch> and who will add support for redistribution into other packaging systems?
12:31:37 <ncoghlan> that does get on to the other aspect of the topic though
12:32:00 <ncoghlan> which is that some language communities are actively hostile to users that want to get their software through a redistributor
12:32:26 <ncoghlan> and also that it isn't practical to plug every package management system in the world into system audit tools
12:32:47 <ncoghlan> that means we're likely to want to look at a more general purpose solution
12:32:58 <ncoghlan> that can be adapted to packages in any language
12:33:14 <ncoghlan> I personally know of at least two: NixOS and conda
12:34:48 <ncoghlan> the idea there being to recommend something that's decent for *user* level dependency management
12:35:03 <ncoghlan> as well as allowing parallel build environments, etc
12:35:20 <ncoghlan> all without affecting the underlying system itself
12:36:09 <ncoghlan> the idea there being that the package-manager-per-language model creates isolated silos
12:36:37 <vpavlin> #info WRT vondruch'a opinion, Ruby might not be good candidate for "Language specific repositories" project
12:38:58 <ncoghlan> #info Python's PEP 440 versioning scheme explicitly introduced redistributor support, any ecosystems without that feature may be ill-suited
12:40:20 <vpavlin> Anything else to this topic?
12:40:47 <hhorak> I haven't look that closely on NixOS and conda, but what would it need on client side (installation)?
12:41:03 <hhorak> some similar tool like rpm is?
12:41:09 <ncoghlan> hhorak: yes
12:41:34 <ncoghlan> I actually have a preference for conda personally
12:41:54 <ncoghlan> mostly because it doesn't even *try* to be a replacement for RPM (whereas nix does)
12:42:05 <hhorak> then I fail to see a reason for such a new format; I though we want upstream-like repositories so users can work with them like with upstream..
12:42:45 <ncoghlan> hhorak: I wrote more about it in the problem statement, but there are actually too problems to be considered here
12:42:52 <ncoghlan> s/too/two/
12:43:32 <hhorak> ncoghlan: I read it but will read it again, no need to repeat here..
12:43:35 <hhorak> thanks
12:43:39 <ncoghlan> it comes down to why I mention both developers and data analysts in my description of the challenges
12:43:50 <ncoghlan> both pip and conda came out of the Python community
12:44:18 <ncoghlan> and the origins of that split reflects a real difference in the way application developers and data analysts approach their tools
12:45:23 <ncoghlan> when Marcela suggested everyone look more closely at conda several weeks ago, I was actually puzzled, since I didn't see it as relevant back then
12:45:23 <vpavlin> #info pip and conda both came out of the Python community - the origins of that split reflects a real difference in the way application developers and data analysts approach their tools
12:45:38 <ncoghlan> even though I was the one that mentioned it
12:46:40 <hhorak> yeah I did look at it, but haven't seen the connection with the requirements we're trying to address.
12:46:49 <ncoghlan> but the more I think about it, the more I think there may be potential value in having a clear distinction at the tool level between "platform dependency management" and "application dependency management"
12:47:30 <ncoghlan> hhorak: no worries, that just means I still have work to do in making the case for its relevance
12:48:31 <ncoghlan> it only clicked for me this week myself, and even for me it's still only at "potentially worth exploring" stage
12:49:59 <ncoghlan> it basically boils down to the different requirements involved in targeting "single ecosystem" developers vs "polyglot programming" developers.
12:50:17 <ncoghlan> while the former is the main near term concern
12:51:16 <ncoghlan> there's a pretty severe problem when one of the first steps in creating a new language now is also to create a new language specific package management system
12:51:33 <ncoghlan> that's just /headdesk worthy for our industry as a whole right there
12:52:59 <vpavlin> Ok, so let's move on - I'm really looking forward to read your write up about this, ncoghlan
12:53:07 <vpavlin> Can we move to the next topic?
12:53:10 <hhorak> since now we need as much brainstorming as possible, let's create an AI:
12:53:11 <vpavlin> We are running out of time..
12:53:14 <hhorak> #action everybody should look at conda/NixOS and continue to discuss Language specific repositories on ML.
12:53:22 <vpavlin> hhorak: +1
12:53:41 <hhorak> vpavlin: not wanting you to prevent from moving on :)
12:54:17 <vpavlin> #topic Election planning
12:54:46 <vpavlin> You'Ve probably seen email from hhorak about elections on ML..anything else to add ATM?
12:55:04 <hhorak> I have few updates more about elections, how it may be done..
12:55:24 <hhorak> I asked about what is the process for having elections, but there is nothing written if I'm not mistaken..
12:55:30 <hhorak> But I got those answers:
12:55:37 <hhorak> (from jreznik)
12:55:52 <hhorak> We should coincide with the FESCo election, which will make propagation easier for us and users.
12:55:59 <hhorak> We should also prepare something similar to: http://fedoraproject.org/wiki/Council/Nominations
12:56:07 <hhorak> And then edit http://fedoraproject.org/wiki/Elections
12:56:31 <vpavlin> #info Every voting member should state if he wants continue his participation  as a voting member in the Env & Stacks WG  by 10th Dec 2014, no response counts as negative answer
12:56:33 <hhorak> We should also approach board/council to get ack from them, but since there are changes happening right now, I don't see it as blocker if we don't do that (or get response on time).
12:57:37 <jreznik> the ack from Board/Council would be more to ack changes in WG chart but I expect if you're decided you want elections...
12:57:43 <vpavlin> #info Env&Stacks WG elections should be aligned with FESCo elections as it would be easier for us and users
12:58:03 <hhorak> jreznik: ah, ok..
12:58:36 <jreznik> the reason why to align is - we had council elections now, fesco/fosco next month or jan and i'm afraid too many elections in short time would lead to less activity from people
12:58:47 * vpavlin nods
12:58:53 <hhorak> +1
12:58:58 <hhorak> The elections of council took 3 weeks, so I expect it will be similar for ours. We just should do the same what fesco will be doing :)
12:59:21 <vpavlin> Let's stalk FESCo!
12:59:21 <hhorak> (took means from beginning of nomination till publishing results)
12:59:49 <hhorak> I guess that's all from me.. about elections..
13:00:14 <jreznik> usually it takes longer but we cut it down a bit, skipped townhalls and did interviews instead... not sure how interviews will scale with fesco/fosco/envstacks
13:01:06 * vpavlin is curious if there will be anybody to vote for at all...:)
13:01:55 <hhorak> This is interesting, do we want to do the interviews?
13:03:21 <ncoghlan> should we wait to see if we get more nominees than we have open seats? :)
13:03:56 <hhorak> ncoghlan: good point :)
13:04:12 <vpavlin> Let's leave this open
13:04:48 <vpavlin> #info Decision to be made if we want Townhall, Interviews (or nothing?)
13:04:49 <bkabrda> as I've noted on the ML, I intend to make my seat available (and I'll run for it)
13:05:27 <vpavlin> Can we move to next topic?
13:06:08 <hhorak> yes
13:06:09 <vpavlin> #topic Chairman for next meeting
13:06:20 <vpavlin> Volunteers?:)
13:07:23 * vpavlin will be travelling to Amsterdam for DockerCon Europe...
13:07:45 <vpavlin> which means I will probably not be able to join
13:07:55 <hhorak> If nobody volunteers, I'll chair the next time. Totally voluntarily :)
13:08:07 <vpavlin> hhorak: As you always do:)
13:08:40 <vpavlin> #info hhorak to chair  meeting on 2014-12-03
13:08:48 <vpavlin> #topic Open floor
13:09:05 <ncoghlan> I just tweaked some of the wording in https://fedoraproject.org/wiki/User:Ncoghlan/User_level_package_management#Directions_to_be_Explored
13:09:11 <ncoghlan> based on the meeting discussion
13:09:44 <vpavlin> Thanks Nick
13:09:56 <vpavlin> Anybody anything else?
13:09:57 <ncoghlan> to point out the near term/longer term split, as well as the fact we know redistribution will be a bad fit for some ecosystems, so we won't try it there
13:10:18 <vondruch> ncoghlan, *thumbs_up*
13:10:31 <vpavlin> ncoghlan: +1
13:11:33 <vpavlin> If there is nothing in next 2 minutes, let's call it a day
13:11:47 <vondruch> ncoghlan, btw do python's naming convention supports something like forks?
13:12:06 <ncoghlan> vondruch: just renaming
13:12:35 <ncoghlan> vondruch: and if the original project wants to later bless a particular replacement project, metadata 2.0 will have an "Obsoleted-By" field
13:12:38 <vondruch> ncoghlan, e.g. old version of package is unmaintained, upstream unresponsive .... it happens that there are pakcages likge "gitlab-rails"
13:13:01 <vondruch> i.e. gitlab's fork of rails
13:13:17 <vondruch> s/i.e./e.g./
13:13:29 <ncoghlan> vondruch: yeah, that's basically what the Python community has
13:14:18 <ncoghlan> although the last major fork that comes to mind was the PIL -> pillow switch
13:15:06 <ncoghlan> org specific forks are pretty rare - in those cases, it's more likely they just won't put it up on PyPI at all
13:15:16 <vondruch> ncoghlan, it might be also "project specific"
13:15:57 <vondruch> ncoghlan, well .... recent for of webkit? although they renamed the package ....
13:16:49 <ncoghlan> yeah - it's one of those things where it doesn't happen often enough (at least for packages I pay attention to) for a particular convention to emerge
13:17:57 <vondruch> ncoghlan, np ... just collection food for further thinking ;)
13:18:35 <ncoghlan> even "Obsoleted-By" is mostly being added for the benefit of project name *changes*
13:19:57 <ncoghlan> I actually did a whole bunch of research on different packaging systems for a Python packaging talk a couple of years ago
13:20:08 <ncoghlan> but it all ended up getting cut for length
13:22:02 <ncoghlan> huh, only last year in fact: https://bitbucket.org/ncoghlan/misc/src/default/talks/2013-07-pyconau/packaging/brispy-talk.md
13:22:13 <ncoghlan> it feels longer ago than that :)
13:22:42 <ncoghlan> anyway, g'night folks!
13:22:47 <vpavlin> Ok, sorry guy, ending a meeting
13:22:52 <vpavlin> #endmeeting