env-and-stacks November 2014

env-and-stacks@lists.fedoraproject.org

9 participants
9 discussions

Confirming that voting members are willing to continue in their role
by Honza Horak 08 Dec '14

08 Dec '14

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

8 9

User level package management & Language specific repositories pages posted
by Nick Coghlan 28 Nov '14

28 Nov '14

Hey folks, I've moved the user level package management page under the Envs & Stacks hierarchy, and also published the initial version of the language specific repositories page: https://fedoraproject.org/wiki/Env_and_Stacks/Projects/UserLevelPackageMana… https://fedoraproject.org/wiki/Env_and_Stacks/Projects/LanguageSpecificRepo… I removed the disclaimer about it still being a draft, but I personally consider everything related to this open for negotiation and discussion until we actually make Fedora level change proposals - that's the point where it makes the transition from "an idea we're investigating" to "we think Fedora should officially endorse this approach". Cheers, Nick. -- Nick Coghlan Red Hat Hosted & Shared Services Software Engineering & Development, Brisbane HSS Provisioning Architect

1 0

Agenda for Env-and-Stacks WG meeting (2014-11-25)
by Honza Horak 26 Nov '14

26 Nov '14

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

3 3

Agenda for Env-and-Stacks WG meeting (2014-11-05)
by Jens-Ulrik Petersen 25 Nov '14

25 Nov '14

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

3 4

Some further thoughts on the "language specific repositories" idea
by Nick Coghlan 24 Nov '14

24 Nov '14

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

2 1

No Env-and-Stacks WG meeting today (2014-11-19)
by Honza Horak 19 Nov '14

19 Nov '14

There is no agenda proposed for this week so let's skip today and have a meeting the next week. Honza

1 0

Reconsidering time for the meeting
by Honza Horak 05 Nov '14

05 Nov '14

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

5 8

Proposal for integration tests infrastructure
by Honza Horak 04 Nov '14

04 Nov '14

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/00057… 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

6 10

Pulp plugin for managing Python packages
by Nick Coghlan 03 Nov '14

03 Nov '14

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

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

env-and-stacks November 2014