----- Original Message -----
first of all, do we have some sort of wiki? We should agree on the tasks below, prioritize
them and write them down, IMO.
We need to clean it and review by those who are aware of these area.
+1. We could write the list (on the wiki?) and assign people who will work on these.
There is a lack in articles about recommended configuration and
step-by-step instructions for the most used scenarios. Particularly, it
means to find out what common scenarios Fedora users use/need and align
these with configuration upstream suggests. Finally, such documentation
will be able to be implemented as DevAssistant modules.
(For those who don't know DevAssistant: , )
Yes, implementing these tasks as assistants would be great. DevAssistant is in the stage
where it's stable enough to start doing this sort of stuff (although we will probably
run in tons of things that DevAssistant core is still missing and we'll need to
implement them on the way).
* Packaging improvements, automation - improving dynamic language
support, automatic requires, metadata etc.
* Packaging automation (copr, fedora-review, CI...that kind of thing)
I think that we have enough tools for these tasks (gem2rpm, pyp2rpm, cpanspec, spec2scl,
FedoraReview, rpmlint, ...). The real challenge is to make these more reliable, they
should be able to work (almost) automatically. As written below, we're currently
looking into implementing the newest Python packaging standards in pyp2rpm.
The thing is, that usually we can't solve these things just by improving our tools.
Sometimes the only way is to work with upstream communities and help them with defining
good packaging standards and then implement them in our tools, which is what we should
primarily do, I think.
* Most of rel-eng infra is done in python, a lot of pythonistas here,
so maybe lend them a hand in cleaning up their scripts?
I don't think we should concentrate on script cleanup. Rather we should help them when
the tools are missing important functionality.
* use some modularization. That way we might see more complex
scripting that would work better for us (and other WGs)
* Packaging guidelines simplification
* currently we mix rules with "howtos", this should be separated
(ideally into developer documentation)
* work on designing and proposing layering of the build-system/repos etc
though this may be complicated to implement:
* feasibility study at first
* copr - use new build service for automatic tasks?
Most importantly for CI. We could, for example have a directory with specfile in git repo
and create commit hooks that would trigger package build on every commit (although for now
this isn't possible, since that would require huge disk capacity, which copr does not
Databases or daemons
* compatibility matrix after Software Collections will be implemented
into the Fedora infrastructure. Having more versions of the same package
will bring many questions about compatibility between versions, not only
in the classic LAMP stack. We'll have to come up with some apparatus to
keep such compatibility matrix in some maintainable dimension.
* improve the Fedora packaging situation - currently there is too much
overhead with adding the numerous small Haskell libraries and updating
them across releases - automatization of packaging, improvement.
* parallel installation of different versions of stacks and cross
0) Switching to Python 3 :) We have a tracking page at , everybody is welcome to help.
Mostly, this is about sending patches to upstreams to help them with porting their code to
1) Making sure Fedora provides the latest versions versions of the
leading Python developer tools (i.e. IDEs, editors, debuggers,
I've seen some discussions about possibility of packaging PyCharm community edition.
That'd be a great IDE to have in Fedora.
2) Help in mediating between the needs of the upstream Python
community (e.g. NumPy, SciPy, SymPy, matplotlib, scikit-learn) and the
requirements for inclusion in the Fedora project. One particularly hot
subject is relaxing the requirements for bundled libraries.
3) Bridging the gap between upstream PyPI packaging and current Fedora
I believe that the new metadata format  will help us a lot. We're already looking
into implementing support into pyp2rpm. By doing so, we will be able to generate more
accurate Requires/BuildRequires of Python packages, and get other metadata in a simple
4) PyPy stack - we should look into the possibility of building some interesting packages
(in the sense that lots of people use them - e.g. Django, Flask) for PyPy so that people
may benefit from PyPy speed.
5) Rethink the Python packaging as a whole - this has been discussed when I proposed
switching to Python 3 (e.g. how to better cope with having python2/python3 packages, how
to cope with packages for other implementations like PyPy or Jython). This has a high
priority on my todo list and once I start working on a proposal for FPC, I'll inform
the list, because there are more people interested in this here and we should work
I guess we need to find common problems also for other languages and
came with something, which will make udpates or packaging of modules
easier or semi-automatic. For example texlive is generated
automatically, so why not do the same with Perl, Ruby, ... or any other
suitable stack of packages.
At least leaf packages could be generated automatically and reviews
shouldn't be so thorough.
Also, we should not forget about Ruby and Node.js. AFAICS Python has pretty good support
in Fedora (and across Linux distributions generally), but that doesn't really apply
for Ruby and Node.js, so we should probably work with these communities to improve it, so
that more people use our stacks and don't compile their own Ruby/Node.js.
Bohuslav "Slavek" Kabrda.