Re: Goals for F13?
Mike McGrath (mmcgr...@redhat.com) said: What does everyone else have? 1) no frozen rawhide which requires faster composes 2) dist-git 3) A functioning message bus with services passing messages I think I know what you'd want from us on 2 and 3, can you think of anything off hand you'd need help with for 1? By faster composes are you thinking composing more often? Does that include distribution? NFR essentially requires two rawhides per day, once we branch for release. Given that we'd also be pushing updates, that's a lot of mashing and load on /mnt/koji. Possible help points for that: - using multiple releng boxes for composition - faster storage Bill ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: New deltarpm -- who do I talk to about testing?
Toshio Kuratomi (a.bad...@gmail.com) said: I have a new deltarpm package built for the rel-eng repo: http://koji.fedoraproject.org/koji/taskinfo?taskID=1721745 I can put it into the rel-eng repository to update the servers but who do I talk to about testing it? We'll also need approval to brakinfra change freeze to deploy it once it's tested. If it's in rawhide, it's already being tested to produce rawhide deltas. Bill ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: New deltarpm -- who do I talk to about testing?
Toshio Kuratomi (a.bad...@gmail.com) said: I can put it into the rel-eng repository to update the servers but who do I talk to about testing it? We'll also need approval to brakinfra change freeze to deploy it once it's tested. If it's in rawhide, it's already being tested to produce rawhide deltas. Cool. So is the deltarpm rpm in the releng repo: http://infrastructure.fedoraproject.org/releng/SRPMS/ just extraneous? No, that's used for composing updates. I know, it's weird to have different systems for different releases. Bill ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Mailing list migration procedures
Jon Stanley (jonstan...@gmail.com) said: I'd like some mailman experts (if we have any) to take a look at this procedure to migrate lists from redhat.com to lists.fp.o and let me know if there's something obviously missing from it or if there's some way that it can be improved. Feel free to make any edits you deem necessary. https://fedoraproject.org/wiki/Mailman_Infrastructure_SOP#Mailman_migration My concern is more procedural than infrastructural - I'd like to make sure we schedule the mass migration in such a way that it does not heavily disrupt development schedules; generally, this would mean doing it sometime after a release but before the alpha of the next release. Bill ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: CVS upgrade step2
Mike McGrath (mmcgr...@redhat.com) said: So I was going to finish the upgrade to cvs1 on Thursday or Friday. Both Jesse and Toshio are out of the country though and it strikes me as a bad idea to make potentially massive changes to that box without having at least one of them around as backup :) So I'm going to wait until next week. As far as I'm concerned, if you want to do it today or Friday (before EOB), that's fine with me. Bill ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: remove old video torrents
Mike McGrath (mmcgr...@redhat.com) said: I'm all for pruning, lets have a plan for it though. Anyone see any reason not to have these up there? Should we come up with some test for what does and does not get removed? I agree. Here's what I am going by: a) content that has reached the end of life. This includes: 1) pre-release content (Alpha, Beta, snapshots, ...) that have been superceeded, and are thus no longer useful for testing. 2) EOL releases that we have moved to archive.fp.o (I'm open to be swayed on this one...) b) content which has exceedingly limited seeders and downloaders, and which has little prospect of increasing those numbers, and which is 1 year old. The several-years-old videos fall into this category, with 0-1 seeder, and no significant increase in downloads in a while (by visual inspection, ~3000 downloads as far back as I can remember). Content which is still considered current (e.g. spins of non-EOL releases) get to stay. We haven't traditionally hosted spins elsewhere, such as archive.fp.o or alt.fp.o, so nuking them removes the only method by which someone could obtain them. Given we're OK on space right now, there's no good reason to remove spins even of EOL releases where the non-spins got archived. This seems reasonable to me. Anyone have issues? Seems reasonable. Should we make this generic so it applies to older alpha/beta trees on the ftp/http site as well? Bill ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: deltarpms not working since rawhide was signed
Chuck Anderson (c...@wpi.edu) said: The infrastructure should either delete and regenerate drpms after the rpm signatures have changed or they should use the code fragment from https://fedorahosted.org/koji/ticket/38#comment:3 to attach rpm signatures to deltarpms. That's *really* hard, as there's not any state to track when packages have been signed out from under the prior delta rpms. The simplest solution would be to just nuke the old ones by hand. Bill ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: deltarpms not working since rawhide was signed
Seth Vidal (skvi...@fedoraproject.org) said: That's *really* hard, as there's not any state to track when packages have been signed out from under the prior delta rpms. The simplest solution would be to just nuke the old ones by hand. when they are signed? or nuke them in createrepo? When rawhide becomes signed, nuke the old drpnms by hand in the tree we're diffing against, so they're not carried forward. If createrepo wants to do signature checking of drpms when it's creating the metadata, it can, and that would also fix this. But that's more work. Bill ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: cgit to replace gitweb?
seth vidal (skvi...@fedoraproject.org) said: In the last day I set up cgit as a replacement for gitweb. It's only in testing right now. You can see it here: http://hosted2.fedoraproject.org/cgit/ I'd like to see it replace gitweb as our web-based git repo browser. However, it will mean the urls from gitweb won't work anymore for fairly obvious reasons. cgit is substantially faster than gitweb and appears to be much lighter on resources, too. I'd like to get some feedback on the negatives/positives to swapping gitweb for cgit. I've often put direct gitweb links in bugzilla as a pointer to particular changesets for people to use/try/refer to. I'm probably not the only one that has done that. Do we have a count of hits on gitweb with referrers outside of gitweb? Bill ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Change request, F10 updates
Jesse Keating ([EMAIL PROTECTED]) said: In order to push out the first round of Fedora 10 updates, a few changes need to be made in the infrastructure. 1) add the 10 release to fedora-updates-push in puppet 2) Update bodhi with 10 mash configs Can I get a few +1s on this? +1 Bill ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: CIA integration
Mike McGrath ([EMAIL PROTECTED]) said: So I was going through some old tickets and stumbled across this: https://fedorahosted.org/fedora-infrastructure/ticket/164 I gave it a quick look over and I'm not against this integration but I'm generally apathetic about it. So I ask if anyone here is interested enough to get it into Fedora. I'm not sure if both the server and client versions are provided there but it looks like what is there is GPLv2. Thoughts? Oof, I should have done something with this a long time ago - I didn't see a huge benefit for it, so I never allocated time to it. But I should have said so in the ticket. Bill ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Removal of old projects from fedorahosted.
Mike McGrath ([EMAIL PROTECTED]) said: [1]https://fedorahosted.org/fedora-infrastructure/ticket/714 So I guess the best thing from here is to send an email to each group notifying them of what has happened and why we'd like to remove their project. tell them how to get the code off if they still want it, etc, etc. Lots of people on this list use hosted projects, what do you think? I'm leery of having a hard and fast 6-month-rule; especially for projects which aren't translated, it's possible to have a decent period without code changes. Maybe review-at-six-months? Bill ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: rawhide, /mnt/koji and /pub/fedora
Jesse Keating ([EMAIL PROTECTED]) said: So I realized something last night. We created a user masher to have the ability to write to /mnt/koji/mash/ but not any of the other koji space. This is useful to prevent too much damage from a horribly wrong rawhide compose. To make things easier in the rawhide compose configs, we decided to run the cron/scripts as the masher user. This is also good because it means things run unprivileged. However I ran into a snag. We have another user, 'ftpsync' that has write access to /pub/fedora/. Previously the rawhide script was ran as root, and thus it was no problem to su ftpsync for the rsync calls. The masher user does not possess the capability of doing this. Since the ftpsync user is only really used to sync data onto the Fedora netapp, I propose that we collapse ftpsync and masher into one user (masher). It'll require minimal puppet changes, mostly just moving some cron jobs from ftpsync over to masher. It will require UID changes, either changing masher to the ftpsync UID (which breaks our new range we just setup), or chmodding some stuff on the Fedora netapp and changing what UID has write access there. For now, I'm syncing rawhide by hand. Comments? Is changing the user that owns the files going to cause unnecessary rsync churn for mirrors? Bill ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Disk Space Issues - cvs-int/build hosts - (includes general note on Nagios Disk notifications)
Nigel Jones ([EMAIL PROTECTED]) said: Problem here, is that there are a LOT of old tarballs in that folder, which leaves me wondering if we should do a spring clean ~1 mo after release. Until we get something like correspondingsource up and running, we don't have a good mechanism for weeding out only the tarballs that correspond to builds that were not/are not shipped. Bill ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Change request
Mike McGrath ([EMAIL PROTECTED]) said: The *real* freeze has started. I'd like to build a different box for the secondary.fedoraproject.org bits. Initial space requirements were off, I'd like to move the bits to a host in PHX. This will require kicking a new host with enough storage. Possibly wiping the old /mnt/koji share (I'll wait for approval from jesse on that) Risk: low This request relates to the F9 release because secondary arch needs a place to host the ia64 bits. Can I get a +1? Assuming we're not going to run out of space once we have 2/3/4 secondary arches, +1. Bill ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Koji backups
Mike McGrath ([EMAIL PROTECTED]) said: We now have all the tapes we need to do koji backups of /mnt/koji. Can I get a +1? Backups are good. +1 Bill ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Change Request: Moving bugzilla sync scripts onto Fedora Boxes
Toshio Kuratomi ([EMAIL PROTECTED]) said: The Bugzilla sync scripts are currently running on a RHEL4 machine on Jeremy's desk. There are a few problems with them that would be hard to fix without RHEL 5. Since it would be helpful to move this out to a Fedora box anyway so anyone can modify them, I'd like to move them to the app servers. As long as there are no weird firewall/xmlrpc issues causing them to need to be 'inside', go for it. Bill ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Mailman list for triage - special requirements
Jon Stanley ([EMAIL PROTECTED]) said: John Poelstra and I were just thinking about a mailing list for watching incoming bugs. Unfortunately, I don't know that there's the right combination of checkboxes in Bugzilla to just get mail about new bugs. However, filtering based on mail header could get that - every new bugmail that Bugzilla sends has a header of X-Bugzilla-Changed-Fields: New that could be filtered on. The question is whether or not mailman is capable of filtering based on arbitrary header values. Note that this question doesn't mean we'll actually do this, we're still mulling over whether or not it's actually a good idea at all (and input on that front is welcomed too!). However, we want to know if it's technically possible or how much effort would be needed to accommodate the request. Why is this better than a RSS feed or similar? Bill ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Mailman List Policy for Fedora Hosted
Jon Stanley ([EMAIL PROTECTED]) said: freemedia is a closed list with private archives, because of the personal information to be found there. fedora-board-list is another one, and I'm sure there's more, dealing with security for example. There needs to be a method of exception to the rule. +1 for the general idea, though - there should be *good* reason to get an exception that requires approval from Someone In Charge(TM) Are we intending to move *active* lists to new hosting? Bill ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Restart TG apps for high mem-usage
Toshio Kuratomi ([EMAIL PROTECTED]) said: Here's a short script to test our TG apps run via supervisor for excessive memory usage and restart them if necessary. We could run this via cron in alternate hours on each app server. Does this seem like a good or bad idea to people? It's a good idea if it's needed, but it's a bad idea that it is needed. What's wrong with TG that it leads to this situation? Bill ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Mirror Manager Backup
seth vidal ([EMAIL PROTECTED]) said: build: koji, plague, local mirrors for building, cvs, bodhi, pkgdb distribution: mirrormanager, mirrormaster, staging, torrent primary site: fp.o, wiki, docs, start.fp.o meta services all of the above will or do require: vpn, fas[2], puppet, infrastructure-cvs, dns, mail meta services additions: backups and then mostly unrelated services: fedorapeople.org, planet.fedoraproject.org, hosted.fedoraproject.org If I was planning strategy, the priority for offsite/redundancy would be: 1) mirrormanager 2) torrent 3) start.fp.o, docs, fp.o 4) mirrormaster 5) hosted 6) wiki 7) fedorapeople/planet 8) build stuff (meta-services sprinkled in as necessary) Bill ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Fusion io solid-state storage
Ignacio Vazquez-Abrams ([EMAIL PROTECTED]) said: Just saw this, figured someone here might be interested. http://www.fusionio.com/ $30/GB. That's gonna hurt. Bill ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Off on Monday
Mike McGrath ([EMAIL PROTECTED]) said: Just letting you guys know I'll be off on Monday, going to a cubs game and generally doing everything you've seen in: Woo, our infrastructure leader, the sausage king of Chicago! Bill ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Upgrade metrics
Axel Thimm ([EMAIL PROTECTED]) said: The interesting part is to create a graph over time to answer the question whether the 13 month EOL is really paying off. And perhaps on base of that graph one could revise this decision. At the very leats it would be interesting to notice the upgrade behaviour of Fedora users. I have no idea how to do that other than marking the HTTP Agent of yum on FN accordingly, as well as the HTTP Agent in anaconda's yum (noting fresh installs vs upgrades). Worth to add this for F8? Well, you could have smolt update the release for a particular hw UUID, and track things that way. Bill ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Fedora 7 Upgrade
Toshio Kuratomi ([EMAIL PROTECTED]) said: Depends... What is the reason for those boxes to be on Fedora instead of RHEL? For the mash/bodhi box, it's because it requires yum-3.2.x and current createrepo. At the moment it's running them recompiled for FC6, and, well, I'd rather not do that long term (or do that on RHEL.) Bill ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: RFR: GIT Package VCS
Karel Zak ([EMAIL PROTECTED]) said: My wish is git rebase always after upgrade to new upstream code. The current make prep is nightmare... See Linux kernel. That's normal that people maintain their patches outside official tree(s) for pretty long time. The modern VCS is the right tool for this job. separate out our changes from what upstream has .. is definitely no problem. Well, it depends on what you're doing. DaveJ tried to move to git pulling the various things we need for our kernel - it ended up being a pretty big problem getting something sane out of it, and he ended up going back to patches. Bill ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: RFR: GIT Package VCS
Jeremy Katz ([EMAIL PROTECTED]) said:
Right. I really don't think we want to just take our current system,
switch out CVS, and end up with all of the same workflows. The change
should be more about how do we improve workflows. That means thinking
about things like:
* How do we make it easier for a maintainer to rebase their package to a
newer upstream?
* How do we make it easier for a maintainer to develop, test, and create
a patch to fix a problem that's being experienced in Fedora?
* How do we make it easy to send these patches to the upstream of the
project being worked on?
* How do we enable downstreams to take our bits, track them and make
changes as they need/want?
* How do we better enable a user who has a problem with something we
ship to be able to fix it themselves and get the fix back to us?
That's the off the top of my head list to give you sort of the idea of
things that really want to be thought about.
Because if we're just switching out CVS for {git,hg,bzr,svn,foobarbazl}
and don't think about these things then we're putting all of our
developers onto a learning curve to switch for what is likely to be
little gain.
Moreover,there have been requests from developers to explicitly *NOT*
significantly change the development methodology for F8 after the changes
of F7.
Bill
___
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Problem with updates updates-testing repo
Stephanos Manos ([EMAIL PROTECTED]) said: Apologies for the noise if this is not the right place to report this it seams that the createrepo script didn't run correctly for updates-7 updates-7-testing since it includes the debuginfo packages The problem is visible either with cli yum or gui tools like yumex The fix is running createrepo with -x debug/* that results in quicker run and smaller metadata files Yes, we'll get this fixed. Bill ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: the mechanics of pushing updates
Luke Macken ([EMAIL PROTECTED]) said: By the looks of the fedora-release-tools module, there are two scripts that have been used to sign packages, ftsign and fedorasign, both of which call /usr/local/bin/rpm-4.1-sign, which is a symlink to /usr/lib/rpm/rpmk. ... which doesn't interact well with brew/koji. Koji keeps a sigcache for each package in pkg/ver/rel/data/sigcache/arch/, although I have no idea at what point in the build process this gets created. I'm also under the impression that just having this detached signature isn't enough, and that there still must be some manual intervention? Is there anything else bodhi needs to do other than make sure the corresponding .sig exists for each package? The sigcache is a koji feature; you can tell it to write out a signed version of the package on demand. mash, at least, does not do this, and will just take whatever existing version is signed with the best key. (Waiting on it to generate signed versions would be rather slow.) This isn't as bad as the previous biarch-list-of-doom[0] anymore. Bodhi imports it into its Multilib database table[1] during initialization, and doesn't deal with it again. Upon submission of an update, bodhi builds the list of associated packages, taking care of multilib based on what's in the db. The multilib table can then be modified with ease using the TurboGears CatWalk database editor, or a simple command-line tool. Still, it's a list - each new added package would potentially require an addition. - rsync the whole repo out TODO. At the moment bodhi stages to /mnt/koji/updates-stage -- where are we going to sync this to? wallace still? Short-term, yes. Older updates are cleaned by a cron script later. TODO. We need something similar to the fedora-updates-clean script that is currently in place (but less hackish), or RepoPrune / repomanage. The TurboGears scheduler[3] is probably a good place for this. I'm going to try and find some time tonight to throw one together. Well, we *could* go to one-update-only, as older updates will be available directly from the koji web server. Disadvantages: - multilib. In a world where we continually add new packages, this *will not scale*. Random idea. Since multilib is handled by mash, which pushed out rawhide nightly, couldn't we just have mash keep the Multilib table up to date? Would this solve the scalability issue wrt new packages? rawhide doesn't necessarily mesh with what's available for earlier releases. Bill ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
the mechanics of pushing updates
Mmm, plumbing. bodhi is heading for production soon. To push updates, what bodhi currently does is, for any update: - sign the package - copy the package to a 'staging' tree of the entirety of updates - read a static list of packages that should be multilib, act on that - run createrepo - check deps on the repo - rsync the whole repo out Older updates are cleaned by a cron script later. Advantages of this approach: - it's simple - it's easy to clean upthings that Go Wrong (just manually remove them from the repo and re-sync) Disadvantages: - multilib. In a world where we continually add new packages, this *will not scale*. So, we need at least *some* sort of better workflow. One alternative - using mash (what we're using to build rawhide.) It would go something like this: - sign the package - tag the package (for updates-testing, or updates) - run mash to create a repo of updates/updates-testing, solve it for multilib - rsync it out Advantages: - solves multilib - doesn't require continually keeping a staging tree around - depcheck is built in when solving multilib - builds on koji tags to let anyone easily query what updates are released Disadvantages: - by rebuilding the repo each time, it's going to be slow once the repo gets large - harder to clear out other strangeness - will only have one version of each updated package The last of these isn't as *big* of a concern now, as all builds will be available through the koji web site, space permitting. Other ideas for better workflow? What do the extras push scripts do? Do we want to add a modified version of mash's multilib solver into bodhi? (This is ignoring the process of rsyncing to the mirror master, which will be gross.) Bill ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Vote for the (probable) name of Fedora 7!
The board has sent a list of suggested names for Fedora 7 to our legal department, and they have responded with the names that have passed preliminary legal approval. Please vote for your favorite choice at: https://admin.fedoraproject.org/voting/vote.cgi The choices are 'Lee', 'Sherman', 'Nothing', 'Cylon', 'Moonshine', 'Siegfried'. You will need to log in with your Fedora account system user/password. Voting will be open until 2007-05-25 00:00:00 UTC. Thanks to Toshio Kuratomi for getting this set up. We apologize for the short voting timeframe - final legal approval can take up to five days, and we'd really like to avoid slipping solely for the name of the release. If there end up being legal issues with the name selected, the Board will decide on the name. (Who knows, could end up being Zod 2: Electric Zod-a-loo). Bill ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: cvsl10n CVSROOT
Dimitris Glezos ([EMAIL PROTECTED]) said: Our translators have made it clear they want to use a SCM for the translations and said an *additional* web-based tool would be nice. So, let's first create our SCM and we'll see about whether we should use pootle. Use *one* SCM. How to gate currently hosted GIT/HG/etc into this is unclear. :/ Bill ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Infrastructure Design - Look Feel
Máirín Duffy ([EMAIL PROTECTED]) said: - Is the main Fedora Project wiki up for redesign as well? I think it could use a little tweaking. Well, there has been talk of moving the frontpage to a static site that is actually designed, along with the docs and other more static content. Doesn't mean the wiki couldn't have a facelift. - I have an account at hosted.fedoraproject.org now so I'm somewhat familiar with it. Could the look feel of this involve themeing trac? Are there any other applications on hosted? (I think there might be cvsweb on there?) Can trac do per-project theming? Bill ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
