Log in

Previous Entry | Next Entry

Environment and Stacks Working Group discussed again what our group should
be doing. I guess this time we broadly defined first goal. At least it
looked like consensus of opinions.

bkabrda proposed topic:
tools for setting up development environments/more
automation for packaging/providing stacks. This topic was discussed for
rest of the meeting.

pingou joined our discussion, because he had work on a tool, which could
help with automation of package reviews outside of bugzilla. He might be
able to work on it more, after he will finish pkgdb2.
The tool can work with packages like R, perl, python and php. All these
packages have *2spec or *2rpm tools, which already can help with packaging.
Haskell can be build from upstream into srpms with cabal-rpm. The
critical part of reviews are licenses. With cooperation with copr we could
have automatically update repositories generated from upstream sources.
tjanez said, it could be incubated within our WG first and then proposed
to general (core) Fedora audience. In my opinion we could put those
packages into non Fedora repo for a while and decide the Fedora workflow later.

These sub-goals were summarized mainly by tjanez:
To provide repositories with automatically updates specs and generated rpms of
Python, Perl, etc. modules that are ALREADY in Fedora.
* In a way, the repository would follow the upstream release schedule.
* As soon as the upstream puts it on CPAN, PyPI, it would be available in the
repo unless there is a major version with API/ABI bump that we cannot back port.
* ABI/API breakage should be checked by api-checker. Tools exist, just no-ones
runs them automatically on new packages.
* The automatic packaging helps to see the automatically updated spec file and
the generated rpm, so they have less work updating the packages. Eager users
can enable them AS IS.
* The other idea is to enable easier/quicker packaging of dependent RPM files
by generating spec files for the packager automatically by review tool.
* There was also an idea regarding trying out a new kind of package review
process (via to-be-developed review app). There already exist some rebase
helper (hhorak will find out more).
* Some sort of CI (common integration) for our package repositories.
* Jenkins http://jenkins.cloud.fedoraproject.org/job/javapackages-tools/
(that's CI for Java tooling - requires/provides generators etc).
* Pingou had started to work on something using datagrepper that we could use
to rebuild automatically all packages that have not been rebuild for 1 Fedora.

See full log for whole conversation.



( 2 comments — Leave a comment )
Nov. 29th, 2013 08:53 am (UTC)
pingou's tool
So what's the difference between the tool you mention and fedora-review-tool?
Nov. 29th, 2013 09:37 am (UTC)
Re: pingou's tool
The tool should help with automatization of packaging. The fedora-review is only giving recommendation what should be improved.
( 2 comments — Leave a comment )