18:03:24 <abadger1999> #startmeeting fpc
18:03:24 <zodbot> Meeting started Thu Sep 26 18:03:24 2013 UTC.  The chair is abadger1999. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:03:24 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:03:54 <Rathann> ok, good luck
18:04:09 <RemiFedora> abadger1999, if I understand correctly, branch name => build tag, so koji env.
18:04:38 <RemiFedora> branch = f20 => f20-build => f20-build-updates-candidates
18:04:41 <bkabrda> I guess review would be needed only for packages that aren't yet in Fedora, for other we would just create new branches in the same way it's done for epel
18:04:49 <abadger1999> RemiFedora: there's no need for that though -- AFAIK that's just set to the same names in koji.
18:05:02 <abadger1999> We used to have F-20  while koji had f20 for instance.
18:05:27 <RemiFedora> but f19 != f20
18:05:47 <abadger1999> bkabrda: <nod>  But that could be seen as a drawback.... FESCo said that package renames needed a rereview and hte changes for a rename are normally less than 5 lines.
18:05:48 <RemiFedora> and so f20 != sclfoo-f20 as it will not use the same build env.
18:06:04 <abadger1999> bkabrda: and the changes for a n scl are definitely more (and more invasive) than that.
18:06:50 <abadger1999> RemiFedora: I'm not sure what you're saying.  Could you spell out hte example more?
18:06:53 <bkabrda> abadger1999: I guess it just seems more practical to me this way, but I don't really see it as a crucial point
18:07:14 <abadger1999> bkabrda: k.
18:08:44 <RemiFedora> abadger1999, when you build for "f20" you need f20-bulid repo + chroot_setup_cmd' = 'groupinstall buildsys-build'
18:09:08 <RemiFedora> for scl you need 'groupinstall buildsys-build  sclfoo-build'
18:09:48 <RemiFedora> notice: I'm not from releng, just trying to explain what I have understand from what I'm using dauly
18:09:56 <RemiFedora> daily
18:10:29 <abadger1999> RemiFedora: <nod>  But I think that's just koji config.  I think we could have a separate package
18:10:57 <abadger1999> where we had different branches that were all scls.
18:11:05 <RemiFedora> but how koji will "compute" what config to use ? from the package name ?
18:11:36 <abadger1999> Probably you'd have different branches i nthe separate package.
18:12:11 <bkabrda> abadger1999: oh, so you want like package sclname-foo with branch sclname-FXX?
18:12:42 <abadger1999> bkabrda: possibly... we've all come to the conclusion that we'd need to talk to releng about what's possible, right?
18:12:51 <bkabrda> abadger1999: agreed
18:13:08 <RemiFedora> yes, I think this is really something which need to be set by releng
18:14:14 <RemiFedora> abadger1999, about specific package (like mingw) ws generic package (like in the draft proposal)
18:14:27 <RemiFedora> I will take php as an example.
18:14:59 <RemiFedora> php itself need lot of change, so can make sens to be a separate package/spec
18:15:09 <RemiFedora> having conditional is just a nightmare
18:15:26 <RemiFedora> for all the others package (php-pear-* or php-pezcl-*) this is just  a trivial change
18:15:36 <RemiFedora> adapting for SCL is a 2' work
18:16:47 <abadger1999> <nod>  -- However, *cough* package renames *cough*
18:17:07 <RemiFedora> and I think this must be a packager choice
18:17:27 <RemiFedora> the reason why I really see scl package as a branch of an existing package.
18:17:29 <abadger1999> To be fair, there's been lots of turnover in fesco since package renames has been decided so maybe the precedent doesn't ocunt.
18:17:43 <RemiFedora> some packager want to keep the same spec in all branch (f20 => epel5)
18:17:53 <RemiFedora> some prefer clean specific per-branch spec file
18:18:25 <abadger1999> <nod>  But this is really a different package from the srpm on up.
18:19:08 <abadger1999> you could build both from the same spec with a lot of conditionalization but even the name of the srpm is different.
18:19:12 <bkabrda> abadger1999: except that you'll usually apply the same patches, fix same CVEs etc.
18:19:17 <RemiFedora> and I'm also a bit afraid about reviews... but well...
18:19:47 <abadger1999> Mmm... that actually also leads to -- bugzilla -- we probably want separate bugzilla entries for the scl than from the "mainstream" package.
18:20:01 <bkabrda> abadger1999: yes
18:20:06 <abadger1999> bkabrda: Uh.... I don't think so.
18:20:11 <abadger1999> (about same patches)
18:20:20 <abadger1999> bkabrda: because you're pegging to a specific version in the scl
18:20:39 <bkabrda> abadger1999: not same as in totally, but as in "you'll usually have to patch both when there is error in one"
18:20:42 <abadger1999> bkabrda: whereas the "mainstream package" will be advancing in version
18:21:03 <abadger1999> <nod> yes, you'll normally have to patch both.  But the patches will be different.
18:21:12 <bkabrda> abadger1999: advancing in rawhide, yes, but not in stable fedoras
18:21:36 <abadger1999> So if you go back to mingw as the precedent -- they're actually more like the "mainstream package" here than scls would be.
18:22:31 <abadger1999> bkabrda: fedora has such a short life cycle and scls have such a long one by comparison that the  difference there is not very large.
18:23:31 <bkabrda> abadger1999: ok, I think the point that we agree on is that when you patch the mainstream package, you'll usually also be patching the scl one... right?
18:24:04 <RemiFedora> bkabrda, you can update to new version in mainstream and backport patch in scl
18:24:23 <bkabrda> RemiFedora: yes, something like that
18:25:11 <abadger1999> attdm's example was raails4 ships in f20.  so he wants a rails3 scl at that time.  So now we have f19, rails3, f20 rails4 & scl-rails3.  In *6 months* we have f20 rails4 + scl-rail3 and f21 rails4.1 + scl-rails3.... there's no longer any supported fedora with a mainstream rails3
18:26:18 <abadger1999> bkabrda: sure -- but that would help if we had source git repos which we don't. We have git repos which contain the patches themselves.
18:27:03 <bkabrda> abadger1999: yep, agreed. I was referring more to the fact that it is more practical for work, if you just have one git repo with more branches and you can merge (even if it is with conflicts) and it is easier to find out which scls may need patching, too
18:27:27 <abadger1999> we have notification of commits.
18:27:44 <abadger1999> For mingw there's a requirement that package maintainers of the mingw packages sign up for commit mail from the main package.
18:28:35 * bkabrda still mumbles something about merging... ;)
18:28:43 <bkabrda> abadger1999: ok, I see your point
18:29:06 <RemiFedora> abadger1999, probably both way work. Probably we should ask infra if they prefer us to double the number of package or the number of branch ? ;)
18:29:54 <abadger1999> RemiFedora: infra/releng + fesco  (I'll ask nirik and dgilmore at the same time next week to get a feel for both)
18:29:59 <RemiFedora> bkabrda, git remote add noncscl ... ; git merge nonscl/f20
18:30:03 <abadger1999> <nod>
18:30:29 <abadger1999> RemiFedora: we could even clone the nonscl master to the scl master.
18:30:48 <abadger1999> so you could pull that from master and then merge if you wanted to.
18:31:36 <abadger1999> But yeah -- i think releng/infra can trump this ifthey don't want to set it up.
18:31:53 <bkabrda> okok, let's ask relengs and infra first and then decide this
18:32:26 <RemiFedora> I just think "another" distro have experience on git + koji setup for scl, so we should take benefit of their solution ;)
18:32:56 <RemiFedora> don't reinvent the wheel...
18:33:40 <abadger1999> RemiFedora: heh -- if we're not reinventing the wheel, then I think we should throw out the underpinings and use environment modules w/ some standardized directory paths ;-)
18:33:47 <abadger1999> j/k
18:34:04 <bkabrda> :)
18:34:29 <RemiFedora> time limit for me in about 15'   (children are hungry...)
18:34:33 <bkabrda> ok, so... shall we end for today? it's sort of late here
18:36:00 <abadger1999> Yep, let's end.
18:36:03 <abadger1999> #endmeeting