proposal: Env-Stacks irc channel
by Jens-Ulrik Petersen
Hi,
This is a follow up mail to the discussion we started
in the meeting on Tuesday, for the benefit of those
who couldn't attend the meeting where the idea was proposed,
about whether we should have an Env and Stacks irc channel
on Freenode for informal discussion and interactions.
A few thoughts on it so far:
Pros
- should allow more real-time interactions between all interested parties
- would make it easy to see and catch up on conversions
- would be quiet enough to chat even with longer response lags
Cons
- one more channel: #fedora-devel is enough..
- hard to find a good short name
(my client config seems unable to restore
channel names longer than ~15 chars;)
- could distract from email communication
- channel could be very quiet...
- timezones
Personally I think it is worth having a channel.
I am usually connected to freenode and having a channel
specific to Env and Stacks would make it easy to
see conversations as they happen or afterwards.
For the name I might suggest #fedora-env
or #fedora-stacks to keep it short.
Jens
ps It might be good to post topics/proposals like this for
discussion to the mailing-list ahead of the meeting so they can be
added to the agenda, though I guess it is also fine to bring them up
at the end: using trac for tracking meeting topics/proposals
might also be good, and could make it easier for non-members
to make suggestions/proposals for discussion.
This time I just remembered the idea spontaneously during
the meeting discussion.
10 years, 2 months
vote on PRD
by Marcela Mašláňová
Guys,
I'd like to ask you to vote about current PRD. The deadline is on
Monday. Do you want to vote on it tomorrow (Friday)?
I know there are still new comments, but for example if we were trying
to figure out what to do with scl, it can take few months.
Marcela
10 years, 2 months
Working on the SCL section in the PRD
by Toshio Kuratomi
At today's meeting there was some concern that the SCL section might not
reflect what we wanted to do with SCLs. I proposed a partial strategy for
how we could work on SCLs but the people we felt were the most important to
get agreement on the strategy weren't present at that point. So sending to
the list for feedback:
== Background ==
There will be SCLs in the main Fedora Repository. Those will be produced by
Fedora packagers following the Fedora Guidelines. These SCLs will also be
buildable for EPEL since they will exist just like any other set of Fedora
packages. That will make those SCLs available in both the Fedora and the
RHEL ecosystems.
However, since SCLs are really defining a platform that sits on top of an
OS, we'll likely also want to give users of Fedora access to SCLs that are
not produced by Fedora and do not follow the Fedora Guidelines. At the
moment, the most prominent of those are the SCLs for RHEL. In the future
there might be a flourishing softwarecollections.org collection of scls as
well. We want to give people access to install these other platforms on
Fedora.
== Strategy ==
The proposed strategy is for the SCLs produced by Fedora in the main Fedora
Repositories to basically stay with the FPC. The SCLs in this other
category are what this working group should work on enabling.
<possible implementation note>
At the meeting, it was mentioned that the softwarecollections.org
repositories might operate under legal requirements similar to the Fedora
copr repositories would also be RH's responsiblity. If this is the case, we
may be able to code software that asks user's to confirm they want to use
softwarecollections.org repositories and then enables those repositories for
them. If this is the case, then our implementation may simply be writing
the software that prompts the user to enable the repositories.
mmaslano, do you have any information on this legal aspect? We would
probably need to have something in public that we could point FESCo/Fedora
Legal at if we want to do things this way.
</implementation>
== sclutils ==
What our involvement in sclutils v2 should be was also brought up in the
meeting. There were some general sentiments that were agreed upon but no
concrete plans stemming from that:
* scls are implemented via rpm macros which in the past has been 100%
controlled by the distributions. This leads us to the point that Fedora
as a distribution needs to be involved with defining these macros.
* Not sure precisely which group should be doing this -- perhaps it should
be FPC since this is what they've dealt with in the past or perhaps it
should be us since we're dealing with new packaging technoilogies.
* The point was brought up that whoever it is, they need to be committed
to working on this issue. If they're not, then it will be a quagmire.
So it could even be a new group of people if that's what it takes
* However, the purpose of this needs to be to get all of the stakeholders
talking to one another. Right now we have a great many stakeholders but
their needs aren't being adequately communicated to each other. Another
group that coordinates would be good. Another group that simply becomes
another stakeholder would be bad.
mmaslano: Something I've been lacking in FPC... Could you send a list of the
stakeholders you know about and what they're doing? Who are the active
people on upstream softwarecollections.org? Who are the people doing
work on sclutils itself? Who are the people working on the scls for RHEL?
How much do those groups have separate interests and how much are they
a single team?
-Toshio
10 years, 2 months
[RFC] Vision and Mission Statement
by Tadej Janež
Hi!
I think our PRD would benefit a lot from having a clear Vision and
Mission Statement at the beginning.
For an example of both, see the Server's PRD:
https://fedoraproject.org/wiki/Server/Product_Requirements_Document_Draft
Below is my initial draft of both.
Vision Statement:
Fedora Environment and Stacks Working Group is a research and
development group working on new ways to provide the latest software
stacks in Fedora. It also works on transforming Fedora into the
preferred environment of software developers.
Mission Statement:
Fedora Environment and Stacks Working Group is a group incubating new
ideas for packaging, testing and delivering the various existing and new
software stacks in Fedora. The successful ideas will graduate and become
an officially released and supported part of the Fedora Project.
Comments?
What should we put in the Mission Statement for the "environment" part?
Tadej
10 years, 3 months
Polishing the PRD
by Tadej Janež
Hi!
There are some parts of the PRD that feel to terse and unclear to me.
They are:
1) (under Testing/additional repositories)
* A repo with packages only for the build. It might help some developers
to just build their package without maintaining the build dependencies.
2) Build systems
* COPR & koji
** COPR able to build an SCL
** koji - a number of improvements for developers (buildlogs, etc.), in
co-operation with the koji upstream.
3) SCL
* SCL in Fedora.
** Pending in FPC. Most probably each SCL will be added into Fedora as a
system-wide change.
* SCL in SCL.org from COPR.
** Possible to use 3rd party repos for various projects.
** Almost ready.
* scl-utils v2
** New features out of scope for this version of the PRD.
4) CI
* Out of scope (going to take a long time to be included in Fedora,
maybe even the inclusion for this group).
** AutoQA - co-operation with Fedora QA.
** Jenkins - upstream projects for Fedora should use
http://jenkins.cloud.fedoraproject.org/
I would expand them myself, but I'm not knowledgeable enough. So, I
would kindly ask those who put them in or those with enough expertise to
expand them.
Also, I would turn the sections of the PRD around so that "About this
Document" section would come at the end. That way the PRD's content will
have more spotlight (it would be similar to the Cloud's PRD).
Thoughts?
Regards,
Tadej
10 years, 3 months
new deadline for PRD
by Marcela Mašláňová
Yesterday, FESCo agreed on new deadline for PRD - 20th January. Let's
finish our PRD before our next meeting (14th).
Marcela
10 years, 3 months
