env-and-stacks
LOGS
16:02:04 <mmaslano> #startmeeting Env and Stacks (2014-02-25)
16:02:04 <zodbot> Meeting started Tue Feb 25 16:02:04 2014 UTC.  The chair is mmaslano. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:02:04 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:02:09 <mmaslano> #meetingname env-and-stacks
16:02:09 <zodbot> The meeting name has been set to 'env-and-stacks'
16:02:16 <mmaslano> #chair abadger1999 pkovar tjanez samkottler bkabrda drieden hhorak juhp mmaslano
16:02:16 <zodbot> Current chairs: abadger1999 bkabrda drieden hhorak juhp mmaslano pkovar samkottler tjanez
16:02:21 <mmaslano> #topic init process
16:02:38 * samkottler is here
16:02:44 <abadger1999> hello
16:02:46 <tjanez> hey
16:02:54 <drieden> hello
16:03:00 <pkovar> hey
16:03:11 <mmaslano> I have terrible network
16:03:16 * hhorak_eng is late, sorry ;)
16:03:19 <mmaslano> hopefully, I will make it
16:03:54 <tjanez> mmaslano, hope you stay "alive" :)
16:04:02 <mmaslano> #topic additional repository
16:04:21 <mmaslano> let's start with name, that must be easy :)
16:04:38 <mmaslano> firstly, many people around didn't know word mantle ;-) so I would stop thinking about this one
16:05:06 <samkottler> +1 mmaslano
16:06:59 <mmaslano> you are quite today :)
16:07:08 <hhorak> since we want one universal repository for start, I'd also eliminate ugly
16:07:17 * abadger1999 agreed with tjanez's summary.
16:07:29 <abadger1999> so I liked playground.
16:08:10 <drieden> +1 abadger1999
16:08:10 <tjanez> In addition to what I wrote on the ML, I concur with drieden's reasoning
16:08:37 <drieden> tjanez thank you.
16:09:14 <mmaslano> I would prefer incubation, because playground doesn't sound like ugly things in repo
16:09:47 <samkottler> incubation is okay with me, too
16:10:05 <samkottler> although it does indicate that the packages will end up in the main repos, which is not necessarily true
16:10:14 <hhorak> so do we "invite new people" or "warn people" in the first place? or rather both?
16:10:41 <mmaslano> I would prefer warning
16:10:45 <abadger1999> samkottler: <nod> That is what I don't like about incubation.
16:10:52 <tjanez> mmaslano, the problem with incubation, staging is that it doesn't reveal the nature of the repository and hints at a different kind of repository that we might have in the future
16:12:03 <tjanez> hhorak, yes both, and I think playground can be interpreted in both ways
16:13:13 <tjanez> If we have to choose though, I would rather have a name that invites new contributors to Fedora than a name that warns of potential drawbacks of the repository
16:13:33 <tjanez> The drawbacks can be stated in the description of the repository
16:14:45 <mmaslano> I do not care much if it's not something terrible :)
16:15:06 <mmaslano> #proposal additional repository should have name - playground
16:15:10 <mmaslano> votes?
16:15:27 <drieden> +1 for playground
16:15:28 <mmaslano> I guess we are using samearguments over and over
16:15:42 <hhorak> +1 playground
16:15:49 <abadger1999> +1
16:15:52 <tjanez> +1
16:16:22 <mmaslano> peer presure
16:16:22 <pkovar> +1
16:16:23 <mmaslano> +1
16:16:52 <samkottler> +1
16:19:07 <mmaslano> #agreed additonal repository will be called playground
16:19:37 <mmaslano> #undo
16:19:37 <zodbot> Removing item from minutes: AGREED by mmaslano at 16:19:07 : additonal repository will be called playground
16:19:44 <mmaslano> #agreed additonal repository will be called playground (+7,-0,0)
16:19:56 <mmaslano> #topic github-like frontend for copr
16:20:14 <mmaslano> thanks bkabrda for summary on mailing list
16:22:44 <hhorak> I'm thinking if it would be possible to extend the existing fedora git repo with some functionality, rather than creating another repo
16:23:28 <tjanez> I would be interested in what people think of having GitHub-like interface for working with packages
16:23:38 <mmaslano> I was wondering if people love github so much, if infrastructure can change ugly git on fedorahosted to gitlab
16:23:55 <mmaslano> gitlab (github like)
16:24:47 <hhorak> mmaslano: I don't know for sure but it might be just addition, not replacement..
16:25:01 <abadger1999> If people want github... I don't think writing our own on top of copr is the way to go.
16:25:05 <abadger1999> It's a lot of work
16:25:06 <mmaslano> hhorak: currently, you have the ugly trac instance
16:25:18 <mmaslano> abadger1999: I didn't say for copr :)
16:25:34 <abadger1999> I'm more in favor of the "build from arbitrary git repos including github" approach
16:25:45 <mmaslano> abadger1999: yeah, it's finefor now
16:25:53 <samkottler> abadger1999: +1
16:26:31 <abadger1999> mmaslano: Re: gitlab... I wouldn't hold my breath on that.  There's problems with the software that aren't priorities for upstream and it's a new large packageset that infra has no experience with.
16:27:05 <hhorak> abadger1999: yeah, I'd rather see any other repo to be an orthogonal feature to "build from git"
16:27:07 <mmaslano> abadger1999: I don't like web git interfaces, so I don't care ;-)
16:27:29 <mmaslano> do we want just new feature in copr?
16:27:33 <mmaslano> build from git
16:27:35 <abadger1999> we could put it on a wishlist (so infra could ask rh for new hires specifically to enable and maintain that, for instance), but I think integration with github might be more immediately usable.
16:27:50 <hhorak> mmaslano: I'd say so, as the first step.
16:27:58 <abadger1999> <nod>
16:28:38 <abadger1999> +1 build from git.
16:30:09 <hhorak> In case git contains a spec file with valid source archive url, it should work. But usually we need to create the source tar ball somehow from git repo and this is the step I'm still missing.
16:30:32 <tjanez> abadger1999, +1, the upstream's direction and behavior is not very healthy
16:30:40 <abadger1999> hhorak: I don't think any of the proposals deal with that (exploded trees).
16:31:16 <tjanez> I agree that we probably don't have resources to write our own GitHub-like interface
16:31:28 <tjanez> +1 just add build from git feature to COPR
16:32:08 <mmaslano> hhorak: I don't know in spec is usually tarball link
16:32:32 <abadger1999> hhorak: Creating a tarball could be handled by the packager creating the tarball and uploading to fedorapeople, for instance.
16:33:05 <abadger1999> hhorak: it wouldn't pass packaging guidelines but that's not a goal of the packages in the playground repo :-)
16:34:35 <hhorak> abadger1999: right, this is how people do it now. so what do we actually mean by "building from git"? As I understood it we wanted to remove this step.
16:34:58 <hhorak> * by "this step" I meant preparing & uploading the tar ball
16:35:20 <abadger1999> hhorak: my understanding was just to enable copr to have a git repo for tracking changes to the spec file, patches, etc.
16:35:36 <abadger1999> hhorak: exploded trees is a different discussion.
16:36:19 <abadger1999> hhorak: we are able to leave out cration and uploading of an srpm if we build from git.
16:36:44 <tjanez> I also though like hhorak, that build from git means that we want to avoid the manual spec of preparing a SRPM
16:36:50 <abadger1999> hhorak: and if the url in the spec file points to an upstream tarball that is reliable, we wouldn't have to create and upload a tarball either.
16:36:54 <mmaslano> tjanez: me too
16:37:08 <abadger1999> I agree.  we are not having to upload an srpm.
16:37:22 <abadger1999> but we may have to upload a source tarball (if upstream doesn't provide one)
16:38:03 <abadger1999> maybe we're meaning the same things but are getting confused in the wording we're using :-)
16:38:15 <hhorak> abadger1999: probably
16:38:31 <tjanez> also, as I understood things, msuchy doesn't want COPR to start "hosting" git repos
16:38:45 <tjanez> or what did you mean abadger1999?
16:38:58 <abadger1999> +1 to not hosting git repos in copr
16:39:18 <tjanez> Ok, cleared up then :)
16:39:31 <abadger1999> I think the idea is to bring an equivalent to the pkgs.fedoraproject.org + fedpkg + koji workflow to coprs.
16:40:30 <mmaslano> if you think about it, it's also not very good for packages, because they would have one git for Fedora, different git for copr packages, another git for their own projects...
16:40:32 <tjanez> Yes, as I see it, the main benefit of using GitHub (or something similar) is to extend *basic* COPR repositories with SCM, lightweight issue reporting, improved collaboration options
16:40:45 <abadger1999> where our equivalent pieces might be github + web form field to add a url to a git repo+tag, copr
16:41:18 <abadger1999> tjanez: +1
16:42:19 <mmaslano> I'm still not sure if it's needed
16:42:22 <abadger1999> A hosting provider like github also gets people bug tracking which is not something we've planned any other method of doing.
16:42:36 <mmaslano> if you have big project, you have your own git, probably with bug reporting
16:42:53 <mmaslano> in small project, when you just rebuild something, it's not needed/wanted
16:42:53 <tjanez> mmaslano, I agree that having too many git repos is not so great, but I think having two, one for the upstream project and the other for packaging, which contains branches, patches on top of the upstream sources, etc.
16:43:05 <pjones> abadger1999: and it's nice, because you get bug tracking at the same place as your project, not at some other place like we usually have with rh bugzilla
16:43:15 <abadger1999> mmaslano: Yes, but this is about packaging... which may be by upstream but also may be by downstream.
16:43:21 <abadger1999> pjones: +1
16:43:52 <mmaslano> abadger1999: why don't we wait for real use-cases
16:44:07 <tjanez> pjones, +1
16:44:45 <abadger1999> mmaslano: Well -- just look at existing coprs for use cases... chromium, for instance
16:45:10 <mmaslano> abadger1999: it might be bad example. It's already in Fedora, isn't?
16:45:41 <abadger1999> not created by upstream.  large software that could do with bug tracking against the packages
16:45:42 <tjanez> mmaslano, no, it's not in Fedora, but is a very good candidate for the new Fedora Playgroud repo
16:45:51 <abadger1999> mmaslano: Not unless it's under a different name
16:46:35 <tjanez> abadger1999, +1 regarding downstream packaging that could use a bug tracker etc.
16:46:44 <mmaslano> abadger1999: my point was anyone can create their own git somewhere, we don't have to do it. Not now
16:46:53 <abadger1999> mmaslano: agreed.
16:47:39 <mmaslano> #info copr should be able to build from git url
16:47:50 <mmaslano> #action mmaslano will ask for RFE
16:48:20 <tjanez> So is there any *political* issue in encouraging packages that will become part of the Playgroud repo to use GitHub/Bitbucket/etc. for SCM, issue tracking, ...
16:48:56 <abadger1999> there is a small bit as the software running those places is not open source.
16:49:15 <abadger1999> I don't think it's a political problem that the Board would veto the idea because of.
16:50:02 <abadger1999> It's also mitigated because we aren't saying "you must use github for this" -- you can host at an all-open-source git repo or still upload srpms.
16:50:21 <abadger1999> maintainers' choice.
16:50:56 <pingou> gitorious is opensource
16:51:13 <tjanez> Ok, then I'm really +1 on building on this for the new Playground repo
16:53:20 <hhorak> so to summarize it, users would create some new git repo on a web of their choice; the repo would contain a spec file, patches, etc. (+ usually lightweight bug tracking system) and users would upload their source tar ball to be somewhere publicly available..
16:53:22 <hhorak> So the change in copr would be that the copr would create srpm from these things instead of users.
16:53:43 <hhorak> Did I understand it correctly?
16:53:45 <abadger1999> hhorak: +1
16:54:26 <hhorak> +1 so that sounds fine for me
16:54:36 <drieden> +1
16:54:39 <abadger1999> copr would only need to grow a way to specify the git url + revision.  copr could use spectool -g  (or equivalent) to retrieve the tarballs and other sources not in the git repo.
16:54:57 <tjanez> +1, or the source tarball could actually come from the upstream directly
16:55:09 <mmaslano> #info opr could use spectool -g  (or equivalent) to retrieve the tarballs and other sources
16:55:15 <mmaslano> #undo
16:55:15 <zodbot> Removing item from minutes: INFO by mmaslano at 16:55:09 : opr could use spectool -g  (or equivalent) to retrieve the tarballs and other sources
16:55:19 <mmaslano> #info copr could use spectool -g  (or equivalent) to retrieve the tarballs and other sources
16:57:16 <abadger1999> Do we have more on the agenda?
16:57:34 <mmaslano> set policy what can be added into repo :)
16:57:51 <mmaslano> abadger1999: or we can ask you where is scl in Fedora currently ;-)
16:57:55 <mmaslano> whichever you prefer
16:58:09 * abadger1999 would like us to start thinking about what we need to give to fesco about changes for f21
16:58:29 <abadger1999> scl in fedora update is fine from me if you want it.
16:59:05 <abadger1999> I've been tlaking with Jan Zeleny about changes to scl-utils and updating the guideline draft.
16:59:36 <abadger1999> I have copr repos up with a sample scl.
16:59:48 <abadger1999> http://copr-fe.cloud.fedoraproject.org/coprs/toshio/SCL-Test-Python2.4/builds/
17:01:02 <abadger1999> Right now -- working on fixing the guidelines wrt defining macros which should hopefully allow me to get python scls to work. (__os_install_post needs to be overridden for python packages to be buildable)
17:01:44 <mmaslano> abadger1999: you should ask bkabrda. He used some scl_overrides
17:01:52 <mmaslano> I do not think anyone else use them
17:02:08 <abadger1999> after that I need to build some test mariadb packages to see that the move of state files and config files to /var/opt/* and /etc/opt/* work correctly.
17:02:48 <hhorak> abadger1999: I can help you with that if you want
17:03:04 <hhorak> abadger1999: with the mariadb stuff
17:03:09 <abadger1999> mmaslano: <nod>  Yeah -- I found that technique in one of his spec files yesterday.  I need to verify that it works and then send him and Jan an email to ask if we should make that hte mandatory way to handle macros in scls.
17:03:49 <mmaslano> abadger1999: no, it doesn't work in perl ;-)
17:03:49 <tjanez> abadger1999, when you are finished with the SCL in fedora part, I would like you to elaborate on 'what we need to give to fesco about changes for f21'
17:04:04 <abadger1999> hhorak: Cool.  I first want to try doing it on my own to make sure someone can follow the guidelines to produce packages.  But I'll definitely ping you if I get stuck.
17:04:17 <abadger1999> That's all I have on SCLs.
17:04:28 <mmaslano> abadger1999: did Jan agreed with your changes for scl-utils?
17:04:29 <abadger1999> any other questions or comments?
17:04:37 <hhorak> abadger1999: ok
17:05:04 <abadger1999> mmaslano: I've run one by him via email that he has agreed to.  (the /var/opt one) I'll get you a bug report link.
17:05:21 <mmaslano> abadger1999: I saw the bug, but no reply there
17:05:43 <abadger1999> mmaslano: I'll have to send him some patches for python bytecompile... I think he'll accept them  -- I just need to verify they work once I override __os_install_post before opening a bz for that.
17:06:03 <abadger1999> mmaslano: <nod>  Yeah -- there was discussion in email -- I'll forward you the email if you've already seen the bug.
17:07:47 <abadger1999> We ready to move on?
17:08:10 <mmaslano> yeah sure
17:08:18 <mmaslano> tjanez: please, start
17:08:56 <tjanez> mmaslano, which topic?
17:09:10 <mmaslano> #topic what we need to give to fesco about changes for f21
17:09:50 <tjanez> ok, I didn't know what abadger1999 meant with that sentence
17:09:59 <tjanez> abadger1999, care to explain?
17:10:30 <abadger1999> So fesco needs to coordinate the tasks that need to be done for fedora.next in order to get f21 created.
17:11:16 <abadger1999> They would like to get information from the working groups about what the WG's want to do that requires changes/additions/new work in fedora.
17:11:48 <tjanez> It seems to me none of the things we are doing should block F21 or any other release
17:11:57 <abadger1999> The idea being, then they can talk to releng, qa, infrastructure, etc about what new things they would need.
17:12:20 <tjanez> unless, some product requires some new technology from us, like the Playgroud repo
17:12:43 <abadger1999> tjanez: I partially agree -- we don't block the releases.  But we might not be able to get our plans implemented if we don't say "we need the following resources"
17:13:00 <tjanez> abadger1999, +1
17:13:36 <abadger1999> Like this new repo -- does it need additional space on the master mirror?  Will it go out to our mirror network?  Does it need to be mashed in order to get multilib support?
17:13:54 <abadger1999> Those are things that will require time from infrastructure and rel-eng.
17:14:18 <tjanez> Yup, understood.
17:15:03 <tjanez> In my view, there are two parts of the Playground repo: the repository itself and the automatic review/gating service/server
17:15:04 <mmaslano> what's mashed?
17:15:14 <abadger1999> Cool.  So we should start assembling a plan for implementing the new repo and who else will need to help in order to get it operational.
17:16:04 <mmaslano> we need space for repo
17:17:12 <abadger1999> mmaslano: we build packages for x86_64 and x86 separately.  But the user's of x86_64 are able to download x86 libraries to run x86 software on x86_64.  mash is a program that releng runs to take the needed x86 builds and put them into the x86_64 yum repo.
17:18:58 * nirik also notes: deltarpms? signing ? how do updates work? is there a testing repo? does it need adding to mirrormanager? will fedup support upgrades with packages there?
17:19:49 <abadger1999> h<nod>
17:20:14 <tjanez> nirik, +1 on having to answer those questions
17:20:55 <mmaslano> abadger1999: um okay that answered my question
17:21:04 <abadger1999> k.
17:21:14 <abadger1999> So for aplan to provide this to fesco...
17:21:26 <abadger1999> How about I create a wiki page for it.
17:21:33 <tjanez> nirik, do you have a wiki or some other document (script even) explaining the workflow in preparing existing repositories?
17:21:49 <abadger1999> and then we can brainstorm to fill in the plan.
17:21:57 <nirik> tjanez: not off the top of my head. there might be some releng pages on the wiki related...
17:22:31 <abadger1999> and next week we can answer any outstanding questions so that we can submit (at least a draft) to fesco.
17:23:21 <tjanez> nirik, ok, if you have something, could you share it?
17:23:37 <tjanez> s/have/find
17:23:42 <tjanez> abadger1999, +1
17:23:44 <mmaslano> nirik: you are probably only one able to name everything
17:23:47 <mmaslano> abadger1999: +1
17:23:57 <nirik> sure, happy to.
17:24:39 <tjanez> nirik, thanks!
17:25:24 <drago01> mmaslano: the mash stuff is what I was talking about on the list
17:27:29 <mmaslano> do we want to continue?
17:27:45 <abadger1999> #action abadger1999 to start wiki page for playground repo resources.  Group will brainstorm and solidify plans this week.
17:28:12 <mmaslano> abadger1999: thanks, sounds good
17:28:46 <hhorak> mmaslano: I'll need to go in couple of minutes
17:29:06 <mmaslano> let's go home
17:29:21 <mmaslano> I'll close meeting in a minute
17:29:41 <tjanez> yes, let's end for today
17:29:46 <drieden> sounds good
17:31:12 <abadger1999> Sounds good.
17:32:10 <mmaslano> #endmeeting