=============================
#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
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
