17:00:37 <bstinson> #startmeeting epel
17:00:37 <zodbot> Meeting started Fri Feb 27 17:00:37 2015 UTC.  The chair is bstinson. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:37 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:44 <bstinson> #meetingname epel
17:00:44 <zodbot> The meeting name has been set to 'epel'
17:00:52 <bstinson> #chairs smooge nirik dgilmore bstinson
17:01:01 <bstinson> #chair smooge nirik dgilmore bstinson
17:01:01 <zodbot> Current chairs: bstinson dgilmore nirik smooge
17:01:13 <bstinson> #topic Who's Here?
17:01:20 * bkabrda is here
17:01:28 * nirik is sort of here, but also doing other stuff too. ;)
17:01:30 <avij> good evening
17:01:34 <bstinson> smooge is out today
17:01:41 <bstinson> hi all!
17:02:01 <bstinson> #chair Evolution
17:02:01 <zodbot> Current chairs: Evolution bstinson dgilmore nirik smooge
17:02:29 <Evolution> WOOHOO
17:02:51 <bstinson> #topic Python 3.X discussion
17:03:10 <bstinson> bkabrda: thanks for coming to the meeting today, and for putting all this together so far
17:03:32 <orionp> Indeed - much appreciated
17:03:38 <bkabrda> bstinson: no problem, I just want to get it working finally :)
17:03:41 * bstinson is searching for the appropriate link to include in the minutes
17:03:55 <bkabrda> bstinson: https://fedoraproject.org/wiki/User:Bkabrda/EPEL7_Python3 ?
17:04:22 <bstinson> yes! it was at the bottom of my notes :)
17:04:33 <bkabrda> i rewrote the proposal a bit, it should be more specific and cleaner
17:04:47 <Evolution> bkabrda: were the ius packages of any help?
17:05:18 <nirik> cool.
17:05:28 <nirik> I look forward to our python3 future. ;)
17:05:34 <bkabrda> Evolution: well, a bit, but most of the work that I had with this was about making the stacks parallel installable, which IUS doesn't solve
17:05:47 <Evolution> ah, fair enough
17:05:57 <bkabrda> but that was fairly easy too :)
17:06:16 <bkabrda> heres the copr with testing builds: https://copr.fedoraproject.org/coprs/bkabrda/python34-epel7/
17:06:36 <nirik> awesome
17:06:46 <bstinson> bkabrda: i pulled from your copr and converted one of my packages in the way you suggest
17:06:49 <bstinson> worked like a charm
17:07:14 <bkabrda> there are some missing requires in some packages there, but if you install python34*, everything will work
17:07:38 <nirik> hum.
17:08:03 <bkabrda> (will fix these when I do actual builds)
17:08:23 * Jeff_S waves
17:08:24 <nirik> python-setuptools is already in rhel tho? or the epel package will just be named python3-setuptools?
17:09:11 <bkabrda> nirik: so, as I note in the proposal, the packages that are in epel must not build python-* subpackage (it's at the very bottom of my proposal)
17:09:46 * maxamillion is here (sorry I'm late)
17:09:56 <nirik> but the package name will be the same as the rhel one?
17:10:02 <nirik> source package?
17:10:23 * orionp wonders if we should do versioning like with do with exclusive arch packages in epel
17:10:27 <bkabrda> nirik: source package, yes. can that be a problem?
17:10:32 <nirik> yes, that won't work. ;(
17:10:38 <nirik> due to the way koji works.
17:10:55 <nirik> if there's a python-setuptools in both rhel and epel we would have to block one or the other.
17:11:01 <bkabrda> nirik: ok, so we'll just have to do it differently for packages that are in rhel
17:11:08 <nirik> yeah. ;(
17:11:24 <nirik> so, for those I guess python3-setuptools and just don't build the python 2 version.
17:11:34 <bkabrda> nirik: we can create python3-setuptools.srpm for these. it will require reviews and stuff, but it will work
17:11:35 <orionp> nirik - why is it different than what we do for missing arches?
17:11:36 <nirik> more complexity sadly.
17:11:52 <nirik> orionp: it could be the same, but then...
17:12:12 <nirik> rhel7 has python-setuptools-0.9.8-3.el7
17:12:16 <nirik> so, we would have to use that version.
17:12:36 <nirik> and not 12.0.3-2 like is in the copr
17:12:43 <nirik> and keep them in sync
17:13:17 <nirik> I guess we could take either approach depending on needs.
17:13:21 <bkabrda> considering that RHEL doesn't have that many packages, it shouldn't be much more work, I think
17:13:25 <nirik> it might be just easier to have the different one tho
17:13:58 <nirik> then you don't need to keep it in sync, etc... and if you have to update it for a python3 issue you don't have to worry.
17:14:20 <orionp> yeah, I suspect the python3 packages will want to be newer ones that what rhel ships
17:14:21 <Evolution> the sync approach might be problematic down the road though for compat between python3x and python 2.7.x
17:14:31 <Evolution> I think having different packages is likely best
17:14:53 <bstinson> i like having separate packages, i can help review if needed
17:14:59 <bkabrda> yeah, we can just say "if the package lives in rhel, you have to create new python3-foo package"
17:15:08 * nirik nods, makes sense.
17:15:12 <bstinson> +1
17:15:24 <bkabrda> for those that don't exist in rhel, I think we can just use current repos
17:15:40 <orionp> yes, that I like a lot
17:16:14 <nirik> yep. seems workable.
17:16:44 <orionp> One thing I don't like is the use of "other" in macro names.  Perhaps "next" ?
17:17:39 <bstinson> are those macros already in process for use in fedora?
17:18:15 <bkabrda> orionp: the thing is, they will get swapped at some point, while the packages will still be built for both stacks, so in this case "next" would actually be the older python3
17:18:52 <bkabrda> bstinson: which ones specifically? the "other" macros won't be used in fedora
17:19:18 <orionp> bkabrda - then this doesn't make sense:
17:19:20 <orionp> # this is only turned on during transitional periods
17:19:21 <orionp> %global with_python3_other 0
17:19:29 <bkabrda> bstinson: and %{python3_pkgversion} will be added to fedora minimal buildroot as well as to EPEL. I talked about this with dennis gilmore and he's ok with it
17:19:45 <bkabrda> orionp: ok, so let me explain
17:20:03 <bkabrda> orionp: most of the time, people will be building just %with_python3
17:20:15 <bkabrda> then there will be new 3X+1 release
17:20:43 <bkabrda> and people will have to rebuild their packages %with_python3_other 1
17:21:11 <bkabrda> then I'll swap python3_pkgversion and python3_pkgversion_other
17:21:22 <nirik> can we perhaps keep a wiki page/list or way to generate it of all the packages affected by this so we can smoothly rebuild everything?
17:21:41 <bkabrda> (while all packages will still have both with_ptyhon3 and with_python3_other)
17:22:11 <bkabrda> ok, now I'm getting confused myself
17:22:12 <smooge> am back
17:22:16 <bkabrda> give me a sec :)
17:22:23 <orionp> want to here my proposal?
17:22:28 <orionp> hear
17:22:46 <bkabrda> orionp: sure
17:23:06 <orionp> right now we have python34
17:23:34 <orionp> we introduce a python35 package that defines %python3_next
17:24:08 <orionp> packages can have: %?python3_next: %global with_python3_next
17:24:15 <orionp> we rebuild everything
17:24:39 <orionp> when we retire python34, python35 is rebuild without defining %python3_next
17:25:35 <orionp> and dropping %python3_next_pkgversion, etc
17:26:10 <orionp> nobody needs to do any toggling in  their packages
17:26:56 <nirik> but they still need to be touched... but I guess there's no way around that?
17:27:26 <bkabrda> orionp: ok, so this has two parts - the first is that basically we can define %with_python3_next in the buildroot, not in the packages
17:27:26 <nirik> oh, I see.
17:27:36 <nirik> hum.
17:27:45 <orionp> hmm, possibly for getting the BRs right - although %python3_next could be in the 3X not the 3X+1 package
17:27:45 <maxamillion> so it would be a package named python34 instead of pyton3?
17:28:19 <bkabrda> orionp: that's why I think "other" is better than "next" :)
17:28:25 <nirik> maxamillion: yes
17:28:46 <maxamillion> :/
17:29:24 <orionp> nirik - but by touched hopefully just a bumprel
17:29:46 <nirik> that would be better than having to tweak macros (less error prone)
17:30:22 <orionp> other/next is always referring to 3X+1 though, right?
17:30:44 <bkabrda> orionp: I'm actually not sure how your proposal is different from mine. sorry, 6:30 PM on friday...
17:31:07 <orionp> otherwise setting with_python3_other 0 doesn't make sense
17:31:29 <bstinson> orionp: i think the suggestion is to have a short period where python3_other_pkgversion: 34, and python3_pkgversion: 35
17:31:40 <bkabrda> bstinson: yeah, exactly
17:31:43 <bstinson> still building for 34 even though 35 has been released
17:31:52 <orionp> why?
17:31:54 <bstinson> i'm wondering how long that period will be
17:32:27 <nirik> there's always going to be cases you can think of to want that...
17:32:36 <bkabrda> orionp: I'm almost sure I had a reason to do it this way, but I can't remember now...
17:32:38 <nirik> but we should try and not do it as much as possible.
17:32:43 <orionp> as in why swap the versions?
17:32:52 <orionp> we need overlap
17:33:24 <nirik> do we know how often upstream releases are planned?
17:33:29 <orionp> but why isn't python3_other/next always greater than python3
17:33:30 <nirik> we need to move faster than that.
17:33:37 <maxamillion> I think I'm missing something, what's the need for python34 and/or python35 instead of just python3 on the package name?
17:33:37 <bkabrda> nirik: I think it's every 9-12 months
17:34:01 <bstinson> we could say "no more new 34 packages on <date>. and put 35 in the buildroot on that day
17:34:21 <nirik> maxamillion: because python3 isn't free from change in it's minor releases. Packages will need rebuilding/adjustment for newer
17:35:06 <bkabrda> orionp: as for swapping the versions, I know I figured that we might need this, but I really can't remember and unluckily I didn't put it in the proposal... I'll try to remember next week and add it there (or I was wrong and we don't need that at all...)
17:35:06 <maxamillion> nirik: right, but why can't we just handle that the same way it is in Fedora?
17:35:42 <bkabrda> maxamillion: the problem is that fedora has rawhide which can be broken for quite a long period of time. epel can't afford that, I think
17:35:43 <orionp> maxamillion - because epel doesn't have releases
17:36:06 <nirik> maxamillion: because we don't have 6month releases.
17:36:11 <nirik> with mass rebuilds between
17:36:24 <nirik> bkabrda: rawhide should not be thought of that way, IMHO. ;)
17:36:25 <maxamillion> right, epel doesn't have releases but it doesn't just magically land in stable ... packages go to testing first, yes?
17:36:34 <bkabrda> nirik: I know, I know... ;)
17:37:00 <nirik> maxamillion: sure, but then a blorp of 60 python3 updates and new python3.5 are released randomly...
17:37:08 <nirik> and break people's stuff.
17:37:19 <nirik> It's the same old issue as always.
17:37:32 <bkabrda> orionp: I think that the point of the swapping is that you want to be able to say "python35" is now the main one, but we still need to build for "python34", so that's the "other" does that make sense?
17:38:01 <nirik> where with this they have to actually actively decide to move to the new one when they are ready.
17:38:34 <bkabrda> nirik: maxamillion: yeah. and if they're not ready, there's a huge regression/problem, we can just wait till it's fixed
17:39:21 <orionp> bkabrda - somewhat, but I don't see the need - I'll add my thoughts to the talk section
17:39:33 <maxamillion> alright, I'll agree to disagree since I appear to be alone in this
17:40:09 <bkabrda> orionp: well, until we retire the whole 34 stack, we need to provide updates/fixes because there may be people still relying on that
17:40:27 <orionp> yes, I understand the need for overlap
17:41:19 <orionp> ultimately it's bike shedding, but the next name to me implies moving forward, which is ultimately what is happening
17:42:44 <bkabrda> orionp: I'm don't really feel strongly about whether it's "next" or "other". if majority wishes "next", I can use it, although in my mind "other" makes more sense
17:42:56 * nirik doesn't much care. ;)
17:43:00 <orionp> I don't particularly think individual packagers should have to worry about turning on or off one or the other builds
17:43:17 <orionp> when there are two stacks, two are built
17:43:25 <orionp> when we're down to one again, one is built
17:44:16 <bkabrda> orionp: yeah, so we can do this automatically by setting with_python3_{next,other} in the buildroot and not using it in packages (in Fedora it'll always be set to 0)
17:44:28 <bkabrda> *not using it in specfiles
17:44:48 <bstinson> so orionp is suggesting that instead of swapping the values of python3_pkgversion and python3_pkgversion_next when 35 is first dropped, but instead setting python3_pkgversion to 35 when we retire 34
17:45:06 <bstinson> am i assuming correctly?
17:45:10 <orionp> right
17:45:29 <nirik> I really like the idea that we could just bump and rebuild things without messing with macros.
17:45:46 <bkabrda> bstinson: that will happen eventually in my proposal, too
17:45:53 <orionp> We'd have this in the spec:
17:46:01 <orionp> %{?:%python3_next_pkgversion: %global with_python3_next 1}
17:46:05 <bstinson> bkabrda: right, but that would get rid of the need for the swap of pkgversion and pkgversion-other in the middle
17:46:40 <bkabrda> bstinson: not sure I understand that
17:48:16 <bkabrda> bstinson: in my proposal, the "swap" between "the one" and "the next" happens when both with_python3 and with_python3_next are enabled. so in fact "next" builds for the older stack. so nothing changes for packagers
17:49:59 <bstinson> so part of retiring 34 would be to move 35 into pkgversion and dropping pkgversion-next, there wouldn't need to be a swap in the middle would there?
17:50:16 <bkabrda> 1) with_python3_next is turned on 2) mass rebuild 3) swap python3 and python3_next macros 4) turn with_python3_next off 5) retire python34
17:51:09 <bkabrda> and between 3) and 4), there can be some time, although we should keep that to minimum
17:52:28 <orionp> I see: 1) with_python3_next is turned on - mass rebuild - this continues for some time, 2) with_python3_next off, retire python34
17:52:40 <bstinson> ahh, i see, there could be a new package between 3 and 4 that wants to target 35 _only_
17:53:32 <bkabrda> orionp: when does swapping the macros happen in your proposal?
17:53:43 <orionp> 2
17:54:01 <orionp> which really just drops _next
17:54:46 <orionp> bstinson - I see your point, but how likely is that?
17:55:08 <bkabrda> orionp: so swapping the macros and making 35 "the main python3" would happen at a single point?
17:55:11 <bstinson> orionp: i'm inclined to call that an edge case, and say "wait until 2) in your proposal"
17:55:33 <orionp> bstinson - yeah, or it could be hacked around if really needed
17:56:15 <orionp> bkabrda - yes,  I don't really see the need to worry about calling one of them the "main" one
17:56:43 <orionp> one is one version, one is the next version, until we don't have a next version :)
17:56:49 <bkabrda> orionp: and at precisely the same time we'd need to retire python34 stack, too, since we'd have no way of maintaining it, right?
17:57:05 <orionp> yes
17:57:06 <bkabrda> orionp: the main one is the one that owns /usr/bin/python3 in my mind
17:57:49 <orionp> that's true - is there going to be a python3 provides?
17:57:59 <bkabrda> orionp: ok. I was planning to have some time to still maintain python34 even we switched to 35, but if that's not needed, we can go with your proposal
17:58:26 <orionp> well, "1" can last as long as needed
17:59:06 <bkabrda> orionp: do we even need python3 provides?
17:59:14 <Evolution> FYI, we're coming up on the hour.
17:59:14 <orionp> I don't know
17:59:28 <nirik> we could always add one later if needs show up
17:59:31 <bkabrda> orionp: I'd say let's not add that provides now and add it later if needed
17:59:44 <orionp> would just switching which own /usr/bin/python3 switch user's installs?
17:59:58 <bstinson> yeah, we should probably get orionp's alternate proposal documented for more discussion / consensus at the next meeting
18:00:01 <orionp> how do people go from 3X to 3X+1
18:00:13 <bkabrda> orionp: could you please write your proposal with the whole process of introducing a new stack and put it on the wiki page or send it to the mailing list? I'll make it part of the proposal itself
18:00:19 <nirik> just yum install python35 right?
18:01:36 <bkabrda> I'll try to go through orionp's proposal and think about it some more, but I guess it makes sense and it's easier. I'll try to sum up advantages and disadvantages for the next meeting (althgouh I'll probably not be able to attend myself)
18:01:56 <bstinson> the mailing list would work well for this too
18:02:01 <bkabrda> bstinson: sure
18:02:19 <bstinson> ok, 30 second open floor :)
18:02:22 <bstinson> #topic Open Floor
18:02:29 <bkabrda> bstinson: orionp: let's continue this on ML, I really need to go :)
18:02:40 <bstinson> bkabrda: again, thanks for your work so far
18:02:43 <bkabrda> thanks guys and see you!
18:02:51 <orionp> will do, sorry to drop this now, thanks again for everything
18:03:03 <nirik> thanks much bkabrda!
18:03:26 <bstinson> anything else before I close?
18:04:08 <bstinson> thanks everyone!
18:04:11 <bstinson> #endmeeting