Re: GitHub usernames in maintainers field
On 12 February 2017 at 06:12, Joshua Root wrote: > On 2017-2-12 12:07 , Ryan Schmidt wrote: >> >> The mega $Id$ removal commit also exposed a limitation of the GitHub >> git-to-svn gateway, which we are using on our server in the mprsyncup >> script. I reported the limitation to GitHub and they said they would look >> into it but I don't know if they've fixed it. I believe we can avoid >> triggering this limitation again by not modifying too many files in a single >> commit. If we hit the limitation again, manual intervention is required to >> throw away the Subversion working copy on the server, and then after the new >> working copy is checked out the portindexes get regenerated, which takes >> hours; I want to avoid going through all that hassle ever again. > > This at least could be avoided by checking out directly from git, I presume? There is also no need to do a single commit. We can do one commit per folder or so. Do we have a ticket to "upgrade" mprsyncup to use git? Mojca PS: In any case the optimisation of with huge builds on the buildbot is currently in a much better shape than it used to be a few months back. Builds of ports with known-to-fail dependencies are no longer attempted, existing packages are not rebuilt, problems with 45 minutes of waiting time on 10.5 were fixed ... Regarding the desire to build all ports at some point, I would still be in favour of supporting meta port names on the buildbot https://trac.macports.org/ticket/52989
Re: GitHub usernames in maintainers field
On Feb 11, 2017, at 23:12, Joshua Root wrote: > On 2017-2-12 12:07 , Ryan Schmidt wrote: >> The mega $Id$ removal commit also exposed a limitation of the GitHub >> git-to-svn gateway, which we are using on our server in the mprsyncup >> script. I reported the limitation to GitHub and they said they would look >> into it but I don't know if they've fixed it. I believe we can avoid >> triggering this limitation again by not modifying too many files in a single >> commit. If we hit the limitation again, manual intervention is required to >> throw away the Subversion working copy on the server, and then after the new >> working copy is checked out the portindexes get regenerated, which takes >> hours; I want to avoid going through all that hassle ever again. > > This at least could be avoided by checking out directly from git, I presume? Right, the mprsyncup script just has a lot of svn specifics in it that we haven't tried to eliminate yet so it was easier to use the git-to-svn bridge.
Re: GitHub usernames in maintainers field
On 2017-2-12 12:07 , Ryan Schmidt wrote: The mega $Id$ removal commit also exposed a limitation of the GitHub git-to-svn gateway, which we are using on our server in the mprsyncup script. I reported the limitation to GitHub and they said they would look into it but I don't know if they've fixed it. I believe we can avoid triggering this limitation again by not modifying too many files in a single commit. If we hit the limitation again, manual intervention is required to throw away the Subversion working copy on the server, and then after the new working copy is checked out the portindexes get regenerated, which takes hours; I want to avoid going through all that hassle ever again. This at least could be avoided by checking out directly from git, I presume? - Josh
Re: GitHub usernames in maintainers field
I appreciate that we are making these changes slowly. This gives the buildbot time to catch up on other commits. I don't want to commit all maintainer-to-GitHub changes in one revision and then cancel the buildbot build, as we did with the $Id$ removal commit, because valuable builds are being done by the buildbot as a result of these commits which I want to allow to happen. The mega $Id$ removal commit also exposed a limitation of the GitHub git-to-svn gateway, which we are using on our server in the mprsyncup script. I reported the limitation to GitHub and they said they would look into it but I don't know if they've fixed it. I believe we can avoid triggering this limitation again by not modifying too many files in a single commit. If we hit the limitation again, manual intervention is required to throw away the Subversion working copy on the server, and then after the new working copy is checked out the portindexes get regenerated, which takes hours; I want to avoid going through all that hassle ever again.
Re: GitHub usernames in maintainers field
There is also a list on https://trac.macports.org/wiki/MacPortsDevelopers I'll probably do the ones from there if nobody beats me to it. Sent from my iPhone... > On Feb 11, 2017, at 15:05, Mojca Miklavec wrote: > >> On 11 February 2017 at 23:25, Ryan Schmidt wrote: >>> On Feb 11, 2017, at 13:14, Mojca Miklavec wrote: On 11 February 2017 at 20:05, Jeremy Huddleston Sequoia wrote: Do we have a mapping list somewhere, so we can just script this for known mappings? >>> >>> The list should be available on our Trac (at least for those who >>> logged in with their github account). >> >> I assumed such a list would only be visible to our Trac sysadmins. Can it be >> seen by anyone logging in to Trac? If so, how? > > Yes and no. One cannot get a list directly, but one can just enter the > email in the CC field and it will suggest you which username belongs > to that email. We don't have a list of all emails either, but that > could be assembled from Portfiles without too much hassle and looked > up one-by-one or scripted if someone really insisted. > > I've been using that workaround to figure out whom to @mention on > various pull requests. > > I don't know if there are any security implications (provided that > emails are public in Portfiles already). But probably this reveals > emails from any GitHub user that ever logged in to our Trac as well, > not just those of maintainers. > > The old trac would hide full email addresses. Anyone logged in as > committer would see full emails, I'm not sure if random newbies would > also see full emails before the transition. I guess they do now. > > My idea would be to get the "official list" from the sysadmins and do > auto-replacement for all ports at the same time. Waiting for > individual committers to do the changes will take forever and just > means a lot of manual work + hundreds of commits (or hundreds of pull > requests to be merged manually from maintainers without commit > rights). Not to even mention all the typos, forgotten ports etc. (For > that reason I would be in favour of keeping a single obfuscated list > somewhere rather than duplicating all entries all over the place. > Duplication is acceptable, but I really don't like manual work.) > > Mojca
Re: GitHub usernames in maintainers field
On 11 February 2017 at 23:25, Ryan Schmidt wrote: > On Feb 11, 2017, at 13:14, Mojca Miklavec wrote: >> On 11 February 2017 at 20:05, Jeremy Huddleston Sequoia wrote: >>> Do we have a mapping list somewhere, so we can just script this for known >>> mappings? >> >> The list should be available on our Trac (at least for those who >> logged in with their github account). > > I assumed such a list would only be visible to our Trac sysadmins. Can it be > seen by anyone logging in to Trac? If so, how? Yes and no. One cannot get a list directly, but one can just enter the email in the CC field and it will suggest you which username belongs to that email. We don't have a list of all emails either, but that could be assembled from Portfiles without too much hassle and looked up one-by-one or scripted if someone really insisted. I've been using that workaround to figure out whom to @mention on various pull requests. I don't know if there are any security implications (provided that emails are public in Portfiles already). But probably this reveals emails from any GitHub user that ever logged in to our Trac as well, not just those of maintainers. The old trac would hide full email addresses. Anyone logged in as committer would see full emails, I'm not sure if random newbies would also see full emails before the transition. I guess they do now. My idea would be to get the "official list" from the sysadmins and do auto-replacement for all ports at the same time. Waiting for individual committers to do the changes will take forever and just means a lot of manual work + hundreds of commits (or hundreds of pull requests to be merged manually from maintainers without commit rights). Not to even mention all the typos, forgotten ports etc. (For that reason I would be in favour of keeping a single obfuscated list somewhere rather than duplicating all entries all over the place. Duplication is acceptable, but I really don't like manual work.) Mojca
Re: GitHub usernames in maintainers field
On Feb 11, 2017, at 13:14, Mojca Miklavec wrote: > On 11 February 2017 at 20:05, Jeremy Huddleston Sequoia wrote: >> Do we have a mapping list somewhere, so we can just script this for known >> mappings? > > The list should be available on our Trac (at least for those who > logged in with their github account). I assumed such a list would only be visible to our Trac sysadmins. Can it be seen by anyone logging in to Trac? If so, how?
Re: GitHub usernames in maintainers field
On 11 February 2017 at 20:05, Jeremy Huddleston Sequoia wrote: > Do we have a mapping list somewhere, so we can just script this for known > mappings? The list should be available on our Trac (at least for those who logged in with their github account). Mojca
Re: GitHub usernames in maintainers field
Do we have a mapping list somewhere, so we can just script this for known
mappings?
Anyone interested in doing this for their ports might find this useful:
for g in */ ; do
sed -i '' '/maintainers/s/\([^{@]\)jeremyhu/\1{jeremyhu @jeremyhu}/g'
$g/*/Portfile
done
There certainly could be some false matches with that, so check `git diff`
first.
--Jeremy
> On Feb 4, 2017, at 17:30, Mojca Miklavec wrote:
>
> Hi,
>
> On 4 February 2017 at 17:07, Clemens Lang wrote:
>> On Thu, Feb 02, 2017 at 03:12:27PM -0800, Eitan Adler wrote:
maintainers {jmr @jmroot} openmaintainer
>>>
>>> Why did we choose to do it this way instead of a central list of email
>>> -> github mapping? This method requires some level of replication.
>>
>> Ports can exists outside of a port repository. External repositories
>> could have different assignments, Portfiles could even exist without a
>> mapping file at all.
>
> What we need is:
> - ability to send emails to maintainers (that includes the buildbot)
> - ability to @mention them in GitHub PRs
> - ability to assign or CC people in Trac tickets
>
> I would in fact prefer to see the official tickets to have a common
> "database of maintainers" with obfuscated email addresses together
> with GitHub usernames and then only see one entry for maintainers in
> the Portfile (but I'm not so strongly opposing having both in the
> Portfile; in particular not now that having both in the Portfile is
> supported and having a separate database is not).
>
> I don't care that much what exactly is written in the Portfile, but I
> need the ability to get the email and @username with "port info" at
> least.
>
> If maintainers simply start *replacing* their emails with their
> usernames in portfiles (which is what I already saw happening in some
> tickets/pull requests a while ago) then:
>
> - we'll lose the ability to email them
> - we won't be able to send them auto-generated emails in case of
> buildbot failures
> - we won't quite know whether a maintainer is a committer or not
>
> and we don't want that.
>
>
> In my opinion the initial addition of github usernames next to email
> addresses should happen with a script. Doing this manually is:
> - tedious, lots of work
> - error prone
> - destined to take forever (using the mapping between emails and
> github accounts from Trac wuould be mo reliable source of information
> that waiting for maintainers)
>
> Maintainers that we'll most urgently want to reach won't answer the
> call to change their usernames; hack, I already managed to open a
> "port abandoned" ticket for a committer who still refuses (or at least
> doesn't bother) to replace his super ancient email address (that he
> never uses to communicate with other macporters) with his macports
> handle, so it wasn't obvious that it was the same person.
>
> Mojca
smime.p7s
Description: S/MIME cryptographic signature
Re: GitHub usernames in maintainers field
Hi,
On 4 February 2017 at 17:07, Clemens Lang wrote:
> On Thu, Feb 02, 2017 at 03:12:27PM -0800, Eitan Adler wrote:
>> > maintainers {jmr @jmroot} openmaintainer
>>
>> Why did we choose to do it this way instead of a central list of email
>> -> github mapping? This method requires some level of replication.
>
> Ports can exists outside of a port repository. External repositories
> could have different assignments, Portfiles could even exist without a
> mapping file at all.
What we need is:
- ability to send emails to maintainers (that includes the buildbot)
- ability to @mention them in GitHub PRs
- ability to assign or CC people in Trac tickets
I would in fact prefer to see the official tickets to have a common
"database of maintainers" with obfuscated email addresses together
with GitHub usernames and then only see one entry for maintainers in
the Portfile (but I'm not so strongly opposing having both in the
Portfile; in particular not now that having both in the Portfile is
supported and having a separate database is not).
I don't care that much what exactly is written in the Portfile, but I
need the ability to get the email and @username with "port info" at
least.
If maintainers simply start *replacing* their emails with their
usernames in portfiles (which is what I already saw happening in some
tickets/pull requests a while ago) then:
- we'll lose the ability to email them
- we won't be able to send them auto-generated emails in case of
buildbot failures
- we won't quite know whether a maintainer is a committer or not
and we don't want that.
In my opinion the initial addition of github usernames next to email
addresses should happen with a script. Doing this manually is:
- tedious, lots of work
- error prone
- destined to take forever (using the mapping between emails and
github accounts from Trac wuould be mo reliable source of information
that waiting for maintainers)
Maintainers that we'll most urgently want to reach won't answer the
call to change their usernames; hack, I already managed to open a
"port abandoned" ticket for a committer who still refuses (or at least
doesn't bother) to replace his super ancient email address (that he
never uses to communicate with other macporters) with his macports
handle, so it wasn't obvious that it was the same person.
Mojca
Re: GitHub usernames in maintainers field
Hi,
On Thu, Feb 02, 2017 at 03:12:27PM -0800, Eitan Adler wrote:
> > maintainers {jmr @jmroot} openmaintainer
>
> Why did we choose to do it this way instead of a central list of email
> -> github mapping? This method requires some level of replication.
Ports can exists outside of a port repository. External repositories
could have different assignments, Portfiles could even exist without a
mapping file at all.
All problems that could have been solved, but presumably in the long run
more and more people will just have their GitHub username in Portfiles,
so this is easier and quicker to implement for now.
--
Clemens
Re: GitHub usernames in maintainers field
On 2 February 2017 at 08:33, Joshua Root wrote:
> MacPorts 2.3.5 added the ability to list GitHub usernames as well as email
> addresses in the maintainers field of Portfiles. Basically instead of this:
>
> maintainers jmr openmaintainer
>
> you can do this:
>
> maintainers {jmr @jmroot} openmaintainer
Why did we choose to do it this way instead of a central list of email
-> github mapping? This method requires some level of replication.
--
Eitan Adler
GitHub usernames in maintainers field
MacPorts 2.3.5 added the ability to list GitHub usernames as well as
email addresses in the maintainers field of Portfiles. Basically instead
of this:
maintainers jmr openmaintainer
you can do this:
maintainers {jmr @jmroot} openmaintainer
All the email obfuscation etc still works the same way, you just wrap
each email and GitHub username that correspond to the same person in
braces together.
Documentation of this should hopefully be added to the Guide soon. I
would encourage port maintainers to add their GitHub username to their
ports.
A couple more examples:
maintainers {jmr @jmroot} {raimue @raimue}
maintainers {jmr @jmroot} {example.com:user @example} openmaintainer
- Josh
