On 10/31/2013 03:56 PM, Toshio Kuratomi wrote:
> On Thu, Oct 31, 2013 at 09:31:13AM +0100, Marcela Mašláňová wrote:
>> I created whenisgood, but imho it's useless, because it didn't offer
>> whole day. Don't forget to change it to your timezones.
> Okay -- new whenisgood created. It should show a timezone selector box now
> and also all the days of the weeks and times.
> Do we want everyone to fill this out or only the voting members?
> (Note -- the web site won't enforce anything in either case.)
Btw I CC'ed nonexisting lists and it didn't complained :) Fixed now.
On Thu, Oct 31, 2013 at 09:31:13AM +0100, Marcela Mašláňová wrote:
> There is not good time for everyone. See meeting planner:
> Someone has to stay late or get up very early. I said I don't want
> many meetings, because it will be difficult to pick good time.
> I created whenisgood, but imho it's useless, because it didn't offer
> whole day. Don't forget to change it to your timezones.
* Is there a "Use timezone" checkbox that is currently unchecked in the
meeting options? I don't have a way to change the timezone when I look at
* Are there some days and times that are unavailable because you can't make
it? Since you're the fesco liason, it would make sense that we can't hold
a meeting without you. If you can make it, though, it would make sense to
list those times as available so we can see what times work for the most
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
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.
* Packaging improvements, automation - improving dynamic language
support, automatic requires, metadata etc.
* Packaging automation (copr, fedora-review, CI...that kind of thing)
* 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?
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
1) Making sure Fedora provides the latest versions versions of the
leading Python developer tools (i.e. IDEs, editors, debuggers,
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
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.