Fedora Developer Portal - UX point of view
by Petr Hracek
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
8 years, 7 months
RepoFunnel and the Software Component Pipeline
by Nick Coghlan
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/SoftwareComponentP...
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
8 years, 8 months
Agenda for Env-and-Stacks WG meeting (2015-08-20)
by Honza Horak
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
8 years, 8 months
Agenda item for e&s Aug 20, 2015
by White, Langdon
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
8 years, 8 months
Rethinking user level package management
by Nick Coghlan
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/UserLevelPackageMa...
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
8 years, 8 months
Agenda for Env-and-Stacks WG meeting (2015-08-06)
by Honza Horak
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
8 years, 8 months
