Re: [Fink-devel] github?
On 2012 Jun 22, at 2:35 PM, Hanspeter Niederstrasser wrote: Buildworlds and dist-wide package roundups (like unstable-stable or multi-package dep upgrades) need a lot of overlapping local modifications and VCS-updating steps, and I stopped trying to do local fixes in the only non-Fink git repo I look at, because there simple local fixes kept getting in the way of easily merging upstream changes. Even though git is being sold as a plug-in replacement for cvs, it shouldn't be approached the same. An ideal workflow in git is to immediately create a local branch every time you work on something. You can update the master all you want, and the temporary branch shouldn't need updating unless the master gets a new patch that you want. The biggest difficulty is overcoming old habits... sent from Lion Wash: Here lies my beloved Zoe, my autumn flower ... somewhat less attractive now that she's all corpsified and gross. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] github?
On Jun 24, 2012, at 10:17 AM, David Lowe wrote: On 2012 Jun 22, at 2:35 PM, Hanspeter Niederstrasser wrote: Buildworlds and dist-wide package roundups (like unstable-stable or multi-package dep upgrades) need a lot of overlapping local modifications and VCS-updating steps, and I stopped trying to do local fixes in the only non-Fink git repo I look at, because there simple local fixes kept getting in the way of easily merging upstream changes. Even though git is being sold as a plug-in replacement for cvs, it shouldn't be approached the same. An ideal workflow in git is to immediately create a local branch every time you work on something. You can update the master all you want, and the temporary branch shouldn't need updating unless the master gets a new patch that you want. The biggest difficulty is overcoming old habits… This sounds great for people writing code for fink-the-program, but I'm still trying to understand how we would use git to manage our large collection of fink .info files which make up the various dists directories. The workflow for these has always been that there is a single master repository, all package maintainers are allowed to update their own packages within that master repository, and those changes are immediately propagated to users via the more static rsync selfupdating method. It's as if every update by a package maintainer is supposed to trigger a release, which should include everything from the previous releases as well. How should I be thinking about this workflow in a git context? -- Dave -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] github?
On 6/24/12 10:49 AM, David R. Morrison wrote: On Jun 24, 2012, at 10:17 AM, David Lowe wrote: On 2012 Jun 22, at 2:35 PM, Hanspeter Niederstrasser wrote: Buildworlds and dist-wide package roundups (like unstable-stable or multi-package dep upgrades) need a lot of overlapping local modifications and VCS-updating steps, and I stopped trying to do local fixes in the only non-Fink git repo I look at, because there simple local fixes kept getting in the way of easily merging upstream changes. Even though git is being sold as a plug-in replacement for cvs, it shouldn't be approached the same. An ideal workflow in git is to immediately create a local branch every time you work on something. You can update the master all you want, and the temporary branch shouldn't need updating unless the master gets a new patch that you want. The biggest difficulty is overcoming old habits… This sounds great for people writing code for fink-the-program, but I'm still trying to understand how we would use git to manage our large collection of fink .info files which make up the various dists directories. The workflow for these has always been that there is a single master repository, all package maintainers are allowed to update their own packages within that master repository, and those changes are immediately propagated to users via the more static rsync selfupdating method. It's as if every update by a package maintainer is supposed to trigger a release, which should include everything from the previous releases as well. How should I be thinking about this workflow in a git context? -- Dave One advantage is in handling package submissions. Assuming we don't want everybody to have unfettered access, then there are a couple of workflow options: 1) If a maintainer has a github (or other provider) account, then maintainer can update his packages in his/her own master distribution tree or a public branch, and submit a pull request to get the packages validated upstream (by us). The person doing the validation can get the changed package descriptions more or less automatically by switching their active branch to a copy of the submitter's branch. If the package(s) pass[es] then the changes can be merged or cherry-picked into the master branch, pushed upstream, and available via the next selfupdate. 2) Maintainers without such accounts could diff their changes against the upstream (us) master, and submit a patch (via email or on the tracker). The person who validates the submission can apply the patch straightforwardly. I've been _against_ this option in the past, but there are good number of user-friendly tools to make applying patches and viewing changes less of a chore. 3) Or, a maintainer can do individual .info and .patch files, as we've been handling all along. Another advantage is for power users who like to roll their own options. As David L. mentioned, they can keep their own branch active, but still have easy access to any changes from upstream. (basically making their whole branch into the local tree) -- Alexander Hansen, Ph.D. Fink User Liaison My package updates: http://finkakh.wordpress.com/ -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] github?
On Jun 22, 2012, at 7:03 PM, Alexander Hansen wrote: On 6/22/12 3:23 PM, Max Horn wrote: Am 23.06.2012 um 00:07 schrieb David R. Morrison: On Jun 22, 2012, at 10:59 AM, Alexander Hansen wrote: Any thoughts about moving dists/ over to github? Even though sourceforge isn't going to close down CVS access, it'd be nice to move to a more modern system. Plus, for users behind firewalls, github allows files to be accessed via https--we're doing pretty much the best we can with proxy support for CVS, but sometimes that's still blocked. And for big updates, like a new OS version, I believe it's easier to handle a branch to do changes in git than in CVS (I'm not sure about that, though). This is as good a time as any to think about making such a change, but of course it would take some time to implement (i.e., its not going to be ready for the imminent release of 10.8). The reason I say this is that we would need to write a selfupdate-git function, and work through issues like how it interacts with selfupdate-cvs, whether we are migrating everything or just the most recent tree or trees, etc. etc. Actually, Daniel Johnson has been working on this: https://github.com/danielj7/fink/tree/selfupdate-git. In the end, it's a matter of committment: DO we *want* to switch to this? Does it pay off for Daniel and others to invest blood and tears into it? Because if it's not clear whether this work has a good chance of being merged in the end, then it's a bit difficult to motivate oneself to work on it... My stance is clear on this: I *want* selfupdate-git, and I really want to stop using CVS for anything. The sooner the better. I'll make our life a lot easier. We could bring Daniel's code into a branch of the official fink repository so that it would be more likely to be tested. He's got a github copy of dists/, too, and a script to transfer updates from SF CVS to that. I don't have a script per se, I run git cvsimport -avk -o master to pull in the latest updates, but with carefully chosen default settings. While I am at it, I'd also like to see us switch to the new dpkg / apt etc. ;) I think it was Sjors who worked on that. My understanding is that Justin Hallet is interested in looking at them, too, near-term. In my testing of them, there remained an issue with update-alternatives (that's referenced in my message from yesterday), but I think they would be good to go as updates if that were fixed--or we could try the latest upstream versions, even. At that point we could look into bootstrapping using them. As for whether to host git repositories. on SF.net or github: that's a mostly irrelevant question. We can easily host on both. It's a trivial matter to switch between them. But github offers so many useful features that SF.net misses that it's not even a close contest. Add in the fact that SF.net tends to leave bug reports and feature requests untended for years in a row, then closes them saying we are now deprecating this function etc., makes me not want to host *anything* anymore on SF.net unless I have no other choice. But that's just me. If others want to host git repositories on SF.net (or bitbucket, or gitorious, or Google Code, or on a private server, or, or, or), that's all fine by me -- after all, one of the big advantages of DVCS like git and mercurial is that everybody gets a full copy of the repository; and which repository is the upstream of which other repository is something that can be changed in a blink of an eye ;). Cheers, Max I believe the notion was that once we switched to git (for whatever subset of platforms) we wouldn't continue to support upgrading via CVS at all: basically users would selfupdate, and then Fink::Selfupdate::CVS would tell them that CVS is done and give them a dialog giving them the option to switch to rsync, https, svn or git. (Does that answer the issue of interaction with selfupdate-cvs?) Assuming that we want to do some testing ;-), then what we could do is: 1) Set up an official selfupdate-git branch of fink by importing Daniel's code. 2) Set up a quasi-official dists/ . 3) Assuming that the test period is going to be longer than we'd be willing to freeze distribution updates, set up a cron job on phinch to run Daniel's script or something like it to keep the github dists/ in sync with sf.net CVS so that it stays fresh while we test (e.g. so that selfupdate actually does something). 4) Set an approximate date to convert over to git. 5) Once we're happy with the operation, then we release a fink that enables git and disables cvs. As to what trees to migrate: there would be some utility in _not_ migrating the 10.4 tree. 10.7 is the first OS X version where git ships with Xcode. This was a motivation to provide selfupdate-svn, since svn is available on 10.5 and later. That would entail OS version tests in
Re: [Fink-devel] github?
On 12-06-22 10:59 AM, Alexander Hansen wrote: Any thoughts about moving dists/ over to github? Even though sourceforge isn't going to close down CVS access, it'd be nice to move to a more modern system. Plus, for users behind firewalls, github allows files to be accessed via https--we're doing pretty much the best we can with proxy support for CVS, but sometimes that's still blocked. And for big updates, like a new OS version, I believe it's easier to handle a branch to do changes in git than in CVS (I'm not sure about that, though). sourceforge also supports git FWIW. I think you can enable them in parallel? -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] github?
On 6/22/12 11:45 AM, Brendan Cully wrote: On 12-06-22 10:59 AM, Alexander Hansen wrote: Any thoughts about moving dists/ over to github? Even though sourceforge isn't going to close down CVS access, it'd be nice to move to a more modern system. Plus, for users behind firewalls, github allows files to be accessed via https--we're doing pretty much the best we can with proxy support for CVS, but sometimes that's still blocked. And for big updates, like a new OS version, I believe it's easier to handle a branch to do changes in git than in CVS (I'm not sure about that, though). sourceforge also supports git FWIW. I think you can enable them in parallel? Maybe. My recollection is that reason we were looking at github over sourceforge was that the latter _didn't_ offer access via HTTPS. -- Alexander Hansen, Ph.D. Fink User Liaison My package updates: http://finkakh.wordpress.com/ -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] github?
On 6/22/2012 1:59 PM, Alexander Hansen wrote: Any thoughts about moving dists/ over to github? Even though sourceforge isn't going to close down CVS access, it'd be nice to move to a more modern system. Plus, for users behind firewalls, github allows files to be accessed via https--we're doing pretty much the best we can with proxy support for CVS, but sometimes that's still blocked. And for big updates, like a new OS version, I believe it's easier to handle a branch to do changes in git than in CVS (I'm not sure about that, though). My git knowledge is very limited, but the following situation has arisen several times with the one git repo that I normally play with, and I could see the same issue arise very frequently if dists/ went to git: If I modify a file locally, either as a quick test or because I want to modify something locally longer term but still get updates automatically from upstream as they happen, 'cvs up' has no problems updating the modified file (and keeping my changes) and only complains when my changes directly conflict with the update. In git, however, a single change that is 1000 lines from the pulled updates stops 'git pull', and then I must either branch, stash, commit, or undo my changes before continuing. This makes updating the repo more difficult and much less automatic since I then have to either branch (and merge branches), or stash/update/unstash changes, etc every time there's a pull. Is there a way to work around what seems to me to be a limitation in git? Buildworlds and dist-wide package roundups (like unstable-stable or multi-package dep upgrades) need a lot of overlapping local modifications and VCS-updating steps, and I stopped trying to do local fixes in the only non-Fink git repo I look at, because there simple local fixes kept getting in the way of easily merging upstream changes. Hanspeter -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] github?
On 6/22/12 2:35 PM, Hanspeter Niederstrasser wrote: On 6/22/2012 1:59 PM, Alexander Hansen wrote: Any thoughts about moving dists/ over to github? Even though sourceforge isn't going to close down CVS access, it'd be nice to move to a more modern system. Plus, for users behind firewalls, github allows files to be accessed via https--we're doing pretty much the best we can with proxy support for CVS, but sometimes that's still blocked. And for big updates, like a new OS version, I believe it's easier to handle a branch to do changes in git than in CVS (I'm not sure about that, though). My git knowledge is very limited, but the following situation has arisen several times with the one git repo that I normally play with, and I could see the same issue arise very frequently if dists/ went to git: If I modify a file locally, either as a quick test or because I want to modify something locally longer term but still get updates automatically from upstream as they happen, 'cvs up' has no problems updating the modified file (and keeping my changes) and only complains when my changes directly conflict with the update. In git, however, a single change that is 1000 lines from the pulled updates stops 'git pull', and then I must either branch, stash, commit, or undo my changes before continuing. This makes updating the repo more difficult and much less automatic since I then have to either branch (and merge branches), or stash/update/unstash changes, etc every time there's a pull. Is there a way to work around what seems to me to be a limitation in git? Buildworlds and dist-wide package roundups (like unstable-stable or multi-package dep upgrades) need a lot of overlapping local modifications and VCS-updating steps, and I stopped trying to do local fixes in the only non-Fink git repo I look at, because there simple local fixes kept getting in the way of easily merging upstream changes. Hanspeter Someone else with more expertise may know more than I do here, but one thing to do would be always to make a local-only branch and do your modifications in the branch. I use the SourceTree GUI, and it offers the handy feature of being able to compare any branch against the current active branch, e.g. a local branch vs. a branch tracking upstream's master. You can then run a diff tool (e.g. FileMerge) on the files with differences so that you can try to integrate your changes into files even if they've been changed upstream in ways that make a merge or cherry-pick not workable. Or, if worst comes to worst, you can at least see upstream's changes as well as your own and manually edit the file. Not that this always saves me from breaking stuff. :-) -- Alexander Hansen, Ph.D. Fink User Liaison My package updates: http://finkakh.wordpress.com/ -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] github?
On Jun 22, 2012, at 10:59 AM, Alexander Hansen wrote: Any thoughts about moving dists/ over to github? Even though sourceforge isn't going to close down CVS access, it'd be nice to move to a more modern system. Plus, for users behind firewalls, github allows files to be accessed via https--we're doing pretty much the best we can with proxy support for CVS, but sometimes that's still blocked. And for big updates, like a new OS version, I believe it's easier to handle a branch to do changes in git than in CVS (I'm not sure about that, though). This is as good a time as any to think about making such a change, but of course it would take some time to implement (i.e., its not going to be ready for the imminent release of 10.8). The reason I say this is that we would need to write a selfupdate-git function, and work through issues like how it interacts with selfupdate-cvs, whether we are migrating everything or just the most recent tree or trees, etc. etc. -- Dave -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] github?
Am 23.06.2012 um 00:07 schrieb David R. Morrison: On Jun 22, 2012, at 10:59 AM, Alexander Hansen wrote: Any thoughts about moving dists/ over to github? Even though sourceforge isn't going to close down CVS access, it'd be nice to move to a more modern system. Plus, for users behind firewalls, github allows files to be accessed via https--we're doing pretty much the best we can with proxy support for CVS, but sometimes that's still blocked. And for big updates, like a new OS version, I believe it's easier to handle a branch to do changes in git than in CVS (I'm not sure about that, though). This is as good a time as any to think about making such a change, but of course it would take some time to implement (i.e., its not going to be ready for the imminent release of 10.8). The reason I say this is that we would need to write a selfupdate-git function, and work through issues like how it interacts with selfupdate-cvs, whether we are migrating everything or just the most recent tree or trees, etc. etc. Actually, Daniel Johnson has been working on this: https://github.com/danielj7/fink/tree/selfupdate-git. In the end, it's a matter of committment: DO we *want* to switch to this? Does it pay off for Daniel and others to invest blood and tears into it? Because if it's not clear whether this work has a good chance of being merged in the end, then it's a bit difficult to motivate oneself to work on it... My stance is clear on this: I *want* selfupdate-git, and I really want to stop using CVS for anything. The sooner the better. I'll make our life a lot easier. While I am at it, I'd also like to see us switch to the new dpkg / apt etc. ;) I think it was Sjors who worked on that. As for whether to host git repositories. on SF.net or github: that's a mostly irrelevant question. We can easily host on both. It's a trivial matter to switch between them. But github offers so many useful features that SF.net misses that it's not even a close contest. Add in the fact that SF.net tends to leave bug reports and feature requests untended for years in a row, then closes them saying we are now deprecating this function etc., makes me not want to host *anything* anymore on SF.net unless I have no other choice. But that's just me. If others want to host git repositories on SF.net (or bitbucket, or gitorious, or Google Code, or on a private server, or, or, or), that's all fine by me -- after all, one of the big advantages of DVCS like git and mercurial is that everybody gets a full copy of the repository; and which repository is the upstream of which other repository is something that can be changed in a blink of an eye ;). Cheers, Max -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] github?
On 6/22/12 3:23 PM, Max Horn wrote: Am 23.06.2012 um 00:07 schrieb David R. Morrison: On Jun 22, 2012, at 10:59 AM, Alexander Hansen wrote: Any thoughts about moving dists/ over to github? Even though sourceforge isn't going to close down CVS access, it'd be nice to move to a more modern system. Plus, for users behind firewalls, github allows files to be accessed via https--we're doing pretty much the best we can with proxy support for CVS, but sometimes that's still blocked. And for big updates, like a new OS version, I believe it's easier to handle a branch to do changes in git than in CVS (I'm not sure about that, though). This is as good a time as any to think about making such a change, but of course it would take some time to implement (i.e., its not going to be ready for the imminent release of 10.8). The reason I say this is that we would need to write a selfupdate-git function, and work through issues like how it interacts with selfupdate-cvs, whether we are migrating everything or just the most recent tree or trees, etc. etc. Actually, Daniel Johnson has been working on this: https://github.com/danielj7/fink/tree/selfupdate-git. In the end, it's a matter of committment: DO we *want* to switch to this? Does it pay off for Daniel and others to invest blood and tears into it? Because if it's not clear whether this work has a good chance of being merged in the end, then it's a bit difficult to motivate oneself to work on it... My stance is clear on this: I *want* selfupdate-git, and I really want to stop using CVS for anything. The sooner the better. I'll make our life a lot easier. We could bring Daniel's code into a branch of the official fink repository so that it would be more likely to be tested. He's got a github copy of dists/, too, and a script to transfer updates from SF CVS to that. While I am at it, I'd also like to see us switch to the new dpkg / apt etc. ;) I think it was Sjors who worked on that. My understanding is that Justin Hallet is interested in looking at them, too, near-term. In my testing of them, there remained an issue with update-alternatives (that's referenced in my message from yesterday), but I think they would be good to go as updates if that were fixed--or we could try the latest upstream versions, even. At that point we could look into bootstrapping using them. As for whether to host git repositories. on SF.net or github: that's a mostly irrelevant question. We can easily host on both. It's a trivial matter to switch between them. But github offers so many useful features that SF.net misses that it's not even a close contest. Add in the fact that SF.net tends to leave bug reports and feature requests untended for years in a row, then closes them saying we are now deprecating this function etc., makes me not want to host *anything* anymore on SF.net unless I have no other choice. But that's just me. If others want to host git repositories on SF.net (or bitbucket, or gitorious, or Google Code, or on a private server, or, or, or), that's all fine by me -- after all, one of the big advantages of DVCS like git and mercurial is that everybody gets a full copy of the repository; and which repository is the upstream of which other repository is something that can be changed in a blink of an eye ;). Cheers, Max I believe the notion was that once we switched to git (for whatever subset of platforms) we wouldn't continue to support upgrading via CVS at all: basically users would selfupdate, and then Fink::Selfupdate::CVS would tell them that CVS is done and give them a dialog giving them the option to switch to rsync, https, svn or git. (Does that answer the issue of interaction with selfupdate-cvs?) Assuming that we want to do some testing ;-), then what we could do is: 1) Set up an official selfupdate-git branch of fink by importing Daniel's code. 2) Set up a quasi-official dists/ . 3) Assuming that the test period is going to be longer than we'd be willing to freeze distribution updates, set up a cron job on phinch to run Daniel's script or something like it to keep the github dists/ in sync with sf.net CVS so that it stays fresh while we test (e.g. so that selfupdate actually does something). 4) Set an approximate date to convert over to git. 5) Once we're happy with the operation, then we release a fink that enables git and disables cvs. As to what trees to migrate: there would be some utility in _not_ migrating the 10.4 tree. 10.7 is the first OS X version where git ships with Xcode. This was a motivation to provide selfupdate-svn, since svn is available on 10.5 and later. That would entail OS version tests in CVS.pm, but I guess those aren't too bad, and they could go away when we finally kill off 10.6 (Yay for single architecture! Maybe!). On the other hand, that would introduce the complexity of having to update packages in two separate VCSes, which
