first ideas what to do

[Marcela Mašláňová]

Hi list,
from our personal conversation before creating this list, where 
mentioned these ideas. Maybe we can start discussing which area we'd 
like to work on, what must be done. Let's not get into details right 
now, start thinking about areas, which need work and what we'd like to 
see fixed.

Documentation
~~~~~~~~~~~~~
Currently, there is a bunch of HOWTOs and similar documents on Fedora
wiki, one deprecated Fedora RPM Guide on docs.fedoraproject.org, an
unfinished Packager's Guide and a Software Collections Guide.

We need to clean it and review by those who are aware of these area.

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.

Infrastructure
~~~~~~~~~~~~~~
* Packaging improvements, automation - improving dynamic language 
support, automatic requires, metadata etc.
  * Packaging automation (copr, fedora-review, CI...that kind of thing)
* Tooling
  * 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?
  * use some modularization. That way we might see more complex rel-eng 
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?

Software
~~~~~~~~
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.

Haskell
* 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 
release support.

Python
1) Making sure Fedora provides the latest versions versions of the
leading Python developer tools (i.e. IDEs, editors, debuggers,
profilers, ...)
2) Help in mediating between the needs of the upstream Python Scientific
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
packaging.

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

Marcela