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? >> >> 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? Why not disable selfupdate-git and -svn 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? 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 ------------------------------------------------------------------------------ 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