Re: Self-introduction & offer of assistance

Hi folks, I know some of you already, but since I just signed up to the list I figured it would be worthwhile explaining my interest in and perspective on the "Environment & Stacks" working group. I'm interested in the work of the Environments & Stacks working group from two perspectives: 1. As one of the chief cat herders in the upstream Python packaging ecosystem, I'm interested in working more closely with Linux distributions to resolve some of the issues that can make working with Python software on Linux more complicated than it needs to be. My Python Packaging 2.0 talk at linux.conf.au 2014 covers that aspect pretty well, and the write-up at http://lwn.net/Articles/580399/ is a good summary. 2. In my day job, I'm the deployment & provisioning architect for several of Red Hat's internal development support tools, including beaker-project.org and bugzilla.redhat.com. The primary languages we currently need to support in production are Python, Ruby, Perl, and Java (along with the ubiquitous JavaScript). I've been having various off-list discussions with Slavek and Langdon White (Red Hat's developer experience architect), but realised recently that it made more sense to take those discussions out of private email and bring them to the Envs & Stacks working group. In joining this group, my main aim is to help work out a good developer workflow for internal use in such a way that similarly smooth workflows can be adopted by anyone else developing on Fedora and deploying on CentOS or RHEL (including as containers running on Project Atomic or RHEL 7). In that vein, my current architectural concept is leaning towards a model where applications are structured along the following lines: - Application & dependencies (language specific) - Language runtime (Software Collections) - Base OS layer (Fedora/CentOS/RHEL) By default, we'd just use the versions of things that were in the base OS layer. If we needed something more specific (whether older on Fedora, or newer on CentOS/RHEL), we'd prefer to get it through a software collection if it was available. Within a language runtime, we'd switch away from yum/rpm entirely and instead use the language specific tools. The advantage of this approach is that: 1. It can be applied directly to existing applications that use upstream packaging tools 2. Switching to pip (et al) inside the software collection avoids any remaining issues with depending on software collections 3. It plays nice with any deployment target (bare metal, VM, container image build) This brings me to a notion which isn't in the current E&S PRD, but which *would* be helpful to us if we adopt this deployment model, rather than always deploying software as RPMs: having language specific repos available where the packages had been through the same level of review as was needed to get into Fedora Playground, but still used the *language* level packaging formats. (This isn't actually my idea, it came up in a conversation with Langdon. However, it ties in so well with other things I'm doing, I decided to take it and run with it). However, I'll post that idea in its own thread, rather than tacking it on here. Regards, Nick.