wikiold frozen, work on wikinew begins, early-import happening right now
by Karsten Wade
http://fedoraproject.org/wiki ==> /wikiold on 27 May == 'wikiold' == MoinMoin
http://fedoraproject.org/wikinew ==> /wiki on 27 May == 'wikinew' == MediaWiki
The content from MoinMoin (wikiold) is being early-imported to MediaWiki
(wikinew). That is happening right now and should be ready in N hours.
N == when it's ready. I'll send another announcement at that time.
This content is going to be imported *again* on 27 May, to capture any
changes made to wikiold. The details of that are being worked on, but
the goal is to have content fidelity. Your help is needed in
maintaining fidelity.
Here is what you should do:
1. Don't edit either wiki until you hear the early-import is done
2. If your content can wait until 27 May (Tuesday) for the public to
view it at fp.org/wiki, then do the work in wikinew and it goes live
with the final-import on Tuesday. This is a chance to fix pages in
wikinew that are not going to stay steady.
** DO NOT edit the page in both wikiold and wikinew. **
** Pick one and stick with it through the migration. **
3. If your content cannot wait until Tuesday and *must* be visible to
the public at fp.org/wiki between now and Tuesday, do the work in
wikiold. On Tuesday, it is final-imported into wikinew. You then want
to check the content post-import as you would any other pages.
Questions? #fedora-docs on irc.freenode.net is where the Wiki Gardeners
hang out. Time to start pruning and trimming and re-planting.
- Karsten, Wiki Gardener
--
Karsten Wade, Sr. Developer Community Mgr.
Dev Fu : http://developer.redhatmagazine.com
Fedora : http://quaid.fedorapeople.org
gpg key : AD0E0C41
15 years, 4 months
Fedora 10 Feature Process
by John Poelstra
Hello Fedora 10,
Fedora 9 completed the second iteration of the Fedora Feature process.
It seemed to run a little smoother than things did with Fedora 8. The
gist of the feedback I heard was that the marketing and documentation
groups loved the feature pages and information they provided while some
developers thought creating and updating the feature pages was too much
work and other developers found it to be no problem at all.
So before we start the next round of Feature Acceptance process by FESCo
I wanted to open a dialogue here that could carry over to the FESCo
meeting on 2008-05-29 whereby FESCo could vote to amend the existing
policy based on the constructive feedback received.
I have created a wiki page to track this process here:
http://fedoraproject.org/wiki/Features/F10PolicyReview
Key proposals so far include:
* Tracker bugs for each feature
* Better test plan information
* No incomplete feature form sections
Admittedly one of the next things we will need is an application to
track this process so we can get away from using the wiki. I'm open to
any volunteers who would like to help write such an application or could
propose an existing open source tool that would handle the current
information we request and track for new features.
Thanks,
John
15 years, 4 months
Important information regarding 'rel-eng@fedoraproject.org' emails
by Jesse Keating
In an effort to be even more open, responsive, and reliable, Fedora
Release Engineering has created an email to Trac gateway. Email
requests for release engineering tasks sent to rel-eng(a)fedoraproject.org
will now be turned into tickets filed in the rel-eng Trac space. This
will allow for better visibility in the tasks needing to be done, a more
public record of task discussions, and better record keeping to prevent
things from falling through the email cracks.
Any person that mails this address should receive an automated response
from the Trac system regarding their ticket with a URL that they can
visit to track the ticket progress, make updates, etc...
Along with using email to submit tickets, email can also be used to
update tickets. So long as you are replying to the mail you get from
Trac about said ticket, and you keep the subject line intact, your email
response will update the ticket.
Please let us know either via email or through the #fedora-admin IRC
channel if you experience any difficulties with this new setup.
--
Jesse Keating
Fedora -- Freedom² is a feature!
15 years, 4 months
Red Hat Bugzilla 3.2 Upgrade Beta 1
by John Poelstra
Hi,
I'm passing the following information on for the team that maintains the
Bugzilla instance Fedora runs in. It provides a peak into the upcoming
Bugzilla update and an opportunity to evaluate it in a test instance.
Check it out.
John
~~~~~~~~~~~~~~~~
Greetings,
The Red Hat Bugzilla team is happy to announce the first beta release
of the next version of Red Hat Bugzilla. The next version will be based
on the upcoming upstream 3.2 code base soon to be released.
https://partner-bugzilla.redhat.com
Along the way to the final release, we will be deploying several
beta releases that will be used for obtaining user feedback
and for finding bugs in our code changes. Red Hat has made substantial
customizations to our current 2.18 based Bugzilla system that have been
ported to the new release. Several of which we are working on having
them accepted
by the upstream community which will help in future bug fixes and
lower maintenance. We are also hoping to use the upgrade process as a
stepping stone to becoming more active in the future road map of Bugzilla
itself by providing help with bug fixes and enhancements and taking
part in future discussions.
Areas of focus for beta1:
Ajax optimizations:
Speedup one component/version/milestone population on the advanced query
screen due
to large volume of data for some products such as RHEL and Fedora.
Speedup of the show_bug.cgi page by reducing amount of HTML needed to
download
by not loading all components unless you want to change the value.
Needinfo actor support:
Using the flags functionality, we are able to specify whom additional
information
is being required of for a report. In the current 2.18 release a
combination of
a bug status called NEEDINFO and needinfo flag were used. In 3.2 only a
needinfo flag
is being used and the bug status will be removed.
Guided bug entry:
Modified stock guided bug entry page used to help non experts report bugs
with proper information.
UI enhancements:
Upstream Bugzilla developers have done extension work on streamlining
the show_bug.cgi page. The page should have a cleaner less cluttered
feel as well as show only editable fields for the values the user is
allowed
to change only. One of the more noticeable things is the removal of the
"Bug Status Change" area and moving it up to the basic bug information
area.
External bug references:
Ability to add links to outside bug trackers.
XMLRPC API:
The Red Hat Bugzilla system was one of the first Bugzilla installations
to utilize
XMLRPC extensively. Upstream as of 3.0 has a new framework for providing
Web Services
to clients to manipulate Bugzilla data. We have worked to help the
upstream to
add features to this framework to support similar functionality to what
we have
had in operation for some time. Some of the core functions are there
such as Bug.get(),
Bug.create(), Bug.search() and Bug.update() which can be used to do most
things needed.
Some of the operations available in our version are not yet available so
we are also
providing most of the old 2.18 API so that your applications and scripts
should continue
to work properly for the time being. Please try your scripts against the
test Bugzilla
system to make sure they are working properly. Let us know if there are
any errors
such as data not being returned in the proper format, certain methods
missing,
or bugs in general.
New methods available (Note: these are subject to change before final
release):
1. Bug.get() - Can be used to get all attributes of one or more bug
reports.
2. Bug.create() - Can create a new bug report in the system.
3. Bug.update() - Can update most attributes of one or more current
bug reports.
4. Bug.search() - Search the database for bugs matching search
criteria similar to advanced search UI.
Also supports quicksearch keywords and reloading of saved searches
saved in the Bugzilla UI.
5. Bug.get_activity() - Retrieve full history of one or more bug reports.
6. Bug.add_comment() - Can add a comment to a current bug report.
7. User.login() - Can take a username and password as parameters that
will return cookies that can be
used for all subsequent XMLRPC method calls. (Note: required to use
the new methods such as Bug.*)
8. User.create() - Create a new user if you have proper permissions.
9. User.get() - Get information about one or more current users if you
have proper permissions.
10. User.update() - Allows updating of email, real name, disabled, etc
for one or more current users.
11. Product.get_products() - Get information about one or more
products in Bugzilla.
12. Component.get() - Get information about one or more Bugzilla
components.
13. Component.create() - Create a new Bugzilla component for a
specific product.
14. Component.update() - Updated the attributes of one or more
Bugzilla components.
Old methods ported to 3.2 (for backwards compatibility):
1. bugzilla.runQuery()
2. bugzilla.getBug()
3. bugzilla.addIT()
4. bugzilla.getBugActivity()
5. bugzilla.nameToId()
6. bugzilla.login()
7. bugzilla.getBugSimple()
8. bugzilla.editComponent()
9. bugzilla.idToName()
10. bugzilla.getBugModified()
11. bugzilla.addComment()
12. bugzilla.updateFlags()
13. bugzilla.closeBug()
14. bugzilla.changeStatus()
15. bugzilla.updateCC()
16. bugzilla.getProdInfo()
17. bugzilla.createBug()
18. bugzilla.changeAssignment()
19. bugzilla.updateDepends()
20. bugzilla.getProdCompDetails()
21. bugzilla.addComponent()
22. bugzilla.updateMilestone()
23. bugzilla.getCompInfo()
24. bugzilla.getProductDetails()
25. bugzilla.getProductDetails()
26. bugzilla.userInfo()
27. bugzilla.addUser()
28. bugzilla.disableAccount()
The newer API is likely to change before the next release of upstream
Bugzilla
so we will be maintaining the older API during the time from 3.2 leading
up to
the next release. We do encourage people to try out the new API also so
as to
be ready for the eventual transition.
There are numerous other changes behind the scenes that we haven't
listed. The goal
is to make sure that functionality that people have come to expect in
2.18 is
possible in the new system.
There are also numerous new features/fixes that are part of the upcoming
3.2
release provided by the upstream Bugzilla community. For more detailed
information
on what has changed since the last release, check out the
[https://partner-bugzilla.redhat.com/page.cgi?id=release-notes.html
Release Notes].
The database is a recent snapshot of the live database so should be useful
for testing to make sure the information is displayed properly and
changeable.
Also with a full snapshot it is possible to test for any performance
related
issues. Email has been disabled so that unnecessary spam is not sent
out. So
feel free to make changes to bugs to verify proper working order.
We are asking for everyone to get involved as much as possible with
testing and feedback
on the beta releases to help us make this the most robust and stable
release possible.
We have done extensive work at laying out what we feel the requirements
are to maintain feature
parity with our current system as well as compiled a list of feature
enhancements
that people would like to see in the next release. Our goal is to deliver a
working bugzilla with the bare essential requirements similar to what is
currently being used
in our current 2.18 system. After that we will begin work on
enhancements as time and resources
permit. To view the final release requirements list please refer to our
[https://bugzilla.redhat.com/show_bug.cgi?id=406071 Bugzilla 3 Tracker].
Please file any enhancement requests or bug reports in our current
Bugzilla system
at [https://bugzilla.redhat.com bugzilla.redhat.com]. File them under
the Bugzilla
product and relevant component with the version 3.2. With everyones help
we can make
this a great release.
Thanks
The Red Hat Bugzilla Team
15 years, 4 months
OpenSSH Key Warning
by admin＠fedoraproject.org
Fedora Contributors,
Recently, there has been a lot of news about the vulnerability
impacting the Debian and Debian-derived OpenSSL Random Number
Generator[1]. While Fedora's OpenSSL did not contain this
vulnerability, we are potentially impacted by it. If you generated
your key on an affected Debian-based[2] system then you need to
regenerate and replace your SSH key(s) on all systems you access
with those keys. Instructions for how to do that for Fedora
are here. [3]
As a general rule, if you do not know when/where you created your
key or whether you have ever authenticated to a Debian-based
system then replace any and all ssh keys you use. This is a
good plan for all ssh keys, independent of whether or not they
are used in the Fedora infrastructure.
We would appreciate your prompt attention to this matter.
Sincerely,
Fedora Infrastructure Team
[1]
http://lists.debian.org/debian-security-announce/2008/msg00152.html
[2] Debian, Ubuntu, Knoppix, etc.
[3] http://fedoraproject.org/wiki/Infrastructure/ReplacingSSHKey
15 years, 4 months
Tracker bugs created for Fedora 10 milestones and Fedora 11
by Jon Stanley
In line with the triage release SOP, I've just created blocker bugs
for Fedora 10 Alpha, Beta, and Preview releases. Trackers are also
created for F11 blocker and target bugs. They are aliased in the
normal way:
- F10Alpha
- F10Beta
- F10PR
- F11Blocker
- F11Target
Feel free to start planning in advance! :)
--
Jon Stanley
Fedora Bug Wrangler
jstanley(a)fedoraproject.org
15 years, 4 months
The Prophecy of the 9 comes true (Fedora 9 walks the earth!)
by Jesse Keating
An ancient text prophesised this day would come, detailing the fate of
all who are willing to accept what is offered to them:
http://docs.fedoraproject.org/release-notes/f9/index.html
And that day has come: the Computer said "I will convert these
unbelievers, and now that I have Sulphur it will be easy." At that,
the heavens opened and burning Sulphur descended upon all the world,
taking on many different forms.
First to hit were the live USB keys. The heathens cried out for mercy,
but were powerless to resist. The sticks were damn persistent and
non-destructively formatted - non-destructively! They showed up
everywhere, casting out demons from computers infected by the dark one
of the interwebs and rescuing lost data from the influence of the evil
crackers.
Then, when they thought it couldn't get any worse, the whole world was
cast into shadow. Lit only by the dim light from their computer
screens, they discovered a mysterious message scrolling across: "K K K
K K K K K 4 4 4 4 4 4". The screens flickered, and the light flooded
out so that the shadow was lifted. After their eyes had adjusted they
saw something so beautiful, teeming with so much potential that they
began to break down. KDE 4 was on their desktops!
The descent gathered pace; next to hit the ground was FreeIPA. At
first this puzzled what remained of the heathens, but then they
realized...they realized that it was going to make system
administrators lives a lot easier! A web interface and command line
tools, interacting with Windows domains and Active Directories? It was
all getting too much for them. Conversions were happening faster and
faster, only aided by mobile broadband, static IP addresses, and much
much more in NetworkManager.
Now, only a few doubters remained and what pushed them over the edge?
The community, stupid! Tirelessly working to push out great code,
great documentation and great artwork, inviting everyone to join where
ever they were in the name of freedom.
http://join.fedoraproject.org
And the Computer, seeing that his work was accomplished and it was
good, decided to rest. Pointing his browser at the Fedora mirrors, he
switched off his monitor and waited for his Sulphur to return to him
through the internet tubes, ready to enjoy another great release from
the Fedora Project.
http://get.fedoraproject.org
http://fedoraproject.org/wiki/Releases/9/ReleaseSummary
(this message brought to you by the Fedora Documentation Team
http://docs.fedoraproject.org/)
--
Jesse Keating
Fedora -- Freedom² is a feature!
15 years, 4 months
