Re: Disk space requirements
On Sat, 2007-03-24 at 10:04 -0500, Matt Domsch wrote: > On Sat, Mar 24, 2007 at 09:58:37AM -0500, Mike McGrath wrote: > > As for the mirrors, what are they obligated to take and what can they pick? > > They can pick and choose however they like fundamentally. They > exclude by arch (e.g. ppc often isn't carried), only Core, no > debuginfo, no repoview, ... Mirrormanager crawls them to know what > they carry in a per-directory basis and can present that to the end > users. > > I would strongly suggest that the mirrors only be asked to keep x86 and x86_64. We can always have a ppc.fedoraproject.org where people can get ppc (same for itanium, etc.) Gives them their own identity, too. I can't imagine that the number of people using those variants would add up to much bandwith for us to carry, and we can't burden them with it in addition to the size increase we're asking them to carry. In addition, if there's a way that we can ask them to only carry current + 1 distro that seems fine with me. Beyond that, set up archive.fedoraproject.org and put them there. I have to imagine that the number of people using releases older than that is so low that it has to be a trailing edge opportunity to ask all of the mirrors to carry it. I don't suppose we have numbers to back any of this up instead of just speculating? Could be gleaned from web logs over time, right? --Chris ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
RE: Vote for the (probable) name of Fedora 7!
On Wed, 2007-05-23 at 11:07 -0400, Voll, Toivo wrote: > Is there an explanation of the names somewhere? What they stand for, why they > are being suggested, how they compare to the previous names... It's Nothing you have to worry about. --Chris > > -- > Toivo Voll > University of South Florida > Academic Computing > Data Network Management > > > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill Nottingham > Sent: Tuesday, May 22, 2007 21:09 > To: fedora-infrastructure-list@redhat.com > Subject: 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 > > ___ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Vote for the (probable) name of Fedora 7!
On Wed, 2007-05-23 at 11:10 -0500, Mike McGrath wrote: > Christopher Blizzard wrote: > > On Wed, 2007-05-23 at 11:07 -0400, Voll, Toivo wrote: > > > >> Is there an explanation of the names somewhere? What they stand for, why > >> they are being suggested, how they compare to the previous names... > >> > > > > It's Nothing you have to worry about. > > > > It's Moonshine I worry about :) > Nothing like a drink of Moonshine. --Chris ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: RFR: GIT Package VCS
On Wed, 2007-06-06 at 10:31 -0400, Jeremy Katz wrote: > > 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? > Awesome stuff. This is the right way to go about the conversation, for sure. I would love to add some stuff to this list: o How do we bring developers and consumers of technology closer together? In a less market-ey speak way to put it: how do we let software developers (not just maintainers!) get directly involved and let them deal directly with the people who want to use it without the maintainer as a mediator? o How do we deal with _more than just RPMs_ as a build and delivery mechanism. (Trust me, this is coming.) o Do we want to move to a process where code is just in a repo and it's built automatically instead of source + patches + spec file? Also, we need to think in use cases instead of abstract questions or about what technology we can use. For example: "A developer has made a patch that he thinks fixes a bug for one of his users. He mails the user and says "here's a pointer to the patch - just click on this button to try a build on your system." One of my goals that I've had for Fedora, one that's easy to understand is, "one click to try any patch." What's required to make that happen? Realistically we probably need to move to a source control system so that when the developer commits (or is pushed in the git sense) the tag with that commit or change is available to apply. Then the build system can just pull that tag, build it and make it available to the user automatically. I would like to compare this to the current work flow we have. Right now you report a bug, the developer looks at the bug, generates a patch. That patch is usually uploaded to bugzilla. Then a very advanced user might be able to take that patch, figure out how to apply it to a spec file, rebuild the rpm and then install and test it. Then that test information might be returned, it might not, but it's hard for you to share that build with other people that might want to test. Our current system creates artificial barriers between developers and users and requires a huge amount of cognitive load to get involved and to get things done. It's slowing things down and creating a bad experience. And worse, everyone doing Linux is doing the same thing. So I think we need to take the next step. Think about how to build simple, easy to understand systems and connect people closer together. So does using git for the package VCS actually help solve this? Not really. But does it mean that it's a step down the right path? Sure. But we need to make sure that we're thinking about the problems correctly instead of just trying to apply a technology to a problem without understanding which problem we're trying to solve. And I don't think our biggest problem is CVS. Our biggest problems are scale and how hard it is for people to be able to share information and be more effective. --Chris ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: RFR: GIT Package VCS
On Wed, 2007-06-06 at 16:16 -0400, Jeremy Katz wrote: > > The problem with a staged approach like this two-fold > 1) Moving off of CVS is going to end up requiring a fair bit of > relearning/retraining for people. Even if we keep the workflow the > same. So by having it as a two-step thing, people have to retrain > themselves _twice_ rather than just once. > 2) If you let some people move and not others, then it becomes very > difficult to know what you have to do to make changes to a specific > package. If you're the only person that works on something, that's > not > such a big deal... but we want to be encouraging collaboration and > working together. Having two different ways of doing that at the same > time is going to mean that everyone has to get over the hump _anyway_. > So why not just take our lumps in get there in a go. So regarding 1. I would suggest that we leave "classic" packages in CVS. Learning another system is a big deal and we get almost no bang for that buck so I don't see us moving off of CVS for our current repo setup any time soon. I think that moving selectively is the option of the developer and/or maintainer and should reflect how the upstream project works. And it's only really required for stuff that's moving quickly or has a large community. Remember one of our primary goals: get as close to upstream as possible. If we're supporting them by using the same DVCS then they are more likely to assist us, not to mention how easy it gets to figure out what's different between repo a and repo b. For example for the kernel, we might want to pull from a git repo. For people who use hg, we just use that. For projects that just release tarballs, we stick with what we have. This might sound crazy (SUPPORT > 1 SYSTEM, ARE YOU CRAZY?) Well, yes, until you realize what you need to do here. To start with you only have to teach the rpm build side how pull a specific tag from a specific repo. On the query side we need a browser for each kind, which is a bit of work, but something I think we need to do anyway. (i.e. "What would git do?") Plus, to be honest, it completely avoids the whole "which damn system do we use." And I like focusing on the end user features instead of getting stuck in VCS dicussion hell. We're not going to get everyone else to agree or even use the same system. So let's build something that supports both. I understand the training costs here, but to be honest I think that local experts will continue to be local experts. And we want more of that not less. --Chris ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: RFR: GIT Package VCS
On Wed, 2007-06-06 at 16:53 -0400, Christopher Blizzard wrote: > > > This might sound crazy (SUPPORT > 1 SYSTEM, ARE YOU CRAZY?) Well, > yes, > until you realize what you need to do here. To start with you only > have > to teach the rpm build side how pull a specific tag from a specific > repo. On the query side we need a browser for each kind, which is a > bit > of work, but something I think we need to do anyway. (i.e. "What > would > git do?") > One more thought for people to chew on. I honestly believe that one of our roles needs to be to service developers. Right now we're set up to service packagers + maintainers. I want to bring developers into the fold and give them tools to be more productive. So what ends up being a little bit more work for us ends up making developers lives much much easier. And that's a total win because it builds our most important base - those developers. --Chris ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: RFR: GIT Package VCS
On Wed, 2007-06-06 at 17:31 -0400, Jeremy Katz wrote: > At the same time, I think we still need to be able to very clearly > separate out our changes from what upstream has. Just a git repo of the > kernel very quickly gets out of control and you end up with bazillions > of things that you never push back upstream because it's easier to just > keep sitting on them. So I don't think that just a VCS repo of the > source is what we want... we're going to end up wanting some integration > with something quilt-like to get patches out; so like stgit or mq or ... Like I said, I think it depends on what the package is and most importantly what the maintainer and developers want to do. I know that Dave Jones didn't want to use git to build the kernel, and that's fine He doesn't have to use it. One thing I'm trying to do here is break the maintainer model that we have today. I want developers to come and work directly in Fedora. And that means taking out that extra step if we can - going directly from a VCS to a package. Using HAL as an example - want to pull in the latest one? Just point your repo at the upstream one and catch up to that release. Then click to build. Or, even better, the developer can do it himself and push it into our release. Remember, in a lot of causes for us the maintainer _is_ the main developer! So why not draw that line as close as possible? > > This might sound crazy (SUPPORT > 1 SYSTEM, ARE YOU CRAZY?) Well, yes, > > until you realize what you need to do here. To start with you only have > > to teach the rpm build side how pull a specific tag from a specific > > repo. On the query side we need a browser for each kind, which is a bit > > of work, but something I think we need to do anyway. (i.e. "What would > > git do?") > > So if I am the owner of the rpm package which has an upstream of hg and > want to fix, test and commit a change to say (for the sake of argument) > neon which is in git, I now have to know two different systems? You're > crazy ;-) No. If you happen to be a maintainer _and_ a developer and you have _chosen_ to use hg or git or whatever, then we make it easy for you. This is about adding options to bring us closer to the upstream developers and make their lives easier. > > To add to the craziness of this path, think about actually maintaining > these packages across different distro releases... every VCS has its > own unique and specially crack-ridden way of handling branching. Yes, but you only need to teach our systems about that once. > > Or when you star to think about the "I'm a downstream of Fedora and need > to change X, Y, and Z" and you are then having them set up potentially 3 > different VCS systems to do so. Depends on what they want to do. > > Or the "it's time for a mass-rebuild; let's go and commit a version bump > to all the packages so we can rebuild. Uhhm. Uh-oh. This is actually easier for those VCS packages than it is today. Right now we have to go in and edit every single spec file, edit, and commit. If we back away from having spec files like that and instead generate that info before compile time (so a "pristine source" is just a set of metadata, rules and a source tag) doing mass rebuilds is _easy_. > > > Plus, to be honest, it completely avoids the whole "which damn system do > > we use." And I like focusing on the end user features instead of > > getting stuck in VCS dicussion hell. We're not going to get everyone > > else to agree or even use the same system. So let's build something > > that supports both. > > So instead of picking _one_ answer, we now have to make sure that we > implement all of the end user features for N systems? Seriously, this > is losing. This comment inspired me to make a very special graphic: http://www.ideasuite.com/~blizzard/images/captain_no.png So let me ask you this question: where do you want Fedora to go? Just keep adding packages? Situation as usual? We got things outside of the firewall. That's nice. We will never rest on our laurels. What's next? I have a pretty specific vision for where we should be two to three years down the road, and it involves innovating in these spaces including looking at having source repos to fix real problems with developer productivity. How can we make developers (not just maintainers) lives easier? How can we shorten the distance between them? I don't see you offering ideas, only saying others are bad. --Chris ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Upgrade metrics
On Fri, 2007-06-15 at 08:54 -0500, Mike McGrath wrote: > > The problem with the smolt numbers is that anyone doing kickstarts, > installing via runlevel 3, yum upgrades or anaconda upgrades will > never > get prompted to enable smolt and there are privacy concerns just > enabling it by default. So I think the only way we can do it is > start > to seed people now, get the word out about smolt, and start > monitoring > upgrades from F7 to F8 and so on. > What happens in the case that the network stuff isn't up when smolt runs during startup? Did it end up being able to wait for the network and queue it for later? I'm a little surprised that the number of units that we have is as small as it is, and how few of them are laptops. Or maybe it's just that our support for laptops is so bad that no one is bothering anymore. :) Would be nice to move smolt out of just the firstboot and do some user surveys as well, but I guess we haven't speced that out and haven't had time to do the work to make that happen. --Chris ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Upgrade metrics
On Fri, 2007-06-15 at 10:51 -0500, Mike McGrath wrote: > > It keeps trying as best as it can until network comes up. If all > that > fails (say a reboot is required before network comes up) the monthly > smolt checkin will start up and we'll get them a month after they > install. The monthly checkin will also let us do queries on 'active' > users say people that have submitted in the last 6 months or 12 > months. Does it do things like reload dns when the network config changes? Because, tee hee, glibc does not handle this kind of thing for you. > > Well we do have smoltGui available and we're working on adding a > rating > system for the entire profile as well as individual devices. The > question is how to get people to run it. > Who is working on that? You know, so I can stick my little nose into it. --Chris ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Upgrade metrics
On Fri, 2007-06-15 at 18:29 +0200, Paulo Santos wrote: > > Something like: > - "New survey is available" > - you click in it, do the survey and send it with the profile, it > would also be nice to have a checkbox to disable the announcements. > That's a good idea. I always worried about how to handle surveys on the client side because that's where the data is. But if you connect it to the smolt data on the server then you can measure based off that. The thing about surveys, though, is that they are connected to the current revisions of some of the software on the machine and not connected to the hardware profile. More the combination, and they change over time. What we want to be able to do is measure the experience with that combination and then measure our improvements over time. I get the impression that there's a one to one mapping from the hardware profile to UUID and that you can change the entire profile and the old data that was in there was lost. (Strangely enough when I looked up my UUID for this machine it was clearly someone else's machine. I ran smolt and stepped on it. I was a little surprised that we had a collision there.) --Chris ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Our SCM
Before you guys descend into a discussion of specific SCMs can you talk about what the goals are for what you want to do? Mike touched on them but I think that it needs more discussion before you talk about what you love/hate about specific tools. --Chris ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Our SCM
On Wed, 2007-06-20 at 11:22 -0700, Karsten Wade wrote: > > > So, Infrastructure is much closer to developers, in that the pool of > potentials are more likely to be clued. But keeping it this hard to > contribute means we are missing out on the 1x more people who are > not clued enough to get over the walls, but who would become so clued > if > we could get them in and working their way along the path to > Enlightenment. > > This goes back to the stuff Blizzard keeps talking about -- getting > down > the barriers between users and developers that our open collaboration > tools ironically create. > Right! So here's another question for you: how do we make things easier? And I don't mean just getting the model right (i.e. DVCS as a mechanism) but also keeping things super-easy to use? Here's a completely crazy idea: do an "online" translation activity that uses google gears on the backend that lets people do their work offline and then can sync up when it's done? That way anyone on linux/windows/mac can participate and they can get hooked directly up to web services we have in place? That's outside of our comfort zone, but it's not completely crazy. Our work has to be about enabling people so that working with us and the rest of the open source community is easy easy easy. --Chris ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Our SCM
On Wed, 2007-06-20 at 15:52 -0400, seth vidal wrote: > > Does that make any sense at all? My specific proposal was mostly about translations which I don't think have the same scaling problems you (rightfully) point out with source in general. I like a lot of what you had to say there. Instead of saying that we pull from an upstream VCS I might say that we keep our own copy. I think that we always want to have a copy of the source that we use for builds somewhere local. But I do like the idea of trying to get upstream repos to keep track of the "fedora" branch or coming up with a set of best practices around that. Anything we can do to make ourselves closer to upstream projects is for teh win. --Chris ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Our SCM
On Wed, 2007-06-20 at 16:06 -0400, Michael DeHaan wrote: > > However it does rely on the accessibility of those upstream repos. > Shouldn't be a major issue. If it's down, no updates. Trust me when I say you don't want to do this. You always want to have a local copy. For OLPC we have a jhbuild script that used to pull from a lot of different repos and someone was _always_ down. We want coupling, but we want it to be loose coupling. --Chris ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: smolt, hardware compatibility and package stats
On Sun, 2007-06-24 at 22:12 +0530, Rahul Sundaram wrote: > Mike McGrath wrote: > > Rahul Sundaram wrote: > >> > >> What do folks think of extending smolt into more of a system profiler > >> including optionally collecting information on installed packages? > >> > > > > I'm on the fence about this but would put package information lower in > > priority then some of the ratings system stuff. Mugshot is doing some > > package stuff already. > > True but that code is tied to mugshot (I asked) and would require users > to sign up with mugshot while Smolt is in first boot and I think many > end users would prefer the unobtrusive method. As long as we have it > optional (ie) I should be able to send the hardware details or the > packaging stats or both, it should be a useful thing to do. I would rather leave the packaging stuff up to the mugshot guys. They will add an interesting social aspect to it. What I _am_ interested for smolt, though, is hardware compatibility surveys. I think that Mike and I have discussed that in the past and we just never figured out how it would work. i.e. "does this laptop suspend with kernel X" which is different than the data we collect now which doesn't really change with time. It's a new set of data related to hardware that we can build entries with over time and be able to measure something important: how good we do with our hardware support and specific releases. --Chris ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: smolt, hardware compatibility and package stats
On Mon, 2007-06-25 at 17:41 -0400, Russell Harrison wrote: > > Doesn't knowing what's installed help determine what could be fighting > with the hardware? Seems like there are two data points to capture. > What's installed (seems like a good feature for smolt) and what's > actually used (which mugshot is collecting now). What people are > using has a social value. What people have installed has more value > for support and future planning. I'm not saying the installed > packages should have a high priority for smolt, but it should be on > the road map, IMO. > I actually think that we need to capture a small bit of that information. i.e. kernel, hal, pm-utils and whatnot. But catching everything? Probably not really needed for hardware compat. (Maybe other things like NM, bluez-utils, etc.) Just trying to keep the scope pretty small. :) --Chris ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: smolt, hardware compatibility and package stats
On Wed, 2007-06-27 at 07:54 -0400, Russell Harrison wrote: > > > On 6/25/07, Christopher Blizzard <[EMAIL PROTECTED]> wrote: > I actually think that we need to capture a small bit of that > information. i.e. kernel, hal, pm-utils and whatnot. But > catching > everything? Probably not really needed for hardware > compat. (Maybe > other things like NM, bluez-utils, etc.) > > Just trying to keep the scope pretty small. :) > > Understood, it just seems to be about the same amount of codding > work to record everything rather than filtering stuff out. Now when > you start talking about storage required. . . that is a different > story. I think the reason I said it should be on the road map is in > the future smolt can help with software compatibility as well. Again > not a high priority given the current scope of smolt, just one for the > list. Right. > > What may be very valuable from a hardware compat standpoint is a > record of packages that aren't in the fedora repos, especially kernel > modules. We know people are going to be installing the nvidia and > fglrx drivers, but what else are they installing because the stock > kernel doesn't have drivers that do what they want. > I actually think that "loaded kernel modules" is one of the things we want to capture for hardware compatibility questions. You could ask questions like "show me all the common modules for laptops that don't suspend" and you might learn a lot from the query about which modules may or may not be bad. At least it's a decent set of data to query. --Chris ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Hosting repos that are not upstream
On Wed, 2007-08-01 at 11:42 -0400, Jesse Keating wrote: > > Collaboration between more than 1 or 2 people on a patch set to > propose > upstream. Yeah, this is what I've been pushing for forever. "Private Builds". The use case is something like project utopia. Where you have to make a pile of builds together in order to make some change and you want to work with and collaborate with other people outside of the mainstream of development. Doing so should be the click of one button. Once again, it's about attracting developers, not really about having only one way of doing things. And developers like to work with other people and have a convenient place to do so. --Chris ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Hosting repos that are not upstream
On Wed, 2007-08-01 at 11:53 -0400, seth vidal wrote: > On Wed, 2007-08-01 at 11:42 -0400, Christopher Blizzard wrote: > > On Wed, 2007-08-01 at 11:42 -0400, Jesse Keating wrote: > > > > > > Collaboration between more than 1 or 2 people on a patch set to > > > propose > > > upstream. > > > > Yeah, this is what I've been pushing for forever. "Private Builds". > > The use case is something like project utopia. Where you have to make a > > pile of builds together in order to make some change and you want to > > work with and collaborate with other people outside of the mainstream of > > development. Doing so should be the click of one button. Once again, > > it's about attracting developers, not really about having only one way > > of doing things. And developers like to work with other people and have > > a convenient place to do so. > > > > OR to rephrase what you've just said: > > it's about maintaining forks and encouraging forking. > > If we setup a new repo at hosted, everytime someone wants to play with > something we'll have an infinite set of repos and we'll have a lot of > languishing and abandoned branches that never get cleaned up. > > Making a repo at fedorapeople.org is trivial and available and it > doesn't require any intervention by people in the infrastructure group. > Just drop your repo there and go! It's really not about forking. It's about allowing for easy experimentation which encourages developers to work with Fedora. Everyone has used repos forever. But repos aren't connected to any particular development branch. (i.e. here's a repo, but where's the development happening? Who is involved? Is it still active?) Also it would seem that keeping the knowledge of changes involved in a particular development effort is important. There are a lot of languishing and abandoned repos that exist out there, too. They just take up a lot more space because they include source + binaries, not just a pointed to a starting point + a set of patches. :P --Chris ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Features for Fedora Project PBX 1.0
On Tue, 2007-08-07 at 16:08 -0500, Mike McGrath wrote: > > I'm not going to say no to this, but I am going to say that if this is > a > service we are serious about offering, it will take $$. Whereas the > contributor only bridge can be made available now with our current > resources. > Yeah, be careful. Supporting developers is one thing but this will take up a lot of space and we're not in a position to start supporting end users. I'm not saying it's a bad idea, just one we're not ready to support. --Chris ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
