> On Nov 12, 2016, at 9:33 AM, Clemens Lang <c...@macports.org> wrote: > > Hi *, > > On Sat, Nov 12, 2016 at 04:19:44PM +0100, Clemens Lang wrote: >> >> https://github.com/macports/macports-base/commit/30c27d5d3ad169ffa5f55465cf9663dbd1ff7537 > >> commit 30c27d5d3ad169ffa5f55465cf9663dbd1ff7537 >> Author: Clemens Lang <c...@macports.org> >> AuthorDate: Sun Nov 6 18:11:49 2016 +0100 >> >> Support multi-valued maintainers >> >> Since our move to GitHub it is sometimes hard to find out whether a pull >> request was sent by a maintainer or what a maintainer's Trac or GitHub >> account is. This can be solved by allowing GitHub usernames as >> maintainers, but puts us in the situation of not having an email address >> on file for a maintainer. >> >> Solve this by supporting multi-valued maintainer fields using Tcl lists, >> so that >> >> maintainers {@github-username macports-handle example.com:localpart} >> >> works and is displayed as beloging to a single person. >> >> While we're at it, drop the two implementations of unobscure_maintainers >> and provide a public API in macports1.0 to be used. >> >> Additionally, add tests that verify the behavior of >> macports::unobscure_maintainers. > > I just merged the above commit to base master. This would allow us to > use GitHub usernames together with MacPorts handles and email addresses > as maintainers in ports. > > This is a new feature, so by our normal rules, this shouldn't be > backported to the 2.3.5 bugfix release due soon. However, it is related > to the GitHub migration and would provide relief for a problem we see > with GitHub quite often at the moment, so I'd like to hear your opinions > on whether we should cherry-pick the change into 2.3.5. > > There is a related pull request for the guide [1] I still need to update > to match the latest adjustments in the base commit, but that is not time > critical as it can be done after the base release. > > Opinions? > > [1] https://github.com/macports/macports-guide/pull/1
Many of the changes in 2.3.5 are to deal with the GitHub transition, so I would be in favor of releasing this change now as well. Perhaps it should more properly be called 2.4, but since our master is in no fix state to be branched for 2.4 at this time and we are still figuring out our release process on GitHub, it might be simpler to do this next release from the 2.3 branch and call it 2.3.5.
