env-and-stacks August 2015

env-and-stacks@lists.fedoraproject.org

6 participants
9 discussions

Fedora Developer Portal - UX point of view
by Petr Hracek 15 Sep '15

15 Sep '15

Hi Mairin, sorry for bother you with this item but I would like to ask you If you can thing about how Fedora Developer Portal could look like. I propose that skin or face for developer.fp.org can be used also for another portals which could be defined later on. Or even if they are already exists. I guess that fedoraproject.org should have a common face:) We would like to release a first version of Fedora Developer Portal in the middle of September but many folks could have holidays and I guess that you too.:) We already have a GitHub repo for mockups [1] and feel free to use it. I would like to really thank you for your time and support. [1] https://github.com/developer-portal/mockups Greetings Petr -- Petr Hracek Software Engineer Developer Experience Red Hat, Inc Mob: +420777056169 email: phracek(a)redhat.com

3 6

Volunteer to organize Env-and-Stacks WG meeting this week? (2015-08-27)
by Honza Horak 26 Aug '15

26 Aug '15

I know about 3 guys not being able to attend the meeting tomorrow, including me. If somebody else is volunteering to organize the meeting (which should be at 12pm UTC this week), feel free to do so. Otherwise, consider this week canceled. Honza

1 0

Cooperation with other WGs on Rings and E&S position in this effort
by Honza Horak 25 Aug '15

25 Aug '15

This is a follow-up for yesterday's meeting [1]. We kind of agreed that E&S should lead the development of rings concept, which means to approach other WGs with guidelines about what rings borders are and the WGs will be responsible for defining the rings. Ring 0+1 would be for example work for Base WG. Since there was no other WG member except me on the meeting yesterday, I'd like to get this plan approved here on ML. [1] http://meetbot-raw.fedoraproject.org/fedora-meeting-2/2015-08-20/env-and-st… Honza

2 3

RepoFunnel and the Software Component Pipeline
by Nick Coghlan 25 Aug '15

25 Aug '15

Hi folks, Based on discussions with various people at Flock last week, I've started hacking on a proof of concept for a "repo funnel" service that allows people to define their own custom repositories in Pulp as a filtered view of the smorgasboard offered by COPR. That way, they can say "I want to use these repos" once in an online service, and subscribe their client machines to that single custom defined repo, rather than having a proliferation of COPR repos directly on client devices, which are then hard to replicate across machines (e.g. a separate laptop and workstation, or multiple remote servers). However, I want to design it in a way that means it also ends up being useful for improvements to the Fedora Review Process, which means putting some thought into the overall workflow this might enable *before* I get too deep into building it. Accordingly, I put together a page on the wiki at https://fedoraproject.org/wiki/Env_and_Stacks/Projects/SoftwareComponentPip… to describe what *I'd* be hoping to get out of this. That page also captures my own input on "What should the role of E&S be in further defining the Fedora Rings concept?" - at the very least, I think we should be the ones responsible for the overall developer experience of the distro (encompassing not just client systems, but relevant online services), that we should be setting expectations for the contributions individual language SIGs make to that process, and defining the handover to the Base WG and the Edition WGs for the assembly of the available software components into the Fedora Editions, EPEL, and the main Fedora repositories. Regards, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

2 4

Agenda for Env-and-Stacks WG meeting (2015-08-20)
by Honza Horak 20 Aug '15

20 Aug '15

WG meeting will be at 17:00 UTC (13:00 EST, 19:00 Brno, 13:00 Boston, 2:00+1d Tokyo, 3:00+1d Brisbane) in #fedora-meeting-2 on Freenode. = Topics = * Rings and modules - how/where to track and document this as real project (Taiga.io?) - rings definition by description? - purpose of that particular ring (benefits from user's PoV) - expectations from content in each ring (2-3 examples of parts (format, content)) - who are users of the particular ring * Open Floor

2 4

Agenda item for e&s Aug 20, 2015
by White, Langdon 19 Aug '15

19 Aug '15

hi! We have a number of different, complementary/competitive, application management technologies (very tough to give them a group name) springing up in the various Edition Working Groups. Technologies including, but probably not limited too: rolekit, xdg-app, nulecule, and docker. I have been proposing to members of those groups and the Council that the discussion of the technologies would be better served in a "central to Fedora" conversation. As a result, I was hoping to add to the agenda for tomorrow's meeting: a) how to invite the conversation to e&s b) what the output of e&s would be c) how to ensure that e&s is the place for these conversations in the future I hope that is clear, otherwise, I can elaborate or answer questions tomorrow in the meeting. Langdon White

1 0

No Env-and-Stacks WG meeting (2015-08-13)
by Honza Horak 07 Aug '15

07 Aug '15

There will be FLOCK already going the next Thursday, so many people are not available. Let's skip the meeting. Honza

1 0

Rethinking user level package management
by Nick Coghlan 06 Aug '15

06 Aug '15

With PyCon Australia behind me (I'll send a status update about that later today, since some of the topics were relevant to this group), I started looking more seriously at the three candidates for user level package management tooling: https://fedoraproject.org/wiki/Env_and_Stacks/Projects/UserLevelPackageMana… I already know conda and nix fairly well (albeit theoretically in the latter case), so my main goal was to get started with conary, and see what would be involved in taking my currently pip based OpenShift deployment for Kallithea (http://www.curiousefficiency.org/posts/2014/12/kallithea-on-openshift.html ) and switch it to using conary instead. The short version: I failed, but in failing, I learned I was asking the wrong question, and thus now have a very strong opinion on the user level package management tech I think we should expose to end users (spoiler: conda > nix > conary), but am still undecided on the direction I think we should be going in the repository management space (and the latter isn't Envs & Stacks decision anyway). --------------- The key thing I realised is that the reason I find conary interesting relates to the way it handles patch management as an open source system integrator - how do you keep track of your different upstream projects, your different supported downstream product versions, and which patches need to be applied where? When it comes to the *end user* experience I'd like for user level package management, I already think conda has all those bases covered, as it was specifically built by Continuum Analytics to solve their own problems as a cross-platform ISV supporting Windows, Mac OS X, and arbitrary Linux distros and targeting individual users that may not have admin access to their employer provided machines. So putting conary (and even conary concepts) into the picture isn't likely to provide any significant gain in the usability of the final "binary artifacts to end users' systems" installation step relative to the vastly simpler approach of "just use conda, as the problem we want to solve is exactly what it was built to handle, and its existing popularity with research scientists and data analysts provides solid evidence of its usability"*. Instead, I'm starting to think that conary's *ideas* (if not the software itself) will be most at a home in the dist-git/fedpkg/rhpkg/copr/koji ecosystem - the machinery whereby upstream source code turns into downstream binary repos, rather than being particularly useful in making the final hop from downstream repo to end user system. As far as nix goes, I think it's a *really* good technology for folks to explore in the "immutable infrastructure" world, where any low level security update is going to involve a container rebuild anyway. For a mutable infrastructure world (like end user workstations), the way that Nix requires pushing updates to higher level components whenever a lower level one is updated (even in an ABI compatible way) is a problem. Regards, Nick. P.S. *Full disclosure: the fact that conda's channel based publication mechanism for binary artifacts aligns well not only with Fedora's existing repo management model, but also with RHEL's subscription management *does* influence my opinion on that - "it's like RPM, but at the individual user level" is *really* easy to explain to both current end users, and to anyone picking up Fedora/RHEL for the first time and needing to learn both. It also means that folks making the jump from "end user" to "system administrator" in the future can have RPM explained to them as "it's like conda, but for the underlying system definition rather than software aimed at individual users") -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

1 1

Agenda for Env-and-Stacks WG meeting (2015-08-06)
by Honza Horak 06 Aug '15

06 Aug '15

WG meeting will be at 17:00 UTC (13:00 EST, 19:00 Brno, 13:00 Boston, 2:00+1d Tokyo, 3:00+1d Brisbane) in #fedora-meeting-2 on Freenode. = Topics = * RHEL.next and how communicate between containers / stacks * Rings in Fedora 24 - documentation would be awesome * Taiga.io - could it be used to track features/projects and it's progress? * Open Floor

1 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

env-and-stacks August 2015