Agenda for Env-and-Stacks WG meeting (2014-09-16)
by Honza Horak
WG meeting will be at 13:00 UTC (14:00 London, 15:00 Brno, 9:00 Boston,
22:00 Tokyo) in #fedora-meeting on Freenode.
= Topics =
* Language specific mirrors for Fedora Playground compliant packages
* SCLs, building above them and their position in Fedora/EPEL
* Picking chairman for the next meeting
* OpenFloor
9 years, 6 months
Language Stacks in Docker Hub
by Václav Pavlín
Hi all,
Docker announced language stacks images in Docker Hub last week:
http://blog.docker.com/2014/09/docker-hub-official-repos-announcing-langu...
They are all based on Debian and pretty outdated. We should consider
creation of such images for our stacks based on Fedora - we are thinking
of releasing F21 Alpha base image so we could maybe build them on top of it.
As we still don't have a build service I proposed some time ago, we
could use Docker Automated Builds - we would "just" need to prepare
Dockerfiles.
Have a look at what they provide and let me know if you think it's
interesting for us.
Thanks,
Vašek
--
Lead Infrastructure Engineer
Developer Experience
Brno, Czech Republic
9 years, 6 months
Meeting minutes from Env and Stacks WG meeting (2014-09-30)
by Marcela Mašláňová
============================================
#fedora-meeting: Env and Stacks (2014-09-30)
============================================
Meeting started by mmaslano at 13:03:32 UTC. The full logs are available
at
http://meetbot.fedoraproject.org/fedora-meeting/2014-09-30/env-and-stacks...
.
Meeting summary
---------------
* init process (mmaslano, 13:04:01)
* recommendation of Koschei (mmaslano, 13:05:14)
* AGREED: Env & Stacks WG recommends adopting Koschei as the suggested
means of tracking build failures on dependency updates (mmaslano,
13:17:09)
* ACTION: bkabrda -> koschei developers should write about Koschei on
Fedora wiki (mmaslano, 13:20:31)
* conda - everyone should look at it (mmaslano, 13:20:35)
* Fedora Stacks images (mmaslano, 13:58:29)
* ACTION: follow up with stano about mapping CVEs to Docker images
that need rebuilding (mmaslano, 14:22:52)
* ACTION: propose reasonable dockerfile for our favourite languages
(mmaslano, 14:23:44)
* chairman (mmaslano, 14:28:13)
* Open Floor (mmaslano, 14:32:32)
Meeting ended at 14:36:14 UTC.
Action Items
------------
* bkabrda -> koschei developers should write about Koschei on Fedora
wiki
* follow up with stano about mapping CVEs to Docker images that need
rebuilding
* propose reasonable dockerfile for our favourite languages
Action Items, by person
-----------------------
* bkabrda
* bkabrda -> koschei developers should write about Koschei on Fedora
wiki
* **UNASSIGNED**
* follow up with stano about mapping CVEs to Docker images that need
rebuilding
* propose reasonable dockerfile for our favourite languages
People Present (lines said)
---------------------------
* ncoghlan (94)
* mmaslano (65)
* juhp_ (37)
* vpavlin (25)
* bkabrda (11)
* hhorak (8)
* zodbot (6)
* pingou (3)
* samkottler (0)
* sicampbell (0)
* tjanez (0)
* juhp (0)
* pkovar (0)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
9 years, 6 months
Koschei recommendation proposal: please vote who have not yet
by Honza Horak
Hi voting members,
on the last meeting we had not enough voting members on-line to vote on
the following proposal:
"Env & Stacks will recommend Koschei as a good idea and we would like to
see it as official fedora service."
So, please, who has not voted yet, do so until the next meeting. So far
mmaslano, juhp and hhorak are +1 for that proposal.
Thanks!
Honza
9 years, 6 months
looking for another candidate for Env & Stacks WG
by Marcela Mašláňová
Hi guys,
I won't be around for few months, so I'm looking for a replacement of
empty seat after me. Honza accepted to be a liaison of the group, but
there will be still one regular empty seat. Any takers?
Thanks,
Marcela
9 years, 6 months
Agenda for Env-and-Stacks WG meeting (2014-09-02)
by Marcela Mašláňová
WG meeting will be at 13:00 UTC (14:00 London, 15:00 Brno, 9:00 Boston,
22:00 Tokyo) in #fedora-meeting on Freenode.
= Topic =
* how hhorak's idea about summary from each WG worked
* epel/epic proposal - chat with smoodge
* OpenFloor
9 years, 7 months
Language specific mirrors for Fedora Playground compliant packages
by Nick Coghlan
As mentioned in my self-introduction email, I'm interested in the idea
of filtered Fedora provided mirrors of PyPI/RubyGems/etc that contained
only packages that had been through Fedora Playground levels of review.
Having such selective mirrors available would mean that we could freely
choose between using the language level packaging tools and RPMs on a
project by project basis without having to recheck the licenses
ourselves. It would also provide a way for us to easily share the
results of our own licensing reviews when we bring in new dependencies
from upstream.
I believe this approach would also set up a good pipeline for bringing
new packages into Fedora:
Step 1: basic review
- if the package is even remotely acceptable to Fedora (e.g. suitable
license, not actively malicious), then flag it for inclusion in the
appropriate language specific mirror
Step 2: draft spec file
- make an initial cut at a spec file (e.g. autogenerated)
- provide as a COPR repo
- include in Fedora Playground
Step 3: full packaging policy compliance
- iterate on the spec file and the package to attain policy compliance
- incorporate into Fedora itself
Does this sound like an approach worth pursuing?
In the specific case of Python, devpi is an existing project that I
believe would be eminently suitable to providing a service like this
(using the whitelisting feature to indicate packages which had been
checked for Fedora Playground policy compatibility): http://doc.devpi.net/
Regards,
Nick.
--
Nick Coghlan
Red Hat Hosted & Shared Services
Software Engineering & Development, Brisbane
HSS Provisioning Architect
9 years, 7 months
Self-introduction & offer of assistance
by Nick Coghlan
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.
--
Nick Coghlan
Red Hat Hosted & Shared Services
Software Engineering & Development, Brisbane
HSS Provisioning Architect
9 years, 7 months
Proposal for every WG to send a short summary *to other WGs directly*
by Honza Horak
Hi working groups members,
since we have learned on Flock that new Fedora working groups do not
communicate with each other much (or enough), I'd like to propose the
following:
Every working group will time to time (e.g. weekly) send short summary
about what they did / were talking about directly to mailing lists of
other working groups + to devel(a)fp.o. Really only a short summary with
links where one can find details.
I tried to collect such info from the meeting logs and mailing lists for
the last few weeks for Env and Stacks WG:
https://lists.fedoraproject.org/pipermail/env-and-stacks/2014-August/0004...
I found many notes are really worth spreading beyond groups' borders,
but it takes too much time for one person to collect all the
information. Thus, proposing to "do a summary once per group and share
with other groups".
Another benefit would be that Matt would have better content for his 5tiftw.
I don't think we need to sync about date or frequency, just remembering
to send a direct mail if anything interesting is done/discussed should
work fine.
List of proposed MLs to send this summary to:
server(a)lists.fedoraproject.org
desktop(a)lists.fedoraproject.org
cloud(a)lists.fedoraproject.org
env-and-stacks(a)lists.fedoraproject.org
devel(a)lists.fedoraproject.org
Comments, ideas or better solutions are welcome as usually, but I might
be offline until Sunday, so do not expect any answers from me in that
time :)
Cheers,
Honza
9 years, 7 months