We need to come up with a solution for hosting repos that aren't
upstream. We have hosted (which I assume is for upstream projects
only). And we have fedorapeople.
Problem: Branches are cheap, creating groups, storage, etc for them is
not (especially if its just for one or two people)
Is hosted our solution for this?
After an initial trial yesterday we would like to use asterisk or
callweaver today for the meeting. What does this mean? Well....
Voices. Part of this is to get us ready for the virtual fudcon coming
up. Those wishing to participate must have at least a headset, a
microphone is also preferable. Those without a mic can also just join
and mute themselves and listen. We'll be recording the meeting so
interested parties can play it back later.
This just got setup so we're still working out the kinks, we may bale at
any moment and just do the standard #fedora-meeting (We will be in
#fedora-meeting for people to ask questions, especially for those
without mics but who are listening in)
If you are interested please go to #fedora-admin prior to the meeting
today and get setup so that we can make sure you aren't causing tons of
extra noise, feedback, etc.
kde - twinkle
gnome - ekiga
other - linphone
Any sip client should work though. Let us know if you have any questions.
I am Anand Capur and I have been on this list for quite a while, but never
really introduced my self. I am interested in joining the sysadmin-noc
group. I have put in my request for the sysadmin group. I am experinced with
apache, xen, fedora (duh...), load balancing, server monitoring, and fixing
general problems. As well as some PHP and HTML. I am also interested in
helping with the Infrastructure SOP. I have had 5+ years of experience with
all of this, as well as being a Fedora Ambassador. I currently live in Ohio,
and in the Eastern Time Zone (EST). I'm interested in being on the team,
because I feel I could help out and give back to fedora.
FYI, for the last week or so I've been mirroring-to-git a couple of
sourceware-hosted CVS repositories:
Why? In case it's not obvious (beyond the dVCS distributed vs.
non-distributed argument): you can do a lot of things so much more
efficiently using Git than with CVS, that this effort has been well worth
my time, if only in removing frustration with CVS :-) For example,
now I no longer have to endure cvs-diff's network-related delays.
Same for annotating and searching logs or old deltas.
Since a few people on those two projects said they too
would appreciate a public git mirror, I went ahead and
published my repository and polished the script to keep
things synchronized via cron.
For those using a CVS repository, getting to know their code through
a read-only Git mirror is a good introduction to using a better version
control system. Providing a service like this to arbitrary projects might
have few down sides (increase disk use, true, but no need to backup, since
the mirror is effectively read-only; also, note that in my experience,
the Git repository is usually only about 20-25% the size of the CVS
repository). But I think there are more pros than cons. There might
even be a net decrease in bandwidth requirements when providing a git
mirror of a fedora-hosted CVS repository, since the git protocol is so
much more efficient.
The bits of infrastructure I use to mirror those two repositories (as
well as emacs and gnulib at savannah) are general enough that it is now
trivial for me to mirror more on git.et.redhat.com. However, providing
a fedora-sponsored service like this would be better for several reasons:
- better (and "official") support
- it's best to keep the mirrored-to Git repo as near as possible to the
CVS repository (efficiency and security), so for CVS-based Fedora-
hosted projects, it's best if any Git mirror is also Fedora-hosted.
- more visibility, good PR for Fedora
- help introduce people to distributed version control
Feedback welcome (feel free to tell me that I'm crazy and you hate Git --
you won't be the first :-)
Publictest4 has been renamed to publictest5, publictest5 has been
renamed to publictest4. This should have the largest impact on glezos
and the translations stuff (sorry for the short notice)
let me know if anything is borked.
This version has a fix to allow the tg FAS provider to work on the new
TG built for F7 and a BaseClient class that can form the basis of a
TurboGears client (CLI or GUI).
For those who have been looking at the snapshots of the client code,
this version has several bugfixes and changes that should make it work
better including the ability to reauthenticate id the session cookie has
On Tue, 2007-07-31 at 19:19 +0530, Ankitkumar Rameshchandra Patel wrote:
> Does this status page gets updated at some interval (Hourly, daily,
> weekly) ? OR
> It's just static, taken from releases (head, f-7, f-6, etc) snapshots.?
Can someone from the infrastructure team answer Ankit's question?