Meeting minutes - today's Env-and-Stacks WG meeting (2013-11-26)

Tue Nov 26 14:18:32 UTC 2013

=============================
#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_stacks.2013-11-26-13.00.log.html
.

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_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