Moving to GitHub: Status Update, Action Required

[Mojca Miklavec]

Hi,

On 21 October 2016 at 20:12, Clemens Lang wrote:
>
> Action Required: GitHub Accounts
> ================================
> Our new Trac installation will use GitHub for login. If you do not have
> a GitHub account yet, please create one now at
>  https://github.com/join
>
> To help us match your previous contributions and Trac tickets to your
> GitHub account, please go to
>  https://github.com/settings/emails
> and ensure that you have added and verified all email addresses you have
> used for MacPorts Trac.

Is that true also for any other email we used prior to becoming
committers? Can new emails be added later? How exactly does it work
when people enter multiple emails? (Judging from, say #37017, I guess
that whenever I was assigned as the owner of the ticket with my old
pre-committer-email, that would now be replaced with my github
handle.)

(not?) related to the above question:
One thing I'm confused about is that whenever I'm listed as a reporter
or in CC, my name would be replaced by all the three data (my macports
handle, my full email, my github account), while the tickets where I'm
the owner only contain my macports email. Tickets where the owner has
been assigned later contain full info about that owner. I didn't
investigate too closely yet.

> Migration Timeline
> ==================
> The switch to Git will happen on the weekend of October 29th/30th. We
> will disable committing to the Subversion repository, run a last
> incremental export to Git and push the changes to GitHub. If you have
> commit access, please do not commit to the repositories at GitHub until
> a mail to the list indicates the conversion is done. Please read through
>  https://trac.macports.org/wiki/WorkingWithGit
> which contains a number of guidelines for working with the MacPorts Git
> repositories.

May I suggest creating a clone of the port repository on GitHub (in
whatever state it is now) and let it serve as a playground for testing
different strategies of pushing, using pull requests, merging,
properly rebasing, merging several commits of a pull request together,
editing pull requests by non-committers (when a pull request needs
just a tiny bit of fixing: will that be one commit or original commit
+ edits by "committer"), ...

It would help a lot if we had at least some idea how we want to
proceed after the official switch. And some "grace period" to test
what we want to do and what we want to avoid. Some playground for
people that are new to git & and github wouldn't hurt either.

Mojca