On 16/10/08, Chris Jones wrote:
On 8 Oct 2016, at 11:29 am, Ryan Schmidt <ryandes...@macports.org> wrote:
On Oct 7, 2016, at 2:18 PM, Christopher Jones <jon...@hep.phy.cam.ac.uk> wrote:
On 7 Oct 2016, at 8:12 pm, Ryan Schmidt <ryandes...@macports.org> wrote:
On Oct 7, 2016, at 1:40 PM, Lawrence Velázquez <lar...@macports.org> wrote:
On Oct 7, 2016, at 2:09 PM, Chris Jones <jon...@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.
_______________________________________________
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev