Re: Closing fedora-docs bugs
by Andrew Ross
----- "Ruediger Landmann" <r.landmann(a)redhat.com> wrote:
> On 12/15/2009 01:24 PM, Andrew Ross wrote:p { margin: 0; }
> > Part of my QE role has been to sniff out and close down ECS
> > documentation bugs. There are currently 8 bugs under the
> "fedora-docs"
> > component that are in RELEASE_PENDING or ON_QE. [1]
> >
> > Would I be stepping on any toes by closing down these bugs (and
> > similar ones in the future)?
>
> I think this would be awesome; thanks for stepping up to volunteer,
> Andrew :)
>
> Cheers
>
> Rudi
>
As suggested, I won't close them immediately. Some kind of warning (reminder for jjmcd) sounds fine :)
Will also look at patch / commit on other bugs.
> --
> fedora-docs-list mailing list
> fedora-docs-list(a)redhat.com
> To unsubscribe:
> https://www.redhat.com/mailman/listinfo/fedora-docs-list
--
Andrew Ross
Associate Quality Engineer
Red Hat Asia Pacific
Phone: 3514 8331
E-mail: anross(a)redhat.com
GPG-KeyID 0xCF53DC64
"We demand rigidly defined areas of doubt and uncertainty!" Vroomfondel in HHGTTG, Douglas Adams
13 years, 9 months
Re: Branch 'f12-tx' - po/ko.po (Action Required)
by noreply＠boxbe.com
Hello Transifex System User,
This message serves as notification that you will not receive any more courtesy notices
from our members for two days. Messages you have sent will remain in a lower
priority queue for our member to review at their leisure.
Future messages will be more likely to be viewed if you are on our member's priority
Guest List.
Thank you,
krishna.tadepalli(a)gmail.com
About Boxbe
This courtesy notice is part of a free service to make email
more reliable and useful. Boxbe (http://www.boxbe.com) uses
your existing social network and that of your friends to keep
your inbox clean and make sure you receive email from people
who matter to you.
Boxbe: Say Goodbye to Email Overload
Visit http://www.boxbe.com/how-it-works?tc=1040577281_1239200604
13 years, 9 months
Closing fedora-docs bugs
by Andrew Ross
Hi Everyone,
Part of my QE role has been to sniff out and close down ECS documentation bugs. There are currently 8 bugs under the "fedora-docs" component that are in RELEASE_PENDING or ON_QE. [1]
Would I be stepping on any toes by closing down these bugs (and similar ones in the future)?
Thanks
Andrew
[1] Example:
https://bugzilla.redhat.com/show_bug.cgi?id=506344
--
Andrew Ross
Associate Quality Engineer
Red Hat Asia Pacific
Phone: 3514 8331
E-mail: anross(a)redhat.com
GPG-KeyID 0xCF53DC64
"We demand rigidly defined areas of doubt and uncertainty!" Vroomfondel in HHGTTG, Douglas Adams
13 years, 9 months
F13 Docs Schedule Meeting
by Eric Christensen
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I'd like to setup a meeting for early next week between the translators
and the docs folks to work out the schedule for the F13 release.
I was thinking Monday between 1800 UTC and 2000 UTC or between 2300 UTC
and 0300 UTC (Tuesday).
Would there be a time in there that we could meet?
Thanks,
Eric
Docs Project Lead
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJLIEizAAoJEDbiLlqcYamxABsP/25XjHbUPX3fhzXdrY+ccWz5
wiSKE+BBHDF4XxSXFIjCUQKQFOiejrm6rUeLI/+vr2zyEeLsm6f6U5das5/iBZp/
TSjJ032AMWAFxKwB6/N2gHs4VYv4doCF/MKh7KN1xcs0Dtnb9sLqfQB9hoyLoV1L
EVcRaQmVMlByN+MS5x1zSOofDuE8RjCHgJukBO0zZlstGuIkiEfZ9PH79SR5tV/5
MgBs2tNftdgkSvvcUv4m2vKqiFUY3jodrfgVQVh6heCvlXQzGvMY6pMn8yliXvJu
/i7ZVqfLZISlY08/VHlhSdR1tkP0N/C68Zpv1n+6hqFUJTPqxbW8Fk/AnyMmvmSz
3uzF3u8jHU+PKiZ+9TOKcBZKI1CnKt+/1h/TzGQ3b4CHvCM+0XFFpM8gC6+l7XDu
XPai/siANNP+g29ipkligE5LKVUYWU1us1C01ExZB8ggqZQ9fV3ohuPKW9kwsqZI
oe7z6vQ2ZftRbzX0/OxsGix/ll9x654Efe/azkHPDr91irgpXCc4xkPXFPr2Dc+z
mAF19SvdYev4h3EUHhuUVKTH5kk/hKR/wk6g8RGSRL0gv9PCY0yIbv36agyO4d86
+DG7jImKoUYkymaxF62zLqcedd6D/5fRFuUnAc4LK2SNpE4oqqbfuKaaih6tNXEy
xX6ZWHR/Ckqmxr6Zp1Ih
=W8Cl
-----END PGP SIGNATURE-----
13 years, 9 months
Addressing Yelp Concerns
by Shaun McCance
Hi all,
I'd like to address the Yelp concerns outlined here:
https://fedoraproject.org/wiki/Desktop_Documentation_Presentation_Options
My comments are generally geared towards Yelp 3.0, which will
be released with Gnome 3.0 in September 2010. The design of
Yelp 3.0 is geared more towards individual documents, focusing
less on the library of installed documents. It will be able
to locate and read help documents in DocBook, Mallard, or HTML.
It will also continue to be able to read man and info, though
I view these as bonus features, and not central to the design
of Yelp.
I do want to make sure that multiple-page HTML documents are
handled well in Yelp. So even if you find that letting Yelp
render DocBook on the fly doesn't work for you, you may still
be able to use Yelp with pre-built HTML.
The front page of Yelp will be the Desktop Help ("User Guide"),
which will be a Mallard document. Mallard is a new format for
topic-oriented help. It has many advantages (which I'll gladly
talk your ear off about), but the primary selling point is that
it's designed around the idea that downstream distributors will
extend and modify upstream documents. I hope the Fedora team
will take advantage of this and extend Gnome's Desktop Help to
better assist users.
That said, I understand that many of the documents that you're
developing and packaging aren't typical desktop or application
help files, and that you may have special requirements to fit
your users' expectations. My goal is to help you help your
users. I hope Yelp will be useful, but if it's not the right
fit, then do what's best for your users. Your users trump my
ego any day.
Enough yakking.
* Fedora documents are found in Help, alongside Gnome documents,
even though these are stand-alone documents generally not coupled
to any particular application and are therefore a different kind
of documentation from what's generally provided in help and what
users therefore expect to find there.
Yelp is moving away from the focus on all installed documents,
although this will still be available. Some clever categorization
could help this. There is, of course, nothing that precludes you
from continuing to put links in the application menu to documents
that are displayed in Yelp.
* Yelp has some size limitations. At this time it is not entirely
clear whether this is a limitation on some specific item such as
index entries or an absolute document size limitation.
There are no real size limitations, except possibly the recursion
limits in libxml2, although I doubt you're hitting those. This
is probably just a symptom of the speed issue below.
* Since yelp handles rendering, there is no control over document
style.
I generally view this as an advantage. Fiddling with design is
not something authors should spend their time on. When they do,
they often create something blingier, but decidedly less readable.
That said, I understand the desire to brand a set of documents.
I'm entirely open to having some sort of XSLT "themes" that can
be installed and referenced by documents. It's something I've
toyed with in the past. But nobody's expressed interest before,
so it never became a priority.
* Yelp does not produce document indices when requested.
True, although that doesn't mean it couldn't. That's clearly an
important feature for Fedora, so I can bump it up on the priority
list.
* Yelp can be slow. For larger documents, very slow. Breaking the
document into multiple files does not help.
DocBook is an inherently single-file format. I assume this is
referring to using SYSTEM entities or XInclude to slurp other
files in. All of that is handled by libxml2. As far as Yelp
is concerned, it's reading one big file.
So when I first took over Yelp, I managed to get a lot of very
big performance improvements in. Then I took a hiatus. Some
of my improvements got lost, and a few I had planned never got
done.
We can make Yelp noticeably faster. I know where most of the
bottlenecks are. Obviously, though, there's no way on-the-fly
transformation will ever be as fast as reading an HTML file.
It's a question of what's fast enough.
* Yelp does not display the Publican-produced revision history.
This I can address, even in the 2.30 timeframe if you want.
Basically, Yelp's interpretation of DocBook revision history
is a product of the way Sun was using it to satisfy, to the
letter, the requirements of the GFDL. It's a quirky legacy
behavior, and we can't throw it away entirely, but we can
adapt to what Publican is doing.
* Publican cannot currently package multiple languages, and at this
time, it appears it will not address yelp packaging in the future.
Packaging a document for Yelp 3.0 is easy. You just have to
put it in a location Yelp understands. No ScrollKeeper or
any registration procedures. If Publican can't change its
installation directory, Yelp may be able to adapt to it.
* Yelp addresses only Gnome and does not help other desktops.
One of the big things happening in Yelp 3.0 is that we're
splitting the transformation core into a separate library,
libyelp. The XFCE team has already expressed an interest
in building their own help viewer on top of libyelp.
Of course, I understand that KDE is important. I've been
talking to the KDE team, and I hope we can finally come to
a consensus on a common help system. That way you can just
install your documents to a common location, and Gnome, KDE,
and XFCE would all pick it up.
* All languages are installed, whether or not needed. The installed
size in all languages for our longer documents is hundreds of megabytes.
I don't see how this has anything to do with Yelp. This
is a matter of how you package your files. Are those pesky
OMF files keeping you from doing language packs properly?
I'm fairly certain there's nothing in the 3.0 designs that
will force this. The Ubuntu team is also interested in
doing language packs for documentation, so I want to get
this right.
* Package maintenance has a high overhead; the package maintainer
must update the package any time any translation team needs to make
a correction or update.
Again, I'm not sure what this has to do with Yelp. Please
let me know what Yelp can do better to help you here.
* Packages for larger documents may be hundreds of megabytes. Each
language may (should) have localised images. Images can take up
substantial space. Limiting images is not an option as images are
useful for various aspects of learning and documentation.
Right, so this is the language pack thing again. I will say
that one of the nice things in Yelp 3.0 is that it looks up
everything according to a path, and can fall back to content
elsewhere in the path. This includes images. So if you have
both a "C" version and a localized version of a document, and
you have non-localized images (common for including icons in
documentation), you don't need to install those images with
the localized document.
I'm also working on allowing the XML files to be compressed
on disk. This doesn't help the package size, but it does
help the install size of the package.
In the end, though, if you have huge documents with lots of
translations, you probably want to do some sort of language
packs. I think this is mostly a packaging and distribution
problem, so the ball's in your court. But I want to make
sure that Yelp isn't putting up extra roadblocks, so please
let me know if it's making this difficult.
Thanks for your time; I know this email was long. And
thanks to everybody who's been bringing these concerns
to my attention. I'm trying to be more involved with
downstream, but there's a lot to keep up with.
--
Shaun
13 years, 9 months
RFC: Unetbootin in Install-Guide
by David Nalley
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi All:
We've had somewhat competing bugs (links below) filed around Unetbootin.
Originally we referenced Unetbootin, and mentioned that we didn't ship
it in Fedora, which is now incorrect, and the cause of the the first
bug that was filed.
Here was original:
UNetbootin is a free and open-source graphical tool that can create
live USB media from live image files on computers that use a wide
range of different Linux distributions. The Fedora Project does not
distribute UNetbootin — it is available from
http://unetbootin.sourceforge.net/. Refer to that website for a
complete description of the tool and instructions on how to use it.
Here is the current paragraph:
UNetbootin is a free and open-source graphical tool that can create
live USB media from live image files on computers that use a wide
range of different Linux distributions. Refer to the documentation
provided with UNetbootin for more information on how to use it.
Ricky has submitted a patch that essentially strips mention of
Unetbootin from the install guide.
Our current documentation is pretty sparse with regards to Unetbootin.
Sooooo, how do we want to handle Unetbootin in our documentation.
https://bugzilla.redhat.com/show_bug.cgi?id=540954
https://bugzilla.redhat.com/show_bug.cgi?id=545577
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Use GnuPG with Firefox : http://getfiregpg.org (Version: 0.7.10)
iEYEARECAAYFAkskoAkACgkQkZOYj+cNI1dF8wCcCpWWyr7ptMMLT5G03VXjNMDB
7j0An0Tlgb9rddR8c3vUv/XIL7HRYKhE
=yXQC
-----END PGP SIGNATURE-----
13 years, 9 months
REMINDER: Updates for docs.fp.o NLT 0600 UTC
by Eric Christensen
Just a reminder, if you have any updates to any guides on docs.fp.o please
make sure it is uploaded to CVS no later than 0600 UTC. CVS will be down
for the weekend and no updates can occur.
--Eric
13 years, 9 months
Re: Docs Installation Guide - Submission and Download problem
by Paul W. Frields
On Fri, Dec 04, 2009 at 10:51:59AM +0200, Dimitris Glezos wrote:
> 2009/12/3 Ruediger Landmann <r.landmann(a)redhat.com>:
> > On 12/02/2009 05:47 PM, Dimitris Glezos wrote:
> >>
> >> Rudi, you could clear the cache and refresh it.
> >>
> >
> > Really? How do I do that? I'd thought that a button like that would be useful for the
> > maintainer of a project
>
> This button is available on the web interface on component pages for
> maintainers.
>
> > , not least of which because changes to a POT in the repo don't automatically
> > trigger a refresh (of course!) while submissions of updated POs do.
>
> This functionality has been available in Transifex for a while, it's
> just that Fedora is still running an old (and unmaintained) version.
Diego posted the summary of what needs to be done here:
https://fedorahosted.org/fedora-infrastructure/ticket/1455#comment:10
In short, we need a few people to step up and help with the process
Diego posted.
We already do have a L10n Admin group[1] that should be overseeing and
managing this process, to ensure a successful rollout for translators.
Their charter is to maintain the infrastructure for translators, and
this clearly falls into that area. I've heard from two of the people
in that group that they can't do all this work themselves, but haven't
heard from Ankit or Asgeir about it.
What I would suggest is that Diego should help with bullet #4 on that
list, as it probably requires the greatest degree of specific
technical knowledge, in this case a database upgrade. The rest of the
work on that ticket could likely be done entirely by the remainder of
the team, maybe with limited input from Diego. It would be helpful
for Asgeir or Ankit to help manage this set of tasks in collaboration
with Diego, who has appropriate package access. (I'm cc'ing Ignacio
directly as well, so he can add appropriate CVS access for any other
people who are willing to help maintain the EL-5 package used on our
Infrastructure.)
Without help, it's doubtful there will be a new Transifex rolled out,
and that means some of the problems people are experiencing will
continue, even though they're already fixed upstream. I'm cc'ing the
docs, devel, and infrastructure lists to see if any of the people in
areas well served by translators are willing to help see this project
through. It's time to pull together, guys, and see if we can help the
translators who give so much across the whole Fedora Project.
* * *
[1] https://fedoraproject.org/wiki/L10N/Tools#Website
--
Paul W. Frields http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://redhat.com/ - - - - http://pfrields.fedorapeople.org/
irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug
13 years, 9 months
Docs Meeting 2009-12-10 Summary
by Eric Christensen
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
===================================================================================================
#fedora-meeting: Docs Project Meeting - Agenda:
http://fedoraproject.org/wiki/Docs_Project_meetings
===================================================================================================
Meeting started by Sparks at 00:00:00 UTC. The full logs are available
at
http://meetbot.fedoraproject.org/fedora-meeting/2009-12-10/fedora-meeting...
.
Meeting summary
- ---------------
* Roll Call (Sparks, 00:00:07)
* Release Notes (Sparks, 00:05:00)
* Status on CMS (Zikula) (Sparks, 00:22:54)
* LINK: https://fedoraproject.org/wiki/Zikula#Module_status (Sparks,
00:23:00)
* Guide Status (Sparks, 00:27:53)
* New Guides (Sparks, 00:34:06)
* F13 Schedule (Sparks, 00:37:48)
* ACTION: Sparks to send a message to L10N and Logistics about a docs
planning meeting for early next week (Sparks, 00:56:45)
* ACTION: jjmcd to review poelcat's schedule and come up with a
recommendation before the meeting (Sparks, 00:57:26)
* Other business (Sparks, 00:58:22)
Meeting ended at 00:59:58 UTC.
Action Items
- ------------
* Sparks to send a message to L10N and Logistics about a docs planning
meeting for early next week
* jjmcd to review poelcat's schedule and come up with a recommendation
before the meeting
Action Items, by person
- -----------------------
* jjmcd
* jjmcd to review poelcat's schedule and come up with a recommendation
before the meeting
* Sparks
* Sparks to send a message to L10N and Logistics about a docs planning
meeting for early next week
* **UNASSIGNED**
* (none)
People Present (lines said)
- ---------------------------
* Sparks (104)
* jjmcd (82)
* radsy (17)
* zodbot (3)
* buggbot (2)
* Darkedge (2)
* ianweller (1)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJLIEj+AAoJEDbiLlqcYamxKUAP/iTJuyDWxhJlzABFqs5HZduZ
JBHCEIw4eiPyiZO+5jZ4nvIWgBi693uBT0prW26u7502g7/FWP/z7B4h7OI8zLYm
3sN2MZOwgkPKf0XS9EQKbuHHSn6klIumvaWdFfC8qXgJuNp4yhfbQkj0bv7IrQaI
AqO0dfhJ9G9kKqGIh9g/Qr02REHYPSFQyaGim0f+yCxbG+KR8Z92GNXQQPqZoPYx
h2WVokDXFM/hWUV4MjpOnABHj/3m6ku8hTYoOM2oiRWC/mkFwa0Bk4Di38ARDI1Y
juvAwK1RO8jHbt2TQq8XETJBuFv26tf2OwlDHUH544TILgj199JBIopsAVUrIMkT
TIlLfkcIX0rDbA9eyiOLgasOHUo9CxBbWxj0huGT7QqqocMyMAq8dFTokrZh/ZZ9
0C2dJW1K2sySEHLHbYBlJY0lZgGZi933BNa0qrkULt1IaOBb4dsC/QV6awEu6AWl
3B+x59bS64fCiDC8fHnqkYD3fWzCTSx+eF075rhDlI1UfB7P3oztVucv2GIrC0wu
FzGDu0ZMmC/RcSVZn+tgu92LN/Rt7rnnrTk66xxKA3J7SNpCxjqE7FFZEYxhkjVr
nia5gfDXTQuLOB2bcUMCRD/S6o5hAYpPysj2i89lW3Le1o+bqKBY1F9IFf/kNjQC
nwL2Wuz0sRq70tfsyumB
=PNfm
-----END PGP SIGNATURE-----
13 years, 9 months
