Re: Git tools for managing patchsets

[Lawrence Velázquez]

> On Oct 24, 2016, at 7:03 PM, Michael  wrote:
> 
>> On 2016-10-24, at 2:57 PM, Marko Käning  wrote:
>> 
>> Well, but I think what you, Michael, are describing, is only needed
>> if you work with many patches which aren’t really committed to any
>> repository.
> 
> Actually, it's something else. It's the tracking of the history of
> changes when those changes get rebased.

The history is tracked by the MacPorts repository.

> This is not about the port files; those work just fine. This is about
> the patchsets needed to port a program to OS X.

There is no difference.

> If I have a set of patches to port version 1 of a program to OS X,
> what happens when version 2 of the program comes out?

The maintainer adjusts the patches for v2, adds some new ones, removes
ones that are no longer needed, and commits the new set of patches to
the repository. No history is lost.

> If you just rebase the patches onto version 2's code, then there is no
> connection between the patches for v1 and v2

Yes, there is. They are linked by the MacPorts repository history.

> there's no good way to compare how your patches for version 1 compared
> to the patches for version 2, or version 3. Etc.

Diff between the commit that updates the port to v2, and its immediate
parent.

> The answer is, that there are now two good methods for doing this. Git
> for Windows has one method (in fairness, I did not understand it, it
> seems mostly manual, but has been developed/improved over years), and
> the just-released git-series has a second one (based around extensions
> to normal git commands).

Not seeing how either of those tools applies to us.

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

[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: Git tools for managing patchsets

[Michael]

On 2016-10-24, at 2:57 PM, Marko Käning  wrote:

> Hi folks,
> 
> when I read only the first two paragraphs of this thread...
> 
> On 24 Oct 2016, at 18:37 , Michael  wrote:
>> So since MacPorts is moving to git, and from what I saw in the "how to use 
>> git" docs you mentioned, you apparently want people to work with patchsets 
>> rebased onto the current head from upstream.
>> 
>> As I was thinking about that, I realized that you lose your history of the 
>> patchset in the process.
> 
> ... I already got the shivers! My goodness, how much did I enjoy the ease of 
> Mercurial! Loosing history because of a patch set?!
> :-/
> 
> Well, but I think what you, Michael, are describing, is only needed if you 
> work with many patches which aren’t really committed to any repository.

Actually, it's something else. It's the tracking of the history of changes when 
those changes get rebased.

This is not about the port files; those work just fine. This is about the 
patchsets needed to port a program to OS X.

If I have a set of patches to port version 1 of a program to OS X, what happens 
when version 2 of the program comes out?

If you just rebase the patches onto version 2's code, then there is no 
connection between the patches for v1 and v2; there's no good way to compare 
how your patches for version 1 compared to the patches for version 2, or 
version 3. Etc.

The answer is, that there are now two good methods for doing this. Git for 
Windows has one method (in fairness, I did not understand it, it seems mostly 
manual, but has been developed/improved over years), and the just-released 
git-series has a second one (based around extensions to normal git commands).

---
Entertaining minecraft videos
http://YouTube.com/keybounce

___
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

[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: Git tools for managing patchsets

[Clemens Lang]

On Mon, Oct 24, 2016 at 11:57:51PM +0200, Marko Käning wrote:
> The only question mark I have there is:
> 
>   Will we ask the committers to squash their changesets or prefer to
>   clutter the main repo with potentially many tiny iterations for the
>   changed ports??

I think "clutter" is not the appropriate word here. We will also not ask
committers to generally squash all their changes.

> Personally I don’t like history rewriting, but a squash every now and
> then seems fine to me, as an update to a port sometimes requires a few
> iterations until it is ready for pushing to the central repo and it is
> usually one logical unit deserving an atomic commit.

It will probably be up to you as a MacPorts developer. I agree that
logical units should be committed atomically, but that doesn't mean that
you cannot commit multiple atomic changes in one push or pull request.

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

Re: Git tools for managing patchsets

[Lawrence Velázquez]

> On Oct 24, 2016, at 5:57 PM, Marko Käning  wrote:
> 
> The only question mark I have there is:
> 
>   Will we ask the committers to squash their changesets or prefer
>   to clutter the main repo with potentially many tiny iterations
>   for the changed ports??
> 
> Personally I don’t like history rewriting, but a squash every now and
> then seems fine to me, as an update to a port sometimes requires a few
> iterations until it is ready for pushing to the central repo and it is
> usually one logical unit deserving an atomic commit.

I would encourage committers to learn how to rewrite history and then
edit pull request branches as they see fit before rebasing them onto
master. Don't assume that contributors will submit logical commits with
polished messages. Even now, I break all but the simplest Trac patches
into multiple commits.

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

Re: Git tools for managing patchsets

[Marko Käning]

Hi folks,

when I read only the first two paragraphs of this thread...

On 24 Oct 2016, at 18:37 , Michael  wrote:
> So since MacPorts is moving to git, and from what I saw in the "how to use 
> git" docs you mentioned, you apparently want people to work with patchsets 
> rebased onto the current head from upstream.
> 
> As I was thinking about that, I realized that you lose your history of the 
> patchset in the process.

... I already got the shivers! My goodness, how much did I enjoy the ease of 
Mercurial! Loosing history because of a patch set?!
:-/

Well, but I think what you, Michael, are describing, is only needed if you work 
with many patches which aren’t really committed to any repository.

Whenever a MacPorts maintainer has finished polishing her/his changes to a 
specific port, those changes will be rebased on top of the current master - 
maintaining all the history - as pointed out by others already.

The only question mark I have there is:

Will we ask the committers to squash their changesets
or prefer to clutter the main repo with potentially
many tiny iterations for the changed ports??

Personally I don’t like history rewriting, but a squash every now and then 
seems fine to me, as an update to a port sometimes requires a few iterations 
until it is ready for pushing to the central repo and it is usually one logical 
unit deserving an atomic commit.

Good night,
Marko

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

Re: QTKit & macOS Sierra

[Marko Käning]

Hi René,

On 24 Oct 2016, at 09:57 , René J.V. Bertin  wrote:

> On Monday October 24 2016 09:54:56 Marko Käning wrote:
> 
> Indirectly, yes. I get the impression port:opencv has been unmaintained for a 
> while, so maybe you can update the official copy from mine?

I’ve added all patches to the main opencv ticket for sierra [1] for stromnov to 
review and also created a ticket for the required changes to CMake’s portgroup 
version 1.1 [2].

@René, can you perhaps add a little description to [2]? Let me know if you 
can’t modify the ticket’s description field. I’ll do that for you in that case.

Thanks in advance!
Greets,
Marko



[1] https://trac.macports.org/ticket/52328
[2] https://trac.macports.org/ticket/52699
___
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

[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

[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: Trac & Subversion available again

[Rainer Müller]

On 2016-10-24 20:24, Daniel J. Luke wrote:
> On Oct 24, 2016, at 1:26 PM, Clemens Lang  wrote:
>> On Mon, Oct 24, 2016 at 12:54:23PM -0400, Daniel J. Luke wrote:
>>> This looks like it's true for me as well (cannot edit tickets beyond
>>> making comments).
>>
>> Try clearing your cache (a force-reload should do that). It seems the
>> problem can also be that the edit form is there, but hidden for you due
>> to some CSS rules.
> 
> no luck (also tried a second browser just in case).

The permission to edit tickets is granted by being a member of the
macports/developers team on GitHub.

Existing developers need to request to be added to this team by sending
a mail to the macports-infra mailing list as instructed in the announcement.

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

Re: Trac & Subversion available again

[Daniel J. Luke]

On Oct 24, 2016, at 1:26 PM, Clemens Lang  wrote:
> On Mon, Oct 24, 2016 at 12:54:23PM -0400, Daniel J. Luke wrote:
>> This looks like it's true for me as well (cannot edit tickets beyond
>> making comments).
> 
> Try clearing your cache (a force-reload should do that). It seems the
> problem can also be that the edit form is there, but hidden for you due
> to some CSS rules.

no luck (also tried a second browser just in case).
-- 
Daniel J. Luke



___
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

[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

[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: Git tools for managing patchsets

[Michael]

> I think Michael is thinking:
> 
> I have port 'foo' in macports and it requires a (rather large/complicated) 
> patch that currently sits in files/ and has to be re-generated every time 
> upstream releases a new version of 'foo'
> 
> And essentially we're saying "we haven't done anything to make that easier" 
> (Macports repo move doesn't change how you are dealing with this now).
> 
> While this should be a minority of ports (and all port maintainers should 
> work to get their patches incorporated upstream whenever possible), it would 
> be worthwhile in looking at things to make handling this situation easier 
> (especially if similar projects already have tools to deal with it). It's 
> also perfectly reasonable to punt on this until after we've settled in after 
> the repo move.
> 
> -- 
> Daniel J. Luke

Exactly.

I'm looking into what "Git for Windows" does, because this is exactly what they 
do -- maintain a large set of patches that are release specific and not 
integrated upstream. And, it's my understanding that MacPorts is basically a 
pair of (port file: how to compile; patch files: how Mac OS / Xnu / Mach 
differs from Unix/Linux/Debian). I was under the impression that the switch 
from SVN to maintain the patch files to Git to maintain the patch files (not 
the port files) was the issue where you wanted rebases at each upstream release.

---
Entertaining minecraft videos
http://YouTube.com/keybounce

___
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

[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

[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

[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

[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: Git tools for managing patchsets

[Daniel J. Luke]

On Oct 24, 2016, at 1:39 PM, Clemens Lang  wrote:
> On Mon, Oct 24, 2016 at 10:29:19AM -0700, Michael wrote:
>> My understanding -- and maybe this is my error here -- is that your
>> patches have to be constantly rebased onto the current version every
>> time the upstream releases a new version.
> 
> I think our understanding of what "upstream" is in this sentence
> differs. We are *not* talking about patches to be applied to packaged
> software, we are talking about changes to the port definitions, i.e. the
> Portfiles themselves. "Upstream" in this case means the master branch of
> github.com/macports/macports-ports, as opposed to a branch in a fork of
> your own that you may be using to prepare changes for a pull request.

I think Michael is thinking:

I have port 'foo' in macports and it requires a (rather large/complicated) 
patch that currently sits in files/ and has to be re-generated every time 
upstream releases a new version of 'foo'

And essentially we're saying "we haven't done anything to make that easier" 
(Macports repo move doesn't change how you are dealing with this now).

While this should be a minority of ports (and all port maintainers should work 
to get their patches incorporated upstream whenever possible), it would be 
worthwhile in looking at things to make handling this situation easier 
(especially if similar projects already have tools to deal with it). It's also 
perfectly reasonable to punt on this until after we've settled in after the 
repo move.

-- 
Daniel J. Luke



___
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

[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: Git tools for managing patchsets

[Clemens Lang]

Hi,

On Mon, Oct 24, 2016 at 10:29:19AM -0700, Michael wrote:
> My understanding -- and maybe this is my error here -- is that your
> patches have to be constantly rebased onto the current version every
> time the upstream releases a new version.

I think our understanding of what "upstream" is in this sentence
differs. We are *not* talking about patches to be applied to packaged
software, we are talking about changes to the port definitions, i.e. the
Portfiles themselves. "Upstream" in this case means the master branch of
github.com/macports/macports-ports, as opposed to a branch in a fork of
your own that you may be using to prepare changes for a pull request.

> When you rebase, you have new commits, and a new history. So the
> history of how your patchset has changed over time resets at each
> rebase at each new upstream release.

There is no "upstream release", just the continous stream of development
happening in macports-ports. We request that all changes to Portfiles
should cleanly rebase on top of our current HEAD of master, so that we
don't get at least two commits (the change & a merge commit) for each
pull request. Yes, the history of that change while it is developed may
be altered by the rebase, but these changes should ideally not be
long-running patches.

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

Re: Git tools for managing patchsets

[Ryan Schmidt]

On Oct 24, 2016, at 12:29, Michael  wrote:
> 
> 
>> On 2016-10-24, at 10:25 AM, Clemens Lang  wrote:
>> 
>> Hi,
>> 
>>> On Mon, Oct 24, 2016 at 09:37:37AM -0700, Michael wrote:
>>> So since MacPorts is moving to git, and from what I saw in the "how to
>>> use git" docs you mentioned, you apparently want people to work with
>>> patchsets rebased onto the current head from upstream.
>>> 
>>> As I was thinking about that, I realized that you lose your history of
>>> the patchset in the process.
>> 
>> If I understand this correctly, this is a problem that applies to
>> repositories of source code, not repositories of build description
>> files. The way we currently keep patches for our ports is putting them
>> next to the Portfiles in what will be the macports-ports Git repository.
>> Consequently, we already have the history of these patchfiles.
>> 
>> As an example, let's consider the yubico-c-client port. It's defined in
>> MacPorts in
>> security/yubico-c-client/Portfile
>> The patches to be applied to the source code of yubico-c-client are
>> under version control in
>> security/yubico-c-client/files
>> which already gives us a history of the patches.
> 
> My understanding -- and maybe this is my error here -- is that your patches 
> have to be constantly rebased onto the current version every time the 
> upstream releases a new version.
> 
> When you rebase, you have new commits, and a new history. So the history of 
> how your patchset has changed over time resets at each rebase at each new 
> upstream release.
> 
> That is my understanding of the issue; if this is wrong, then I'm trying to 
> solve a non-existent problem.
> 
> (And if you don't have that problem, please tell me how you are using rebase 
> and not losing history :-). 

The way that we handle patches in a port's files directory won't change just 
because we move from svn to git. Or maybe I don't understand what you're 
saying. 
___
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

[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

[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: Git tools for managing patchsets

[Michael]

On 2016-10-24, at 10:25 AM, Clemens Lang  wrote:

> Hi,
> 
> On Mon, Oct 24, 2016 at 09:37:37AM -0700, Michael wrote:
>> So since MacPorts is moving to git, and from what I saw in the "how to
>> use git" docs you mentioned, you apparently want people to work with
>> patchsets rebased onto the current head from upstream.
>> 
>> As I was thinking about that, I realized that you lose your history of
>> the patchset in the process.
> 
> If I understand this correctly, this is a problem that applies to
> repositories of source code, not repositories of build description
> files. The way we currently keep patches for our ports is putting them
> next to the Portfiles in what will be the macports-ports Git repository.
> Consequently, we already have the history of these patchfiles.
> 
> As an example, let's consider the yubico-c-client port. It's defined in
> MacPorts in
>  security/yubico-c-client/Portfile
> The patches to be applied to the source code of yubico-c-client are
> under version control in
>  security/yubico-c-client/files
> which already gives us a history of the patches.

My understanding -- and maybe this is my error here -- is that your patches 
have to be constantly rebased onto the current version every time the upstream 
releases a new version.

When you rebase, you have new commits, and a new history. So the history of how 
your patchset has changed over time resets at each rebase at each new upstream 
release.

That is my understanding of the issue; if this is wrong, then I'm trying to 
solve a non-existent problem.

(And if you don't have that problem, please tell me how you are using rebase 
and not losing history :-).

---
Entertaining minecraft videos
http://YouTube.com/keybounce

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

Re: Git tools for managing patchsets

[Clemens Lang]

Hi,

On Mon, Oct 24, 2016 at 09:37:37AM -0700, Michael wrote:
> So since MacPorts is moving to git, and from what I saw in the "how to
> use git" docs you mentioned, you apparently want people to work with
> patchsets rebased onto the current head from upstream.
> 
> As I was thinking about that, I realized that you lose your history of
> the patchset in the process.

If I understand this correctly, this is a problem that applies to
repositories of source code, not repositories of build description
files. The way we currently keep patches for our ports is putting them
next to the Portfiles in what will be the macports-ports Git repository.
Consequently, we already have the history of these patchfiles.

As an example, let's consider the yubico-c-client port. It's defined in
MacPorts in
  security/yubico-c-client/Portfile
The patches to be applied to the source code of yubico-c-client are
under version control in
  security/yubico-c-client/files
which already gives us a history of the patches.

If I understand the tools you proposed correctly, they work on top of
the source code of yubico-c-client, which would be a clone of
  https://github.com/Yubico/yubico-c-client


Or am I misunderstanding things here?

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

[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: Trac & Subversion available again

[Daniel J. Luke]

On Oct 23, 2016, at 12:02 AM, Joshua Root  wrote:
> On 2016-10-23 14:48 , Jeremy Huddleston Sequoia wrote:
>> I still cannot edit tickets (beyond making comments).  My @macports.org 
>> email address was on my github account months ago, so that's not the issue.
> 
> The problem would have been that you weren't a member of the MacPorts org on 
> GitHub. Once you accept the invitation I just sent, you should be able to 
> edit tickets.

This looks like it's true for me as well (cannot edit tickets beyond making 
comments).

-- 
Daniel J. Luke



___
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

[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

Git tools for managing patchsets

[Michael]

So since MacPorts is moving to git, and from what I saw in the "how to use git" 
docs you mentioned, you apparently want people to work with patchsets rebased 
onto the current head from upstream.

As I was thinking about that, I realized that you lose your history of the 
patchset in the process.

The Git mailing list pointed me to these resources, that I thought I'd pass up 
to you.

1. git-series: track changes to a patch series over time
" Debian package maintenance tends to have this exact family of problems:
 maintaining a set of patches to upstream code, rebasing those patches on
 new upstream versions, reorganizing/refining/adding/dropping patches,
 having individual patches merged upstream, and backporting changes *from*
 upstream."

https://lists.debian.org/debian-devel-announce/2016/10/msg4.html

2. Stacked git -- looks like a similar system, tracking a "stack of patches".
https://stgit.org/

3. A discussion looking at git-series vs stacked git:
https://lists.debian.org/debian-devel/2016/08/msg00220.html


---
Entertaining minecraft videos
http://YouTube.com/keybounce

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

Re: [154081] trunk/dports/textproc/extractopinion/Portfile

[Ryan Schmidt]

> On Oct 24, 2016, at 6:56 AM, Mojca Miklavec  wrote:
> 
> On 20 October 2016 at 10:41, Mojca Miklavec wrote:
>> On 20 October 2016 at 04:42, Joshua Root wrote:
>>> On 2016-10-20 13:23 , Ryan Schmidt wrote:
 
 
> On Oct 19, 2016, at 9:04 PM, mo...@macports.org wrote:
> 
> Revision
> 154081
> Author
> mo...@macports.org
> Date
> 2016-10-19 19:04:20 -0700 (Wed, 19 Oct 2016)
> Log Message
> 
> extractopinion: switch to perl5.24 (#52081)
> Modified Paths
> 
>• trunk/dports/textproc/extractopinion/Portfile
 
 
> @@ -29,7 +29,7 @@
> depends_lib port:crfpp \
> port:libiconv \
> port:gawk \
> -port:p5.22-text-csv_xs \
> +port:p5.24-text-csv_xs \
> port:juman6 \
> port:knp3
 
 
 This only changes the dependency but doesn't tell the build system to use
 it. That needs to be done in patch-perl.diff. (We've actually forgotten to
 change this every time since perl5.12.)
>>> 
>>> Probably a good reason to use a placeholder string in the patch file and
>>> then reinplace it with the actual version-specific string in the portfile.
>> 
>> I agree. But then again this might also be a good reason to ask
>> ourselves whether we have any users of this software at all. Not even
>> the patch phase succeeds and there were apparently no complaints about
>> a broken port for years. (Unless the users gave up too soon and didn't
>> know how to file a bug report.)
> 
> I committed a fix in r154202 (https://trac.macports.org/changeset/154202).
> 
> If I missed something, please let me know.

Since r154202 changes the files that get installed, the revision should be 
increased.


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

Re: [154081] trunk/dports/textproc/extractopinion/Portfile

[Mojca Miklavec]

On 20 October 2016 at 10:41, Mojca Miklavec wrote:
> On 20 October 2016 at 04:42, Joshua Root wrote:
>> On 2016-10-20 13:23 , Ryan Schmidt wrote:
>>>
>>>
 On Oct 19, 2016, at 9:04 PM, mo...@macports.org wrote:

 Revision
 154081
 Author
 mo...@macports.org
 Date
 2016-10-19 19:04:20 -0700 (Wed, 19 Oct 2016)
 Log Message

 extractopinion: switch to perl5.24 (#52081)
 Modified Paths

 • trunk/dports/textproc/extractopinion/Portfile
>>>
>>>
 @@ -29,7 +29,7 @@
  depends_lib port:crfpp \
  port:libiconv \
  port:gawk \
 -port:p5.22-text-csv_xs \
 +port:p5.24-text-csv_xs \
  port:juman6 \
  port:knp3
>>>
>>>
>>> This only changes the dependency but doesn't tell the build system to use
>>> it. That needs to be done in patch-perl.diff. (We've actually forgotten to
>>> change this every time since perl5.12.)
>>
>> Probably a good reason to use a placeholder string in the patch file and
>> then reinplace it with the actual version-specific string in the portfile.
>
> I agree. But then again this might also be a good reason to ask
> ourselves whether we have any users of this software at all. Not even
> the patch phase succeeds and there were apparently no complaints about
> a broken port for years. (Unless the users gave up too soon and didn't
> know how to file a bug report.)

I committed a fix in r154202 (https://trac.macports.org/changeset/154202).

If I missed something, please let me know.

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

Re: QTKit & macOS Sierra

[René J . V . Bertin]

On Monday October 24 2016 09:54:56 Marko Käning wrote:

Indirectly, yes. I get the impression port:opencv has been unmaintained for a 
while, so maybe you can update the official copy from mine?

>I think I already let you know, that this did the job! :)
>
>
>
>
>On 21 Oct 2016, at 01:54 , René J.V. Bertin  wrote:
>
>> On Friday October 21 2016 00:38:02 Marko Käning wrote:
>>> Please find attached opencv's log.
>> 
>> I've tested and committed a patch that builds opencv using AVFoundation 
>> instead of QTKit on 10.9 and up. Hopefully that solves your issue.
>> 
>> night!
>> R.
>

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