On Saturday 05 May 2012 09:09:22 Paul Gardiner wrote: > I've just generated a push request. Is that considered a valid > alternative to a ticket, or should I open a corresponding > ticket too.

You need to open a ticket as well. Most devs don't read pull requests on github, especially not since we're no longer committing direct to github. For tracking and accounting purposes we prefer to have everything in one place. -- Stuart Morgan _______________________________________________ mythtv-dev mailing list mythtv-dev [at] mythtv http://www.mythtv.org/mailman/listinfo/mythtv-dev

On 05/05/2012 10:27, Stuart Morgan wrote: > On Saturday 05 May 2012 09:09:22 Paul Gardiner wrote: >> I've just generated a push request. Is that considered a valid >> alternative to a ticket, or should I open a corresponding >> ticket too. > > You need to open a ticket as well. Most devs don't read pull requests on > github, especially not since we're no longer committing direct to github. For > tracking and accounting purposes we prefer to have everything in one place.

Ok. Makes sense.

Just out of interest, what is your committing procedure now if no longer direct to github?

On Saturday 05 May 2012 11:01:25 Paul Gardiner wrote: > On 05/05/2012 10:27, Stuart Morgan wrote: > > You need to open a ticket as well. Most devs don't read pull requests on > > github, especially not since we're no longer committing direct to > > github. For tracking and accounting purposes we prefer to have > > everything in one place. > > Just out of interest, what is your committing procedure now if no > longer direct to github?

We're back to using our own server which achieves a much better uptime than github.

Github has never been especially reliable, they had more than their fair share of hardware/software faults and they are also a magnet for DDOS and hack attacks which sometimes left our repo inaccessible for hours. Added to that their post-commit hooks would regularly fail to fire meaning tickets didn't get automatically closed and commit emails were never sent.

At least when our server _does_ go down we have some control and aren't left hanging. -- Stuart Morgan _______________________________________________ mythtv-dev mailing list mythtv-dev [at] mythtv http://www.mythtv.org/mailman/listinfo/mythtv-dev

On 05/05/2012 11:38, Stuart Morgan wrote: > On Saturday 05 May 2012 11:01:25 Paul Gardiner wrote: >> On 05/05/2012 10:27, Stuart Morgan wrote: >>> You need to open a ticket as well. Most devs don't read pull requests on >>> github, especially not since we're no longer committing direct to >>> github. For tracking and accounting purposes we prefer to have >>> everything in one place. >> >> Just out of interest, what is your committing procedure now if no >> longer direct to github? > > We're back to using our own server which achieves a much better uptime than > github. > > Github has never been especially reliable, they had more than their fair share > of hardware/software faults and they are also a magnet for DDOS and hack > attacks which sometimes left our repo inaccessible for hours. Added to that > their post-commit hooks would regularly fail to fire meaning tickets didn't > get automatically closed and commit emails were never sent. > > At least when our server _does_ go down we have some control and aren't left > hanging.

I see. Ok. Thanks for the info. I guess github gets updated every now and then, and so isn't wildly out of date for casual developers.

On 05/05/2012 09:27 AM, Stuart Morgan wrote: > On Saturday 05 May 2012 13:13:54 Paul Gardiner wrote: >> I see. Ok. Thanks for the info. I guess github gets updated every now >> and then, and so isn't wildly out of date for casual developers. > One of our post-commit hooks syncs our repo with the copy on github.

(meaning the public repo on github is just as up to date as the repo on our server).

Also wanted to mention that the "historical" benefit of a ticket on Trac (that references your pull request): it's archived in Trac and in our mailing list archive. Any github-only communication is "lost" (or at least buried in a separate location that makes finding information harder than searching one location). This makes it very challenging to later figure out what happened.

We're considering making some changes that would make it easier to create a ticket in conjunction with the pull requests, but haven't yet figured out exactly how we want to handle it. We're hoping to come up with an approach that makes it easy for users/submitters but that maintains the historical benefit. Unfortunately, we haven't yet come up with a good mix of automation that doesn't result in one or more party having to do extra work. (I.e. if we automatically create a ticket, it will then have to be triaged--probably including writing a proper subject/description and linked to/moved to any existing ticket that covers the issue--or if we require specific information/format in the pull request (to allow creating/adding to the proper ticket), a user who submits a pull request would have to look that up before submitting (not to mention just knowing about the procedure). And, if we were to just send an e-mail "form letter" in response to the github pull request email for the user to fill out/return, it's actually probably just as easy to send them a link to the Trac New Ticket page. We may end up just doing that last approach until we can figure something else out, if for no other reason than to let users know that we do prefer a Trac ticket in addition to/referencing the pull request.)

On 05/05/2012 15:22, Michael T. Dean wrote: > On 05/05/2012 09:27 AM, Stuart Morgan wrote: >> On Saturday 05 May 2012 13:13:54 Paul Gardiner wrote: >>> I see. Ok. Thanks for the info. I guess github gets updated every now >>> and then, and so isn't wildly out of date for casual developers. >> One of our post-commit hooks syncs our repo with the copy on github. > > (meaning the public repo on github is just as up to date as the repo on > our server). > > Also wanted to mention that the "historical" benefit of a ticket on Trac > (that references your pull request): it's archived in Trac and in our > mailing list archive. Any github-only communication is "lost" (or at > least buried in a separate location that makes finding information > harder than searching one location). This makes it very challenging to > later figure out what happened. > > We're considering making some changes that would make it easier to > create a ticket in conjunction with the pull requests, but haven't yet > figured out exactly how we want to handle it.

That's good to hear, but it's plenty easy enough now it is. I asked not because I wanted to avoid creating a ticket, but I just wanted to know which of 'both' or 'pull request only' was better for you. I think it took me 6 hours to understand the piece of code I needed to change, about half an hour to make the changes, overnight to test. After that it was only 10 mins to create the pull request (that long only because it was the first time I'd done it), and then less than 2 mins to create the ticket.