[Fedora-infrastructure-list] Quick project for doc's
by Mike McGrath
Throwing this out there for anyone interested. Karsten (quaid) has
requested a script that will compare the packages between two
releases. Below is a quick IRC chat we had. I've been busy with
other stuff so I won't be able to get to it right away. The idea of
coming to us is maintainability. Whatever we end up with will end up
in CVS and maintained by us so anyone out there that's good with
Perl/Python/XML sign up. Don't take it if you don't have time to do
it, I already did that :) Whoever wants it go ahead and reply to the
list so everyone knows, and add it to:
http://fedoraproject.org/wiki/Infrastructure/Schedule
If you need any help let me know and I'll point you in the right direction.
-Mike
======== From #fedora-docs ===========
[15:16:54] * quaid gets an example
[15:17:36] <quaid>
http://fedora.redhat.com/docs/release-notes/fc5/#sn-PackageChanges
[15:18:06] <quaid> and someone did help with that list, which I
just put into a <screen> block
[15:19:30] <quaid> so, you can see a bit of the package info in
there, and the designation of if it is coming in or out.
[15:20:11] <quaid> naturally, it would be cool for it to say what
happened to a package leaving, such as going to Extra, but that
doesn't seem doable
... that info isn't stored anywhere to extract.
[15:20:24] <quaid> so, here is the need, in cascading order:
[15:20:29] <mmcgrath> k
[15:20:31] <quaid> 1. treediff -> a nice list
[15:20:39] <quaid> 2. nice list -> XML list
[15:21:06] <quaid> 3. a nice script that can be run somewhere to
let a clueless editor do this easily
[15:21:10] <quaid> </>
[15:21:49] <quaid> we want to put in the set for each test, etc.,
so it shows the package changes incrementally in that way.
[15:23:25] <mmcgrath> I got'cha.
[15:23:45] <mmcgrath> So what of that stuff would you like the
infrastructure team to do?
[15:26:37] <mmcgrath> quaid: I think I'm following you now, you
just really want some scripts to do all of this stuff automatically
and then stick the
results somewhere for you guys to do some final touches.
[15:27:34] <quaid> mmcgrath: right, although the results could be
a 100% valid XML document (header declaring it as e.g. a 'section'),
and we really
don't need to anything more than XInclude it.
[15:28:45] <quaid> also, a reason for turning to Infrastructure v.
cooking it up ourselves in maintainability ... we want something that
is part of
the formal process and has some support so when e.g. treediff or
something changes, the smarts are there to fix it. :)
[15:29:57] <mmcgrath> I don't think that will be too much of a
problem. We can at least have SOMETHING to you soon. you'll probably
have to get back
to me a few times about how to fine tune it
16 years, 7 months
[Fedora-infrastructure-list] Package DB TurboGears/SQLObject schema
by Toshio Kuratomi
Greetings all, Elliot in particular,
I started to parse the owners.list file in preparation for setting up
some sort of ACL system on the new VCS and decided to look into how this
is going to interact with the PackageDB. For starters, I took the
TurboGears schema that Elliot posted and added comments.
Are the comments in this file accurate? Can you explain what the
"status" fields in the *History classes represent?
-Toshio
16 years, 9 months
[Fedora-infrastructure-list] coverity code checker in Extras
by Max Spevack
The folks over at Coverity have offered to allow Fedora Extras to use
their services, and would like a yes or no. Rather than make this
decision in a vacuum, I believe that the Fedora Extras Steering Committee
has earned the right to make this decision for themselves.
If we can get a decision by the end of the week, that would be great.
What follows is my own analysis, for whatever it's worth.
PROS
+ It's good technology, and has been used in Linux projects previously
with success. Google "coverity linux" or something similar.
+ If we act on the results, it could be a great boon for the FE code
quality in general.
+ It doesn't cost us anything.
+ It forms a relationship between Coverity and Red Hat, and sets the table
for more work partnership later, if things go well.
+ Bugs are bugs, and flaws are flaws. We should be happy to know about
them, however they are found, and we should fix them.
CONS
+ It's not open source, but there is no free alternative that can do the
same thing.
+ We need to make sure it doesn't disrupt or break our build system too
much. So that will require some technical work and time from certain
folks.
My gut is that we should say that we're interested, and start hashing out
the technical details of how it will all work with them.
If we go ahead, I think that in addition to the Board, someone in FESCO
needs to "own" this and be our point person for technical questions, etc.
Thanks,
Max
--
Max Spevack
+ http://fedoraproject.org/wiki/MaxSpevack
+ gpg key -- http://spevack.org/max.asc
+ fingerprint -- CD52 5E72 369B B00D 9E9A 773E 2FDB CB46 5A17 CF21
16 years, 9 months
[Fedora-infrastructure-list] Service Cleanup
by Warren Togami
Any objections to blanket disabling of this stuff across all servers?
Warren Togami
wtogami(a)redhat.com
isdn pcmcia apmd rawdevices microcode_ctl
Utterly useless to us.
atd anacron
Do we want to keep these? I've always turned them off personally.
messagebus haldaemon cups acpid xfs
Only relevant to desktops?
xinetd
Only turn this on if we actually use anything that requires it?
arptables_jf
Have or will we ever use this?
16 years, 9 months
[Fedora-infrastructure-list] CVS outage
by Mike McGrath
The migration today went fairly well, few bumps but all infrastructure
should be back up now except for the CVS box. He's hurt, hurt bad.
The issue is with booting and because many things at the colo are
still in a transition right now we cannot access PDU's to restart it.
We will be addressing this issue first thing tomorrow morning (US
morning) when the techs are back in the data center.
Outages are never fun and we apologize for any inconvenience this has
caused but once everything is back up we will be in a better spot for
future expandability of the Fedora Project's infrastructure.
-Mike
16 years, 9 months
[Fedora-infrastructure-list] Re: Fedora Outage Notice for August 30th, 2006
by Karsten Wade
On Tue, 2006-08-29 at 18:42 -0400, Warren Togami wrote:
> Date: August 30th, 2006
> Time: 8:00AM - 8:00PM Mountain Standard Time (UTC -7)
Thanks all for your hard work here.
A request to please check the Documentation and Translation schedules
when planning outages. We have schedules that are tied to the Core
schedule, but off by appropriate times for various things:
http://fedoraproject.org/wiki/DocsProject/Schedule
I note this because we are supposed to be pushing content into CVS today
to make a Translation freeze for tomorrow. In all likelihood, we can
work unaffected by the outage. But <24 hours to plan our work around
was unexpected.
Thanks again, this is honestly not a complaint, just wanted you to be
aware of other schedules affected by outage planning.
Karsten
--
Karsten Wade, RHCE, 108 Editor ^ Fedora Documentation Project
Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject
quaid.108.redhat.com | gpg key: AD0E0C41
////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
16 years, 9 months
[Fedora-infrastructure-list] "sorry" server ip address
by Matthew Galgoci
Hello,
The "sorry" server ip address for the outage today is the following:
66.187.224.150
It currently resolves to www.redhat.com but that is ok, it is a name vhost.
Put this in your /etc/hosts file to test:
66.187.224.150 www.fedoraproject.org
We're adding a wildcard ServerAlias for *.fedoraproject.org also - that change
is in flight and will land in about 20 min.
--
Matthew Galgoci
IS Production Operations
Red Hat, Inc
919.754.3700 x44155
16 years, 9 months
Fwd: [Fedora-infrastructure-list] A cvs space for the Usability Sig
by Damien Durand
---------- Forwarded message ----------
From: Damien Durand <splinux(a)fedoraproject.org>
Date: 27 août 2006 12:18
Subject: Re: [Fedora-infrastructure-list] A cvs space for the Usability Sig
To: "Patrick W. Barnes" <nman64(a)n-man.com>
Hi,
"temporary storage" aren't the good words, I'm actually starting an
application for "Fedora Usability" called "fusability". It's like bug-buddy
but allow to produce usability repports. Yes actually I can host this on a
my web access because it's not usable.
Bugzilla allow to conserve patchs or other? I don't think that it's the best
solution but now that can be acceptable because the Usability Sigs has an
existance of 2 weeks.
The "Usability packages" is a good idea, We can produce "unofficial"
packages for testing the application massively...
I'm agree with you, cvs is not essential actually because usability is too
young but that can be good for a efficient and productive work. Send the
sources by mail etc... is not really great.
2006/8/27, Patrick W. Barnes <nman64(a)n-man.com>:
> On Saturday 26 August 2006 12:11, "Damien Durand" <
> splinux(a)fedoraproject.org>
> wrote:
> >
> > I would like to ask for a cvs space for the Usability Sig so as to host
> > temporarily some documentations, codes and patches, allowing a more
> > efficient and productive work.
> >
>
> CVS isn't for temporary storage. You need to work with other projects to
> keep
> things where they belong. Documentation should be kept in packages, with
> the
> Documentation Project, or on the wiki. Patches should be provided through
> Bugzilla to appropriate maintainers or directly to upstream. Efficiency
> is
> achieved through collaboration and management, not version control.
>
> Unless the Usability SIG starts producing stand-alone packages, and I
> don't
> see any reason that it ever should, I can't imagine why it would have any
> real need for its own CVS repository.
>
> --
> Patrick "The N-Man" Barnes
> nman64(a)n-man.com
>
> http://www.n-man.com/
>
> LinkedIn:
> http://www.linkedin.com/in/nman64
>
> Have I been helpful? Rate my assistance!
> http://rate.affero.net/nman64/
> --
>
>
>
>
16 years, 9 months
