Tienes una invitación para el siguiente evento.
Título: Fedora Server Working Group Weekly IRC Meeting
The Fedora Server Working Group will hold a public IRC meeting in
#fedora-meeting-1 on Freenode each Tuesday at 1600 UTC.
Cuándo: cada semana de 11:00 a 12:00 martes del mar 5 de nov al sáb 1 de
feb de 2014 Lima
Lugar: #fedora-meeting-1 on Freenode
Calendario: tony blair
* Anthony Mogrovejo- organizador
* server(a)lists.fedoraproject.org - opcional
Tu asistencia es opcional.
Detalles del evento:
Invitación de Google Calendar: https://www.google.com/calendar/
Recibes este mensaje de cortesía en la dirección
server(a)lists.fedoraproject.org de la cuenta porque eres uno de los
participantes de este evento.
Si deseas dejar de recibir notificaciones para este evento, recházalo. Si
lo prefieres, solicita una cuenta de Google en
https://www.google.com/calendar/ y controla la configuración relativa a las
notificaciones de todo el calendario.
PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN
SUMMARY:Fedora Server Working Group Weekly IRC Meeting
DESCRIPTION:The Fedora Server Working Group will hold a public IRC meeting
in #fedora-meeting-1 on Freenode each Tuesday at 1600 UTC.
LOCATION:#fedora-meeting-1 on Freenode
Hi all. I'm going to be at Usenix LISA next week. Stop by the Fedora booth
(and BoF) if you are around. I'll also be asking about use cases and needs
and wants. If there's anything in particular you all would like me to ask,
let me know!
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
Ok this is just an example that hit me today, so I wonder what is the
opinion here, please do not concentrate on the problem at hand but on
the general problem it highlights (user experience on server).
In a headless F20 if you "yum install firefox" you get a broken
application when you want to run it through an ssh session (I ssh -Y in
I think this is a reasonably common mode of operation, and yet
installing firefox does not bring in all the dependencies it needs to
The classic dependency it misses that I know about is xorg-x11-xauth,
however in F20 firefox apparently also misses fonts and will show an
unintelligible crash report dialog (unintelligible because there are no
I think a good server experience will require that yum install firefox
on a headless system installs all required packages to make it work, is
this something we need to take care of going forward ?
Apparently there is some dispute about who owns the bug, but I wasn't
able to find out where, on #fedora-devel I was told it was in a bug that
has probably been closed w/o resolving the issue ...
Simo Sorce * Red Hat, Inc * New York
Greetings you all
So here's the thing throughout Fedora history there has always been the
attempt to put a one label ( target users ) on the entire community and
always has it failed ( understandably so ) and trying to do so here in
the form of an single "PRD" for the server community will fail in the
same manner since each of the existing server application or application
stack exist to address a particular problem or fill in a missing space
in the IT sector which means each of this exist to address *different*
set of target audience thus we will never be able to .
In anycase people have failed to realise this all this after all these
years and still try to put one label on everything in a such a diverse
community ( and in our case the server aspect of the project ) and since
I suck at writing analogies or explain why that is people simply have to
come to conclusion by themselves.
Now what I believe what we stand for, what our true purpose is, our
core, our essence, our mission statement Fedora Server WG can be
summarized into this one sentence...
"Fedora Server WG where we discover product solutions that work well for
our users, our administrators, our developers and our project."
--> T-shirt anyone <-- ;)
We should be identifying which server applications work well on their
own or work well with each other out of those 500+ we have ( think of
them as ingredients ).
Once we have done that we add a Fedora secret sauce ( what we feel they
are lacking for the 21 century which for example could be that missing
configuration api ) and form a PRD for that recipe and implement it.
In anycase that's my view and we need to hash out if people think of
"Fedora server" as single product and an PRD can be applied to it as
such or multiple products.
One discussion we didn't get to finish in today's meeting was the
membership section of Jóhann's governance charter draft. As stated
during the meeting, he felt having this cross-section of Fedora would
"ensure coverage and proper release process for server product."
The draft link is here, for convenience:
After the meeting I went back to the Fedora.next proposal to see what it
says about membership in the working groups and read this:
"There will be at least one FESCo member in each to act as a liaison.
There should be a liaison with the QA, rel eng, docs, marketing, and
web/infrastructure groups as well although these may not be people from
those teams but people tasked with facilitating dialogue between those
groups and the working group instead."
Jóhann's proposal seems to follow the spirit of this (adding the design
team as a group needing representation; thank you for that. :) ) With
that in mind I've changed my position on this matter a bit, and I would
like to hear your thoughts on this proposal:
- The proposal says we would continue to have nine voting members, but
then talks about there being a member each to represent 7 Fedora groups
and 3 additional members to represent the server community itself. I
think the representation of the server community itself is too slim
here, and I think the slots could overlap.
- I would like to propose instead that we maintain a nine voting member
roster, but require that at least five of the members be able to
directly represent the server community. By this, I specifically would
like to require any or all of the following requirements be met by a
'server community' representative (under which all of our current
'server community' reps and other members qualify as well):
- member has worked professionally as a system administrator for a
deployment of at least 10 production servers
- member has been involved significantly as a contributor to an
enterprise Linux distribution or enterprise management product for Linux
- Instead of having each of the cross-section teams across Fedora (docs,
rel-eng, QA, ambassadors, infra, design, marketing) have a member of
their team directly serving in the Server working group, I would like to
suggest instead following the Fedora.next proposal suggestion that each
of these teams have a liaison on the working group who isn't necessarily
a member of the team they represent. So, for example, Stephen could be
the liaison for the Fedora marketing team even though he is not a member
of that team, and whenever the working group needs to interface with
that team it would be Stephen's responsibility to contact them. So each
team has a 'go-to' person on our working group, and our working group
has a 'go-to' person for each team we'd need to interface with. To have
the same person managing the relationship could simplify communications.
- In order to determine who is the liaison for which of the 7 groups,
for now we could go with people who are a member of the groups are the
liaison and groups that do not have a member on the working group would
have a member not already a liaison for another team nominated to be
their liasion. When someone who is the liaison for a given Fedora team
leaves the group, that group will be given the opportunity to suggest a
replacement but the decision as to who to pick would ultimately be up to
the remaining members of the working group.
With this proposal in mind -
I am still not sure how the turnover works. Do we serve until we're sick
of serving, or is there a term / period we are on and then are up for
re-elections? The draft does not cover this really.
Anyway, let's discuss :)