On Mar 18, 2013, at 18:57 , Eli Stevens (Gmail) <wickedg...@gmail.com> wrote:
> Every single email I get from a github pull request contains a header like: > > Reply-To: mobius-medical/dev < > reply+p-111-0123456789abcdef-...@reply.github.com> > > And sending email to that email address causes the content of that email to > show up in the pull request. > > Unless public repos behave differently in this regard from private ones > (which is what I'm using when I see these), it seems like we can solve the > content mirroring issue *trivially*. Nobody needs to volunteer to be > online 150% of the time for anything. If someone on the ML wants to have a > reply appear in the PR, then you make sure the reply.github.com address is > CCd. If you don't, then just send to the ML. > > Is all of the discussion about github PRs unaware of this current > email-to-PR-comment bridge, or is there some non-obvious inadequacy (in > which case it should be spelled out)? Thanks for pointing this out, I looked at this as well, but then had to write lengthy emails instead. My 150% number is only to illustrate the futility of this argument. Cheers Jan -- > > Eli > > > On Mon, Mar 18, 2013 at 7:51 AM, Jan Lehnardt <j...@apache.org> wrote: > >> >> On Mar 18, 2013, at 15:46 , Benoit Chesneau <bchesn...@gmail.com> wrote: >> >>> On Mon, Mar 18, 2013 at 7:26 AM, Jan Lehnardt <j...@apache.org> wrote: >>>> >>>> On Mar 18, 2013, at 15:17 , Benoit Chesneau <bchesn...@gmail.com> >> wrote: >>>> >>>>> Jan, you can reject anything but that doesn't mean that my argument is >>>>> invalid. And what this reject means by the way? >>>> >>>> I meant to say “I don’t believe your argument is correct”. >>> >>> Yes so what does it means? >>>> >>>> >>>>> Also yes it will favor github, the latency introduced by manual >>>>> updates will make the things impracticable unless you will be online >>>>> 100% of the time. And i wouldn't want that you or anyone do that job. >>>>> This is a painful job that is also imo doesn't adress the problem. >>>> >>>> I will be online 150% the time if it is needed. Again, I expect the >>>> need to do a manual copy to be *minimal*. Either way, the data will >>>> be on dev@ first, favouring dev@ for most-real-time-info, and GitHub >>>> second, that should align with your interests. >>> >>> no. You still don't understand my concern. I don't care that the >>> information goes first on the dev ml. I'm concerned to have a neutral >>> way to discuss at the time you want, not depending of a manual >>> synchronisation. Since you can't physically be online 150% of the time >>> that's impossible anyway. Also i'm in favor of direct contacts not >>> contacts *via* someone. >> >> I get that, and I will raise that this sucks and needs automating once >> this becomes an actual problem. For now this is a theoretical concern. >> >> >>>>> To answer to noah no I am not changing my position which was to be -0 >>>>> (and not +) . I will let a vote to decide. I am in disagreement with a >>>>> solution that address only 20% >>>>> of the problem. In my opinion we need a way that encourage people to >>>>> use a neutral workflow from the beginning. And if we choose to use >>>>> this 20% solution then we should also decide about a deadline to end >>>>> it if it doesn't work and also a deadline to end it if we didn't >>>>> figure to address the problem of having a 2 way channel. >>>> >>>> Ok, let’s see how this goes and revisit in 12 months. >>> 12 months can be damageable . Let say 3 months eventually. Though this >>> is not to us to decide. >> >> 6 then. >> >> Jan >> -- >> >>
