Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
On Sat, May 26, 2012 at 12:18 PM, Alexey Shvetsov ale...@gentoo.org wrote: Since most of us want clean cut solution so i will close bug #333699 as WONTFIX Along these lines, I'm looking at 333531 (the git migration tracker), and it seems like there isn't actually much to do: 333685 - Seems like no action, and not sure how critical 333687 - while the bug is still open, as far as I can tell it seems good enough to me to move forward 333697 - ditto 333701 - paused since there are other tasks to do first, though it seems to me that little remains 333705 - not sure how critical this actually is - do we care if in some obscure case history is lost? Nothing says that we have to completely destroy the old cvs repo. Maybe we should just do a mock migration now and post copies of the before/after somewhere public and let people have at them. 333709 - seems like there is legitimate work to be done here, but again nothing that big So, what is the big issue? Is there something not being tracked, or is one of those items a lot harder than it looks? Rich
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
Ok. Since most of us want clean cut solution so i will close bug #333699 as WONTFIX -- Best Regards, Alexey 'Alexxy' Shvetsov Petersburg Nuclear Physics Institute, NRC Kurchatov Institute, Gatchina, Russia Department of Molecular and Radiation Biophysics Gentoo Team Ru Gentoo Linux Dev mailto:alexx...@gmail.com mailto:ale...@gentoo.org mailto:ale...@omrb.pnpi.spb.ru
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
On Fri, 25 May 2012, Kent Fredric wrote: On 25 May 2012 13:21, Alec Warner anta...@gentoo.org wrote: So I'm a bit confused. Is GitHub open source? Your confusion begets more confusion: Whether or not Github is open-source seems orthogonal to whether or not we use it, as github is a website, a service, and there are a few such websites, of which, github appears to be the defacto most-popular one. Actually, Alec's question is not so far-fetched. The Gentoo Social Contract says that Gentoo will never depend upon a piece of software unless it is open source. Ulrich
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
On 25 May 2012 18:12, Ulrich Mueller u...@gentoo.org wrote: Actually, Alec's question is not so far-fetched. The Gentoo Social Contract says that Gentoo will never depend upon a piece of software unless it is open source. Though in the case of github, gentoo is not depending upon it. Github could die in a ball of fire, and it wouldn't change the core development, it would only change the development for the people who elected to use github. Anyone can use any git platform that competes with github, be it bitbucket, gitorious, or a private git server they created. Github is just a convenient go-to service for many. -- Kent perl -e print substr( \edrgmaM SPA NOcomil.ic\\@tfrken\, \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 ); http://kent-fredric.fox.geek.nz
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
On Fri, May 25, 2012 at 8:47 AM, Kent Fredric kentfred...@gmail.com wrote: On 25 May 2012 18:12, Ulrich Mueller u...@gentoo.org wrote: Actually, Alec's question is not so far-fetched. The Gentoo Social Contract says that Gentoo will never depend upon a piece of software unless it is open source. Though in the case of github, gentoo is not depending upon it. Github could die in a ball of fire, and it wouldn't change the core development, it would only change the development for the people who elected to use github. This thread has had many suggestions about how things might be laid out. For instance I think it would be against our social contract to host the master git tree on github as someone suggested earlier in the thread. My intent was mostly to keep the contract in mind when coming up with such solutions. Anyone can use any git platform that competes with github, be it bitbucket, gitorious, or a private git server they created. Github is just a convenient go-to service for many. -- Kent perl -e print substr( \edrgmaM SPA NOcomil.ic\\@tfrken\, \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 ); http://kent-fredric.fox.geek.nz
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
On Thursday, May 24, 2012 07:56:58 AM Michał Górny wrote: On Wed, 23 May 2012 16:14:53 -0500 Dan Douglas orm...@gmail.com wrote: If not I will be leaving Gentoo for Funtoo in the near future, though there are disadvantages to doing this I don't look forward to dealing with. Most of us will probably be doing that :P. Eh sorry that wasn't meant to be antagonistic. I'll still have Gentoo boxen to deal with. I just need to be able to use git on the tree (even without the full history is perfectly fine) to ease the difficulty of local overlay management. Glad to hear that will be possible, or at least somewhat easier. -- Dan Douglas signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
El mié, 23-05-2012 a las 17:00 -0300, Ezequiel Garcia escribió: On Wed, May 23, 2012 at 4:37 PM, Arun Raghavan ford_pref...@gentoo.org wrote: I, for one, think we should stay with CVS and leave all this git Linusware to the new-fangled Fedora kids with their fancy init systems and tight coupling. CVS was good enough for my grandfather, and it's good enough for you. Perhaps it would be instructive if you could tell us one advantage of cvs over git. (This is me exposing me to your terrible dev-flames, I was feeling too cold ;) I think Arun's comment was sarcastic ;) I guess that cvsserver bug can be dropped from blockers, no? Now, the other pending blockers... :( signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
On 24 May 2012 05:35, Alexey Shvetsov ale...@gentoo.org wrote: Full clone will be about 1G or so but no more then 2. If we will drop changelog it will be much smaller And if you use git commit signing instead of ebuild manifests, intra-commit churn will almost be negligible. :D -- Kent perl -e print substr( \edrgmaM SPA NOcomil.ic\\@tfrken\, \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 ); http://kent-fredric.fox.geek.nz
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
On 24 May 2012 08:32, Rich Freeman ri...@gentoo.org wrote: Sure. The slow commit rate encourages careful deliberation before hitting the enter key, which therefore improves quality. Then, if you do make a mistake the slow commit rate means that fixing that mistake can take a long time, which increases the amount of pain our end-users run into due to the mistake, which leads to lots of flame wars on -dev. That means that the guy who made the mistake is subjected to more public ridicule, and is less likely to do it again, That improves quality too. Since cvs doesn't tie together tree-wide changes in a nice way or allow them to be transactionally completed, individual package maintainers don't need to be as concerned with the big picture view. Now as the maintainer of libfoo the fact that somebody changed my ebuild without making a corresponding change in some profile is completely hidden from me, and I can go to sleep peacefully without realizing that my users are all going to have horribly broken systems in the morning. Blissful ignorance of end-user suffering improves developer morale, and helps get rid of pesky users at the same time. cvs also makes more more aware of what is going on around me. Anytime I want to work on something in parallel with the main development branch I get to manually merge changes in, which keeps me aware of my place in the world. That means that I'm less likely to build nice new features, which means fewer bugs, which improves quality, and may even drive away users as an added bonus! See, cvs is really the wave of the future! Rich meta name=sarcasm value=on / This CVS stuff sounds a bit too uppity and unstable to me, sounds like we should go back to the tried and true code collaboration by date-stamped tarballs of the tree which are centralised once a week to a master tarball. -- Kent perl -e print substr( \edrgmaM SPA NOcomil.ic\\@tfrken\, \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 ); http://kent-fredric.fox.geek.nz
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
Kent Fredric писал 2012-05-24 13:02: On 24 May 2012 05:35, Alexey Shvetsov ale...@gentoo.org wrote: Full clone will be about 1G or so but no more then 2. If we will drop changelog it will be much smaller And if you use git commit signing instead of ebuild manifests, intra-commit churn will almost be negligible. :D Yep. Each signature to manifest adds ~512B of echanged data. And this will be added every commit. Also Manifest contain checksumms for all filesincluding ebuild, patches, metadata and so on. thin-manifests will contain only DIST data so they will be much smaller -- Best Regards, Alexey 'Alexxy' Shvetsov Petersburg Nuclear Physics Institute, NRC Kurchatov Institute, Gatchina, Russia Department of Molecular and Radiation Biophysics Gentoo Team Ru Gentoo Linux Dev mailto:alexx...@gmail.com mailto:ale...@gentoo.org mailto:ale...@omrb.pnpi.spb.ru
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
On 24 May 2012 09:48, Michael Weber x...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/23/2012 11:14 PM, Dan Douglas wrote: On Wednesday, May 23, 2012 04:47:04 PM Robin H. Johnson wrote: 2. rsync generation is NOT going away. Users will still be using it. First, I'd stick with the current rsync to spread the tree (mirror work and mirrors+regular rsync users shouldn't notice any backend switch at all). Would users have a way of gaining read-only access? This would be EXTREMELY helpful. Sure, this would be possible like any other git checkout (layman-git-overlays, github.com, etc.). Please compare (browsing source and access description) http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/ http://git-exp.overlays.gentoo.org/gitweb/?p=exp/gentoo-x86.git - -- Gentoo Dev http://xmw.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk+9W0EACgkQknrdDGLu8JADaQD+KC6cLJ5LqpNrKkNEBT1kAvJW xn+ZcfcMGJzc8GPyQZAA/jKug+5/DlDAHVGBIjAJOi9xf4EFqroL4eyPY8SD2neh =dvFZ -END PGP SIGNATURE- I think there should most definitely be an official github mirror of the main tree, just a read-only mirror from githubs perspective. Just how to best do the mirroring is the question a) Replicate to github when a user does 'push' with a server-side push hook? ( Downside: if github goes down, gentoo devs will see it when they push, and pushing takes longer because the output from the replicated push is delivered to the original dev ) b) Daemonized hook that monitors for changes in the master repo, and replicates commits to github after each push c) Tie it with the rsync tree building system so every time the tree is built for rsync clients, the master is replicated to github. Also, this should obviously be force-pushed, so any branch rebases on the master repo are replicated to the github mirror properly. -- Kent perl -e print substr( \edrgmaM SPA NOcomil.ic\\@tfrken\, \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 ); http://kent-fredric.fox.geek.nz
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
On Thu, 24 May 2012 22:17:20 +1200 Kent Fredric kentfred...@gmail.com wrote: On 24 May 2012 09:48, Michael Weber x...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/23/2012 11:14 PM, Dan Douglas wrote: On Wednesday, May 23, 2012 04:47:04 PM Robin H. Johnson wrote: 2. rsync generation is NOT going away. Users will still be using it. First, I'd stick with the current rsync to spread the tree (mirror work and mirrors+regular rsync users shouldn't notice any backend switch at all). Would users have a way of gaining read-only access? This would be EXTREMELY helpful. Sure, this would be possible like any other git checkout (layman-git-overlays, github.com, etc.). Please compare (browsing source and access description) http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/ http://git-exp.overlays.gentoo.org/gitweb/?p=exp/gentoo-x86.git - -- Gentoo Dev http://xmw.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk+9W0EACgkQknrdDGLu8JADaQD+KC6cLJ5LqpNrKkNEBT1kAvJW xn+ZcfcMGJzc8GPyQZAA/jKug+5/DlDAHVGBIjAJOi9xf4EFqroL4eyPY8SD2neh =dvFZ -END PGP SIGNATURE- I think there should most definitely be an official github mirror of the main tree, just a read-only mirror from githubs perspective. Just how to best do the mirroring is the question a) Replicate to github when a user does 'push' with a server-side push hook? ( Downside: if github goes down, gentoo devs will see it when they push, and pushing takes longer because the output from the replicated push is delivered to the original dev ) b) Daemonized hook that monitors for changes in the master repo, and replicates commits to github after each push c) Tie it with the rsync tree building system so every time the tree is built for rsync clients, the master is replicated to github. d) Talk with github folks to add our repo as 'mirror'. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
On Thu, 24 May 2012 16:40:02 +0200 Michał Górny mgo...@gentoo.org wrote: d) Talk with github folks to add our repo as 'mirror'. Can we keep the master on Gentoo hardware please. Also, there still should be a bug at b.g.o and git format-patch works just fine for that. Maybe it's only github now but how many places is a developer supposed to monitor? signature.asc Description: PGP signature
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
On Thu, May 24, 2012 at 11:02 AM, Ralph Sennhauser s...@gentoo.org wrote: Can we keep the master on Gentoo hardware please. Also, there still should be a bug at b.g.o and git format-patch works just fine for that. Maybe it's only github now but how many places is a developer supposed to monitor? I'm actually a little torn on this one. I'm fine with keeping the master on Gentoo in the sense that this is where the rsync tree gets generated. However, gitbub has a lot of tools like pull requests that could potentially improve workflow, especially for things like proxy maintainers. So, letting those teams work more outside of Gentoo and just push their changes into Gentoo might make sense. Perhaps github should be viewed as a widely-shared overlay that gets automatic updates from the main tree in the master branch (or whatever we call it). You can work on a branch in github, get it where you want it to be, and then push it to Gentoo pretty easily. When I don't have access to an upstream repository I often just push a copy to a fork on Github just to make my own life easier. Rich
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
On Thu, 24 May 2012 17:02:24 +0200 Ralph Sennhauser s...@gentoo.org wrote: On Thu, 24 May 2012 16:40:02 +0200 Michał Górny mgo...@gentoo.org wrote: d) Talk with github folks to add our repo as 'mirror'. Can we keep the master on Gentoo hardware please. Yes, that's the intent. I'm just saying that github seems to have a hidden feature of mirroring external repos. https://github.com/mirrors -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
On 24/05/2012 03:19, Mark Wright wrote: Michael Weber x...@gentoo.org writes: Clean cut turns of cvs access on a given and announced timestamp, rsync-generation/updates is suspended (no input - no changes), some magic scripts prepare the git repo (according to [3], some hours duration) and we all checkout the tree (might be some funny massive load). +1 for clean cut to git clean cut +1
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
On 25 May 2012 03:02, Ralph Sennhauser s...@gentoo.org wrote: On Thu, 24 May 2012 16:40:02 +0200 Michał Górny mgo...@gentoo.org wrote: d) Talk with github folks to add our repo as 'mirror'. Can we keep the master on Gentoo hardware please. Definitely. But having a mirror on github will increase forkability, and will make it much faster for people to get started on contribution. When the user has their tree up to how they want it, they can either send a pull request to another gentoo dev who also has a fork on github, or send a link to the commit via some medium ( bug tracker ? ) , and some dev can just add that as a remote, and merge/cherry-pick the commits they want.. In my books, github is mostly a marketing and ease of access platform that streamlines the ability for people to get started contributing and facilitate easy distribution of changes back to upstream. But this is mostly side topic. CLEAN CUT++ If there are problems with it, we can address those when we know what they are, not when we're inventing problems that might not actually exist due to conjecture. I haven't encountered any real problems yet in size or performance constraints with perl-experimental . Sure, its not portage, its only ~800 packages vs portages 15000 , but it should be a somewhat reasonable synthetic workload. Side note: I assume, that there is, a way, if you *really* need it, to copy all the new git commits back to the cvs tree if something critically broken in git turns up so bad it has to be dropped. I think it unlikely, but knowing there is a way to go back would give much reassurance. -- Kent perl -e print substr( \edrgmaM SPA NOcomil.ic\\@tfrken\, \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 ); http://kent-fredric.fox.geek.nz
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 24/05/12 01:13 PM, Kent Fredric wrote: On 25 May 2012 03:02, Ralph Sennhauser s...@gentoo.org wrote: On Thu, 24 May 2012 16:40:02 +0200 Michał Górny mgo...@gentoo.org wrote: d) Talk with github folks to add our repo as 'mirror'. Can we keep the master on Gentoo hardware please. Definitely. But having a mirror on github will increase forkability, and will make it much faster for people to get started on contribution. When the user has their tree up to how they want it, they can either send a pull request to another gentoo dev who also has a fork on github, or send a link to the commit via some medium ( bug tracker ? ) , and some dev can just add that as a remote, and merge/cherry-pick the commits they want.. ...is this something we (as the developer base) WANT non-dev's to be able to do?? I would expect we'd want the tree to still be treated as read-only-not-modifyable by the rest of the gentoo/linux community, otherwise we're going to have a rather large mess on our hands (multiple forks of the main tree != a uniform main tree + overlays, the way it does now) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iF4EAREIAAYFAk++dWAACgkQ2ugaI38ACPBBpAD9EaJsSNXMS6bDbttJStVqghlO Q46xkgPIgunriOLJhDoA/06HH/kgXd/Qrq/Ex0X3kV9nDmYqE0OmiFM1kVTfdVCD =dcOs -END PGP SIGNATURE-
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 24 May 2012 13:52:32 -0400 Ian Stakenvicius a...@gentoo.org wrote: When the user has their tree up to how they want it, they can either send a pull request to another gentoo dev who also has a fork on github, or send a link to the commit via some medium ( bug tracker ? ) , and some dev can just add that as a remote, and merge/cherry-pick the commits they want.. ...is this something we (as the developer base) WANT non-dev's to be able to do?? I would expect we'd want the tree to still be treated as read-only-not-modifyable by the rest of the gentoo/linux community, otherwise we're going to have a rather large mess on our hands (multiple forks of the main tree != a uniform main tree + overlays, the way it does now) That's only a problem if you don't merge things quickly. Encouraging users to submit git format-patches or merge requests is a great way of reducing developer workload. - -- Ciaran McCreesh -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAk++eQMACgkQ96zL6DUtXhF4kgCfZkdR7RTvUUlFdTgdNkyDHwGK NlgAoKgSUKEWN6WnrihawHkhhrPbJlv2 =8RdD -END PGP SIGNATURE-
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
...is this something we (as the developer base) WANT non-dev's to be able to do?? I would expect we'd want the tree to still be treated as read-only-not-modifyable by the rest of the gentoo/linux community, otherwise we're going to have a rather large mess on our hands (multiple forks of the main tree != a uniform main tree + overlays, the way it does now) Yes, we want them to. There is still going to be a master authoritative tree, forks of that tree will exist for the purpose of adding new ebuilds to the master tree / bumping existing packages. If your worry is There are copies of gentoo /usr/portage out there that aren't GIT HEAD , then stop worrying, as thats already the case. As soon as somebody modifies a file in their local /usr/portage, that happens, and as soon as a users portage tree gets older than 1 hour, that happens. And if your worry is But they could be replicating it in that form, then don't worry, they could already be doing that, nothing is stopping people from re-providing their full (tweaked) /usr/portage via rsync to others. In fact, if you're running in a network with a network master, you're doing that to an extent. But those sources are not official, and have no utility outside development/private use scenarios, and thus, don't compete with overlays directly. Sure, you *could* make something like an overlay by forking gentoo master and then maintaining that, but it would be impractical, and you'd be better off using a plain overlay ( less noise ), or using that fork for the purpose of getting things in master. You /could/ do a long-lived public maintained fork, and then you'd be Sabyon / Funtoo. Doing this has its own difficulties, but I think long term, enabling this is good: Sabyon/Funtoo can fork gentoo on github, and then any improvements made on their forks, gentoo can easily steal back, and its easier to track the differences between them. Win/Win in my books. Summarised: Yes, its a good idea. No, we shouldn't try stopping them. Actually, really can't stop them, its already happening, Git will just make the workflow better on top of it. -- Kent perl -e print substr( \edrgmaM SPA NOcomil.ic\\@tfrken\, \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 ); http://kent-fredric.fox.geek.nz
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 05/24/2012 06:52 PM, Ian Stakenvicius wrote: On 24/05/12 01:13 PM, Kent Fredric wrote: On 25 May 2012 03:02, Ralph Sennhauser s...@gentoo.org wrote: On Thu, 24 May 2012 16:40:02 +0200 Michał Górny mgo...@gentoo.org wrote: d) Talk with github folks to add our repo as 'mirror'. Can we keep the master on Gentoo hardware please. Definitely. But having a mirror on github will increase forkability, and will make it much faster for people to get started on contribution. When the user has their tree up to how they want it, they can either send a pull request to another gentoo dev who also has a fork on github, or send a link to the commit via some medium ( bug tracker ? ) , and some dev can just add that as a remote, and merge/cherry-pick the commits they want.. ...is this something we (as the developer base) WANT non-dev's to be able to do?? I would expect we'd want the tree to still be treated as read-only-not-modifyable by the rest of the gentoo/linux community, otherwise we're going to have a rather large mess on our hands (multiple forks of the main tree != a uniform main tree + overlays, the way it does now) Why do you care? If someone uses a forked tree then he and his users are on their own. However, I would like to have the ability to accept pull requests from users and then push my local tree back to the official one. - -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBCgAGBQJPvn8KAAoJEPqDWhW0r/LCjVMP/jdZ+f96hx3zF25XIfn5xKdg jsPO1kQ7KLMLFg+ZxhDMYo/ORbbOuuqtyBA9pnoDYgSB9xSQ5ETIemsyoL6MHMmj 7DGyUkd0HUFIROjaEDCD0BipPyY5Cpj/D2Ep9br0o4mfXTi2qVg5sE8qVsjguVf5 3tZ1GEm8w4k8UIj39pICX5o9X35nTlG6gkQh2cy6ZO3+MHBmyt3WOzmRczrW4bgX kcMprYYdqoHd/VcC4LJoKMO8ALlX7UdsU2Yoe68ImKvdSdhxdqla9qPqUmf2kqqE DYZoYnu1+NI5CtN2d30Ut0ewUqP/9/kKb0Gx/QKZkD9DR+jAv75O0M/PM3MpVP/P wxUVRzmv48WNXJmahqiv1fiBbWR4Al5KXIfk8g49oPxNjDFb00ij0G0YSxfbvbih kEZl24hiqumO+oLdJOGhQTbeFDDDtnJuT8Ft9914FW77dWt9M/B61udlaS5B4E41 rgP5kHVb3wmbPcS8uc8YklceJfog3FVUzghTzH9swz9umSSmO1B6JGOVKFBuyTCY MNGn9Oz+n/Vklbg63br4AIsyokpTbGx3coeTJzQ3Jry97l5L3+TlJFqk9I644cIs cqsh575aAlHyakvZfWdIgbBschcsRWTRuzaZAeTW4qnMMVhMn19nTkgoSCyu2PEp Qq32ezdYxEpv4a3X40M6 =m1ok -END PGP SIGNATURE-
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
On Thursday, May 24, 2012 01:52:32 PM Ian Stakenvicius wrote: On 24/05/12 01:13 PM, Kent Fredric wrote: On 25 May 2012 03:02, Ralph Sennhauser s...@gentoo.org wrote: On Thu, 24 May 2012 16:40:02 +0200 Michał Górny mgo...@gentoo.org wrote: d) Talk with github folks to add our repo as 'mirror'. Can we keep the master on Gentoo hardware please. Definitely. But having a mirror on github will increase forkability, and will make it much faster for people to get started on contribution. When the user has their tree up to how they want it, they can either send a pull request to another gentoo dev who also has a fork on github, or send a link to the commit via some medium ( bug tracker ? ) , and some dev can just add that as a remote, and merge/cherry-pick the commits they want.. ...is this something we (as the developer base) WANT non-dev's to be able to do?? I would expect we'd want the tree to still be treated as read-only-not-modifyable by the rest of the gentoo/linux community, Of course it's read only - just like all other public repositories. You don't want to accept improvments? I don't understand this. otherwise we're going to have a rather large mess on our hands (multiple forks of the main tree != a uniform main tree + overlays, the way it does now) Forking happens when it's hard to contribute. You even want to make overlays difficult? The only real mechanism Gentoo provides for user extensibility? -- Dan Douglas signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
Am Mittwoch, 23. Mai 2012, 18:33:41 schrieb Michał Górny: On Wed, 23 May 2012 14:42:37 +0200 Michael Weber x...@gentoo.org wrote: *if you still read this* *wow* Please discuss my arguments and come to the conclusions to RESO/WONT-FIX testing git-cvsserver, make a clean cut and remove this bug from the blockers of [TRACKER] portage migration to git. Kill it! And while we're at it, kill ChangeLogs as well! /me hides... with git log some-cat/foo we will have it automagically. -- 0x35A64134 - 8AAC 5F46 83B4 DB70 8317 3723 296C 6CCA 35A6 4134 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
On 24/05/12 02:37 PM, Dan Douglas wrote: On Thursday, May 24, 2012 01:52:32 PM Ian Stakenvicius wrote: Of course it's read only - just like all other public repositories. You don't want to accept improvments? I don't understand this. I have no problem with accepting improvements, i'm just leary of semi-official copies of the tree that could be checked out and checked into by non-dev's (this said, I don't know that much about git but I assume that github users could commit to the github copy yes? that being the way users would contribute?) otherwise we're going to have a rather large mess on our hands (multiple forks of the main tree != a uniform main tree + overlays, the way it does now) Forking happens when it's hard to contribute. You even want to make overlays difficult? The only real mechanism Gentoo provides for user extensibility? Nono, I was comparing the (from my perspective) mess of multiple forks of the main tree that hosting on github/other services could potentially enable, with a single uniform source of the main tree plus overlays for extended contribution (which is the system we have now). Git is about decentralized version control. When you clone a repo, you have your own fork. When everyone has their own branch, everyone is effectively equal. So yes you can expect much much more forking. In Git land, forks are good. There's no way to enforce that people only pull from some official source. It works out in practice so that 99% of the time people only care about a couple branches of one repository. Counterintuitively, this comes as a side- effect of git actually doing distribution properly and making it easier for everybody's workflow. The overlay model by contrast is quite broken on its own and virtually forces creation of new overlays in order to make changes without the benifits of version control (with regards to the rsync tree at least). What Github does is facilitate making it easy to fork/branch and provide a central way to push changes back into a remote through pull requests. Pull requests and other web services around git hosting are pretty much the thing that makes github worth using. From the standpoint of accepting patches, the differenc e to you is rather than (or in addition to) accepting patches through bugzilla, you can choose to accept a push directly from someone else's copy of the repo. It isn't like a wiki - everybody commits to their own repositories and pushing to a remote is on a whitelist basis just like in centralized version control. Anyway, others are better at selling Git than I and there are no shortage of resources out there describing distributed development models. I think this thread is supposed to be about the technical hurdles and it looks like whether or not it's feasible to support github. I can't really comment on the latter. Aside from whatever hoops the Gentoo devs have to jump through in trying to maintain multiple repos, it's hard to see the downsides to using github in and of itself. Talk to the Gentoo Haskell guys, they've been using Github for some time. And if memory serves, KDE used to be on Github or Gitorious before moving to o.g.o -- Dan Douglas signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
On Thu, May 24, 2012 at 5:32 PM, Rich Freeman ri...@gentoo.org wrote: On Thu, May 24, 2012 at 11:02 AM, Ralph Sennhauser s...@gentoo.org wrote: Can we keep the master on Gentoo hardware please. Also, there still should be a bug at b.g.o and git format-patch works just fine for that. Maybe it's only github now but how many places is a developer supposed to monitor? I'm actually a little torn on this one. I'm fine with keeping the master on Gentoo in the sense that this is where the rsync tree gets generated. However, gitbub has a lot of tools like pull requests that could potentially improve workflow, especially for things like proxy maintainers. So, letting those teams work more outside of Gentoo and just push their changes into Gentoo might make sense. So I'm a bit confused. Is GitHub open source? Perhaps github should be viewed as a widely-shared overlay that gets automatic updates from the main tree in the master branch (or whatever we call it). You can work on a branch in github, get it where you want it to be, and then push it to Gentoo pretty easily. When I don't have access to an upstream repository I often just push a copy to a fork on Github just to make my own life easier. Rich
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
On 25 May 2012 13:21, Alec Warner anta...@gentoo.org wrote: So I'm a bit confused. Is GitHub open source? Your confusion begets more confusion: Whether or not Github is open-source seems orthogonal to whether or not we use it, as github is a website, a service, and there are a few such websites, of which, github appears to be the defacto most-popular one. -- Kent perl -e print substr( \edrgmaM SPA NOcomil.ic\\@tfrken\, \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 ); http://kent-fredric.fox.geek.nz
[gentoo-dev] Portage Git migration - clean cut or git-cvsserver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, i've looked at the blockers of [TRACKER] portage migration to git [1] and want to discuss testing git-cvsserver [2]. There are two proposed scenarios how to migrate the developers write access to the portage tree. Clean cut turns of cvs access on a given and announced timestamp, rsync-generation/updates is suspended (no input - no changes), some magic scripts prepare the git repo (according to [3], some hours duration) and we all checkout the tree (might be some funny massive load). testing git-cvsserver proses Clean cut with the additional ability to continue using cvs update/commit, - in best case - on the old checkout w/o alteration on the developers side. Clean cut forces us to clean up out dirty checkouts (I have some added directories, added ebuilds i hesitated to `repoman commit`). Plus we have to alter all our hot-wired portage mangling scripts from cvs'ish to git'ish (I use my read/write checkout as portage tree (cvs checkout + egencache for checkout) and have an automated google-chrome bump script). But this can be accomplished on a per developer basis, and slackers don't stall the process. testing git-cvsserver forces us all to test these cvs'ish scripts and behaviours against a git-cvsserver and report. We all know that this test-runs will never happen, stalling this bug till infinity. Plus infra/subset of devs marshalling the migration get stuck between fixing git issues and git-cvsserver. *if you still read this* *wow* Please discuss my arguments and come to the conclusions to RESO/WONT-FIX testing git-cvsserver, make a clean cut and remove this bug from the blockers of [TRACKER] portage migration to git. My lengthy 2 cents. [1] https://bugs.gentoo.org/333531 [2] https://bugs.gentoo.org/333699 [3] https://bugs.gentoo.org/333705#c2 - -- Gentoo Dev http://xmw.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk+82z0ACgkQknrdDGLu8JBUWAD/dmuqyES/mYDrMam+/txnHmgd VaQaqwHMlwzzqQwbpY4A/0h+5Vp8sLbOE78k4SCaGE2dCQtmeOz0jd1YxkDzP+YW =jXLQ -END PGP SIGNATURE-
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
Am Mittwoch 23 Mai 2012, 14:42:37 schrieb Michael Weber: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, i've looked at the blockers of [TRACKER] portage migration to git [1] and want to discuss testing git-cvsserver [2]. There are two proposed scenarios how to migrate the developers write access to the portage tree. Clean cut turns of cvs access on a given and announced timestamp, rsync-generation/updates is suspended (no input - no changes), some magic scripts prepare the git repo (according to [3], some hours duration) and we all checkout the tree (might be some funny massive load). testing git-cvsserver proses Clean cut with the additional ability to continue using cvs update/commit, - in best case - on the old checkout w/o alteration on the developers side. Clean cut forces us to clean up out dirty checkouts (I have some added directories, added ebuilds i hesitated to `repoman commit`). Plus we have to alter all our hot-wired portage mangling scripts from cvs'ish to git'ish (I use my read/write checkout as portage tree (cvs checkout + egencache for checkout) and have an automated google-chrome bump script). But this can be accomplished on a per developer basis, and slackers don't stall the process. testing git-cvsserver forces us all to test these cvs'ish scripts and behaviours against a git-cvsserver and report. We all know that this test-runs will never happen, stalling this bug till infinity. Plus infra/subset of devs marshalling the migration get stuck between fixing git issues and git-cvsserver. *if you still read this* *wow* Please discuss my arguments and come to the conclusions to RESO/WONT-FIX testing git-cvsserver, make a clean cut and remove this bug from the blockers of [TRACKER] portage migration to git. My lengthy 2 cents. [1] https://bugs.gentoo.org/333531 [2] https://bugs.gentoo.org/333699 [3] https://bugs.gentoo.org/333705#c2 - -- Gentoo Dev http://xmw.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk+82z0ACgkQknrdDGLu8JBUWAD/dmuqyES/mYDrMam+/txnHmgd VaQaqwHMlwzzqQwbpY4A/0h+5Vp8sLbOE78k4SCaGE2dCQtmeOz0jd1YxkDzP+YW =jXLQ -END PGP SIGNATURE- I support RESOLUTION WONTFIX, if nobody cares about the bug since it was opened it is obvious out of interest. There is no reason to support jurassic software. Clean cut++ Cheers -- Johannes Huber (johu) Gentoo Linux Developer / KDE Team GPG Key ID F3CFD2BD signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
On May 23, 2012 1:55 PM, Johannes Huber j...@gentoo.org wrote: Am Mittwoch 23 Mai 2012, 14:42:37 schrieb Michael Weber: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, i've looked at the blockers of [TRACKER] portage migration to git [1] and want to discuss testing git-cvsserver [2]. There are two proposed scenarios how to migrate the developers write access to the portage tree. Clean cut turns of cvs access on a given and announced timestamp, rsync-generation/updates is suspended (no input - no changes), some magic scripts prepare the git repo (according to [3], some hours duration) and we all checkout the tree (might be some funny massive load). testing git-cvsserver proses Clean cut with the additional ability to continue using cvs update/commit, - in best case - on the old checkout w/o alteration on the developers side. Clean cut forces us to clean up out dirty checkouts (I have some added directories, added ebuilds i hesitated to `repoman commit`). Plus we have to alter all our hot-wired portage mangling scripts from cvs'ish to git'ish (I use my read/write checkout as portage tree (cvs checkout + egencache for checkout) and have an automated google-chrome bump script). But this can be accomplished on a per developer basis, and slackers don't stall the process. testing git-cvsserver forces us all to test these cvs'ish scripts and behaviours against a git-cvsserver and report. We all know that this test-runs will never happen, stalling this bug till infinity. Plus infra/subset of devs marshalling the migration get stuck between fixing git issues and git-cvsserver. *if you still read this* *wow* Please discuss my arguments and come to the conclusions to RESO/WONT-FIX testing git-cvsserver, make a clean cut and remove this bug from the blockers of [TRACKER] portage migration to git. My lengthy 2 cents. [1] https://bugs.gentoo.org/333531 [2] https://bugs.gentoo.org/333699 [3] https://bugs.gentoo.org/333705#c2 - -- Gentoo Dev http://xmw.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk+82z0ACgkQknrdDGLu8JBUWAD/dmuqyES/mYDrMam+/txnHmgd VaQaqwHMlwzzqQwbpY4A/0h+5Vp8sLbOE78k4SCaGE2dCQtmeOz0jd1YxkDzP+YW =jXLQ -END PGP SIGNATURE- I support RESOLUTION WONTFIX, if nobody cares about the bug since it was opened it is obvious out of interest. There is no reason to support jurassic software. Clean cut++ Cheers -- Johannes Huber (johu) Gentoo Linux Developer / KDE Team GPG Key ID F3CFD2BD Another vote for clean cut from me.
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
Please discuss my arguments and come to the conclusions to RESO/WONT-FIX testing git-cvsserver, make a clean cut and remove this bug from the blockers of [TRACKER] portage migration to git. +1 Please cut cvs support once and for all. -- Andreas K. Huettel Gentoo Linux developer kde, sci, arm, tex, printing signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/23/2012 09:25 AM, Andreas K. Huettel wrote: Please discuss my arguments and come to the conclusions to RESO/WONT-FIX testing git-cvsserver, make a clean cut and remove this bug from the blockers of [TRACKER] portage migration to git. +1 Please cut cvs support once and for all. +1 for clean cut -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk+85e4ACgkQVxOqA9G7/aDWpgD/SYfC3aOlOP2kAwK3qt81smH8 YWs60Kl77Xx+wIM1jx8A/0PkisxPTsLE5jR59GhaDmC+epoodW1GOak//pAvCmCG =F8Rw -END PGP SIGNATURE-
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
On 05/23/2012 07:54 AM, Johannes Huber wrote: Am Mittwoch 23 Mai 2012, 14:42:37 schrieb Michael Weber: Hi, i've looked at the blockers of [TRACKER] portage migration to git [1] and want to discuss testing git-cvsserver [2]. There are two proposed scenarios how to migrate the developers write access to the portage tree. Clean cut turns of cvs access on a given and announced timestamp, rsync-generation/updates is suspended (no input - no changes), some magic scripts prepare the git repo (according to [3], some hours duration) and we all checkout the tree (might be some funny massive load). testing git-cvsserver proses Clean cut with the additional ability to continue using cvs update/commit, - in best case - on the old checkout w/o alteration on the developers side. Clean cut forces us to clean up out dirty checkouts (I have some added directories, added ebuilds i hesitated to `repoman commit`). Plus we have to alter all our hot-wired portage mangling scripts from cvs'ish to git'ish (I use my read/write checkout as portage tree (cvs checkout + egencache for checkout) and have an automated google-chrome bump script). But this can be accomplished on a per developer basis, and slackers don't stall the process. testing git-cvsserver forces us all to test these cvs'ish scripts and behaviours against a git-cvsserver and report. We all know that this test-runs will never happen, stalling this bug till infinity. Plus infra/subset of devs marshalling the migration get stuck between fixing git issues and git-cvsserver. *if you still read this* *wow* Please discuss my arguments and come to the conclusions to RESO/WONT-FIX testing git-cvsserver, make a clean cut and remove this bug from the blockers of [TRACKER] portage migration to git. My lengthy 2 cents. [1] https://bugs.gentoo.org/333531 [2] https://bugs.gentoo.org/333699 [3] https://bugs.gentoo.org/333705#c2 I support RESOLUTION WONTFIX, if nobody cares about the bug since it was opened it is obvious out of interest. There is no reason to support jurassic software. Clean cut++ Cheers clean-cut++ -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
Please kill CVS with fire! I've been waiting for this since 2009. -- Fabio Erculiani
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
+1 for killing cvs Johannes Huber писал 2012-05-23 15:54: Am Mittwoch 23 Mai 2012, 14:42:37 schrieb Michael Weber: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, i've looked at the blockers of [TRACKER] portage migration to git [1] and want to discuss testing git-cvsserver [2]. There are two proposed scenarios how to migrate the developers write access to the portage tree. Clean cut turns of cvs access on a given and announced timestamp, rsync-generation/updates is suspended (no input - no changes), some magic scripts prepare the git repo (according to [3], some hours duration) and we all checkout the tree (might be some funny massive load). testing git-cvsserver proses Clean cut with the additional ability to continue using cvs update/commit, - in best case - on the old checkout w/o alteration on the developers side. Clean cut forces us to clean up out dirty checkouts (I have some added directories, added ebuilds i hesitated to `repoman commit`). Plus we have to alter all our hot-wired portage mangling scripts from cvs'ish to git'ish (I use my read/write checkout as portage tree (cvs checkout + egencache for checkout) and have an automated google-chrome bump script). But this can be accomplished on a per developer basis, and slackers don't stall the process. testing git-cvsserver forces us all to test these cvs'ish scripts and behaviours against a git-cvsserver and report. We all know that this test-runs will never happen, stalling this bug till infinity. Plus infra/subset of devs marshalling the migration get stuck between fixing git issues and git-cvsserver. *if you still read this* *wow* Please discuss my arguments and come to the conclusions to RESO/WONT-FIX testing git-cvsserver, make a clean cut and remove this bug from the blockers of [TRACKER] portage migration to git. My lengthy 2 cents. [1] https://bugs.gentoo.org/333531 [2] https://bugs.gentoo.org/333699 [3] https://bugs.gentoo.org/333705#c2 - -- Gentoo Dev http://xmw.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk+82z0ACgkQknrdDGLu8JBUWAD/dmuqyES/mYDrMam+/txnHmgd VaQaqwHMlwzzqQwbpY4A/0h+5Vp8sLbOE78k4SCaGE2dCQtmeOz0jd1YxkDzP+YW =jXLQ -END PGP SIGNATURE- I support RESOLUTION WONTFIX, if nobody cares about the bug since it was opened it is obvious out of interest. There is no reason to support jurassic software. Clean cut++ Cheers -- Best Regards, Alexey 'Alexxy' Shvetsov Petersburg Nuclear Physics Institute, NRC Kurchatov Institute, Gatchina, Russia Department of Molecular and Radiation Biophysics Gentoo Team Ru Gentoo Linux Dev mailto:alexx...@gmail.com mailto:ale...@gentoo.org mailto:ale...@omrb.pnpi.spb.ru
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
On 05/23/2012 10:39 AM, Alexey Shvetsov wrote: +1 for killing cvs Looks like the bloodbath begins. I too am in favor of killing cvs. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 8040 5A4D 8709 21B1 1A88 33CE 979C AF40 D045 5535 GnuPG ID : D0455535
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
On 23/05/12 14:42, Michael Weber wrote: Hi, i've looked at the blockers of [TRACKER] portage migration to git [1] and want to discuss testing git-cvsserver [2]. There are two proposed scenarios how to migrate the developers write access to the portage tree. Clean cut turns of cvs access on a given and announced timestamp, I want to see to it gone. +1 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 +1 for git switch. git-cvsserver would make sense if it would be completely transparent for cvs client. and it's not. so why bother setuping fragile things? - -- Sergei -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iEYEARECAAYFAk+9ETgACgkQcaHudmEf86pHTgCgh0lWhRz5VAf0N9xRPOE4gld3 IXIAn1Q9q7BSaIGZpiUHgATng2rBVBWZ =vbwK -END PGP SIGNATURE-
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
On Wed, 23 May 2012 14:42:37 +0200 Michael Weber x...@gentoo.org wrote: *if you still read this* *wow* Please discuss my arguments and come to the conclusions to RESO/WONT-FIX testing git-cvsserver, make a clean cut and remove this bug from the blockers of [TRACKER] portage migration to git. Kill it! And while we're at it, kill ChangeLogs as well! /me hides... -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
On Wed, May 23, 2012 at 10:43 AM, Anthony G. Basile bluen...@gentoo.org wrote: Looks like the bloodbath begins. I too am in favor of killing cvs. Please, let it die. I'll miss my scripts, but I'll gladly deal with that over whatever breakage comes along every time some cvs plugin messes up the tree, or we can't use some useful git feature because cvs amazingly enough behaves like an scm invented 20 years ago. Rich
Re: Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
On Wed, 23 May 2012 14:42:37 +0200 Kill it! And while we're at it, kill ChangeLogs as well! /me hides... +1 +1 +1 +1 ... -- Andreas K. Huettel Gentoo Linux developer kde, sci, arm, tex, printing signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
Michał Górny писал 2012-05-23 19:33: On Wed, 23 May 2012 14:42:37 +0200 Michael Weber x...@gentoo.org wrote: *if you still read this* *wow* Please discuss my arguments and come to the conclusions to RESO/WONT-FIX testing git-cvsserver, make a clean cut and remove this bug from the blockers of [TRACKER] portage migration to git. Kill it! And while we're at it, kill ChangeLogs as well! /me hides... Well this can be done with *meaningfull* git commit messages =D so +1 -- Best Regards, Alexey 'Alexxy' Shvetsov Petersburg Nuclear Physics Institute, NRC Kurchatov Institute, Gatchina, Russia Department of Molecular and Radiation Biophysics Gentoo Team Ru Gentoo Linux Dev mailto:alexx...@gmail.com mailto:ale...@gentoo.org mailto:ale...@omrb.pnpi.spb.ru
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
On Wed, May 23, 2012 at 02:42:37PM +0200, Michael Weber wrote: i've looked at the blockers of [TRACKER] portage migration to git [1] and want to discuss testing git-cvsserver [2]. There are two proposed scenarios how to migrate the developers write access to the portage tree. The primary reasons to continue to support CVS-style access via git-cvsserver: 1. Lightweight partial/subtree checkouts - Git has implemented subtree checkouts, but they still bring down a fairly large packfile. 2. Arches were Git repos are too heavy (Kumba wanted this for MIPS) If we can get rid of #2, we're willing to live with #1. Clean cut turns of cvs access on a given and announced timestamp, rsync-generation/updates is suspended (no input - no changes), some magic scripts prepare the git repo (according to [3], some hours duration) and we all checkout the tree (might be some funny massive load). 1. You will be given git bundles instead of being allowed to do initial clone. That way it's just a resumable HTTP download. 2. rsync generation is NOT going away. Users will still be using it. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
Robin H. Johnson писал 2012-05-23 19:47: On Wed, May 23, 2012 at 02:42:37PM +0200, Michael Weber wrote: i've looked at the blockers of [TRACKER] portage migration to git [1] and want to discuss testing git-cvsserver [2]. There are two proposed scenarios how to migrate the developers write access to the portage tree. The primary reasons to continue to support CVS-style access via git-cvsserver: 1. Lightweight partial/subtree checkouts - Git has implemented subtree checkouts, but they still bring down a fairly large packfile. 2. Arches were Git repos are too heavy (Kumba wanted this for MIPS) Isnt git works with shallow clone? like # git clone --depth 1 or any other desired value git+ssh://gitrepo.uri::repo So you can clone in this manner and push changes back Also for depth = 1 pack size will be similar to gzipped rsync snapshot (~40M) If we can get rid of #2, we're willing to live with #1. Clean cut turns of cvs access on a given and announced timestamp, rsync-generation/updates is suspended (no input - no changes), some magic scripts prepare the git repo (according to [3], some hours duration) and we all checkout the tree (might be some funny massive load). 1. You will be given git bundles instead of being allowed to do initial clone. That way it's just a resumable HTTP download. 2. rsync generation is NOT going away. Users will still be using it. -- Best Regards, Alexey 'Alexxy' Shvetsov Petersburg Nuclear Physics Institute, NRC Kurchatov Institute, Gatchina, Russia Department of Molecular and Radiation Biophysics Gentoo Team Ru Gentoo Linux Dev mailto:alexx...@gmail.com mailto:ale...@gentoo.org mailto:ale...@omrb.pnpi.spb.ru
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
On 23.05.2012 18:47, Robin H. Johnson wrote: On Wed, May 23, 2012 at 02:42:37PM +0200, Michael Weber wrote: i've looked at the blockers of [TRACKER] portage migration to git [1] and want to discuss testing git-cvsserver [2]. There are two proposed scenarios how to migrate the developers write access to the portage tree. The primary reasons to continue to support CVS-style access via git-cvsserver: 1. Lightweight partial/subtree checkouts - Git has implemented subtree checkouts, but they still bring down a fairly large packfile. 2. Arches were Git repos are too heavy (Kumba wanted this for MIPS) If we can get rid of #2, we're willing to live with #1. Clean cut turns of cvs access on a given and announced timestamp, rsync-generation/updates is suspended (no input - no changes), some magic scripts prepare the git repo (according to [3], some hours duration) and we all checkout the tree (might be some funny massive load). 1. You will be given git bundles instead of being allowed to do initial clone. That way it's just a resumable HTTP download. 2. rsync generation is NOT going away. Users will still be using it. Was this a vote for or against a quick proceeding towards git? You are probably the one who can judge best if the infra side could be made ready soonish. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
On Wed, May 23, 2012 at 12:47 PM, Robin H. Johnson robb...@gentoo.org wrote: 2. Arches were Git repos are too heavy (Kumba wanted this for MIPS) Please don't go to this trouble for the ability to commit to portage on *really* slow systems.
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
Matt Turner писал 2012-05-23 19:59: On Wed, May 23, 2012 at 12:47 PM, Robin H. Johnson robb...@gentoo.org wrote: 2. Arches were Git repos are too heavy (Kumba wanted this for MIPS) Please don't go to this trouble for the ability to commit to portage on *really* slow systems. Isnt cvs too sloow on mips? git is much more faster. Same for arm. About big repos, well why not use shallow cloned repo. It will work with plane history -- Best Regards, Alexey 'Alexxy' Shvetsov Petersburg Nuclear Physics Institute, NRC Kurchatov Institute, Gatchina, Russia Department of Molecular and Radiation Biophysics Gentoo Team Ru Gentoo Linux Dev mailto:alexx...@gmail.com mailto:ale...@gentoo.org mailto:ale...@omrb.pnpi.spb.ru
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
Robin H. Johnson писал 2012-05-23 19:47: On Wed, May 23, 2012 at 02:42:37PM +0200, Michael Weber wrote: i've looked at the blockers of [TRACKER] portage migration to git [1] and want to discuss testing git-cvsserver [2]. There are two proposed scenarios how to migrate the developers write access to the portage tree. The primary reasons to continue to support CVS-style access via git-cvsserver: 1. Lightweight partial/subtree checkouts - Git has implemented subtree checkouts, but they still bring down a fairly large packfile. 2. Arches were Git repos are too heavy (Kumba wanted this for MIPS) If we can get rid of #2, we're willing to live with #1. Clean cut turns of cvs access on a given and announced timestamp, rsync-generation/updates is suspended (no input - no changes), some magic scripts prepare the git repo (according to [3], some hours duration) and we all checkout the tree (might be some funny massive load). 1. You will be given git bundles instead of being allowed to do initial clone. That way it's just a resumable HTTP download. 2. rsync generation is NOT going away. Users will still be using it. Another good point for repo size https://git.wiki.kernel.org/index.php/GitFaq#How_do_I_use_git_for_large_projects.2C_where_the_repository_is_large.2C_say_approaching_1_TB.2C_but_a_checkout_is_only_a_few_hundred_MB.3F_Will_every_developer_need_1_TB_of_local_disk_space.3F -- Best Regards, Alexey 'Alexxy' Shvetsov Petersburg Nuclear Physics Institute, NRC Kurchatov Institute, Gatchina, Russia Department of Molecular and Radiation Biophysics Gentoo Team Ru Gentoo Linux Dev mailto:alexx...@gmail.com mailto:ale...@gentoo.org mailto:ale...@omrb.pnpi.spb.ru
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
On Wed, May 23, 2012 at 07:58:17PM +0300, Alexey Shvetsov wrote: Isnt git works with shallow clone? like # git clone --depth 1 or any other desired value git+ssh://gitrepo.uri::repo So you can clone in this manner and push changes back Also for depth = 1 pack size will be similar to gzipped rsync snapshot (~40M) The shallow clone is still a shallow clone of the entire repo, and you get the subtree checkout as just part of that. Shallow clones are also read-only last I checked. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
Robin H. Johnson писал 2012-05-23 20:19: On Wed, May 23, 2012 at 07:58:17PM +0300, Alexey Shvetsov wrote: Isnt git works with shallow clone? like # git clone --depth 1 or any other desired value git+ssh://gitrepo.uri::repo So you can clone in this manner and push changes back Also for depth = 1 pack size will be similar to gzipped rsync snapshot (~40M) The shallow clone is still a shallow clone of the entire repo, and you get the subtree checkout as just part of that. Shallow clones are also read-only last I checked. That isnt true =) you can commit from shallow clone if and only if original repo doesnt have a branching and merging points before and after shallow clone point respectively -- Best Regards, Alexey 'Alexxy' Shvetsov Petersburg Nuclear Physics Institute, NRC Kurchatov Institute, Gatchina, Russia Department of Molecular and Radiation Biophysics Gentoo Team Ru Gentoo Linux Dev mailto:alexx...@gmail.com mailto:ale...@gentoo.org mailto:ale...@omrb.pnpi.spb.ru
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
On Wed, May 23, 2012 at 1:22 PM, Alexey Shvetsov ale...@gentoo.org wrote: That isnt true =) you can commit from shallow clone if and only if original repo doesnt have a branching and merging points before and after shallow clone point respectively Is that going to be a practical condition to maintain? And how big will the repository actually be? Are we talking a GB or two, or something orders of magnitude larger? Rich
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
Rich Freeman писал 2012-05-23 20:32: On Wed, May 23, 2012 at 1:22 PM, Alexey Shvetsov ale...@gentoo.org wrote: That isnt true =) you can commit from shallow clone if and only if original repo doesnt have a branching and merging points before and after shallow clone point respectively Is that going to be a practical condition to maintain? And how big will the repository actually be? Are we talking a GB or two, or something orders of magnitude larger? Rich Full clone will be about 1G or so but no more then 2. If we will drop changelog it will be much smaller -- Best Regards, Alexey 'Alexxy' Shvetsov Petersburg Nuclear Physics Institute, NRC Kurchatov Institute, Gatchina, Russia Department of Molecular and Radiation Biophysics Gentoo Team Ru Gentoo Linux Dev mailto:alexx...@gmail.com mailto:ale...@gentoo.org mailto:ale...@omrb.pnpi.spb.ru
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
On Wed, May 23, 2012 at 01:32:45PM -0400, Rich Freeman wrote: On Wed, May 23, 2012 at 1:22 PM, Alexey Shvetsov ale...@gentoo.org wrote: That isnt true =) you can commit from shallow clone if and only if original repo doesnt have a branching and merging points before and after shallow clone point respectively Is that going to be a practical condition to maintain? We're going to have lots of branches and merges. And how big will the repository actually be? Are we talking a GB or two, or something orders of magnitude larger? In terms of repo size, we were going to be slicing the history into two parts: - fresh start - historical The 'fresh start' is what new commits will go on top of, and ranges 40-120MB depending on what git window compression is used. The historical is ~1.2GB, and if you want a continuous history, you just use graft to merge the two. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
Alexey Shvetsov schrieb: Shallow clones are also read-only last I checked. That isnt true =) you can commit from shallow clone if and only if original repo doesnt have a branching and merging points before and after shallow clone point respectively There can also be breakage when someone reverts a commit that it is not part of your shallow clone's history, and then you pull. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
-1 -- Rafael Goncalves Martins Gentoo Linux developer http://rafaelmartins.eng.br/
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
I, for one, think we should stay with CVS and leave all this git Linusware to the new-fangled Fedora kids with their fancy init systems and tight coupling. CVS was good enough for my grandfather, and it's good enough for you. -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) (arunsr | GNOME)
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
On Thu, May 24, 2012 at 1:07 AM, Arun Raghavan ford_pref...@gentoo.org wrote: I, for one, think we should stay with CVS and leave all this git Linusware to the new-fangled Fedora kids with their fancy init systems and tight coupling. CVS was good enough for my grandfather, and it's good enough for you. +1 -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
On Wed, May 23, 2012 at 9:37 PM, Arun Raghavan ford_pref...@gentoo.org wrote: I, for one, think we should stay with CVS and leave all this git Linusware to the new-fangled Fedora kids with their fancy init systems and tight coupling. CVS was good enough for my grandfather, and it's good enough for you. The difference is that while Git is much faster, comes with a very low WTF/secs rate and really forces you to do things the right way, other L*e software is not and I agree with you on this. my 0.02c ;-) -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) (arunsr | GNOME) -- Fabio Erculiani
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 +1 for git I am more used to it, I find it easier to use regarding the utilities as well as the gui and it is more consistent. The fact alone that I can update a single directory in CVS without updating all others can cause breakage, cause repoman checks may be erroneous. On 05/23/2012 09:37 PM, Arun Raghavan wrote: I, for one, think we should stay with CVS and leave all this git Linusware to the new-fangled Fedora kids with their fancy init systems and tight coupling. CVS was good enough for my grandfather, and it's good enough for you. This sounds rather emotional to me. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPvT/OAAoJEFpvPKfnPDWzgPIH/38QflM4GNiUNo3bC5/8tock FM03JE1Iln4ThvLl25opwGiO5R8akoD3koroUVPLoWV//QfYmcQIm7k7dJJCk4+m WSQ6H21fL9v2m6QX7PuJwaENFSFBxu3UFy6BE+39iFJAPBiigH1hbE0rad/twYdr xhnHZti1rGbaFBeXxlGmdhJYi7dtndyuZgTu0oQFfE0+sAAK2GPe5CGLoOFHdtxS WCMY3C3cB0R7XPoJwUvvt2KmIEXNWfq6rDW3o6so89VdRSNykwMLdK1eZ+MZidIE 61CAJiuIsT4cKX5pbqo72GtU4tUOkQ6jjaJhofAcrSMYKA0IsxYvFAYnKqO4lh4= =cdBk -END PGP SIGNATURE-
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
On Wed, May 23, 2012 at 4:37 PM, Arun Raghavan ford_pref...@gentoo.org wrote: I, for one, think we should stay with CVS and leave all this git Linusware to the new-fangled Fedora kids with their fancy init systems and tight coupling. CVS was good enough for my grandfather, and it's good enough for you. Perhaps it would be instructive if you could tell us one advantage of cvs over git. (This is me exposing me to your terrible dev-flames, I was feeling too cold ;)
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
Arun Raghavan писал 2012-05-23 22:37: I, for one, think we should stay with CVS and leave all this git Linusware to the new-fangled Fedora kids with their fancy init systems and tight coupling. CVS was good enough for my grandfather, and it's good enough for you. CVS is damn slow. On every cvs up it should stat *all* files and cvs entryes in current state its ~212k files in gentoo-x86. It will be sloow on every machine unless you put all this files in ram Actual number of usefull files is only about ~60k (ebuilds,eclasses,metadata.xml,patches) Its comparable to linux kernel git tree ~42k files And yes git is much more faster. PS if ibm s/360 was good for my grandfather why we all use modern intel pc? Lets stay under 1 MIPS machines like s/360 -- Best Regards, Alexey 'Alexxy' Shvetsov Petersburg Nuclear Physics Institute, NRC Kurchatov Institute, Gatchina, Russia Department of Molecular and Radiation Biophysics Gentoo Team Ru Gentoo Linux Dev mailto:alexx...@gmail.com mailto:ale...@gentoo.org mailto:ale...@omrb.pnpi.spb.ru
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
On Thu, May 24, 2012 at 01:07:08AM +0530, Arun Raghavan wrote: I, for one, think we should stay with CVS and leave all this git Linusware to the new-fangled Fedora kids with their fancy init systems and tight coupling. CVS was good enough for my grandfather, and it's good enough for you. I hope this is sarcasm or a joke? William pgp8HVeq1dZv3.pgp Description: PGP signature
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
On Wed, May 23, 2012 at 4:00 PM, Ezequiel Garcia elezegar...@gmail.com wrote: On Wed, May 23, 2012 at 4:37 PM, Arun Raghavan ford_pref...@gentoo.org wrote: I, for one, think we should stay with CVS and leave all this git Linusware to the new-fangled Fedora kids with their fancy init systems and tight coupling. CVS was good enough for my grandfather, and it's good enough for you. Perhaps it would be instructive if you could tell us one advantage of cvs over git. Sure. The slow commit rate encourages careful deliberation before hitting the enter key, which therefore improves quality. Then, if you do make a mistake the slow commit rate means that fixing that mistake can take a long time, which increases the amount of pain our end-users run into due to the mistake, which leads to lots of flame wars on -dev. That means that the guy who made the mistake is subjected to more public ridicule, and is less likely to do it again, That improves quality too. Since cvs doesn't tie together tree-wide changes in a nice way or allow them to be transactionally completed, individual package maintainers don't need to be as concerned with the big picture view. Now as the maintainer of libfoo the fact that somebody changed my ebuild without making a corresponding change in some profile is completely hidden from me, and I can go to sleep peacefully without realizing that my users are all going to have horribly broken systems in the morning. Blissful ignorance of end-user suffering improves developer morale, and helps get rid of pesky users at the same time. cvs also makes more more aware of what is going on around me. Anytime I want to work on something in parallel with the main development branch I get to manually merge changes in, which keeps me aware of my place in the world. That means that I'm less likely to build nice new features, which means fewer bugs, which improves quality, and may even drive away users as an added bonus! See, cvs is really the wave of the future! Rich
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/23/2012 06:58 PM, Justin wrote: Was this a vote for or against a quick proceeding towards git? No, just to decide if git-cvsserver (providing cvs access) should be part of an git master tree szenario. In bugzie: Should https://bugs.gentoo.org/333699 stay a blocker of https://bugs.gentoo.org/333531. No flame about git over cvs in general, whether or not sparse checkouts (i.e. w/o kde-*,gnome-* categories) make sense. Michael - -- Gentoo Dev http://xmw.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk+9SfMACgkQknrdDGLu8JCGtQEAiS3Wcsll94w2rqlMP2WpSypU fLdxa2wjstJ5Y/2iXCcA+wX/p+OwBzjLAxiwKnSl98XlLSIT/Qsxm5H1TvEEJ71w =k8j9 -END PGP SIGNATURE-
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
On Wed, 23 May 2012 15:25:54 -0500 William Hubbs willi...@gentoo.org wrote: On Thu, May 24, 2012 at 01:07:08AM +0530, Arun Raghavan wrote: I, for one, think we should stay with CVS and leave all this git Linusware to the new-fangled Fedora kids with their fancy init systems and tight coupling. CVS was good enough for my grandfather, and it's good enough for you. I hope this is sarcasm or a joke? Obviously. His grandfather used SCCS. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/23/2012 07:06 PM, Alexey Shvetsov wrote: Isnt cvs too sloow on mips? git is much more faster. Same for arm. About big repos, well why not use shallow cloned repo. It will work with plane history Can we please cut that out. I do/did arch testing on arm5, ppc, sparc on rsync trees and committed the changes from my shiny 2007s notebook. I did hesitate to spread my commit credentials over all these machines. Michael - -- - -- Gentoo Dev http://xmw.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk+9Sv8ACgkQknrdDGLu8JBFLAEAghjKAQwckMndZfO/gGQyVI3N butEASSJZYQetyNthUgA/3e5Sf9B93ED/wDSDflKP7YwTVwiFOe5c65Md4vdEsQs =FW7S -END PGP SIGNATURE-
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
On Wed, May 23, 2012 at 10:37:55PM +0200, Michał Górny wrote: On Wed, 23 May 2012 15:25:54 -0500 William Hubbs willi...@gentoo.org wrote: On Thu, May 24, 2012 at 01:07:08AM +0530, Arun Raghavan wrote: I, for one, think we should stay with CVS and leave all this git Linusware to the new-fangled Fedora kids with their fancy init systems and tight coupling. CVS was good enough for my grandfather, and it's good enough for you. I hope this is sarcasm or a joke? Obviously. His grandfather used SCCS. Heh, that's possible, or maybe he even used prodos [1], which was pretty cool for its time. William [1] http://en.wikipedia.org/wiki/PRODOS pgp4O14kFI8pz.pgp Description: PGP signature
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
On Wednesday, May 23, 2012 04:47:04 PM Robin H. Johnson wrote: 2. rsync generation is NOT going away. Users will still be using it. Would users have a way of gaining read-only access? This would be EXTREMELY helpful. If not I will be leaving Gentoo for Funtoo in the near future, though there are disadvantages to doing this I don't look forward to dealing with. -- Dan Douglas signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/23/2012 11:14 PM, Dan Douglas wrote: On Wednesday, May 23, 2012 04:47:04 PM Robin H. Johnson wrote: 2. rsync generation is NOT going away. Users will still be using it. First, I'd stick with the current rsync to spread the tree (mirror work and mirrors+regular rsync users shouldn't notice any backend switch at all). Would users have a way of gaining read-only access? This would be EXTREMELY helpful. Sure, this would be possible like any other git checkout (layman-git-overlays, github.com, etc.). Please compare (browsing source and access description) http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/ http://git-exp.overlays.gentoo.org/gitweb/?p=exp/gentoo-x86.git - -- Gentoo Dev http://xmw.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk+9W0EACgkQknrdDGLu8JADaQD+KC6cLJ5LqpNrKkNEBT1kAvJW xn+ZcfcMGJzc8GPyQZAA/jKug+5/DlDAHVGBIjAJOi9xf4EFqroL4eyPY8SD2neh =dvFZ -END PGP SIGNATURE-
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
Michael Weber x...@gentoo.org writes: Clean cut turns of cvs access on a given and announced timestamp, rsync-generation/updates is suspended (no input - no changes), some magic scripts prepare the git repo (according to [3], some hours duration) and we all checkout the tree (might be some funny massive load). +1 for clean cut to git
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
On Wed, May 23, 2012 at 3:37 PM, Arun Raghavan ford_pref...@gentoo.org wrote: I, for one, think we should stay with CVS and leave all this git Linusware to the new-fangled Fedora kids with their fancy init systems and tight coupling. CVS was good enough for my grandfather, and it's good enough for you. -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) (arunsr | GNOME) I seriously cannot tell this is serious, trolling, or sarcasm. If it's either of the latter two, can we please cut that out? Way too often sarcasm and inside jokes are misunderstood and we waste a lot of bandwidth figuring it out.
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
On Wed, 23 May 2012 16:14:53 -0500 Dan Douglas orm...@gmail.com wrote: If not I will be leaving Gentoo for Funtoo in the near future, though there are disadvantages to doing this I don't look forward to dealing with. Most of us will probably be doing that :P. -- Best regards, Michał Górny signature.asc Description: PGP signature
