Fedora 21 Alpha Release Readiness Meeting :: Thursday, Sep. 04, 19:00 UTC
by Jaroslav Reznik
Fedora 21 Alpha Release Readiness Meeting.
date: 2014-09-04 place: irc.freenode.net in #fedora-meeting-2
time: 19:00 UTC (3 PM EDT, 12 PM PDT, 21:00 CEST)
This Thursday, September 04, we will meet to make sure we are coordinated
and ready for the Alpha release of Fedora 21 on Tuesday, September 09, 2014.
Please note that this meeting will occur on September 04 even if the
release is delayed at the Go/No-Go meeting on the same day two hours
earlier.
You may received this message several times, but I was asked to open this
meeting to the teams and I'll also hope this will raise awareness and more
team representatives will come to this meeting. This meeting works best
when we have representatives from all of the teams.
Jaroslav
9 years, 7 months
Re: Release notes have a launcher - maybe we should remove that
by Pete Travis
On Aug 28, 2014 3:05 PM, "Elad Alfassa" <elad(a)fedoraproject.org> wrote:
>
> Hello all.
>
> As you may know, we ship a launcher called "Release Notes" in our
> default install.
> During the F18 Launcher Purge[1] Allan asked the docs team to remove
> it from the default install, but his request was rejected[2].
>
> But now we have guidelines[3], and the guidelines state:
> * An "app" is an application as defined by the GNOME 3 HIG[4]
> * An app launcher SHOULD Launch software that is an actual app - see
> the GNOME 3 HIG for the exact definition
>
> And the release notes, well, are not an app (per the definition in the
> GNOME 3 HIG).
>
> Moreover, I don't really think users expect to find release notes
> inside the OS itself - no other OS does that.
>
> We can link to the release notes in our download page, our help page
> on the website (which will be linked from start.fpo once I finish
> implementing the new designs we got), and a bookmark in Firefox
> (pointing to a local copy of the release notes) - so the release notes
> won't exactly be invisible or inaccessible.
>
> We could also go the extra step (of craziness) and copy the release
> note PDF into the liveuser's Document directory (in the kickstart),
> where it will be indexed by tracker and thus accessible via documents
> and people who search for "release notes" in the shell would be able
> to find it (why would they do that? I don't know). It's possible, but
> for me it seems extremely crazy and unnecessary.
>
> While I'm aware what I'm suggesting here might be a little bit
> controversial, I do think it is something which we should consider.
>
> [1] https://fedoraproject.org/wiki/Design/F18_Launcher_Purge
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=846316
> [3] https://fedoraproject.org/wiki/User:Elad/Draft_app_guidelines
> [4] https://people.gnome.org/~tobiasmue/hig3/application-basics.html
> --
> -Elad Alfassa.
> --
This seems like [another] case of "we want to show all available desktop
files without filters, but that looks cluttered, so all other packages
should change so we don't have to add filters." I appreciate the work
you're putting into the details on the default install, really, but as has
often been pointed out it will be really easy to gain that clutter back
with Software. Two things can change here; *all* packages shipping
desktop files, or the *one* displaying them.
Okay, backseat developer hat off, docs hat on. Yeah, I'd like to be free
of the fedora-release-notes RPM. It's a little extra work - really just a
spec bump and rebuild at that stage - I wouldn't have to do.
That said, users *should* have Release Notes, by default, offline, and
discoverable. Fedora changes a lot between releases, and I sincerely
believe that taking the extra measures to expose users to this
documentation helps alleviate frustration and prevents dissatisfaction when
something doesn't work as expected. What seems obvious in context isn't
always so apparent to those on the outside of your process. A measurable
portion of users will look for the reasoning and recommended remedies for
unexpected things they encounter.
Not everyone will simply think "oh, I can install that firewall config tool
with Software, I'm just going to accept that and not question it or look
for more information." Some will look for RNs, some will look for
speculative forum posts, some will look for blog posts, and some will look
for *you* to *personally justify* your actions. Our goal is to provide all
of these people the information they need to understand the behavior they
encounter and achieve the behavior they want. It's a service provided by
the Docs team to both users *and* developers. The benefits outweigh the
pain of having an icon that you aren't that interested in.
As a maintainer of that package, I'd welcome specific suggestions or
requests to improve presentation.
--Pete
9 years, 7 months
[system-administrators-guide] update the looks to section id
by Rashadul Islam
update the looks to section id
en-US/Viewing_and_Managing_Log_Files.xml | 21 ++++++++++++++-------
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/en-US/Viewing_and_Managing_Log_Files.xml b/en-US/Viewing_and_Managing_Log_Files.xml
index 0264b99..0a3e343 100644
--- a/en-US/Viewing_and_Managing_Log_Files.xml
+++ b/en-US/Viewing_and_Managing_Log_Files.xml
@@ -30,8 +30,10 @@
<para>Some log files are controlled by a daemon called <systemitem class="daemon">rsyslogd</systemitem>. A list of log files maintained by <systemitem class="daemon">rsyslogd</systemitem> can be found in the <filename>/etc/rsyslog.conf</filename> configuration file.</para>
<para>
<application>rsyslog</application> is an enhanced, multi-threaded syslog daemon which replaced the <command>sysklogd</command> daemon. <application>rsyslog</application> supports the same functionality as <application>sysklogd</application> and extends it with enhanced filtering, encryption protected relaying of messages, various configuration options, or support for transportation via the <systemitem class="protocol">TCP</systemitem> or <systemitem class="protocol">UDP</systemitem> protocols. Note that <application>rsyslog</application> is compatible with <application>sysklogd</application>.
+
</para>
- <section id="s1-configuring-rsyslog">
+ <section
+ id="s1-configuring-rsyslog">
<title>Configuring rsyslog</title>
<para>
The main configuration file for <application>rsyslog</application> is <filename>/etc/rsyslog.conf</filename>. It consists of <firstterm>global directives</firstterm>, <firstterm>rules</firstterm> or comments (any empty lines or any text following a hash sign (<literal>#</literal>)). Both, global directives and rules are extensively described in the sections below.
@@ -63,7 +65,7 @@ $MainMsgQueueSize 50000
$ModLoad <replaceable><MODULE></replaceable>
</screen>
<para>
- where <option>$ModLoad</option> is the global directive that loads the specified module and <replaceable><MODULE></replaceable> represents your desired module. For example, if you want to load the <literal>Text File Input Module</literal> (<command>imfile</command> — enables <application>rsyslog</application> to convert any standard text files into syslog messages), specify the following line in your <filename>/etc/rsyslog.conf</filename> configuration file:
+ where <option>$ModLoad</option> is the global directive that loads the specified module and <replaceable><MODULE></replaceable> represents your desired module. For example, if you want to load the <literal>Text File Input Module</literal> (<command>imfile</command> — enables <application>rsyslog</application> to convert any standard text files into syslog messages), specify the following line in your <filename>/etc/rsyslog.conf</filename> configuration file:
</para>
<screen>
$ModLoad imfile
@@ -802,7 +804,8 @@ kern.=crit joe
</section> -->
- <section id="s1-logfiles-locating">
+ <section
+ id="s1-logfiles-locating">
<title>Locating Log Files</title>
<indexterm significance="normal">
<primary>log files</primary>
@@ -950,7 +953,8 @@ compress
</para>
</section>
</section>
- <section id="s1-logfiles-viewing">
+ <section
+ id="s1-logfiles-viewing">
<title>Viewing Log Files</title>
<indexterm significance="normal">
<primary>log files</primary>
@@ -1087,7 +1091,8 @@ compress
When you check the <guilabel>Show matches only</guilabel> option, only the matched strings will be shown in the log file you are currently viewing.
</para>
</section>
- <section id="s1-logfiles-adding">
+ <section
+ id="s1-logfiles-adding">
<title>Adding a Log File</title>
<para>To add a log file you wish to view in the list, select <menuchoice><guimenu>File</guimenu>
<guimenuitem>Open</guimenuitem>
@@ -1111,7 +1116,8 @@ compress
</para>
</note>
</section>
- <section id="s1-logfiles-examining">
+ <section
+ id="s1-logfiles-examining">
<title>Monitoring Log Files</title>
<indexterm significance="normal">
<primary>log files</primary>
@@ -1137,7 +1143,8 @@ compress
</mediaobject>
</figure>
</section>
- <section id="s1-log-files-additional-resources">
+ <section
+ id="s1-log-files-additional-resources">
<title>Additional Resources</title>
<para>To learn more about <application>rsyslog</application>, <application>logrotate</application>, and log files in general, refer to the following resources.</para>
<section id="s2-log-files-installed-docs">
--
1.8.1.4
9 years, 7 months
Re: Release notes have a launcher - maybe we should remove that
by Elad Alfassa
Hi all.
To clarify my opinion on this, my proposal is:
We drop the launcher. Main fedoraproject.org page will link to the
release notes if it fits the design and website team's design.
Release notes will also be linked from get.fpo and the Fedora help
page (the help page will be linked to from basically everywhere).
In addition, in the first month after GA we will have a very prominent
"news bar" saying Fedora 21 was released recently and people can
download it or read the release notes, with appropriate links.
After this month the link will stay but move to a less distracting
location at the bottom of the page.
It will be *way* more visible than it is now, and we won't need to
deal with the problematic launcher.
--
-Elad Alfassa.
9 years, 7 months
Re: Release notes have a launcher - maybe we should remove that
by Elad Alfassa
On Tue, Sep 2, 2014 at 1:16 AM, Leslie S Satenstein
<lsatenstein(a)yahoo.com> wrote:
>
> Hi Elad
>
> Sometimes I wonder if I am alone with the documentation group. I see that you and I have similar ideas.
>
> I have been stating that the release notes, perhaps in pdf format, should be stored in the same directory as the ISO images.
>
> The notes could be in html format by language
> b) Torrent file -- ditto
> c) PDF or *odt format
>
> If wanted, use a a separate directory to hold the notes. In this case, a language code in the title would distinguish the appropriate translation.
>
> In my view, If I have already installed the ISO, it is too late for the notes -- Fedora21 will be functional. The true use of the notes is for planning the upgrade, be it by fresh installation or via fedup.
>
> But what would be of interest to me for pre-installation planning would be a bill-of-lading -- a contents list for each of the Fedora 21 iso images.
>
> Regards
>
> Leslie
> Mr. Leslie Satenstein
>
Hi Leslie.
That sounds like a good compromise.
The Final Release Criteria doesn't state we need the release notes on
the *installed* system, it uses the phrasing "on the image"
https://fedoraproject.org/wiki/Fedora_21_Final_Release_Criteria#Release_n...
So, yes, this is possible, but to make it happen we need to generate
PDFs for the release notes, and get rel-eng to put them on the media
itself.
Just one thing: next time please use "reply to all" to reply on-list
so other people can see your message too.
Is this compromise (putting PDF files in the directory on the media
instead of in the live system itself) acceptable for everyone?
--
-Elad Alfassa.
9 years, 7 months
Re: Release notes have a launcher - maybe we should remove that
by Pete Travis
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 08/30/2014 10:42 AM, Michael Catanzaro wrote:
> On Sat, 2014-08-30 at 19:22 +0300, Elad Alfassa wrote:
>> I really don't undertand why "not installing the release notes" is
>> such a big change we need to wait for the next cycle to implement.
>> It's really just a one line change. And if we want to install them but
>> not provide a launcher (so they could be opened by a bookmark in
>> Firefox) than I'd happily provide a patch to split the launcher to a
>> subpackage.
>
> Eh, I'm just picking my battles here. A Release Notes launcher that
> starts Firefox is not good and we should get rid of it, but it's not
> very bad either and if the release notes people want another cycle to
> rethink how to present the release notes, well why not let them have it?
>
> Another thing we could do is add it as a default web app. GNOME Software
> requires "epiphany-runtime" which is all of Epiphany except the desktop
> file, so that it can install and remove web apps. Well, why not make the
> release notes a web app -- then the release notes team gets to keep the
> desktop launcher, and we are happy since it's a real application.
>
>
Someone had proposed that in #fedora-docs late yesterday, I like it.
I'm working on some copy right now, and will go for an ephiphany web-app
style presentation in GNOME for the next RPM.
For the record, the collaboration part of my arguments here are *far*
more important to me than the actual inclusion of a Release Notes RPM.
It's a valid discussion, and I would much rather start on that basis,
instead of potentially missing a discussion about a design philosophy on
a SIG list, then finding out about the impact when I learn that an RC
isn't meeting release criteria because of my package.
- --
- -- Pete Travis
- Fedora Docs Project Leader
- 'randomuser' on freenode
- immanetize(a)fedoraproject.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJUAgFYAAoJEL1wZM0+jj2ZfXYH/A6jnJh2qnZMqMcggGjamzg4
k2tQQoT/Imx9HF3ZEebs2WlS1w2b8HVg/WBFx0joGXMV9iER8TeFQSOLndy7Col1
vmO44BtWCUJfHG6valf+g+mnXuMMeVLsPy707axSKR/glctRakD1msXiyqpz/IxF
CxFJGennU4f2ypXAPszk6SS26MkIJuY+nyB/5CDN1NAW5yWgPQ8xTH/xxPt6Imnm
KycuexVq4MrmtPO7R0VdThavxJLf9GaAR0Exv/HqJXuEhKrxsAmTMOsPsxKWyZR3
aNPGb5XDfeIz3eAkUdI7goKTxYDaeVD5sW0KxXDBBdTKnbyCK7MSpjoI3wDfB5k=
=0JZ2
-----END PGP SIGNATURE-----
9 years, 7 months
