Hello, Bill and all, >> * use both BerliOS and GitHub in parallel for >> some weeks, as an experiment, migrating back >> and forth (I'd be willing to help in that),
> You need to define what you mean as 'parallel' working > entails. Yes. > ... How would you propose a developer do work on such a > parallel git repository. I envision(ed) three groups of people: SVN-developers, Git-developers, and merge masters. The SVN developers continue as usual on BerliOS. The Git developers work on GitHub pretty much as if BerliOS did not exist. And the merge masters carry changes back and forth between the two worlds. > For example who would make sure that the upstream git repo > is always mirrored the authoritative svn repo? Me. (For a suitable definition of "always".) To spell out what my "I'd be willing to help in that" means: I'll be willing to do the SVN <-> Git merge master for a few weeks (say, three). Say, I'll try to provide daily service. The idea is: Let people on the SVN side work as they always have. Let people on the GitHub side throw pull request at the GitHub project like one does on GitHub. And let the merge masters move changes back and forth to connect both worlds. Some details would need to be clarified. E.g.: Which changes from whom may appear where on the SVN side. Who does which quality control on incoming code. But, as far as merges themselves are concerned, as long as we can keep people from reformating sources (re-indent everything or so) grand style, I'm not afraid of those. (I've been "merge master" before.) Ok, but that seems to be "mathematics on the empty set". Unless there is a late change of opinion, we have a decision to move to SourceForge. And that is certainly a valid, reputable choice from what I know - nothing wrong with that. Regards, Andreas DJ3EI _______________________________________________ Wsjt-devel mailing list [email protected] https://lists.berlios.de/mailman/listinfo/wsjt-devel
