So what do we want to see by the Fedora 9 release? Here's a list I'd like to see:
1) Remove all of our FC6 boxes (either by upgrade or move to RHEL)
2) Separate Test infrastructure - Right now we have people using test boxes that connect to production databases and information. This needs to stop. (I understand luke and dgilmore have had some discussions about this already)
3) Finalized backup solution and koji share (we are out of room for both backups and koji)
4) Further hardening of our systems. Implementing puppet has done a lot of good but there's more that needs to be done. This includes making sure all boxes come up as expected on reboot. Ensuring we have some sort of management system in place for our xen guests that can run on multiple hosts.
5) Further system replication - Anything related to distribution or the primary website (including docs, and mirrors) should be able to run while PHX is down. Its already pretty close to that.
6) New torrent server
7) New collaboration servers
8) Move hosted out of PHX and on to new server beach systems. This will likely include creating a new "hosted" group.
9) FAS2 - This will be a big project and is one I'm hoping to accomplish prior to F9 test1. Ricky has done some great work with it, we'll see what it takes to finish it off.
10) Better systems integration - Many of our systems now support different rss feeds and such. We can more easily integrate these systems together with groups, koji, pkgdb, FAS2, bodhi, you name it.
11) Fewer new systems - This goes along with all the stuff we did to get F7 and F8 ready. For F9 I'd like to see the team take a bit more time taking each project to focus on that last 10%. Its always harder then it seems and with the FAS switchover I feel its important.
:: whew ::
I'd like to spend time at next week's meeting (I'll likely not be at this weeks meeting) talking about what is important for the individuals in the rest of the team to get done. After that meeting we'll have a F9 milestone in place and populated with tickets.
What else do you guys want to do in the next 6 months?
Whats important to you not only as a Fedora Infrastructure member, but as a contributor?
-Mike
On Wed, 2007-11-21 at 15:03 -0600, Mike McGrath wrote:
- Move hosted out of PHX and on to new server beach systems. This will
likely include creating a new "hosted" group.
Somewhat related is that it'd be good to build up new machines per-SCM as opposed to the current fun with chroots on cvs.fedoraproject.org. I should get back to the work I started for replacing git.fedoraproject.org as a first one to tackle
Jeremy
Jeremy Katz wrote:
On Wed, 2007-11-21 at 15:03 -0600, Mike McGrath wrote:
- Move hosted out of PHX and on to new server beach systems. This will
likely include creating a new "hosted" group.
Somewhat related is that it'd be good to build up new machines per-SCM as opposed to the current fun with chroots on cvs.fedoraproject.org. I should get back to the work I started for replacing git.fedoraproject.org as a first one to tackle
That's something worth talking about. As it is we run hg, mercurial and git in the same chroot (we're not looking to go with another chroot) but I think we could just run it on the machine, there's a script + ssh_key setup in those chroots for security. I think they'd be just as affective out of a chroot on the hosted boxes. I also wouldn't mind moving the locations from:
git://git.fedoraproject.org/git/hosted/fedora-infrastructure.git/ to git://git.fedoraproject.org/fedora-infrastructure.git/
On Wed, 2007-11-21 at 15:35 -0600, Mike McGrath wrote:
Jeremy Katz wrote:
On Wed, 2007-11-21 at 15:03 -0600, Mike McGrath wrote:
- Move hosted out of PHX and on to new server beach systems. This will
likely include creating a new "hosted" group.
Somewhat related is that it'd be good to build up new machines per-SCM as opposed to the current fun with chroots on cvs.fedoraproject.org. I should get back to the work I started for replacing git.fedoraproject.org as a first one to tackle
That's something worth talking about. As it is we run hg, mercurial and git in the same chroot (we're not looking to go with another chroot) but I think we could just run it on the machine, there's a script + ssh_key setup in those chroots for security.
They could all share the same machine, it just makes the apache config more painful. Running them on separate machines[1] also gives us nice isolation and lets us upgrade each on its own as makes sense for it. It would also make it so that we could do things like enabling the cvspserver frontend to git. I'm not really sold much one way or the other, though.
I don't think that we want to run it on the same machine as the hosted frontend, though.
I think they'd be just as affective out of a chroot on the hosted boxes. I also wouldn't mind moving the locations from:
git://git.fedoraproject.org/git/hosted/fedora-infrastructure.git/ to git://git.fedoraproject.org/fedora-infrastructure.git/
You should be able to at least do 'git clone git://git.fedoraproject.org/hosted/fedora-infrastructure.git' now. But if you're pulling over ssh, the additional /git is necessary due to the fact that you're ssh'ing and looking at the paths on the filesystem
Jeremy
[1] Separate virtual machines
You should be able to at least do 'git clone git://git.fedoraproject.org/hosted/fedora-infrastructure.git' now. But if you're pulling over ssh, the additional /git is necessary due to the fact that you're ssh'ing and looking at the paths on the filesystem
Why not add an additional symlink from the root dir to make the path consistent?
regards,
Florian La Roche
Florian La Roche wrote:
You should be able to at least do 'git clone git://git.fedoraproject.org/hosted/fedora-infrastructure.git' now. But if you're pulling over ssh, the additional /git is necessary due to the fact that you're ssh'ing and looking at the paths on the filesystem
Why not add an additional symlink from the root dir to make the path consistent?
Could be done with separate machines but can't be done now due to all the hosted repositories being on the same machine.
ie, we have: /git/hosted /bzr/hosted /hg/hosted /svn/hosted
Which of these should a /hosted symlink point to?
-Toshio
Toshio Kuratomi wrote:
Florian La Roche wrote:
You should be able to at least do 'git clone git://git.fedoraproject.org/hosted/fedora-infrastructure.git' now. But if you're pulling over ssh, the additional /git is necessary due to the fact that you're ssh'ing and looking at the paths on the filesystem
Why not add an additional symlink from the root dir to make the path consistent?
Could be done with separate machines but can't be done now due to all the hosted repositories being on the same machine.
ie, we have: /git/hosted /bzr/hosted /hg/hosted /svn/hosted
Which of these should a /hosted symlink point to?
I think he's talking about fedora-infrastructure.git -> /git/hosted/fedora-infrastructure
This does raise a good point though, surely there's a git approved way of dealing with this.
-Mike
On Wed, 2007-11-21 at 16:24 -0600, Mike McGrath wrote:
Toshio Kuratomi wrote:
Florian La Roche wrote:
You should be able to at least do 'git clone git://git.fedoraproject.org/hosted/fedora-infrastructure.git' now. But if you're pulling over ssh, the additional /git is necessary due to the fact that you're ssh'ing and looking at the paths on the filesystem
Why not add an additional symlink from the root dir to make the path consistent?
Could be done with separate machines but can't be done now due to all the hosted repositories being on the same machine.
ie, we have: /git/hosted /bzr/hosted /hg/hosted /svn/hosted
Which of these should a /hosted symlink point to?
I think he's talking about fedora-infrastructure.git -> /git/hosted/fedora-infrastructure
This does raise a good point though, surely there's a git approved way of dealing with this.
The normal way is that you just have the /git or whatnot. The addition of hosted/ in there is purely our own doing :)
Jeremy
On Wed, 21 Nov 2007 18:46:00 -0500 Jeremy Katz katzj@redhat.com wrote:
The normal way is that you just have the /git or whatnot. The addition of hosted/ in there is purely our own doing :)
It was our doing to separate out the non hosted stuff from the hosted stuff, as I had no idea once we split things off if the hosted stuff would live out on it's own, vs the other git stuff.
On Wednesday 21 November 2007, Mike McGrath wrote:
- FAS2 - This will be a big project and is one I'm hoping to accomplish
prior to F9 test1. Ricky has done some great work with it, we'll see what it takes to finish it off.
this will be good to see it finalised
- Better systems integration - Many of our systems now support
different rss feeds and such. We can more easily integrate these systems together with groups, koji, pkgdb, FAS2, bodhi, you name it.
use ssl auth as an option across all web based apps.
- Fewer new systems - This goes along with all the stuff we did to get
F7 and F8 ready. For F9 I'd like to see the team take a bit more time taking each project to focus on that last 10%. Its always harder then it seems and with the FAS switchover I feel its important.
:: whew ::
I'd like to spend time at next week's meeting (I'll likely not be at this weeks meeting) talking about what is important for the individuals in the rest of the team to get done. After that meeting we'll have a F9 milestone in place and populated with tickets.
What else do you guys want to do in the next 6 months?
better integration with downstream from us projects. like OLPC not sure exactly how and what yet.
get a concrete plan in place to evaluate the use of cvs for package maintenance. and evaluate if we move to something else at all, with a plan to have it implemented for F10 if the decision is to move away from cvs
Whats important to you not only as a Fedora Infrastructure member, but as a contributor?
Mike McGrath wrote:
So what do we want to see by the Fedora 9 release? Here's a list I'd like to see:
- Remove all of our FC6 boxes (either by upgrade or move to RHEL)
For the TurboGears apps, this should be pretty easy to do (FC6 and RHEL5 are very close).
- Separate Test infrastructure - Right now we have people using test
boxes that connect to production databases and information. This needs to stop. (I understand luke and dgilmore have had some discussions about this already)
We're going to need to get FAS2 up and running and expose information either directly via LDAP or via JSON-RPC for this to work. That's definitely a good thing; I just want to mention that we have to get that working first.
- Move hosted out of PHX and on to new server beach systems. This will
likely include creating a new "hosted" group.
Are we going to consider anything in the git/bzr/hg/svn repositories to be hosted for this purpose? A few things in there pre-date tthe existence of hosted.
- FAS2 - This will be a big project and is one I'm hoping to accomplish
prior to F9 test1. Ricky has done some great work with it, we'll see what it takes to finish it off.
Thanks Ricky! This is an important piece as there's potentially a lot of porting that needs to be done once it is finished.
-Toshio
Toshio Kuratomi wrote:
- Move hosted out of PHX and on to new server beach systems. This
will likely include creating a new "hosted" group.
Are we going to consider anything in the git/bzr/hg/svn repositories to be hosted for this purpose? A few things in there pre-date tthe existence of hosted.
Not sure, I'd like to build a clearly defined list of what we provide as part of "hosted". We can grandfather in whats there I suppose if we can't come to an agreement. What projects specifically are you wondering about?
-Mike
Mike McGrath wrote:
Toshio Kuratomi wrote:
- Move hosted out of PHX and on to new server beach systems. This
will likely include creating a new "hosted" group.
Are we going to consider anything in the git/bzr/hg/svn repositories to be hosted for this purpose? A few things in there pre-date tthe existence of hosted.
Not sure, I'd like to build a clearly defined list of what we provide as part of "hosted". We can grandfather in whats there I suppose if we can't come to an agreement. What projects specifically are you wondering about?
I wonder mostly because I want to figure out if we'll be hosting one git/hg repo after the hosted split-off or two. The things in git and hg but not in a hosted repo are:
git: gitreleng: releng gitkernel: dhoward.git/ext3-devel linville/netmerge-2.6.git roland.git steved.git gitzaitcev: zaitcev/linux-2.6-volk.git gitpilgrim: pilgrim gitthemes: bluecurve-classic-metacity-theme fedorabubbles-gdm-theme bluecurve-gdm-theme fedoradna-gdm-theme bluecurve-gnome-theme fedoradna-kdm-theme bluecurve-gtk-themes fedoraflyinghigh-gdm-theme bluecurve-icon-theme fedoraflyinghigh-kdm-theme bluecurve-kde-theme fedora-gnome-theme bluecurve-kdm-theme fedora-icon-theme bluecurve-kwin-theme fedorainfinity-gdm-theme bluecurve-metacity-theme fedorainfinity-screensaver-theme bluecurve-qt-engine fedora-screensaver-theme bluecurve-xmms-skin
hg: hgfedora: livecd-devel hgolpc: olpc-artwork--devel qemu-admin--devel sugar--devel system-config-qemu--devel qemu-manager--devel capture-pixmap--devel image--devel mem-monitor--devel qemu-network--devel sdk--devel
-Toshio
On Wed, 2007-11-21 at 14:59 -0800, Toshio Kuratomi wrote:
Mike McGrath wrote:
Toshio Kuratomi wrote:
- Move hosted out of PHX and on to new server beach systems. This
will likely include creating a new "hosted" group.
Are we going to consider anything in the git/bzr/hg/svn repositories to be hosted for this purpose? A few things in there pre-date tthe existence of hosted.
Not sure, I'd like to build a clearly defined list of what we provide as part of "hosted". We can grandfather in whats there I suppose if we can't come to an agreement. What projects specifically are you wondering about?
I wonder mostly because I want to figure out if we'll be hosting one git/hg repo after the hosted split-off or two. The things in git and hg but not in a hosted repo are:
I'd really prefer to only have to host one machine running services per SCM if at all possible. And there's no reason it shouldn't be.
Jeremy
infrastructure@lists.fedoraproject.org
-
Dennis Gilmore -
Florian La Roche -
Jeremy Katz -
Jesse Keating -
Mike McGrath -
Toshio Kuratomi