Re: Backups
Mike McGrath wrote: Nils Breunese wrote: Mike McGrath wrote: Hopefully we'll be using both tape and disk backups. Once our new disk tray gets in we'll have to prepare to backup a couple TB of Binary RPMs. Some of our backups will be going to disk, some will be going to tape. Additionally it seems that bacula is more efficient at backing things up. Efficient in term of what precisely? And what backend are we using with BackupPC right now? In terms of how long it takes to do the backups and how much load it requires. BackupPC is written in perl. The backup times and load differ greatly with the backend you choose. Are we doing rsync over ssh right now? We could speed that up by using Blowfish. Maybe rsyncd? If we want to reduce the load we could also go with the tar backend, though that will increase the traffic used. But yeah, it could entirely be the case that Bacula is more suited for this job. :) Nils Breunese. ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: RFR: GIT Package VCS
Jeffrey C. Ollie wrote: With F8T1 fast approaching (it's currently scheduled to be released on 1 August 2007) we need to get cracking on a new VCS system. I've been working on converting the CVS repositories to GIT on some spare hardware that I've had laying around. I think that it's at a stage where input testing from the community is needed to move the project forward. Therefore I'd like to request a test Xen host to move the repository over: http://fedoraproject.org/wiki/Infrastructure/RFR/GitPackageVCS More information about the repository I've been setting up can be found here: http://fedoraproject.org/wiki/JeffOllie/VCS/Git I'm glad this is started back up. One thing that amuses me is back before the F7 launch it almost seemed assured that we would all go with mercurial. This line isn't so clear now, a lot of people have been using git. It seems our future is either going to be A) do nothing and continue with CVS or B) move to HG or Git. One thing that will be tricky about this is that we'll be completely re-designing how we use our source management. Its not just removing cvs and plugging in some other technology in its place. I think Jesse and Jeremy may have had something particular in mind for this but I'm not sure. The hurdles as I see them are: ACL's Making sure checkouts and commits don't take forever Good tagging abilities What else is there? -Mike ___ 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 09:17 -0500, Mike McGrath wrote:
I'm glad this is started back up. One thing that amuses me is back
before the F7 launch it almost seemed assured that we would all go with
mercurial. This line isn't so clear now, a lot of people have been
using git. It seems our future is either going to be A) do nothing and
continue with CVS or B) move to HG or Git.
Yeah, definitely time to start this back up.
One thing that will be tricky about this is that we'll be completely
re-designing how we use our source management. Its not just removing
cvs and plugging in some other technology in its place. I think Jesse
and Jeremy may have had something particular in mind for this but I'm
not sure.
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.
Jeremy
___
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 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? * How do we do all that while keeping it simple :) Well, I guess now we can all start thinking about it. Source Control is supposed to be a tool to empower developers, lets make sure that what we end up with is just that. -Mike ___ 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:44 -0400, Jeremy Katz wrote: On Wed, 2007-06-06 at 10:31 -0400, Jeremy Katz wrote: On Wed, 2007-06-06 at 09:17 -0500, Mike McGrath wrote: I'm glad this is started back up. One thing that amuses me is back before the F7 launch it almost seemed assured that we would all go with mercurial. This line isn't so clear now, a lot of people have been using git. It seems our future is either going to be A) do nothing and continue with CVS or B) move to HG or Git. Yeah, definitely time to start this back up. And just to make things clear, it's time to start up talking about it, investigating our options and getting some things rolling. But that _doesn't_ mean we should rush things to just get them done based on an arbitrary deadline. This is the sort of thing we're going to have to live with for a long while, so it's better to have it take an extra release cycle before rolling out and get it right. Otherwise, we'll have a revolt on our hands :-) I agree and I disagree. Yes, we need to carefully consider our next step. On the other hand I think that we need to get off of CVS as soon as possible. From what I've seen while testing the conversion to GIT there seems to be corruption in some of the CVS repositories. It's most noticeable in large/active packages (the kernel is a notable example) but sometime small packages are affected. I don't think that it's had a major effect so far because I think that it's relatively rare that people go back and look at old revisions of the packages (probably because that's so difficult in CVS). You can see the effect of the corruption in my git repos thusly: git clone git://161.210.6.204/kernel cd kernel gitk devel origin/FC-6 If you scroll down (way way down) you'll see that the history of the FC-6 branch diverges much much sooner than it should at: 66b7d75c65cfc08a513b7e3a51b9e9661c79f793 2005-08-18 2.6.13-rc6-git10 rather than at: a81d311b742ee08174abb017b6b0caabaa369867 2006-10-12 Initialize branch FC-6 for kernel Compare that with: gitk devel origin/F-7 where you can see the histories diverge at: 80cedc3f9b0705ef0e38565d69869d7871c5c8b8 2007-05-18 Initialize branch F-7 for kernel Jeff signature.asc Description: This is a digitally signed message part ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Moin 1.6 and 1.7
Last summer we were tracking GSoC changes against the 1.5 trunk of Moin. Those change never got merged, so did not make the 1.6 release. FWIW, we're still looking for someone interested in Python, DocBook, and Moin to help maintain those patches; if we did, we might get them accepted into the trunk. A current SoC project is working on providing a Wiki interface for editing man/info pages. More details are found on Ville-Pekka's project page[1]. The question has come up from Ville-Pekka if we want to track our changes against the current Moin version (1.6) or the upcoming (1.7), and we need to have a decision within the week. Any thoughts on this? From the project page[1]: * Finally decide on 1.6 vs. 1.7. This needs to happen this week as of writing (week 23). No major changes will get to 1.6 anymore, so if I based my project on it, then Fedora would need to run an unmerged branch of the code. Probably not what we want? My suggestion is to work on 1.7 branch and hopefully get my changes merged into mainline eventually. [1] http://fedoraproject.org/wiki/SummerOfCode/2007/VillePekkaVainio -- Karsten Wade, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 // signature.asc Description: This is a digitally signed message part ___ 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 11:09 -0500, Jeffrey C. Ollie wrote: On Wed, 2007-06-06 at 10:44 -0400, Jeremy Katz wrote: On Wed, 2007-06-06 at 10:31 -0400, Jeremy Katz wrote: On Wed, 2007-06-06 at 09:17 -0500, Mike McGrath wrote: I'm glad this is started back up. One thing that amuses me is back before the F7 launch it almost seemed assured that we would all go with mercurial. This line isn't so clear now, a lot of people have been using git. It seems our future is either going to be A) do nothing and continue with CVS or B) move to HG or Git. Yeah, definitely time to start this back up. And just to make things clear, it's time to start up talking about it, investigating our options and getting some things rolling. But that _doesn't_ mean we should rush things to just get them done based on an arbitrary deadline. This is the sort of thing we're going to have to live with for a long while, so it's better to have it take an extra release cycle before rolling out and get it right. Otherwise, we'll have a revolt on our hands :-) I agree and I disagree. Yes, we need to carefully consider our next step. On the other hand I think that we need to get off of CVS as soon as possible. From what I've seen while testing the conversion to GIT there seems to be corruption in some of the CVS repositories. It's most noticeable in large/active packages (the kernel is a notable example) but sometime small packages are affected. I don't think that it's had a major effect so far because I think that it's relatively rare that people go back and look at old revisions of the packages (probably because that's so difficult in CVS). I wouldn't be entirely certain there -- for one thing, don't discount bugs in the conversion process. Also, there have been rare cases where things have been munged a bit directly which leads to things being ... not exactly as perhaps expected. Jeremy ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Moin 1.6 and 1.7
Karsten, Personally i would go for 1.7, since im sure that noone will want to maintain their own moin branch, and keep patching it manually without breaking the rest of the new patches. Paulo On 6/6/07, Karsten Wade [EMAIL PROTECTED] wrote: Last summer we were tracking GSoC changes against the 1.5 trunk of Moin. Those change never got merged, so did not make the 1.6 release. FWIW, we're still looking for someone interested in Python, DocBook, and Moin to help maintain those patches; if we did, we might get them accepted into the trunk. A current SoC project is working on providing a Wiki interface for editing man/info pages. More details are found on Ville-Pekka's project page[1]. The question has come up from Ville-Pekka if we want to track our changes against the current Moin version (1.6) or the upcoming (1.7), and we need to have a decision within the week. Any thoughts on this? From the project page[1]: * Finally decide on 1.6 vs. 1.7. This needs to happen this week as of writing (week 23). No major changes will get to 1.6 anymore, so if I based my project on it, then Fedora would need to run an unmerged branch of the code. Probably not what we want? My suggestion is to work on 1.7 branch and hopefully get my changes merged into mainline eventually. [1] http://fedoraproject.org/wiki/SummerOfCode/2007/VillePekkaVainio -- Karsten Wade, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 // ___ 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: Moin 1.6 and 1.7
O/H Paulo Santos έγραψε: Personally i would go for 1.7, since im sure that noone will want to maintain their own moin branch, and keep patching it manually without breaking the rest of the new patches. Working with upstream 1.7 sounds more sane. -d -- Dimitris Glezos Jabber ID: [EMAIL PROTECTED], GPG: 0xA5A04C3B http://dimitris.glezos.com/ He who gives up functionality for ease of use loses both and deserves neither. (Anonymous) -- ___ 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
Christopher Blizzard wrote: Awesome stuff. This is the right way to go about the conversation, for sure. I would love to add some stuff to this list: Anyone know how our other friends are doing their package management? I know OpenSuSE doesn't really have a cvs at all, its completely lookaside cache (package/release/md5sum-filename) or some such thing. Anyone interested in doing some research on debian and Ubuntu? -Mike ___ 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: RFR: GIT Package VCS
On Wed, 2007-06-06 at 13:50 -0400, Christopher Blizzard wrote: 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? When I first read these two posts, I thought you guys are crazy, but then I thought about it a bit more and started thinking Whoah! This could be really cool! I think what is described here could certainly be done with Git (it'd probably work in another distributed SCM but I'm less famililar with those so I can't say for sure). It also occurred to me that this would be a very big change in how we manage packages so maybe some kind of hybrid approach would make the transition easier. So what about something like this: 1. We convert the package repository to a new SCM so that we can get off of CVS, but the process/workflow remains relatively unchanged. This I think that we could definitely have in place by F8. 2. We set up a parallel package repository that enables our new workflow. When a package maintainer is ready to move a package to the new workflow, building from the old-style repository is disabled and the package is built from the new-style one. 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 think that this is more of a Web UI issue rather than a SCM issue. Koji will already build a package based upon a tag in CVS, it wouldn't take a lot of work to extend that to GIT or some other SCM (example patches for SVN are available in a ticket on Koji's bug tracker). What you would need is a Web UI that would: 1. Let users browse the packages and tags that are available in the SCM. 2. Or users could be directed to a particular package/tag by posting a link in bugzilla/mailing list post. 3. Be able to click on a button to request a build from Koji for a particular package/tag/release/arch. Since the build is going to take some time, users would need to supply an email address where a notification would be sent with a link to download the resulting packages. These packages would be cached for a while in case other people wanted to try out those packages as well. Packages built in this fashion wouldn't become part of rawhide or an update to a released package - that would still require action by the maintainer. Jeff signature.asc Description: This is a digitally signed message part ___ 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 14:32 -0500, Jeffrey C. Ollie wrote: When I first read these two posts, I thought you guys are crazy, No argument here ;-) but then I thought about it a bit more and started thinking Whoah! This could be really cool! I think what is described here could certainly be done with Git (it'd probably work in another distributed SCM but I'm less famililar with those so I can't say for sure). Yeah, once you start thinking about things like this it becomes pretty clear that a DVCS is almost a requirement rather than a it'd be nice. It also occurred to me that this would be a very big change in how we manage packages so maybe some kind of hybrid approach would make the transition easier. Yes, it is a big change. A huge change. A groundbreaking change even. Something which shows that Fedora isn't just sitting off quietly, but innovating and doing so with toolsets that are entirely open and available for anyone to use. So what about something like this: 1. We convert the package repository to a new SCM so that we can get off of CVS, but the process/workflow remains relatively unchanged. This I think that we could definitely have in place by F8. 2. We set up a parallel package repository that enables our new workflow. When a package maintainer is ready to move a package to the new workflow, building from the old-style repository is disabled and the package is built from the new-style one. 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. Jeremy ___ 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 Wednesday 06 June 2007 16:25:18 Mike McGrath wrote: Thats not to say that some good work couldn't get done now though, jcollie isn't that involved in polishing our current tools but he's got a git background. I say let him test and let us know what he comes up with. Absolutely. In order to be successful in deploying during F9 time frame, we HAVE to have things up and testable during F8 timeframe. No question. -- Jesse Keating Release Engineer: Fedora pgprDM5nsdP1X.pgp Description: PGP signature ___ 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: 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. 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 ... 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 ;-) 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. 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. 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. 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. Jeremy ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
