On 12/6/12 5:24 AM, Max Horn wrote: > Hi akh, > > I am all for switching to selfupdate-git and -svn as soon as possible. We > just need to make sure the code works reliably, and come up with a good > transitioning strategy. And I applaud all efforts to that, and am grateful > that you are interested in working on this, and would like to help with it > where I can. > > > Unfortunately, I am not sure how good the current code really works, and some > fundamental questions regarding the new setup are not yet answered (or at > least I am not aware of the answers)... > > One of those questions is how to handle the various dist trees. One proposal > that's been floating around is to put each of those into a separate git > branch. So we'd have branches > 10.4 (made from the current 10.4-EOL) > 10.5 (made from current 10.4) > 10.7 > There would be a map file somewhere (or perhaps a floating tag/branch name or > so?) which would ensure that 10.6 users would get the 10.5 branch, and 10.8 > users the 10.7 branch. > > Then when we EOL 10.5, we create a new 10.6 branch from the 10.5 branch, and > update the map file (or whatever other solution we use). Moreover, the > selfupdate code would have to know about this, and then automatically switch > to the new branch when run (this applies to both the -git and -svn variants). > > > An alternate approach is this: all dist trees are in the "master" branch of a > "dists" git repository. So there would be dirs and symlinks in it like this: > (note that git can store symlinks just fine): > 10.4 (made from the current 10.4-EOL) > 10.5 (made from current 10.4) > 10.6 (symlink to 10.5) > 10.7 > 10.8 (symlink to 10.7) > > This has some advantages: I think it would be easier to implement, as it > would be closer to our current setup. It also makes it easy to "upgrade" to a > new OS X version (even though we discourage that, of course) if we decide to > additionally get rid of the /sw/fink/dists symlink (replacing it a lookup in > "/sw/fink/$OS_VERSION/"). Getting rid of that symlink would also make it dead > easy to EOL a version: To EOL 10.5, we just replace the 10.6 symlink by a > copy of the 10.5 dir, and then proceed to develop it independently. > > > > We need to decide how we want to handle this. Among other things. >
Sure. > > On 03.12.2012, at 22:43, Alexander Hansen wrote: > >> Anonymous CVS has been out for two business days plus a weekend. That >> means that users behind firewalls can't easily get new package >> descriptions, since ViewVC is not updating to make new packages >> available either. >> >> I propose the following: >> >> 1) Merge the selfupdate-git code into the official fink repository >> master so that it's easier to convince people to take a look at it. > > I am not sure if I buy into that. It's perfectly easy to ignore code that is > in our main repository, too :-). But OK, if somebody is willing to test those > commands, it'll be a bit easier to allow them to do that if those commands > are part of a released fink version. > > However, this also poses a major problem in my eyes: If that selfupdate-git > is part of a released version of Fink, then regular may en up using it when > they should not. This could result in people selfupdating to outdated trees; > and if we decide that we need to modify the functionality of selfupdate-git > slightly, we then have to worry about how to let those people recover. > > So, if we put this into a regular released version, then ONLY if those > commands are disabled by default, or "hidden" (e.g. until finalized, the > commands could be named "_do_not_use-selfupdate-git"). > > > OTOH, if the idea is to not have the commands in a released fink until they > are mature (which I'd kind of prefer), then I don't see how merging it > unfinished into master helps. I'd much rather see us develop it on a branch > -- that's what branches are for, after all. It's not really harder to install > a fink from any branch than installing it from master. > What I meant was that our developers might be more inclined to try some testing if the code were in _our_ repository. I wouldn't say to release it until everything works. Bringing it to master was based on the fact that the pull request is set up that way on github. I'd already forgotten that it could be manually pulled into a branch. And this would indicate why I'd like to have the code in our repository: I use git more than some of our folks, and I'm _still_ on the vertical portion of the learning curve. > > >> 2) Modify Daniel J.'s scripts and set up an official github repository >> for .info and .patch files, so that maintainers can experiment with >> something that approximates what the live setup will be. > > Aha. I have not looked at Daniel's scripts, where can I find them? My own > scripts for converting our CVS work by > a) using rsync to pull the CVS repository from the SF.net servers (works > incrementally, so very fast) > b) "hide" stuff I don't want, like ancient dists (anything before 10.4 in my > case, we don't support that anymore anyway) > c) use "git cvsimport" to import any new changes incrementally into a git > repos > so I assume it's something similar. > > > >> 3) Do any/all cleanups needed to make the above work properly, including: >> switching selfupdate methods--presumably at this time we'd still want >> to have CVS available but deprecated > > I guess for the transition period this would be good, "just in case". > Although I'd hope that "selfupdate-rsync" would provide an equally good if > not better fallback. > > Which reminds me: I am not full sure how selfupdate-rsync works right now, I > feel it would be important to make sure it keeps working > The problem is the mirror sites. Other than gecko2's site and the Todai site, everybody mirrors off phinch. That breaks down when phinch does. Losing anonymous cvs broke phinch's rsync, but I modified phinch to use my sourceforge account and do ext checkouts from CVS instead of anonymous. I'm not sure whether the other mirrors have caught back up yet. > >> >> Putting .info/patch files for svn and dependencies into the fink tarball >> for the 10.4 tree--my recollection is that the svn which comes with >> Xcode on 10.5 may be too old for the github git->svn bridge. > > We should verify whether this is indeed the case. As to adding svn.info, that > only makes sense if we also pull in all deps of svn -- and there are tons of > that... So I am not sure how feasible that is. Actually, the git package has > far less deps... > > Of course in the past, we provided versions of fink that included full > snapshots of dists/ ... it might be time to resurrect that, at least > partially? > > And/or resurrect the "selfupdate-point" variant, which downloads a tarball of > package descriptions... by tweaking it slightly, we could even try to make it > download automatically generated tarballs from github.com (like on > https://github.com/fink/fink/downloads) > > And/or just tell users to use selfupdate-rsync by default :-). > Other than the people who work for governments or big corporations who have firewalls that block rsync (and can't update Fink at all right now). > >> >> Putting .info/patch files for git and dependencies into the fink tarball >> for the 10.4 tree. >> >> 4) Roll out a fink-0.35.0 which enables this. >> > > Weeelll, as I said, I'd be careful to let users access this feature unless we > are at least sure how to handle the various dists trees (as branches or > subdirs). > > > Cheers, > Max > >> Any thoughts on 1) ? -- Alexander Hansen, Ph.D. Fink User Liaison My package updates: http://finkakh.wordpress.com/ ------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d _______________________________________________ fink-core mailing list fink-core@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.apple.fink.core Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-core
