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. 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. > 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 > > 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 :-). > > 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/ > > ------------------------------------------------------------------------------ > Keep yourself connected to Go Parallel: > BUILD Helping you discover the best ways to construct your parallel projects. > http://goparallel.sourceforge.net > _______________________________________________ > 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 > ------------------------------------------------------------------------------ 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
