============================= #fedora-meeting: (2013-11-26) =============================

Meeting started by mmaslano at 13:00:25 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2013-11-26/environment_and_s... .

Meeting summary --------------- * init process (mmaslano, 13:01:15) * http://piratepad.net/PwUiH4MEPR (mmaslano, 13:09:53)

* tools for setting up development environments/more automation for packaging/providing stacks (mmaslano, 13:19:58) * LINK: http://ambre.pingoured.fr/cgit/review_srv.git/ (pingou, 13:41:51) * 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 (mmaslano, 13:48:49) * 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 (mmaslano, 13:48:58)

Meeting ended at 14:00:03 UTC.

Action Items ------------

Action Items, by person ----------------------- * **UNASSIGNED** * (none)

People Present (lines said) --------------------------- * mmaslano (40) * juhp_ (36) * tjanez (35) * pingou (30) * sochotni (18) * hhorak (6) * samkottler (4) * zodbot (4) * bkabrda (3) * pkovar (1) * abadger1999 (0) * juhp (0) * handsome_pirate (0)

Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot

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_Brainstorm... 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