> On Jun 10, 2015, at 15:33, Alexander Hansen <alexanderk.han...@gmail.com> > wrote: > > >> On Jun 10, 2015, at 15:25, Daniel Johnson <daniel.johnso...@gmail.com> wrote: >> >> >>> On Jun 10, 2015, at 5:44 PM, Alexander Hansen <alexanderk.han...@gmail.com> >>> wrote: >>> >>>> >>>> On Jun 10, 2015, at 09:53, Alexander Hansen <alexanderk.han...@gmail.com> >>>> wrote: >>>> >>>>> >>>>> On Jun 10, 2015, at 09:50, Daniel Macks <dma...@netspace.org> wrote: >>>>> >>>>> On Wed, 10 Jun 2015 09:34:05 -0700, Alexander Hansen >>>>> <alexanderk.han...@gmail.com> wrote: >>>>> No surprise there. :-) >>>>>> >>>>>> I was going to initialize the 10.9-libc++ distribution, but then I >>>>>> got to thinking about whether it might not be a bad plan to use a cvs >>>>>> import of the 10.7 tree and then rename the directory, so that we can >>>>>> preserve the history. >>>>>> >>>>>> Thoughts? >>>>> >>>>> I do not support making a new distro subdir by simply cloning the old. >>>>> This is a great chance to prune out lots of old crap that doesn't >>>>> build, stop relying on system hacks like X11 symlink, stop carrying >>>>> forward -shlibs stub packages from old libversions, etc. However, >>>>> cloning the old into a holding-pen in git (preserving history) and then >>>>> using that for selective manual moving into the live distro still >>>>> within git gives us history linkage. New dist would essentially be a >>>>> fork or branch. >>>>> >>>>> dan >>>>> >>>>> -- >>>>> Daniel Macks >>>>> dma...@netspace.org >>>>> >>>>> >>>> >>>> Sure, that makes sense. >>> >>> Well, maybe. ;-) I’m not exactly sure about how this would be implemented, >>> since I believe the selfupdate-git code only pulls from master. Perhaps >>> we’d have to tweak that during the development phase, and have the to-be >>> processed stuff be in a non-master branch. >> >> That can easily be changed in SelfUpdate/git.pm. You’d have to change the >> repo from my mirror to the official one anyway. There is another issue >> though. If we make a new repo now for 10.9+, it will quickly diverge from >> the existing one. It won’t be easy to merge them later and could become a >> bit of a nightmare for maintainers. What is the plan for distros going >> forward? Are we just going to freeze <=10.7 and leave them in cvs while >> 10.9+ goes to git? If so, we need to do that now before adding distros or >> we’re in for headaches later. We’re going to have to decide this before >> doing anything else. >> >> Daniel >> > > Yeah, good question. > > My initial thought was to keep everything in CVS until 10.11 is released, > while we clean up the new 10.9-libc++ tree and then switch 10.9 and later > over to git at the same time as EOL’ing 10.7 and 10.8. That might not be > the best way to go, though. > -- > Alexander Hansen, Ph.D. > Fink User Liaison >
Thinking further, it might be best not to get cute and just set up a 10.9-libc++ distribution in CVS, and then do the git migration after we club all of the packages that won’t work or don’t want on ElCaveman. -- Alexander Hansen, Ph.D. Fink User Liaison ------------------------------------------------------------------------------ _______________________________________________ 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
