Re: Moving to GitHub: Status Update, Action Required

2016-10-31 Thread Clemens Lang 
Hi,

On Mon, Oct 31, 2016 at 10:25:33AM +0100, Davide Liessi wrote:
> I have just noticed in one of my GitHub repositories that in Settings
> -> Options there is a "Merge button" section that lets you
> enable/disable the behaviours of the merge button described in the
> above link.
> Maybe you could leave only "Allow rebase merging" enabled and disable
> the rest.

We already did this, but thanks for the pointer.

-- 
Clemens
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Moving to GitHub: Status Update, Action Required

2016-10-31 Thread Davide Liessi 
2016-10-25 15:35 GMT+02:00 Ryan Schmidt :
>
>> On Oct 25, 2016, at 6:54 AM, Rainer Müller  wrote:
>>
>> On 2016-10-25 10:36, Ryan Schmidt wrote:
>>>
>>>
>>> On Oct 24, 2016, at 17:57, Clemens Lang  wrote:
>>>
> On Tue, Oct 25, 2016 at 12:17:57AM +0200, Marko Käning wrote:
> A description of how exactly one would rebase (potentially squash and
> history-rewrite) a submitted PR onto current master should be on our
> WorkingWithGit wiki page.

 the easiest approach is just clicking the button that does this on
 GitHub. Of course there's also a way to do it from the command line.
>>>
>>> We should document, with screenshots, the specific buttons that should be 
>>> clicked to achieve this, for the benefit of those developers like me who 
>>> are not that familiar with git and GitHub.
>>
>> Keeping such a documentation with screenshots updated to the current
>> GitHub release seems excessive. The GitHub documentation already has
>> screenshots. We should not try to recreate it, but rather place the
>> links to the relevant sections.
>>
>> https://help.github.com/articles/merging-a-pull-request/
>
> As long as we don't just link, but in cases where their documentation offers 
> multiple choices, tell the user which of those choices to use.

I have just noticed in one of my GitHub repositories that in Settings
-> Options there is a "Merge button" section that lets you
enable/disable the behaviours of the merge button described in the
above link.
Maybe you could leave only "Allow rebase merging" enabled and disable the rest.

Best wishes.
Davide
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Moving to GitHub: Status Update, Action Required

2016-10-28 Thread Rainer Müller 
On 2016-10-28 16:02, Craig Treleaven wrote:
>> On Oct 21, 2016, at 2:12 PM, Clemens Lang  wrote:
>> ...
>> Migration Timeline
>> ==
>> The switch to Git will happen on the weekend of October 29th/30th. ...
> 
> Is this still on track?

Yes, expect Subversion to go read-only this weekend. Shortly afterwards,
the repositories on GitHub will be the authoritative source for MacPorts.

The infrastructure team did not schedule the exact time when this will
happen, but definitely this weekend.

Rainer
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Moving to GitHub: Status Update, Action Required

2016-10-28 Thread Ryan Schmidt 

> On Oct 28, 2016, at 9:02 AM, Craig Treleaven  wrote:
> 
>> On Oct 21, 2016, at 2:12 PM, Clemens Lang  wrote:
>> ...
>> Migration Timeline
>> ==
>> The switch to Git will happen on the weekend of October 29th/30th. ...
> 
> Is this still on track?

Yes.


___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Moving to GitHub: Status Update, Action Required

2016-10-28 Thread Craig Treleaven 
> On Oct 21, 2016, at 2:12 PM, Clemens Lang  wrote:
> ...
> Migration Timeline
> ==
> The switch to Git will happen on the weekend of October 29th/30th. ...

Is this still on track?

Craig
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Moving to GitHub: Status Update, Action Required

2016-10-25 Thread Ryan Schmidt 

> On Oct 25, 2016, at 6:54 AM, Rainer Müller  wrote:
> 
> On 2016-10-25 10:36, Ryan Schmidt wrote:
>> 
>> 
>> On Oct 24, 2016, at 17:57, Clemens Lang  wrote:
>> 
 On Tue, Oct 25, 2016 at 12:17:57AM +0200, Marko Käning wrote:
 A description of how exactly one would rebase (potentially squash and
 history-rewrite) a submitted PR onto current master should be on our
 WorkingWithGit wiki page.
>>> 
>>> the easiest approach is just clicking the button that does this on
>>> GitHub. Of course there's also a way to do it from the command line.
>> 
>> We should document, with screenshots, the specific buttons that should be 
>> clicked to achieve this, for the benefit of those developers like me who are 
>> not that familiar with git and GitHub. 
> 
> Keeping such a documentation with screenshots updated to the current
> GitHub release seems excessive. The GitHub documentation already has
> screenshots. We should not try to recreate it, but rather place the
> links to the relevant sections.
> 
> https://help.github.com/articles/merging-a-pull-request/

As long as we don't just link, but in cases where their documentation offers 
multiple choices, tell the user which of those choices to use.


___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Moving to GitHub: Status Update, Action Required

2016-10-25 Thread Rainer Müller 
On 2016-10-25 10:36, Ryan Schmidt wrote:
> 
> 
> On Oct 24, 2016, at 17:57, Clemens Lang  wrote:
> 
>>> On Tue, Oct 25, 2016 at 12:17:57AM +0200, Marko Käning wrote:
>>> A description of how exactly one would rebase (potentially squash and
>>> history-rewrite) a submitted PR onto current master should be on our
>>> WorkingWithGit wiki page.
>>
>> the easiest approach is just clicking the button that does this on
>> GitHub. Of course there's also a way to do it from the command line.
> 
> We should document, with screenshots, the specific buttons that should be 
> clicked to achieve this, for the benefit of those developers like me who are 
> not that familiar with git and GitHub. 

Keeping such a documentation with screenshots updated to the current
GitHub release seems excessive. The GitHub documentation already has
screenshots. We should not try to recreate it, but rather place the
links to the relevant sections.

https://help.github.com/articles/merging-a-pull-request/

Rainer
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Moving to GitHub: Status Update, Action Required

2016-10-25 Thread Ryan Schmidt 


On Oct 24, 2016, at 17:57, Clemens Lang  wrote:

>> On Tue, Oct 25, 2016 at 12:17:57AM +0200, Marko Käning wrote:
>> A description of how exactly one would rebase (potentially squash and
>> history-rewrite) a submitted PR onto current master should be on our
>> WorkingWithGit wiki page.
> 
> the easiest approach is just clicking the button that does this on
> GitHub. Of course there's also a way to do it from the command line.

We should document, with screenshots, the specific buttons that should be 
clicked to achieve this, for the benefit of those developers like me who are 
not that familiar with git and GitHub. 



___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Moving to GitHub: Status Update, Action Required

2016-10-24 Thread Clemens Lang 
Hi,

On Tue, Oct 25, 2016 at 12:17:57AM +0200, Marko Käning wrote:
> A description of how exactly one would rebase (potentially squash and
> history-rewrite) a submitted PR onto current master should be on our
> WorkingWithGit wiki page.

the easiest approach is just clicking the button that does this on
GitHub. Of course there's also a way to do it from the command line.

> At the moment it is not very clear to me how a MacPorts committer
> would actually deal with a pull request submitted by a port maintainer
> to the central repository. But I’ve got to admit that I haven’t read
> much more than our wiki page up to now. There are surely more details
> in GitHub’s help...

Part of the problem here is that we're not exactly sure either. We'll
just see how it goes for the first few PRs and then define the rules as
we see what works for us.

-- 
Clemens
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Moving to GitHub: Status Update, Action Required

2016-10-24 Thread Marko Käning 
I fully agree with Mojca, that it is better to work on a private fork for the 
start and let others - like Clemens suggested - take part in reviewing on that 
forked repository. This way one can train what would have to be done on the 
main macports-ports repo before causing trouble there...


On 24 Oct 2016, at 19:58 , Clemens Lang  wrote:

> Yes, that's also my preference. So we can agree on:
> - rebase when merging PRs
> - rewrite history on PR branches until it looks good

A description of how exactly one would rebase (potentially squash and 
history-rewrite) a submitted PR onto current master should be on our 
WorkingWithGit wiki page.

At the moment it is not very clear to me how a MacPorts committer would 
actually deal with a pull request submitted by a port maintainer to the central 
repository. But I’ve got to admit that I haven’t read much more than our wiki 
page up to now. There are surely more details in GitHub’s help...
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Moving to GitHub: Status Update, Action Required

2016-10-24 Thread Clemens Lang 
On Mon, Oct 24, 2016 at 08:22:38PM +0200, Mojca Miklavec wrote:
> Even if the method of achieving this is not prescribed***, I wouldn't
> mind a bit of testing before screwing up the real repository.
> 
> *** But having some cheatsheet would help.

Sure, feel free to create a fork, play around, add me to the review and
I'll find stuff that you can change so you can play around ;-)

-- 
Clemens
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Moving to GitHub: Status Update, Action Required

2016-10-24 Thread Vincent Habchi 
> 
> You should check with the developers of Coda on their Git support. I
> don't think a tool built especially for website editing will be the best
> choice, but maybe it works for you.

Otherwise I also use PyCharm free edition for some Python related tasks, and it 
seems to have built-in GitHub support, so maybe that should work too.

Thanks anyway for the hard work.

Vincent

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Moving to GitHub: Status Update, Action Required

2016-10-24 Thread Mojca Miklavec 
On 24 October 2016 at 20:08, Lawrence Velázquez wrote:
>> On Oct 24, 2016, at 1:58 PM, Clemens Lang wrote:
>>> On Mon, Oct 24, 2016 at 07:47:18PM +0200, Mojca Miklavec wrote:
>>>
>>> (My preference would be to keep linear history for master and not to
>>> keep ten broken revisions of a Portfile resulting from stepwise
>>> improvements in a pull request, but it would be nice to do some
>>> testing first.)
>>
>> Yes, that's also my preference. So we can agree on:
>> - rebase when merging PRs
>> - rewrite history on PR branches until it looks good
>
> +1 to both (so +2, I guess?). We want to avoid merge commits, and we
> want the history that is ultimately added to master to be clean and
> understandable. The precise method of achieving this (squash merging,
> interactive rebasing, etc.) is not really important.

Even if the method of achieving this is not prescribed***, I wouldn't
mind a bit of testing before screwing up the real repository.

*** But having some cheatsheet would help.

Mojca
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Moving to GitHub: Status Update, Action Required

2016-10-24 Thread Lawrence Velázquez 
> On Oct 24, 2016, at 1:58 PM, Clemens Lang  wrote:
> 
> I don't think we should mandate a complex "run these magic git commands"
> workflow. Making things complicated will just make them go wrong.

Agreed.

>> On Mon, Oct 24, 2016 at 07:47:18PM +0200, Mojca Miklavec wrote:
>> 
>> (My preference would be to keep linear history for master and not to
>> keep ten broken revisions of a Portfile resulting from stepwise
>> improvements in a pull request, but it would be nice to do some
>> testing first.)
> 
> Yes, that's also my preference. So we can agree on:
> - rebase when merging PRs
> - rewrite history on PR branches until it looks good

+1 to both (so +2, I guess?). We want to avoid merge commits, and we
want the history that is ultimately added to master to be clean and
understandable. The precise method of achieving this (squash merging,
interactive rebasing, etc.) is not really important.

vq
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Moving to GitHub: Status Update, Action Required

2016-10-24 Thread Clemens Lang 
Hi,

On Mon, Oct 24, 2016 at 08:00:04PM +0200, Vincent Habchi wrote:
> I’ve bought Coda 2 when I use to do a bit of HTML development. Can I
> use it to check out - tinker with the new MacPorts GIT repository?

You should check with the developers of Coda on their Git support. I
don't think a tool built especially for website editing will be the best
choice, but maybe it works for you.

-- 
Clemens
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Moving to GitHub: Status Update, Action Required

2016-10-24 Thread Lawrence Velázquez 
> On Oct 24, 2016, at 2:00 PM, Vincent Habchi  wrote:
> 
> I’ve bought Coda 2 when I use to do a bit of HTML development. Can
> I use it to check out - tinker with the new MacPorts GIT repository?

You can use any Git client you like, as long as you're aware that we'll
effectively be trashing the current repository soon. So don't get too
attached to it!

vq
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Moving to GitHub: Status Update, Action Required

2016-10-24 Thread Vincent Habchi 
Guys,

I’ve bought Coda 2 when I use to do a bit of HTML development. Can I use it to 
check out - tinker with the new MacPorts GIT repository?

TIA,
Vincent

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Moving to GitHub: Status Update, Action Required

2016-10-24 Thread Clemens Lang 
On Mon, Oct 24, 2016 at 07:47:18PM +0200, Mojca Miklavec wrote:
> I can send you a screenshot comparing the version I opened two hours
> ago and the same page reloaded just now. The result changed in the
> meantime. In any case I can no longer provide you any broken example
> (there are still some for other developers, but I cannot judge about
> whether other developers did the migration already or not).

So that's probably because the conversion does not happen instantly, but
is processed in a delayed cronjob and wasn't finished when you initially
looked at it.

> The problem I have right now though is how to list the tickets owned /
> reported by me. The query I used on the old trac no longer works.
> 
> For example:
> [[TicketQuery(status=assigned|new|reopened~=mo...@macports.org)]]

Use your GitHub username as owner instead of the email address.

> The idea is not to play with it on my own. I know how trivial git
> commands work. What is not yet clear to me is whether we would be
> clicking the gui buttons to accept pull requests or do some
> non-conventional steps of merging multiple commits, adding our changes
> on top, rebasing to master etc.

I would leave that up to the developers. Previously, GitHub did not
support rebasing pull requests, but that was fixed a while ago, so now
you can also merge PRs by rebasing them on top of master.

I don't think we should mandate a complex "run these magic git commands"
workflow. Making things complicated will just make them go wrong.

> (My preference would be to keep linear history for master and not to
> keep ten broken revisions of a Portfile resulting from stepwise
> improvements in a pull request, but it would be nice to do some
> testing first.)

Yes, that's also my preference. So we can agree on:
 - rebase when merging PRs
 - rewrite history on PR branches until it looks good

-- 
Clemens
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Moving to GitHub: Status Update, Action Required

2016-10-24 Thread Mojca Miklavec 
On 24 October 2016 at 19:15, Lawrence Velázquez wrote:
>> On Oct 24, 2016, at 12:50 PM, Mojca Miklavec wrote:
>>
>> (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.
>
> Can you provide some examples?

I can send you a screenshot comparing the version I opened two hours
ago and the same page reloaded just now. The result changed in the
meantime. In any case I can no longer provide you any broken example
(there are still some for other developers, but I cannot judge about
whether other developers did the migration already or not).

The problem I have right now though is how to list the tickets owned /
reported by me. The query I used on the old trac no longer works.

For example:
[[TicketQuery(status=assigned|new|reopened~=mo...@macports.org)]]

>> 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.
>
> I'm not sure it's necessary to host such a sandbox repository in the
> macports organization. The "macports-ports" repository
> (https://github.com/macports/macports-ports.git) already contains
> a stale version of the ports tree; you can fork it and play around with
> it as you wish.

The idea is not to play with it on my own. I know how trivial git
commands work. What is not yet clear to me is whether we would be
clicking the gui buttons to accept pull requests or do some
non-conventional steps of merging multiple commits, adding our changes
on top, rebasing to master etc. (My preference would be to keep linear
history for master and not to keep ten broken revisions of a Portfile
resulting from stepwise improvements in a pull request, but it would
be nice to do some testing first.)

Mojca
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Moving to GitHub: Status Update, Action Required

2016-10-24 Thread Ryan Schmidt 


> On Oct 24, 2016, at 12:15, Lawrence Velázquez  wrote:
> 
> The "macports-ports" repository
> (https://github.com/macports/macports-ports.git) already contains
> a stale version of the ports tree; you can fork it and play around with
> it as you wish.

If you clone or fork any of the preliminary repositories there now, be prepared 
to delete those forks and clones later. And please do not submit any pull 
requests at this time. We will be force-pushing to those repositories this week 
which will invalidate any existing clones, forks or pull requests. 
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Moving to GitHub: Status Update, Action Required

2016-10-24 Thread Clemens Lang 
Hi,

On Mon, Oct 24, 2016 at 06:50:47PM +0200, Mojca Miklavec wrote:
> Is that true also for any other email we used prior to becoming
> committers?

Yes.

> Can new emails be added later?

Yes, but you'll have to relogin.

> 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.)

All email addresses you add will be replaced with your GitHub account.

> 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.

I could not find any tickets assigned to your email addresses. Maybe you
checked before the migration ran?

> 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"), ...

You can do all of that in a fork of the repository.

> 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.

Proposals for rules are very welcome. Feel free to start a wiki page so
we can have a discussion. Also note that any testing can easily be done
in a fork of the repository.

-- 
Clemens
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Moving to GitHub: Status Update, Action Required

2016-10-24 Thread Lawrence Velázquez 
> On Oct 24, 2016, at 12:50 PM, Mojca Miklavec  wrote:
> 
>> 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?

Yes.

> Can new emails be added later?

Yes. If you add a new address to your GitHub account later, you should
sign out of Trac. When you sign back in, references to that new address
will be switched over within minutes. (That is to say, the migration
occurs continuously and not just when you create your NewTrac account.)

> 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.)

That's right. Your NewTrac account takes over references to all email
addresses listed on your GitHub account.

> (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.


Can you provide some examples? In all three situations (reporter, owner,
Cc), I see only my GitHub username and real name. Likewise, for users
who have created a NewTrac account, I see only their GitHub username and
optional real name. (If they haven't created an account yet, their email
address is listed.)

> 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.

I'm not sure it's necessary to host such a sandbox repository in the
macports organization. The "macports-ports" repository
(https://github.com/macports/macports-ports.git) already contains
a stale version of the ports tree; you can fork it and play around with
it as you wish.

vq
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Moving to GitHub: Status Update, Action Required

2016-10-24 Thread 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
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Moving to GitHub: Status Update, Action Required

2016-10-22 Thread Lawrence Velázquez 
> On Oct 22, 2016, at 9:40 AM, Marko Käning  wrote:
> 
>> On 22 Oct 2016, at 15:34 , Ryan Schmidt  wrote:
>> 
>> as well as the "hub" command line program in the "hub" port.
> 
> Exactly, that’s the one I meant. Perhaps it’s worth mentioning it on the
> wiki page.

I've added several tools to the list since last night. Further
suggestions are welcome.

https://trac.macports.org/wiki/WorkingWithGit#tools

vq
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Moving to GitHub: Status Update, Action Required

2016-10-22 Thread Ryan Schmidt 

> On Oct 22, 2016, at 7:49 AM, Marko Käning  wrote:
> 
> Hi Clemens,
> 
> On 22 Oct 2016, at 14:41 , Clemens Lang  wrote:
>> Developers will merge them, either using the command line client, or the
>> GitHub UI. We haven't decided and documented which merge method to use,
>> although I'd prefer the rebase.
> 
> ok, I see.
> 
> BTW, you’ve mentioned in some thread lately this GitHub command line client!
> However, exactly that client doesn’t yet appear on the WorkingWithGit tools
> page [1]. I guess it would be worth adding.

There's the "git" command line program in the "git" port, as well as the "hub" 
command line program in the "hub" port.


___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Moving to GitHub: Status Update, Action Required

2016-10-22 Thread Marko Käning 

On 22 Oct 2016, at 14:49 , Joshua Root  wrote:

> Please see the Migration Timeline section in the first message in this 
> thread. Developers cannot yet push to the git repos.

yes, I figured that now.


OK, awaiting you guys’ decisions on the new workflow.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Moving to GitHub: Status Update, Action Required

2016-10-22 Thread Marko Käning 
Hi Clemens,

On 22 Oct 2016, at 14:41 , Clemens Lang  wrote:
> Developers will merge them, either using the command line client, or the
> GitHub UI. We haven't decided and documented which merge method to use,
> although I'd prefer the rebase.

ok, I see.

BTW, you’ve mentioned in some thread lately this GitHub command line client!
However, exactly that client doesn’t yet appear on the WorkingWithGit tools
page [1]. I guess it would be worth adding.


> Pull access means that we haven't given the team write access to the
> repository yet, so at the moment being a member of the GitHub org only
> gives you added privileges in Trac. This will change as soon as we're
> done with the conversion next weekend.

OK, that clarifies things. Thanks.

Greets,
Marko



[1] https://trac.macports.org/wiki/WorkingWithGit#tools

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Moving to GitHub: Status Update, Action Required

2016-10-22 Thread Joshua Root 

On 2016-10-22 23:31 , Marko Käning wrote:

Hi Clemens,

great to see the GitHub conversion progressing this rapidly! Thumbs up from 
me!!!


When reading the WorkingWithGit wiki page [1] I saw how port contributors can 
post
their suggestions to MacPorts via "Pull Requests”, yet it does not get clear 
from
that text how those PRs will then actually be included into the official repo…


The usual way; an organisation member will review the PR and merge it if 
appropriate. We're still open to suggestions on the details of the workflow.



Just this moment I got invited to MacPorts' "Developer team" on GitHub and saw 
that
I now have "pull access” to the MacPorts ports repository, which is probably 
enabling
me in the future to push changes into it?

But the term “pull access” confuses me here!

I mean, I can pull in changes into my clone or fork from the MacPorts repo any 
time…

Can you clarify this somewhat, as I have no experience yet in teams on GitHub!?

Thanks,
Marko


Please see the Migration Timeline section in the first message in this 
thread. Developers cannot yet push to the git repos.


- Josh
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Moving to GitHub: Status Update, Action Required

2016-10-22 Thread Clemens Lang 
Hi,

On Sat, Oct 22, 2016 at 02:31:32PM +0200, Marko Käning wrote:
> When reading the WorkingWithGit wiki page [1] I saw how port
> contributors can post their suggestions to MacPorts via "Pull
> Requests”, yet it does not get clear from that text how those PRs will
> then actually be included into the official repo…

Developers will merge them, either using the command line client, or the
GitHub UI. We haven't decided and documented which merge method to use,
although I'd prefer the rebase.


> Just this moment I got invited to MacPorts' "Developer team" on GitHub
> and saw that I now have "pull access” to the MacPorts ports
> repository, which is probably enabling me in the future to push
> changes into it?
> 
>   But the term “pull access” confuses me here!
> 
> I mean, I can pull in changes into my clone or fork from the MacPorts
> repo any time…

Pull access means that we haven't given the team write access to the
repository yet, so at the moment being a member of the GitHub org only
gives you added privileges in Trac. This will change as soon as we're
done with the conversion next weekend.

-- 
Clemens
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Moving to GitHub: Status Update, Action Required

2016-10-22 Thread Marko Käning 
Hi Clemens,

great to see the GitHub conversion progressing this rapidly! Thumbs up from 
me!!!


When reading the WorkingWithGit wiki page [1] I saw how port contributors can 
post
their suggestions to MacPorts via "Pull Requests”, yet it does not get clear 
from
that text how those PRs will then actually be included into the official repo…

Just this moment I got invited to MacPorts' "Developer team" on GitHub and saw 
that
I now have "pull access” to the MacPorts ports repository, which is probably 
enabling
me in the future to push changes into it?

But the term “pull access” confuses me here!

I mean, I can pull in changes into my clone or fork from the MacPorts repo any 
time…

Can you clarify this somewhat, as I have no experience yet in teams on GitHub!?

Thanks,
Marko




[1] 
https://trac.macports.org/wiki/WorkingWithGit#Commongittaskswhileworkingwithports
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Moving to GitHub: Status Update, Action Required

2016-10-21 Thread Michael 

On 2016-10-21, at 8:03 PM, Lawrence Velázquez  wrote:

>> On Oct 21, 2016, at 10:55 PM, Ryan Schmidt  wrote:
>> 
>>> On Oct 21, 2016, at 9:47 PM, Lawrence Velázquez  wrote:
>>> 
 On Oct 21, 2016, at 10:20 PM, Craig Treleaven  
 wrote:
 
 Also, is the consensus that a graphical user interface over git
 more likely to be harmful than helpful?  The Tools section at the
 bottom of the page doesn’t give any kind of recommendation.
>>> 
>>> I don't know that there is any sort of consensus on that. Everyone
>>> has their own preferences, and Git is almost absurdly flexible about
>>> workflows. I don't think our documentation should recommend any
>>> particular tools.
>> 
>> I think it would be reasonable for us to mention that GitHub Desktop
>> is a GUI client that exists and works for basic operations like
>> creating or switching between branches and committing changes and has
>> a handy diff viewer to see your changes before committing and even
>> lets you select which portions of your diff you want to commit. But it
>> is of no help with even slightly more advanced git commands.
> 
> Sure, we should certainly list more tools; that section is a bit sparse.
> I just meant that we shouldn't recommend any one tool over the others
> (e.g., "if you like GUI tools, you should use X").

The first thing I noticed not mentioned in that doc was "git gui". While you do 
mention that you can commit multiple changes, separately, before pushing it all 
out, the question is, how do you separate a bunch of edits into several 
separate commits.

"git gui", for me, is an invaluable tool for reviewing changes before 
committing them, and for breaking changes into several commits. This looks like 
something that deserves to be mentioned as a "start here" tool.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Moving to GitHub: Status Update, Action Required

2016-10-21 Thread Lawrence Velázquez 
> On Oct 21, 2016, at 10:20 PM, Craig Treleaven  wrote:
> 
> However, would it be possible to add a tangible example of updating
> a port to that page?  
> 
> I know a little bit about Subversion and less about Git.  I would like
> to see a soup-to-nuts example of cloning the ports tree, updating
> a Portfile, maybe deleting an old patch and adding a new one, and
> getting the updated port into MacPorts (direct commit v. pull
> request).  It would be helpful if one-time requirements (setting name
> and email address) were clearly separated from repetitive steps
> (pulling changes from master?).  Otherwise, it is going to be a wee
> bit nerve-wracking the first few times...

This would be good.

> Also, is the consensus that a graphical user interface over git more
> likely to be harmful than helpful?  The Tools section at the bottom of
> the page doesn’t give any kind of recommendation.

I don't know that there is any sort of consensus on that. Everyone has
their own preferences, and Git is almost absurdly flexible about
workflows. I don't think our documentation should recommend any
particular tools. 

vq
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Moving to GitHub: Status Update, Action Required

2016-10-21 Thread Craig Treleaven 
> On Oct 21, 2016, at 2:12 PM, Clemens Lang  wrote:
> 
> Hello MacPorts users and developers,
> 
> ... Please read through
> https://trac.macports.org/wiki/WorkingWithGit
> which contains a number of guidelines for working with the MacPorts Git
> repositories.
> 
The Working with Git page is pretty good.  There is a lot of good background 
and explanation of why and how Git is different from svn.

However, would it be possible to add a tangible example of updating a port to 
that page?  

I know a little bit about Subversion and less about Git.  I would like to see a 
soup-to-nuts example of cloning the ports tree, updating a Portfile, maybe 
deleting an old patch and adding a new one, and getting the updated port into 
MacPorts (direct commit v. pull request).  It would be helpful if one-time 
requirements (setting name and email address) were clearly separated from 
repetitive steps (pulling changes from master?).  Otherwise, it is going to be 
a wee bit nerve-wracking the first few times...

Also, is the consensus that a graphical user interface over git more likely to 
be harmful than helpful?  The Tools section at the bottom of the page doesn’t 
give any kind of recommendation.

Craig
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev