Confirming that voting members are willing to continue in their role
by Honza Horak
Dear voting members,
as agreed in the Charter [1] initially, there will be elections soon,
the first one will be coincide with the FESCo election that occurs near
January 2015. According to the charter, we're going to refresh half the
seats, which means 4 seats.
Since we need to pick-up 4 seats for the first time, this e-mail serves
for getting feedback from current voting members, who are expected to
explicitly state, whether they are willing to continue in their current
role of voting member.
Current voting members, please, reply to the list and express your
position whether you are willing to stay to be voting member of the Env
& Stacks.
Negative or no answer by 10th Dec 2014 would mean your seat may be
available for new comers.
Thanks for collaboration,
Honza
[1] https://fedoraproject.org/wiki/Env_and_Stacks/Governance_Charter
9 years, 4 months
Agenda for Env-and-Stacks WG meeting (2014-11-25)
by Honza Horak
WG meeting will be at 12:00 UTC (07:00 EST, 13:00 Brno, 7:00 Boston,
21:00 Tokyo, 22:00 Brisbane) in #fedora-meeting on Freenode.
= Topics =
* Follow-ups
* Language specific repositories
* Election planning
* Chairman for next meeting
* Open Floor
9 years, 4 months
Agenda for Env-and-Stacks WG meeting (2014-11-05)
by Jens-Ulrik Petersen
WG meeting will be at 12:00 UTC (07:00 EST, 13:00 Brno, 9:00 Boston,
21:00 Tokyo, 22:00 Brisbane) in #fedora-meeting on Freenode.
= Topics =
* Follow-ups
* Integration tests
* Election planning
* Chairman for next meeting
* Open Floor
9 years, 4 months
Some further thoughts on the "language specific repositories" idea
by Nick Coghlan
I started writing a long email regarding some of my concerns about the
scalability of the "language specific repos" idea, and decided they'd be
better to capture on the wiki instead:
https://fedoraproject.org/wiki/User:Ncoghlan/User_level_package_management
In large part, it grows out of asking myself the question "What problem
are we actually trying to solve with language specific repos?", and it
seemed to mostly come down to having a way for users (including
developers) to install packages and manage dependencies *independently*
of the system package manager.
That then lead to some questions about the downsides of enabling that
(especially around auditing) and whether it's really feasible to fully
support every single language specific packaging system at the platform
layer - at some point, we're going to just have to treat those systems
as opaque binary blobs, and leave the issue of handling security updates
up to the application provider.
The other main concern I have is around integrating with the build and
review tooling - it seems to me like we may need an abstracted plugin
based hosting system like Pulp to make that a tractable problem, rather
than integrating directly with the ecosystem specific repository hosting
services.
Regards,
Nick.
--
Nick Coghlan
Red Hat Hosted & Shared Services
Software Engineering & Development, Brisbane
HSS Provisioning Architect
9 years, 4 months
Reconsidering time for the meeting
by Honza Horak
Hi,
as we were talking on the yesterday's meeting, we may consider changing
the meeting time, so it better fits our needs, especially after DST is
over. I've created whenisgood:
http://whenisgood.net/2h5zadw
Please, fill-in until 30th Oct, I'll sumarize results Fri, 31th Oct.
Honza
9 years, 5 months
Proposal for integration tests infrastructure
by Honza Horak
Fedora lacks integration testing (unit testing done during build is not
enough). Taskotron will be able to fill some gaps in the future, so
maintainers will be able to set-up various tasks after their component
is built. But even before this works we can benefit from having the
tests already available (and run them manually if needed).
Hereby, I'd like to get ideas and figure out answers for how and where
to keep the tests. A similar discussion already took place before, which
I'd like to continue in:
https://lists.fedoraproject.org/pipermail/devel/2014-January/193498.html
And some short discussion already took place here as well:
https://lists.fedoraproject.org/pipermail/env-and-stacks/2014-October/000...
Some high level requirements:
* tests will be written by maintainers or broader community, not a
dedicated team
* tests will be easy to run on anybody's computer (but might be
potentially destructive; some secure environment will not be part of tests)
* tests will be run automatically after related components get built
(probably by Taskotron)
Where to keep tests?
a/ in current dist-git for related components (problem with sharing
parts of code, problem where to keep tests related for more components)
b/ in separate git with similar functionality as dist-git (needs new
infrastructure, components are not directly connected with tests, won't
make mess in current dist-git)
c/ in current dist-git but as ordinary components (no new infrastructure
needed but components are not directly connected with tests)
How to deliver tests?
a/ just use them directly from git (we need to keep some metadata for
dependencies anyway)
b/ package them as RPMs (we can keep metadata there; e.g. Taskotron will
run only tests that have "Provides: ci-tests(mariadb)" after mariadb is
built; we also might automate packaging tests to RPMs)
Structure for tests?
a/ similar to what components use (branches for Fedora versions)
b/ only one branch
Test maintainers should be allowed to behave the same as package
maintainers do -- one likes keeping branches the same and uses "%if
%fedora" macros, someone else likes specs clean and rather maintain more
different branches) -- we won't find one structure that would fit all,
so allowing both ways seems better.
Which framework to use?
People have no time to learn new things, so we should let them to write
the tests in any language and just define some conventions how to run them.
Cheers,
Honza
9 years, 5 months
Pulp plugin for managing Python packages
by Nick Coghlan
I actually opened up my Pulp devel mailing list folder for the first
time in a while, and the first thing I saw was that they're currently
working on a plugin for Python packages: https://github.com/pulp/pulp_python
One of the things that has been worrying me about the idea of language
specific package repos is the sheer complexity of managing them all.
(The fact Slavek found 35 new packages he'd need to respin as RPMs to
deploy devpi for the pilot did nothing whatsoever to reassure me...)
For those that aren't aware, Pulp is a plugin based repository
management system written in Python, where the different repositories
can all share common infrastructure for things like scheduling updates,
uploading new content, and mirroring files out to remote sites, but
publish content in a way that can be consumed by application specific
packaging tools (it's actually one of the upstream projects for Red Hat
Satellite 6+).
The already released plugins cover RPMs and Puppet modules, but in
addition to the Python support mentioned above, there's also
experimental modules for Docker image registry support.
I've actually used Pulp before (version 1 though, when the plugin model
was still in alpha), and rather liked their approach, as well as finding
their dev team quite easy to work. I hadn't previously thought of it in
the context of language specific repositories for Fedora, but now that I
have, I'll explore the idea further.
Cheers,
Nick.
--
Nick Coghlan
Red Hat Hosted & Shared Services
Software Engineering & Development, Brisbane
HSS Provisioning Architect
9 years, 5 months
