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)? 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 > -- > >
