On 12/6/12 8:55 PM, Dustin Cartwright wrote: > On Thu, Dec 6, 2012 at 10:24 AM, Alexander Hansen > <alexanderk.han...@gmail.com> wrote: > >> 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. > > As this example illustrates, the most complicated part of git isn't > going to be using it to do selfupdate, it's committing, creating > branches, merging, pull requests etc. Switching repositories is > inherently somewhat abrupt. One day the git repository is only a > mirror of CVS, and while selfupdate has been well-tested, the the only > commits are going to be tests which had no impact because they were > overwritten by the next sync with CVS. The next day, CVS is frozen and > has to use git to commit, push, etc. > > I think that part of the transition should be a document describing > how package maintainers are going to be using git with fink. I'd be > happy to write a guide to maintaining packages for fink with git, but > I don't feel like I'm in a position to be presuming any policies > without some input from others. > > In addition to the branches versus directories issue that Max raised: > Are changes going to be incorporated into the main repository as > merges or cherry-picks? Should a package update be squashed into a > single commit, or is some intermediate history okay? If one person > updates multiple packages, should they be done as separate branches, > or if they're just sequential commits on a single branch, is that > okay? (The latter would be problematic if changes are merged, but > might be okay for cherry-picking.) What about changes to multiple > packages in a single commit? Are there going to be any standards on > the format of the commit message? > >>>> 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? >>>
If somebody has the time to do that, they can knock themselves out. I don't. >>> 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). > > Is part of this proposal that fink the package gains a dependency on > svn and git? No. Why not disable selfupdate-git and -svn during bootstrap There's no selfupdate _during_ bootstrap. > (i.e. not even have an option since cvs will be deprecated and point > is obsolete), and after bootstrap the user can install the git package > and switch to selfupdate-git? And how do they do this without a package description? That's what my point was: we don't ship a package description for git or svn in the fink tarball, and users can't easily get the descriptions without doing a selfupdate. If they're on a sufficiently new system then there are Apple-provided svn and git binaries so that's not a problem. > > One way to do this would be to have a fink-selfupdate-git package > which contains no real files, but does 3 things: its presence > indicates to selfupdate-git that it can be enabled, it introduces a > dependency on git, and it has a post-rm script which prompts the user > to switch to a different selfupdate method if SelfUpdateMethod is set > to git. > > Dustin > I'm not in favor of a "real" placeholder package, since things can change on a user's system without triggering removal of the package. -- 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
