where to place bugzilla components
by Karsten Wade
As we begin to have more documents that have installable packages
(beyond the release-notes and fedora-release-notes package), it might
be confusing why we have apparently duplicate bugzilla components.
What do you all think of this historical methodology?
Would be nice to get a modern consensus so we can document how and
why.
As an example, we have the 'release-notes' component in the Fedora
Documentation product on https://bugzilla.redhat.com. There is also
the 'fedora-release-notes' package component in the Fedora product.
The 'release-notes' component is for the upstream content. In that
sense, *any* bugs reported against content should really be moved to
that component; we probably have failed to do that until now.
The 'fedora-release-notes' component is really for the package only.
Because 'f-r-n' doesn't really break many things, it may not get many
such bugs.
Now that we can easily build RPM packages using Publican, we are
likely to see more documents submitted as actual packages to be
installable in Fedora. Then they show up under System >
Documentation, etc.
As a final confusing item, we have a Trac instance in the *real*
upstream project, https://fedorahosted.org/release-notes. This issue
tracker is strictly for the writing team(s) to coordinate work. So, a
bug against 'f-r-n' may get moved to the 'r-n' component, then create
one or more tickets in the upstream Trac.
We could look at eliminating the Fedora Documentation component. What
are the risks of doing that?
Rewards seem to be -- simpler system, less confusion about where to
file a bug.
For the record, no one has ever reported confusion in where to file a
Release Notes bug. People find one or the other component, probably
don't know of the other, and file their bug. Since we haven't been
moving bugs between components, most folks are probably not aware
there are two similar-sounding bugzilla components.
One approach is, we could look at completely eliminating the Fedora
Documentation product. We would then move all of our content/upstream
bugs to the individual Trac instances. This would require a package
for each document, so it had a way to take bug reports via bugzilla
under the regular Fedora product. Just like any other package works
in Fedora.
- Karsten
--
Karsten 'quaid' Wade, Community Gardener
http://quaid.fedorapeople.org
AD0E0C41
15 years, 4 months
Re: Some thoughts on beat writing
by Dale Bewley
----- "Karsten Wade" <kwade(a)redhat.com> wrote:
> So, yes, there is a novel idea here -- a permanent beat page on the
> wiki that has:
>
> * Commands to use to get more info about packages (yum info, rpm -q
> --changelog)
>
> * List of packages for that section
>
> * Programmatically generated changes between FN and FN-1
I hadn't pondered digging into the sqlite files. I found koji to be helpful for finding the version delta of packages across (non-EOL) distributions.
My messy hack is here
http://fedoraproject.org/wiki/DaleBewley#Virtualization_Release_Notes
* pkgs.in contains CSV package name, relnotes URL
* dist.in contains f9, f10, etc
#!/bin/bash
grep -v '^#' pkgs.in | while read line; do
grep -v '^#' dist.in | while read dist; do
pkg=`echo $line | awk '{print $1}'`
notes=`echo $line | awk '{print $2}'`
ver=`koji latest-pkg "$dist" "$pkg" | tail -1 | awk '{print $1}'`
echo "$pkg, $dist, $ver, $notes"
done
done
I then read the upstream relnotes for each release since the last Fedora distribution to produce a summary of changes for the Fedora relnotes.
John mentioned a page to augment a beat for tracking changes. That may be an appropriate use of the discussion tab on an article. As a new beat writer, I used my personal page for that.
I think a page of tips like this will be very helpful.
15 years, 4 months
Self-Introduction: Basil Mohamed Gohar
by Basil Mohamed Gohar
Greetings, Fedora Documentation list! My name is Basil Mohamed Gohar,
and I'm keen to join the Fedora Documentation project per encouragement
from Karsten Wade. What follows, hopefully, fulfills the requirements
of the Self-Introduction for joining the group, but should also give you
a bit of an idea of me.
I am a graduate of The Ohio State University with a bachelors degree in
Electrical & Computer Engineering (it's only one major despite covering
two subjects), class of the Summer of 2004. I currently work as a web
developer for a small consulting firm in Columbus, Ohio whose primary
business relates to virtual schooling, including homeschooling & charter
school programs.
My personal experience with Fedora started with Fedora Core 5, when I
installed it on my computer just to play & explore a GNU/Linux operating
system. Though I'd been a support of free software since I understood
what it was, I had not yet been ready to take the plunge & commit myself
to it. That experience changed it for me, and by the time Fedora Core 6
was released, I had switched to using it as my main system. Prior to
using Fedora, though, I had been using Red Hat Enterprise Linux 3 & 4 on
two servers that I leased for hosting my own web sites since 2004 &
2005, respectively, so I grew familiar with a command-line *nix
environment through managing those servers. I am what some would call a
free software fundamentalist, because I believe free software is
fundamentally better due to the principle that is free as in freedom.
I have had some experience writing documentation for projects & programs
before, but nothing as large-scale as Fedora. I am a native speaker of
the English language, having been born & raised in the US my whole life.
I tend to be picky about grammar where I notice a mistake, and I am
pedantic when it comes to ensuring what has been stated is factually
correct. I consider myself to be verbose, but clear, when I write, but
that is a judgment best left for others. ;) I have done a little
documentation work for the Fedora Unity project, but that stalled when I
had to move on to other projects at that time.
I have been using computers since I was very young, as there has always
been a computer of some kind available in our homes. Being a developer,
I suppose that I am an "expert" computer using on most platforms, with
the exception of Mac OS, as I do not own any Apple hardware.
As I mentioned earlier, I am a web developer by trade & hobby. I work
primarily with PHP & MySQL. I would describe myself as a PHP guru, but
I wouldn't disagree if others claimed I was. ;) I have been
programming for over 6 years, having taught myself PHP after learning
basic Perl to parse HTML tables to convert them to Microsoft Excel
documents (yuck!). I was also encouraged by my desire to write my own
website code for listing files for people to download.
I feel I am an excellent match for the Fedora Documentation project
because I believe that free software is fundamentally superior, I
communicate well, and I want to contribute to something that will
benefit people & make free software easier for people to use by having
quality resources available to them.
My GPG fingerprint follows:
pub 1024D/25DB6E43 2008-12-11
Key fingerprint = 29B4 52ED 2335 1948 652A 22BB 873C DA6A 25DB 6E43
uid Basil Mohamed Gohar (Basil's GPG key) <abu_hurayrah(a)hidayahonline.org>
sub 2048g/7B467FE6 2008-12-11
I look forward to contributing more in the future, and I will follow-up
with an idea I had which is what encouraged Karsten to prompt me to
officially join the project in the first place.
________________________________________________________________________
Basil Mohamed Gohar
abu_hurayrah(a)hidayahonline.org
www.basilgohar.com
15 years, 4 months
Writing teams
by Karsten Wade
To make our lives sane, this project needs to work only on content
that people are actually committed to doing. In other words, there
are no release notes unless people want to write them.
First step is getting a lead writer for each document. If no one is
willing to lead, then we need to drop that guide from our production
list for Fedora 11.
Here is the list:
http://fedoraproject.org/wiki/Docs_Project_content_tasks_for_experienced_...
Once there is a lead, that person needs to work with all of us on
recruiting. That person should *not* expect to do all the work, and
in fact doesn't even need to be a good writer or editor; this is more
project management work.
If a team wants to act as a collective without a formal lead, that
team needs to put together a plan that will work, then bring it here
for discussion/approval/etc.
A single person can lead more than one guide, just be aware of the
workload.
- Karsten
--
Karsten 'quaid' Wade, Community Gardener
http://quaid.fedorapeople.org
AD0E0C41
15 years, 4 months
Re: Some thoughts on beat writing
by John J. McDonough
Paul I appreciate the feedback.
I do have a few thoughts on specific ways things might be made better for
new beat writers, but I also imagined that if other beat writers engaged in
the conversation, better ideas would emerge.
A little shooting from the hip:
1) Seed the beats, especially the untouched beats, with the information
available from yum. This can be done programatically, and I would be
willing to work on that, but I suspect that there may be a better way, and
in any case, the mapping of packages to beats is something that probably
needs to be easily editable, and that raises some issues I haven't
reconciled.
2) Provide some relatively automatic way for a beat writer to know what has
changed within his domain without grazing all 11K packages. I will do this
for myself for F11, whether I can do it in a way that is appropriate in a
production environment, I'm less sure. (I'm a big fan of really grody
hacks).
3) Provide new beat writers with an assigned mentor, preferably someone with
at least some familiarity with the beat content, as well, of course, as the
process.
I'm pretty sure other beat writers out there have much better ideas but they
are keeping their mouths shut. Perhaps I should have waited a few more
days. Indeed, with the holiday fast upon us, many of the stateside beat
writers are probably already headed off to their turkeys, leaving their
laptops alone and lonely over the long weekend. On the other hand, perhaps
some will emerge from their tryptophan haze in a talkative mood!
--McD
15 years, 4 months