RE: publictest boxes
by Simon Birtwistle
I've updated the usage of pt15 to include Zikula - note there also seems to
be a separate installation of Zikula relating to calendar testing on there.
Simon
> -----Original Message-----
> From: fedora-infrastructure-list-bounces(a)redhat.com [mailto:fedora-
> infrastructure-list-bounces(a)redhat.com] On Behalf Of Mike McGrath
> Sent: 17 June 2009 21:15
> To: Fedora Infrastructure List
> Subject: publictest boxes
>
> Hey guys, If any of you are sponsor for a publictest box or are using
> a
> publictest box. Please fill out the information for that box on the
> wiki.
> See publictest2 for example:
>
> https://fedoraproject.org/wiki/Infrastructure/Server/publictest2
>
> -Mike
>
> _______________________________________________
> Fedora-infrastructure-list mailing list
> Fedora-infrastructure-list(a)redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.5.364 / Virus Database: 270.12.76/2183 - Release Date:
> 06/17/09 05:53:00
14 years, 10 months
[Fwd: publictest boxes]
by Paul W. Frields
>From the fedora-infrastructure-list -- just making sure it's seen here
since I think we have a Zikula instance on a publictest box.
Paul
----- Forwarded message from Mike McGrath <mmcgrath(a)redhat.com> -----
Date: Wed, 17 Jun 2009 15:14:55 -0500 (CDT)
From: Mike McGrath <mmcgrath(a)redhat.com>
To: Fedora Infrastructure List <fedora-infrastructure-list(a)redhat.com>
Subject: publictest boxes
X-BeenThere: fedora-infrastructure-list(a)redhat.com
Hey guys, If any of you are sponsor for a publictest box or are using a
publictest box. Please fill out the information for that box on the wiki.
See publictest2 for example:
https://fedoraproject.org/wiki/Infrastructure/Server/publictest2
-Mike
_______________________________________________
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
----- End forwarded message -----
14 years, 10 months
Fedora 11 Retrospective Recap
by John Poelstra
Fedora 11 Retrospective Recap
2009-06-16
Wiki version: https://fedoraproject.org/wiki/Fedora_11_Retrospective_Notes
Invitees: Cross section of people and leads from each group:
https://fedoraproject.org/wiki/Fedora_11_Retrospective_Invitees
Attendees: James Laska, Bruno Wolff, Jóhann B. Guðmundsson, John
McDonough, Jon Stanley, Jarod Wilson, Todd Zullinger, Ricky Zhou, Steven
Moix, Mike McGrath,Jack Aboutboul, Paul Frields, Eric Christensen, John
Poelstra, Edward Kirk, Adam Williamson, Máirín Duffy, and Jesse Keating
Unrepresented Teams: Ambassadors, Translation
Location: Global teleconferencing system & Fedora Gobby
When: 2009-06-16 @ 14:00 UTC
== Meeting Guidelines & Agenda ==
1) Each person gets five minutes to say whatever they want. Suggested
questions to answer:
a) What went well?
b) What could have gone better?
c) If time and resources were not an issue, what three things would
make Fedora 12 our best release ever?
2) While the speaker has the floor nobody can interrupt or correct what
they are saying
--there are no "wrong" ideas
--other participants can seek clarification from speaker after they
are done
3) Other attendees will help capture points raised in gobby
4) Open discussion and go forward plans after each person has had an
opportunity to speak
== Meeting Outcomes ==
o Individual feedback (see below)
o John Poelstra will create a wiki version of these notes and post link
to in email recap to fedora-advisory-board
--https://fedoraproject.org/wiki/Fedora_11_Retrospective_Notes
o Jesse suggested checking back in a month to see how we are doing on
the things we said we said we wanted to change
--email is fine; telephone not required
o Jesse strongly urged people on the call to take the proposals from the
recent FAD back to their teams
--feedback needed ASAP
--will affect many parts of Fedora
--https://fedoraproject.org/wiki/Fedora_Activity_Day_Fedora_Development_Cycle_2009#Resulting_Output
o John Poelstra encourage attendees to blog about this meeting to give a
wider audience an understanding of what the meeting was like and what
they thought about it
o The Fedora CMS (Zicula) will affect a lot of groups in Fedora
--We need a point person to coordinate these efforts for our
greatest chance at success
--No one has been identified
o ADDED AFTER THE FACT by John Poelstra
--Anyone is free to tag onto the end of the wiki document to add
their own feedback
--https://fedoraproject.org/wiki/Fedora_11_Retrospective_Notes#Additional_Feedback_Outside_of_the_Meeting
== Legend ==
(+) Went well
(-) Could have gone better
(w) Wish-list--no limits--everyone CAN have a pony
== Jon Stanley (jds2001) - fesco ==
(+) Feature process went well
--good contingency plans
(-) X item fell through the cracks
(-) Meeting minutes creation failed
(+) Started using a minute meeting bot
(w) Massive QA testing
(w) Earlier freezing/branching for critical packages
== Eric Christensen (Sparks) - docs ==
(-) Release notes churn at the last minute
--some is legitimately unforeseen, other notes just not timely enough
(-) docs.fedoraproject.org page doesn't flow well
--languages hard to find
(+) Turned out more guides and docs than past releases
(+) use of Red Hat guides that were relicensed
(w) Zikula CMS
--will replace the existing docs.fp.o
(w) standardize and focus on release notes and meet more users point
== Jarod Wilson (j-rod) - FESCo ==
(+) Feature process went smoothly--deadlines understood and less confusion
(+) No major disagreements within FESCo
(-) No major disagreements within FESCo
(-) Meeting minutes
(-) Collection of public feedback not optimal (need more _constructive_
feedback)
(-) Secondary architecture team updates
(w) Focused Fedora kernel QA effort--build up community
== John J. McDonough (jjmcd) - docs ==
(+) people were great
(+) use of publican went surprisingly well
(+) install guide is the best we've ever had
(-) integrating milestones better into schedule
(-) pushing to docs.fedoraproject.org is an ugly process
--Too many formats
(-) Need more packagers on the docs team
(w) More engagement with developers/determining who to talk to
(w) PackageKit get fixed
--problems finding application to click on
(w) Problems with wireless on NetworkManager
== Edward Kirk (tk009) - BugZappers ==
(+) Communication really good about what was going on between all the
teams and across the project
(+) More people are joining the project and contributing
(-) Blocker bugs were not handled very well
(-) Problems at the end with Anaconda
--identifying blocker bugs before the last minute
(w) A more solid, stable release that is technically better than
anything else out there
== James Laska (jlaska) - QA ==
(+) 20 test days--way more than F10
(+) Documentation around test days and how to create live images, etc.
(+) Test results reporting
(+) Common F11 Bugs
--multiple teams were invested in success
(+) Community testing
(-) No specific test days for Sound
(-) No concept of capacity
(-) Clarify hand off procedures between Release Engineering & QA for RC
--"who has the ball?"
(-) Transparency around release readiness decision and whether to slip
--public discussion & publish minutes
(-) Automation of testing
(-) No metrics around health of QA community
(w) Micro-communities around each of the features
--specific dashboard
--blocker bug tracking
(w) Community test case management system
== Adam Williamson (adamw) - QA/BugZappers ==
(-) reading several reviews that Fedora 11 is un-installable
(-) unclear how to get in late release notes additions in a cooperative way
(+) Test Days were fantastic
(+) BugZappers and QA wiki spaces were substantially revised
(w) A massive testing lab
(w) Improving kernel triage for future releases
== Bruno Wolff - Games Spin ==
(+) Help from Jeremy Katz to enhance livecd-tools for larger games iso size
(+) Rawhide updates come quickly from the mirrors and Koji
(+) test days were helpful and gave focus to people
(+) New Spin process documentation got developed
--specific test instructions are now available
(-) Broken installer and video got in the way of testing
--painful when rawhide was broken
(-) We don't have a process for maintaining recurring spins
(w) Less broken stuff
(w) Spins process document finished
(w) Lots of test days
(w) More with live USB with persistent storage
== Jack Aboutboul & Steven Moix - Marketing ==
(+) Lots of progress restructuring the marketing team
(+) Release schedule helped cross team coordination
(-) Need to identify task inter dependencies and add them to the schedule
(-) Better capture things that get accomplished
(+) Inter group communication with Art, Translation, etc.
(w) Host mini-meetings with different teams throughout the release cycle
(+) Continuous content production
--building up and telling stories
(w) Fedora Magazine
(+) Tracking press reports in different languages
(w) Finding a better way to do metrics to identify how far our reach is
and understand audience
(w) More marketing to younger audiences and greater public awareness
== Ricky Zhou - Websites==
(+) two or three people helping consistently with Web team tasks
(-) Late changes from marketing and docs team which had minor impact
(w) Add a review period so that issues can be identified and corrected
before release
== Mairin Duffy - Design ==
(-) Need to see feedback to the Design list as opposed to sprung on blogs
(w) Six more designers on the team!
(w) pink pony!!!!11!!
== Jesse Keating - Release Engineering ==
(+) Better involvement with QA and Triage
--improved confidence in QA beating on the trees
(+) Did a better job of managing the blocker lists
(+) Good help from others verifying blocker bugs
(+) Test Days ... more feature owners are requesting targeted testing
(+) No last minute compose-related surprises
(-) Better communication around what testing needs to be done
--improve capture of testing outside of the matrix (mailing lists)
(-) Clearer guidelines around code changes
(+) FAD Proposals -
https://fedoraproject.org/wiki/Fedora_Activity_Day_Fedora_Development_Cyc...
(w) earlier review blocker bugs
--maybe weekly after we branch
(w) automated QA which provides automatic feedback
== Jóhann B. Guðmundsson - QA Team==
(w) Taking test days to the next level
--improved advertisement
--re-use live images for additional testing
(w) coordinate with upstream testing
(w) litmus testing system added to Fedora
--litmus is coded to be quite mozilla-specific (according to jlaska)
(w) Use of Fedora QA Trac system to track request from maintainers
(w) Host test day without requiring maintainer present
(-) lack consensus amongst maintainers if a reporter is supposed to
report to our bugzilla or upstream one
(w) Daily scheduled testing on components.
== Todd Zullinger -- Websites Team ==
(+) more complete translations than we've had before
(+) Infrastructure team syncing release content earlier than past releases
(w) relocate everyone to a tropical island where we can all work
together in person
== Mike McGrath - Infrastructure ==
(+) team is growing
(-) multiple release slips hindered work in infrastructure due to freezes
--one big slip would be nicer
(w) Feature freezes in earlier
(w) Contingency plans for core distro functionality
(w) Look for key ways that Infrastructure can enable success of QA Team
== Paul Frields ==
(+) Well coordinated for the releases including slip announcements
(+) Ambassadors did a great job behind the scenes
--media production
--release parties
(-) Feedback mechanisms are unclear and point to too many different places
--documentation and marketing materials
--could anaconda bug reporting mechanism be helped by design team?
(w) Marketing, Docs, Website, Design team work on coordinated approach
to the Zicula (CMS)
--organized and well coordinated fashion
(w) More forceful in not allowing late/invasive changes to rawhide and
putting them off to next release
14 years, 10 months
Publican documentation on docs.fp.o?
by Ruediger Landmann
The Publican User Guide is provided by the publican-docs package, which
makes it available in /usr/share/doc/publican-doc-<version>, and
therefore under the Documentation menu in GNOME. There's also an old
version on the web on the developer's fedorapeople page [1].
However, with pretty much all Fedora docs now built in Publican, I'm
thinking it would be useful to publish a copy of the Publican User Guide
on docs.fpo.o alongside the existing Fedora Documentation Guide. That
way, we can refer members of the docs and localisation teams to an
up-to-date version at a fixed address; it also gives us a fixed address
for links in other documentation (this whole issue arose in connection
with updating the Translation Quick Start Guide).
Unless anyone has any objection, I'll take care of this tomorrow.
Cheers
Rudi
[1] http://jfearn.fedorapeople.org/Publican/
14 years, 10 months
Re: selinux user guide
by Geert Warrink
Scott Radvan wrote:
> I have built and posted both here:
> http://sradvan.fedorapeople.org/SELinux_User_Guide/
> Please let me know if you are happy with how they look, and I will
> publish them to http://docs.fedoraproject.org
>Thank you for all your work with these translations!
I've made a few final corrections in the Dutch translation.
You can publish this translation now.
I am very happy with this document. It is a very clear description
of the SELinux principles and it helped me a lot to understand it
better.
Thanks,
Geert Warrink
14 years, 10 months
F12 and Beyond
by Eric Christensen
You will probably recognize some of these from the previous message
"What went wrong? What went right?" I sent to the list. These are
items that we wanted to fix within 60 days. Sixty days is August 13th
(a Thursday) so please provide input on these and if you'd like to help
with something please speak up!
Eric
Voted for these goals in order of decreasing priority:
Better communication and interaction with other teams and program
manager
* Docs Leader should attend/audit/log/read other project meetings
* L10n
* Design
* Websites
* Appoint liasions to other sub-projects rather than overloading DPL
with meetings
* Release schedule needs to include items for announcements to other
teams
* Docs Project sit down (virtually) with poelcat and grok the schedule
and release process
docs.fp.o site sucks (Mo knows)
* Zikula
* Zikula IS *THE* SOLUTION.
* Track record
* Participation by their upstream in Fedora == BIG +
* Package all the pieces.
* Train the people
* Migrate all the EOL guides/docs into it.
* Tagging/categorization of documents by Lang, Release, Format (,
subject matter?)
* Eight modules remaining to be packaged (no review BZs yet)
* Pervasive bundling of libraries
* Need to package some PHP libraries to make this happen
* SHA-256 library
* Puppetization of configs has started, but is incomplete
* Infrastructure is blocking on modules/packaging
* Zikula will help with infrastructure testing/tuning
Need guide for wiki and DocBook markup
* Clean up Help:Editing
* Move many Docs wiki pages to Archive: and start over!
* Create a getting "started guide" that tells you the what and how and
provide links to short howtos
* Two docs:
* Quick Start Guide on the wiki
* Documentation Guide in formal repo
Release Notes Issues
* We need a more rigorous freeze on wiki release note beats
* RN documents are not all in one place (about-fedora, readme's, etc.)
* Two documents... one for "normal users" and one for "advanced users".
* Normal users = front-end features -- Created by Mktg & Docs
* Links to the RN section (Advanced users) for those that want to know
more.
* Advanced users = back-end features + front-end features -- Created by
Docs
* Schedule
* Marketing completion of talking points/tour
* Tour should provide a link to upgrade page * Docs editing content
* Has to be ported to the appropriate container (Zikula, website...,
tupperware(TM), ziplock(R) bag?)
* Screen shots have to be done
* Translated
We don't know anything about visit statistics for docs.fp.o
Release notes are ill-defined
One target for bugs, consistent pointers across Publican, wiki, docs
website, etc.
Need to understand release schedule and what is implied by freezes,
trans, etc
* Note each line item/milestone on the wiki and explain what are the
action items to complete it
Getting RPMs pushed - going through f13 takes as much time as building
the rpm
Need to have process and deal with old/orphaned/rogue wiki documents
* (https://fedoraproject.org/wiki/User:Sparks/BZ_and_Guide_Table)
Improve understanding and communication with L10n
No good documentation on moving things from wiki to DocBook/Publican
stores
14 years, 10 months
selinux user guide
by Domingo Becker
Would you please publish a draft of the SELinux User Guide in Spanish ?
I think warrink would also want one in Dutch.
kind regards
Domingo Becker (es)
14 years, 10 months
Ideas for Fedora Planet site
by Valent Turkovic
I have a few ideas and suggestions on how to improve Fedora Planet
site, please tell me what do you think about them.
1. Search
- currently there isn't any search on Fedora Planet. Fedora bloggers
have great posts and are a really valuable resource, searching through
their greats posts with tips&tricks would be a real benefit to
everybody.
2. Previous posts
- sometimes I'm way from the PC for days, and some times I have extra
free time, it would be nice to be able to catch up with previous
Fedora Planet posts by looking at previous post. Currently there is
only one page of posts that is really rapidly updated, and if you miss
some great post it is lost in the internet tubes forever ;)
3. Digg style voting on best posts
- this is just an idea, but what do you think of adding a "Digg" style
button or "thumbs up" and "thumbs down" button on planet posts, sure
the posts should be rotated to show the newest ones, but somewhere on
the edges could be top 10 posts of the week or something similar...
Cheers!
--
http://kernelreloaded.blog385.com/
linux, blog, anime, spirituality, windsurf, wireless
registered as user #367004 with the Linux Counter, http://counter.li.org.
ICQ: 2125241, Skype: valent.turkovic
14 years, 10 months
Shared open-source style guide
by Phil Bull
Hi guys,
An idea was floated at WOSCON [1] to create a shared open-source style
guide for documentation writers [2]. This would be a "vanilla" style
guide, which projects could modify and extend if necessary. Advantages
include:
* No need for projects to write their own style guide from scratch
* Reasonable uniformity in style and terminology across projects
* Independence from external style guides, which may cost money to
access
* Projects which don't have a style guide get one for free
We have people from GNOME, Ubuntu, Xfce and Drupal discussing this right
now, and we'd love for other projects to let us know if they are
interested in the concept, and to give us their feedback if they are.
PLEASE get in touch via the WOS website [1] rather than replying
directly to this message, since this is getting crossposted to a lot of
doc lists.
Thanks,
Phil
[1] - http://writingopensource.com
[2] - http://writingopensource.com/node/14
--
Phil Bull
https://launchpad.net/people/philbull
14 years, 10 months
