13:00:25 <mmaslano> #startmeeting (2013-11-26)
13:00:25 <zodbot> Meeting started Tue Nov 26 13:00:25 2013 UTC.  The chair is mmaslano. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:00:25 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
13:00:47 <mmaslano> #meetingname Environment and Stacks
13:00:47 <zodbot> The meeting name has been set to 'environment_and_stacks'
13:01:03 <mmaslano> #chair abadger1999 pkovar tjanez samkottler bkabrda handsome_pirate hhorak juhp
13:01:03 <zodbot> Current chairs: abadger1999 bkabrda handsome_pirate hhorak juhp mmaslano pkovar samkottler tjanez
13:01:15 <mmaslano> #topic init process
13:01:21 <mmaslano> hi guys
13:01:29 <tjanez> hi
13:01:40 <bkabrda> hey
13:01:49 <hhorak> Hi all
13:02:29 <juhp_> hi
13:06:25 <mmaslano> so, do we continue discussion from last week?
13:06:36 <mmaslano> I saw lot of ideas what we should be doing on mailinglist
13:06:48 <mmaslano> but I guess we need higher level ideas...
13:07:10 <juhp_> yes
13:08:14 <tjanez> mmaslano: I agree that we should maybe try to define what our WG in a more general way
13:08:24 <juhp_> should we try to collect ideas somewhere and then try to extract higher level goals from there perhaps?
13:08:45 <mmaslano> tjanez: definitely
13:09:44 <tjanez> juhp_: the piratepad last week was an attempt
13:09:53 <mmaslano> #info http://piratepad.net/PwUiH4MEPR
13:09:59 <tjanez> juhp_: It's been copied to https://fedoraproject.org/wiki/User:Toshio/Env_and_Stacks_Charter_Brainstorming
13:10:01 <mmaslano> we can continue there
13:10:31 <hhorak> having in mind concrete ideas from mailing list, we can ask WHY we want to do it and we should get more general ideas
13:10:59 <juhp_> tjanez, thanks - I just opened the pad
13:12:02 <juhp_> it looks more formal than what I had in mind at this stage but good
13:12:49 <mmaslano> it should be shorter
13:12:57 * pkovar is late
13:13:36 <tjanez> one of the high-level goals which comes to mind is "to enable inclusion of all (legally acceptable) stacks in Fedora, which are not possible in today's Fedora landscape (policies, guidelines, tools, ...)"
13:14:07 <tjanez> I'd put it in the pad, however, I don't know where to put it
13:15:15 <juhp_> tjanez, yes
13:15:51 <juhp_> right that is why I would prefer a more free-form wiki page for branch-storming
13:16:12 <sochotni> juhp_: brainstorming?
13:16:21 <juhp_> ah yes thanks ;)
13:16:24 <juhp_> :)
13:16:29 <juhp_> lol
13:17:26 <tjanez> Another thing we should do is define the terms environment and stacks
13:17:32 <juhp_> sochotni, also agree with your idea of a package review app - that seems totally needed - dunno if it is really in the scope of this WG per se
13:17:54 <sochotni> juhp_: it's probably more in line with core fedora infra
13:17:58 <mmaslano> tjanez: personally, I don't are what is stack and what is environment
13:17:59 <juhp_> yes
13:17:59 <sochotni> i.e. generic tooling
13:18:24 <juhp_> could we just be the Stacks WG? :)
13:18:32 <mmaslano> sure  :)
13:19:01 <juhp_> seems okay to me too
13:19:36 <bkabrda> so my high-level proposal: tools for setting up development environments/more automation for packaging/providing stacks (meaning python2/python3, ruby/jruby)
13:19:36 <sochotni> I agree it would be less confusing
13:19:40 <juhp_> maybe Env is supposed to imply more than Stacks? <shrug/>
13:19:47 <mmaslano> maybe
13:19:58 <mmaslano> #topic tools for setting up development environments/more automation for packaging/providing stacks
13:21:03 <tjanez> I would also be for just Stacks WG :), but juhp_ has a point, maybe we want to also work on improving the development environment
13:21:12 <tjanez> here is where "environment" comes in :)
13:21:20 <juhp_> true
13:21:34 <juhp_> so maybe we are good with the name then :)
13:22:33 <sochotni> pingou | sochotni: I had started something yes, but I haven't touched it in a while
13:22:42 <sochotni> that was wrt review app
13:23:06 * pingou looks at the title
13:23:12 <tjanez> sochotni: I liked your idea regarding the Fedora review app
13:23:21 <mmaslano> it could improve the process, it could help automatization
13:23:30 <juhp_> yes
13:23:45 <tjanez> sochotni: I think it could be incubated within our WG first and then proposed to general (core) Fedora audience
13:23:57 <mmaslano> tjanez: sounds good
13:24:01 <pingou> I need to get pkgdb2 out of the door, but if there is such a demand I can start working again on the review app
13:24:20 <mmaslano> pingou: I was thinking about automatic generation of srpm from some upstreams
13:24:50 <pingou> mmaslano: things like R, perl, python (to some extend) and php would be pretty easy
13:25:08 <pingou> we already have a bunch of *2spec and sometime even *2rpm
13:25:25 <pingou> the critical part of the review becomes more the license than the spec file
13:25:44 <mmaslano> pingou: yes, we have tools, which we are using for generation of packages
13:26:09 <sochotni> in cooperation with copr we could have automatically updated repos
13:26:11 <pingou> but maybe we could come up with something like: insert here you upstream project url to tarball -> get your srpm here and your rpm from this copr repo
13:26:26 <sochotni> yeah
13:26:27 <juhp_> my cabal-rpm tool can generally generate haskell srpms from upstream but of course that is special case
13:26:46 <mmaslano> pingou: big picture :) give a list of modules, which we want from cpan/other sources and receive them in srpm :)
13:26:48 <sochotni> being able to build stuff by giving Fedora service a github url with sources would be nice :-0
13:26:51 <pingou> a first thing would be to gather all these projects :)
13:27:11 <mmaslano> pingou: we don't need everything available, just list of what's interesting
13:27:24 <pingou> mmaslano: I mean the *2spec projects
13:27:31 <pingou> to see which area we cover
13:27:48 <mmaslano> ok
13:28:08 <mmaslano> pingou: i was also thinking about helper for updating existing packages
13:28:26 <pingou> I've been playing in the R field quite a bit, we have R2spec in the repo that comes in with a R2rpm flavor, the issue of on building the deps when provided with a certain project
13:28:33 <juhp_> mmaslano, yes
13:28:39 <tjanez> So, if I understand correctly, there is demand for an RPM repository that contains all, e.g. CPAN, Pypi packages?
13:28:50 <pingou> mmaslano: one day I will want to write an easy spec API in python :)
13:29:02 * pingou already has his own UpdateRPackage.py that does it :]
13:29:12 <bkabrda> tjanez: I wouldn't say all. more like some of them ("important") in the latest versions or so
13:29:19 <pingou> tjanez: only the one the user asks
13:29:22 <mmaslano> tjanez: not all, we could do only what we have in Fedora. It would safe time which we spend on updates of packages
13:29:27 <pingou> tjanez: maybe like: all the deps for projects X
13:30:17 <tjanez> Aha, ok, this is a bit different
13:30:27 <tjanez> then what I though :)
13:30:52 <tjanez> I would like to come up with some high-level description of what we want this *2spec tools and repositories coming from that
13:31:12 <pingou> (why do I feel like there is an interesting mailing-list I'm missing? :))
13:31:20 <mmaslano> I gues we have one are what we want to do
13:31:41 <mmaslano> pingou: it should be discussed on our mailnig list, but it wasn't yet
13:31:45 <samkottler> pingou: it hasn't gotten very interesting yet, but you should join the stack-and-envs list
13:31:54 <pingou> samkottler: thanks ;)
13:32:13 <juhp_> envs-and-stacks :)
13:32:24 <pingou> yup I corrected and subscribed, thanks
13:32:38 <samkottler> heh, I figured he'd be able to find it regardless :)
13:32:46 <juhp_> great
13:33:02 <tjanez> One of the goals would be: "To provide repositories with automatically updates specs and generated rpms of Python, Perl, etc. modules that are ALREADY in Fedora"
13:33:24 <juhp_> do we have to restrict to in Fedora already?
13:33:25 <mmaslano> sounds good to me as high level goal
13:33:37 <tjanez> So in a way, the repository would follow upstream release schedule
13:33:44 <pingou> I'd wouldn't do it for things which are already in Fedora
13:33:55 <tjanez> As soon as the upstream puts it on CPAN, PyPI, it would be available in the repo
13:34:04 <pingou> unless indeed there is a major version with API/ABI bump that we cannot back port
13:34:09 <samkottler> there'd be huge bloat in the repos if we did it for everything
13:34:19 <pingou> but otherwise I'd go mroe w/ automated rpm generation for the missing deps
13:34:32 <mmaslano> samkottler: I would prefer only list of important as was said
13:34:36 <juhp_> there could be a middle way - but yeah if you want full automation...
13:34:38 <tjanez> juhp_, pingou: I'm just discussing, I would like to see your point
13:35:06 <samkottler> we might have to figure out how to track ABI changes over time because lots of library authors don't properly version
13:35:31 <pingou> copr is clearly going to lack the space to fully automatically build everything + I just don't think we want that anyway
13:35:51 <juhp_> if we had a lower barrier of entry than main fedora repos it would be a good testing ground for new candidate packages/stacks too
13:36:12 <mmaslano> yeah, but the space on copr is a real problem
13:36:46 <juhp_> sure not everything - I am just suggesting we don't have to restrict to fedora only packages - and even if we do there will be new dependencies that need to be packaged anyway
13:36:46 <pingou> mmaslano: well not so far, but might become yes
13:36:53 <tjanez> juhp_: Yes, I agree, but who should select which subset of PyPi/CPAN is interesting and packaged automatically AS IS
13:37:10 <juhp_> tjanez, right I dunno
13:37:20 <hhorak> samkottler: I already started looking into it and rather than one spicific api/abi testing tool I'd like to come up with some general tool that could test more than that and would be easy to run the same on localhost or in the infrastructure
13:37:29 <pingou> juhp_: I'd go more the opposite, copr are complementary to the official fedora repo, so don't re-build what already is
13:37:33 <juhp_> perhaps additional packages could be added/proposed somehow shrug
13:37:49 <tjanez> juhp_, or do it like AUR in Arch
13:37:59 <juhp_> pingou, okay perhaps - but then what about newer versions
13:38:11 <juhp_> tjanez, yea
13:38:31 <sochotni> hhorak: you mean rpm QA tool?
13:38:36 <pingou> juhp_: then it would appply indeed, but only on branch where this update hasn't been done (for example to get django 1.6 on F20)
13:38:48 <juhp_> sure
13:39:22 <hhorak> sochotni: something like that..
13:40:33 <juhp_> I like the overall idea we're creating
13:40:57 <tjanez> juhp_: +1
13:41:20 <sochotni> pingou: for the logs, can you point to the codebase for current review tool?
13:41:51 <pingou> http://ambre.pingoured.fr/cgit/review_srv.git/
13:42:20 <tjanez> Could someone attempt to summarize the general idea of the discussion?
13:42:21 <pingou> but it's still quite far from complete
13:42:37 <mmaslano> juhp_: +1
13:42:58 <sochotni> pingou: I don't expect anything else :-)
13:43:13 <sochotni> it's just something to start off from
13:43:39 <pingou> sochotni: for the record I did put it on the list of things I would like to work on next year (sent to my manager :))
13:44:02 <pingou> so I might get some time to revive it
13:44:08 <sochotni> pingou: good!
13:46:42 <tjanez> So, my attempt at summarization: one idea regarding the automatic packaging is to help existing maintainers see the automatically updated spec file and the generated rpm, so they have less work updating the packages, and to enable the eager users to use them AS IS
13:46:57 * mmaslano has to leave in 14 minutes
13:47:09 <mmaslano> tjanez: yes
13:47:30 <mmaslano> tjanez: I would be fine with summarization of what we said -> first goal
13:47:44 <juhp_> tjanez, I might add early access to packages/stacks still under/before package review
13:47:44 <mmaslano> and next week we can speak about different area
13:48:21 <tjanez> juhp_: yes, agreed
13:48:30 <tjanez> the other idea I saw was: The other idea is to enable easier/quicker packaging of dependent RPM files by generating spec files for the packager automatically
13:48:49 <mmaslano> #info So, my attempt at summarization: one idea regarding the automatic packaging is to help existing maintainers see the automatically updated spec file and the generated rpm, so they have less work updating the packages, and to enable the eager users to use them AS IS
13:48:50 <juhp_> yes
13:48:58 <mmaslano> #info the other idea I saw was: The other idea is to enable easier/quicker packaging of dependent RPM files by generating spec files for the packager automatically
13:49:42 <hhorak> sounds fine.
13:50:21 <tjanez> There was also an idea regarding trying out a new kind of package review process (via to-be-developed review app)
13:50:45 <hhorak> I remember I heard already of some "rebase helper" that could be used (if ready).. I'll try to get more info and will send to ML.
13:50:50 <tjanez> which could be incubated within our WG and then re-iterated/refined for proposal into Fedora proper
13:52:34 <tjanez> Along side the new review process, we could rethink the packaging guidelines (along the ideas proposed in the ML)
13:53:22 <sochotni> I believe whole approach to packaging could be changed/improved while preserving current guidelines
13:53:31 <sochotni> just giving us more time to actually care bout it
13:55:02 <juhp_> yeah
13:55:36 <tjanez> sochotni: Yes, agreed. I was thinking about also improving the documentation on the Wiki pages so it would be shorter and not mix guidelines, best practices, etc.
13:55:51 <tjanez> But this could be improved independently
13:56:29 <juhp_> that is true - more streamlining and separating to the bare essentials would be good
13:56:30 <tjanez> I also like the idea proposed by hhorak about some sort of CI for our package repositories
13:57:01 <tjanez> So that we ensure that the already included packages stay in good shape
13:57:13 <tjanez> Spec files come to mind first
13:57:40 <sochotni> tjanez: http://jenkins.cloud.fedoraproject.org/job/javapackages-tools/ (that's CI for Java tooling - requires/provides generators etc)
13:57:45 <pingou> I had started to work on something using datagrepper that we could use to rebuild automatically all packages that have not been rebuild in, say, 1 fedora release
13:58:23 <pingou> if that's also of interest, I could pick it up again :)
13:58:25 <mmaslano> I need to go, volunteer who take chairman?
13:58:42 <tjanez> sochotni: Cool, I will check it our
13:59:46 <mmaslano> no volunteer?
13:59:56 <sochotni> we are getting to one hour....we'll just have to pick it up later
14:00:03 <mmaslano> #endmeeting