Issues with oudated ports / GitHub

[Marcel Bischoff]

On 16/10/08, Chris Jones wrote:
>
>
>> On 8 Oct 2016, at 11:29 am, Ryan Schmidt <ryandesign at macports.org> wrote:
>>
>>
>>> On Oct 7, 2016, at 2:18 PM, Christopher Jones <jonesc at hep.phy.cam.ac.uk> wrote:
>>>
>>>
>>>> On 7 Oct 2016, at 8:12 pm, Ryan Schmidt <ryandesign at macports.org> wrote:
>>>>
>>>>
>>>>>> On Oct 7, 2016, at 1:40 PM, Lawrence Velázquez <larryv at macports.org> wrote:
>>>>>>
>>>>>> On Oct 7, 2016, at 2:09 PM, Chris Jones <jonesc at hep.phy.cam.ac.uk> wrote:
>>>>>>
>>>>>> Currently, once they find out about svn, and trac
>>>>>
>>>>> We will still use Trac for issue tracking, although I believe someone is
>>>>> looking into integrating GitHub sign in.
>>>>
>>>> Rainer and Clemens looked into this and got it up and running on our test installation.
>>>>
>>>
>>> So what exactly does this mean ?
>>
>> It means you will log in to our Trac installation using your GitHub credentials, instead of via Mac OS Forge credentials as it is now.
>>
>>
>>> Because, honestly, once the migration to GitHub is done unless comments sent to a github pull request are automatically sync’ed to trac, and vice versa, I do not see how trac can be maintained as a via system for discussing the pull requests (and frankly I din’t really see why you would want to).
>>
>> There will be no syncing of anything between GitHub pull requests and Trac tickets because they are different entities. Trac tickets are where bug reports and other issues will be filed. Currently, if someone has a fix for an issue, they would attach a patch to the Trac ticket; in future, they will instead open a GitHub pull request and paste a link to the pull request into the ticket (or paste a link to the Trac ticket into the pull request; I'm not sure if we've decided that detail yet).
>
>At my work we use gitlab and Jira in a similar way, but there is automatic links between the two, in that if i quote a jira id in a git lab merge request, links between the two is produced automatically. Having to do this by hand strikes me as potentially error prone and a little cumbersome.
>
>> And as Rainer said, there may be some simple changes for which it is sufficient to just submit a pull request, without opening a corresponding Trac ticket. We haven't defined what those situations would be yet.
>
>I would hope that for a simple updates to a port, that isn't addressing
>a bug report, then no trac ticket will required. The pull request
>really should be enough in this case, and if any discussion on the
>update is required it can occur in the pull request. If during the
>course of that discussion it transpires the update needs more work,
>then fine a trac ticket could be opened at that point. But  would hope
>for most it would simply not be necessary, and if it where a
>requirement to always do this i think that would be an unnecessary
>overhead.

This is how I feel as well. Having Trac running in parrallel to GitHub
feels like overhead that's just there because it's there. I understand
the need to use advanced functionality and having worked with any one
piece of technology for a decade, people are not going to change away
it. Only if it was really, really awful. But then they would have
changed it a long time ago. It's force of habit. When looking for
alternatives you compare them to your ingrained habits — that is not
going to work. Any major deviation will always feel not quite right.

I for one don't understand why one would carry around all that baggage
anyhow. Why not leave the old Trac as is and start fresh with a simple,
reduced issue tracker? Splitting discussion and code on two platforms
will create overhead. Unnecessary overhead I may add. Code and
discussion should go hand in hand.

I see this happening in the future: a first-time contributor opens a
pull request with a new port (not an update to an existing one),
describing everthing of value in the pull request itself. The
contributor will not open a Trac ticket because he has just opened the
pull request which is self-explanatory and doesn't want to enter all
that information a second time. The pull request gets ignored or
rejected because the contributor did not open a proper Trac ticket. The
contributor has a bad experience, decides to devote his time to a less
bureocratic project and quietly leaves.