Thread: GIT move
So we've discussed a move to git for some time and are just about ready to do that based on Maciek's work. So in conjunction with that, I think we should move off of pgfoundry at the same time. pgfoundry is bound to be shutdown soon and we shouldn't stick with it to the end like we did with gborg. So instead of moving to the disorganized git.postgresql.org which only offers git hosting, I'd suggest we move to github which will give us more exposure and additional hosting features like a wiki and issue tracking. Since we don't have any major work in progress I see no need to hold up this move. Does anyone have an objection to moving things over the weekend of 2/4? The only thing that pgfoundry still supports is the jdbc-commits mailing list. So we could send that mail to the general pgjdbc list or we could not bother sending it anywhere and let people pick it up via the methods provided by github or perhaps we could petition the postgresql.org infrastructure for another list. Kris Jurka
Kris, I don't have any specific objection to moving to github. What is disorganized about git.postgresql.org ? +1 to moving to github +1 to the issue tracking +1 to the weekend of 2/4 Dave Cramer dave.cramer(at)credativ(dot)ca http://www.credativ.ca On Wed, Jan 25, 2012 at 2:38 AM, Kris Jurka <books@ejurka.com> wrote: > > So we've discussed a move to git for some time and are just about ready to > do that based on Maciek's work. So in conjunction with that, I think we > should move off of pgfoundry at the same time. pgfoundry is bound to be > shutdown soon and we shouldn't stick with it to the end like we did with > gborg. So instead of moving to the disorganized git.postgresql.org which > only offers git hosting, I'd suggest we move to github which will give us > more exposure and additional hosting features like a wiki and issue > tracking. > > Since we don't have any major work in progress I see no need to hold up > this move. Does anyone have an objection to moving things over the > weekend of 2/4? > > The only thing that pgfoundry still supports is the jdbc-commits mailing > list. So we could send that mail to the general pgjdbc list or we could > not bother sending it anywhere and let people pick it up via the > methods provided by github or perhaps we could petition the postgresql.org > infrastructure for another list. > > Kris Jurka > > > -- > Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-jdbc
So git.postgresql.org offers nothing but git hosting, right? Do you see no value in at least mirroring there from github? This would be a one-liner, and easily cron-able. I guess the downside is that currently there seems to be no way to indicate that the git.postgresql.org repo is *not* the canonical one and that mirrored updates may lag. Other than that, github sounds good. With the pages feature ( http://pages.github.com/ ), it should even be possible to move large parts of the website there. For what it's worth, I see no need for a -commits list. Barring any unforeseen problems, the timeline looks good to me. The keyword expansion turned out to be a cvs2git bug, but the maintainer committed a fix; I'll try that tonight. --- Maciek Sakrejda | System Architect | Truviso 1065 E. Hillsdale Blvd., Suite 215 Foster City, CA 94404 (650) 242-3500 Main www.truviso.com
On Wed, Jan 25, 2012 at 12:54 PM, Maciek Sakrejda <msakrejda@truviso.com> wrote: > So git.postgresql.org offers nothing but git hosting, right? Do you > see no value in at least mirroring there from github? This would be a > one-liner, and easily cron-able. I think there may be some merit in this; that being that git.postgresql.org is where people will look for software related to pg. > > Other than that, github sounds good. With the pages feature ( > http://pages.github.com/ ), it should even be possible to move large > parts of the website there. For what it's worth, I see no need for a > -commits list. The commits list is nice to see progress. Is there another way on github, or using git ? Dave Cramer dave.cramer(at)credativ(dot)ca http://www.credativ.ca
On Wed, 25 Jan 2012, Dave Cramer wrote: > I don't have any specific objection to moving to github. What is > disorganized about git.postgresql.org ? If you don't know exactly what you are looking for, it's real tough to find it. It's not a software directory, it's a list of repos that have a 30 character description. There's dead code, empty repos, and obscure projects mixed in. In my opinion it's really just a dumping ground and that's fine because its goal is just to provide git hosting which it does. So I don't have a problem with mirroring from github to git.postgresql.org, but I think if we're going to use other github features, it should be the master. Kris Jurka
On Wed, Jan 25, 2012 at 02:26:57PM -0500, Dave Cramer wrote: > On Wed, Jan 25, 2012 at 12:54 PM, Maciek Sakrejda <msakrejda@truviso.com> wrote: > > So git.postgresql.org offers nothing but git hosting, right? Do you > > see no value in at least mirroring there from github? This would be a > > one-liner, and easily cron-able. > > I think there may be some merit in this; that being that > git.postgresql.org is where people will look for software related to > pg. > > > > > > Other than that, github sounds good. With the pages feature ( > > http://pages.github.com/ ), it should even be possible to move large > > parts of the website there. For what it's worth, I see no need for a > > -commits list. > > The commits list is nice to see progress. Is there another way on > github, or using git ? Yes: "Watch repo" button, which brings commits to your homepage. Also both your homepage and repos itself are RSS-able. -- marko
On 01/25/2012 08:38 AM, Kris Jurka wrote: > So we've discussed a move to git for some time and are just about ready to > do that based on Maciek's work. So in conjunction with that, I think we > should move off of pgfoundry at the same time. pgfoundry is bound to be > shutdown soon and we shouldn't stick with it to the end like we did with > gborg. So instead of moving to the disorganized git.postgresql.org which > only offers git hosting, I'd suggest we move to github which will give us > more exposure and additional hosting features like a wiki and issue > tracking. > > Since we don't have any major work in progress I see no need to hold up > this move. Does anyone have an objection to moving things over the > weekend of 2/4? > > The only thing that pgfoundry still supports is the jdbc-commits mailing > list. So we could send that mail to the general pgjdbc list or we could > not bother sending it anywhere and let people pick it up via the > methods provided by github or perhaps we could petition the postgresql.org > infrastructure for another list. > > Kris Jurka +1 -- Andreas Joseph Krogh<andreak@officenet.no> - mob: +47 909 56 963 Senior Software Developer / CTO - OfficeNet AS - http://www.officenet.no Public key: http://home.officenet.no/~andreak/public_key.asc
Did this happen ? Dave Cramer dave.cramer(at)credativ(dot)ca http://www.credativ.ca On Sun, Jan 29, 2012 at 7:40 AM, Andreas Joseph Krogh <andreak@officenet.no> wrote: > On 01/25/2012 08:38 AM, Kris Jurka wrote: >> >> So we've discussed a move to git for some time and are just about ready to >> do that based on Maciek's work. So in conjunction with that, I think we >> should move off of pgfoundry at the same time. pgfoundry is bound to be >> shutdown soon and we shouldn't stick with it to the end like we did with >> gborg. So instead of moving to the disorganized git.postgresql.org which >> only offers git hosting, I'd suggest we move to github which will give us >> more exposure and additional hosting features like a wiki and issue >> tracking. >> >> Since we don't have any major work in progress I see no need to hold up >> this move. Does anyone have an objection to moving things over the >> weekend of 2/4? >> >> The only thing that pgfoundry still supports is the jdbc-commits mailing >> list. So we could send that mail to the general pgjdbc list or we could >> not bother sending it anywhere and let people pick it up via the >> methods provided by github or perhaps we could petition the postgresql.org >> infrastructure for another list. >> >> Kris Jurka > > > +1 > > -- > Andreas Joseph Krogh<andreak@officenet.no> - mob: +47 909 56 963 > Senior Software Developer / CTO - OfficeNet AS - http://www.officenet.no > Public key: http://home.officenet.no/~andreak/public_key.asc > > > > -- > Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-jdbc
On Mon, 6 Feb 2012, Dave Cramer wrote: > Did this happen ? > Not completely. I'm most of the way through it, but was not able to finish last night. I will complete the move today. Kris
>> Did this happen ? >> > > Not completely. I'm most of the way through it, but was not able to > finish last night. I will complete the move today. Great to hear; please let me know if you hit any issues with the transition scripts. Also, vaguely on this topic, I'm not sure if there's a formal plan for methods of accepting patches (e.g., via github pull requests), but I highly recommend that all patches be required to be rebased against trunk/master, resulting in fast-forward merges into the main tree. This makes history much simpler to follow (no merge nodes) without a significant downside. --- Maciek Sakrejda | System Architect | Truviso 1065 E. Hillsdale Blvd., Suite 215 Foster City, CA 94404 (650) 242-3500 Main www.truviso.com
On Mon, Feb 6, 2012 at 7:47 PM, Maciek Sakrejda <msakrejda@truviso.com> wrote: >>> Did this happen ? >>> >> >> Not completely. I'm most of the way through it, but was not able to >> finish last night. I will complete the move today. > > Great to hear; please let me know if you hit any issues with the > transition scripts. > > Also, vaguely on this topic, I'm not sure if there's a formal plan for > methods of accepting patches (e.g., via github pull requests), but I > highly recommend that all patches be required to be rebased against > trunk/master, resulting in fast-forward merges into the main tree. > This makes history much simpler to follow (no merge nodes) without a > significant downside. > Currently the main project still requires a context patch as well Dave Cramer dave.cramer(at)credativ(dot)ca http://www.credativ.ca
>> Also, vaguely on this topic, I'm not sure if there's a formal plan for >> methods of accepting patches (e.g., via github pull requests), but I >> highly recommend that all patches be required to be rebased against >> trunk/master, resulting in fast-forward merges into the main tree. >> This makes history much simpler to follow (no merge nodes) without a >> significant downside. >> > > Currently the main project still requires a context patch as well Good point. I'll see if I can dig up the discussion on the main project's list and argue against following that here ;) (or maybe the discussion will change my mind)--I think a rebased pull request (squashed to a single changeset, if appropriate) is essentially a fancier context patch. --- Maciek Sakrejda | System Architect | Truviso 1065 E. Hillsdale Blvd., Suite 215 Foster City, CA 94404 (650) 242-3500 Main www.truviso.com
On Mon, 6 Feb 2012, Kris Jurka wrote: > > Not completely. I'm most of the way through it, but was not able to > finish last night. I will complete the move today. > OK, the converted repository is up at https://github.com/pgjdbc I have removed all CVS keyword expansions of PostgreSQL instead of replacing them with the full filename. I don't think the path tells you a whole lot, the file is there on disk so you can check the path if you care. It just seems like a maintenance headache. Additionally I have converted the .cvsignore files to .gitignore. Cleanup that still needs to happen: 1) The website has instructions for fetching the code from CVS which must be updated. http://jdbc.postgresql.org/development/cvs.html 2) The website build scripts still have assumptions about CVS and directory layouts for building documentation and translation statuses. Other than that, I think we're good to go. Kris Jurka
> OK, the converted repository is up at > > https://github.com/pgjdbc Cloned it, looks great. No manufactured anything, authors look good, history looks good. > I have removed all CVS keyword expansions of PostgreSQL instead of > replacing them with the full filename. I don't think the path tells you a > whole lot, the file is there on disk so you can check the path if you > care. It just seems like a maintenance headache. +1 (I only did the fixed expansion to be consistent with the server project, but I personally prefer no keywords at all as well). > Additionally I have converted the .cvsignore files to .gitignore. I see that this is a straight rename. Note that there are some minor semantic differences: http://cvs2svn.tigris.org/ds/viewMessage.do?dsForumId=1670&dsMessageId=2870852 . I think the most relevant of these is the recursive behavior of 'foo' (versus '/foo') in a .gitignore file, but I don't think that matters for the ones we have. I can take a look at updating the website if you'd like. Should it mention CVS at all (just in case we did something catastrophically stupid that we have not yet noticed), and if so, is anyone planning to mirror patches to CVS for any amount of time, or is it frozen as of the transition? Thanks, --- Maciek Sakrejda | System Architect | Truviso 1065 E. Hillsdale Blvd., Suite 215 Foster City, CA 94404 (650) 242-3500 Main www.truviso.com
>> Currently the main project still requires a context patch as well > > Good point. I'll see if I can dig up the discussion on the main > project's list and argue against following that here ;) (or maybe the > discussion will change my mind)--I think a rebased pull request > (squashed to a single changeset, if appropriate) is essentially a > fancier context patch. A post-mortem from Josh Berkus [1] and a blog post from Magnus Hagander [2] seem to be the clearest in summing this up. As far as I can tell, the reason the main project requires patches was to change the *process* as little as possible in the course of changing the VCS plumbing. There's certainly value in that (especially for a large project and not everyone chomping at the bit to switch workflows). Git-empowered (for lack of a better term) workflows can emerge and be standardized later, after the community is comfortable with just the mechanics of git. I have no strong feelings regarding the authorship metadata. For the smaller jdbc project, I think if the committers are comfortable accepting pull requests via github, that would make the workflow simpler for some potential contributors. Standard patches could of course still be accepted, for the git-averse. [1]: http://lwn.net/Articles/409635/ [2]: http://blog.hagander.net/archives/175-PostgreSQL-now-on-git!.html --- Maciek Sakrejda | System Architect | Truviso 1065 E. Hillsdale Blvd., Suite 215 Foster City, CA 94404 (650) 242-3500 Main www.truviso.com
Maciek Sakrejda <msakrejda@truviso.com> writes:
> A post-mortem from Josh Berkus [1] and a blog post from Magnus
> Hagander [2] seem to be the clearest in summing this up. As far as I
> can tell, the reason the main project requires patches was to change
> the *process* as little as possible in the course of changing the VCS
> plumbing.
That's *a* reason, but not the only one. Other large considerations are
that we consider that the act of submitting the patch to the mailing
list is evidence of intent to license the code under the Postgres
license, and further that this evidence is archived in the PG list
archives. If someone writes in and just provides a link, there is no
permanent record of what was submitted, or at least none under the
project's control. So we just have a warmer feeling about the
legalities and the traceability of contributions when it's done this
way.
Of course you're free to adopt your own policies for the JDBC project,
but I just wanted to point out that the above quote is not a good
summary of the reasons for the main project's policy.
regards, tom lane
>> As far as I >> can tell, the reason the main project requires patches was to change >> the *process* as little as possible in the course of changing the VCS >> plumbing. > > That's *a* reason, but not the only one. Other large considerations are > that we consider that the act of submitting the patch to the mailing > list is evidence of intent to license the code under the Postgres > license, and further that this evidence is archived in the PG list > archives. That's an excellent point--thanks for the clarification. --- Maciek Sakrejda | System Architect | Truviso 1065 E. Hillsdale Blvd., Suite 215 Foster City, CA 94404 (650) 242-3500 Main www.truviso.com
I for one would like to keep the policy that we require a context patch to be sent to the list. Having to chase down everyone's git repo seems like more work rather than less Dave Cramer dave.cramer(at)credativ(dot)ca http://www.credativ.ca On Wed, Feb 8, 2012 at 1:39 AM, Maciek Sakrejda <msakrejda@truviso.com> wrote: >>> As far as I >>> can tell, the reason the main project requires patches was to change >>> the *process* as little as possible in the course of changing the VCS >>> plumbing. >> >> That's *a* reason, but not the only one. Other large considerations are >> that we consider that the act of submitting the patch to the mailing >> list is evidence of intent to license the code under the Postgres >> license, and further that this evidence is archived in the PG list >> archives. > > That's an excellent point--thanks for the clarification. > --- > Maciek Sakrejda | System Architect | Truviso > > 1065 E. Hillsdale Blvd., Suite 215 > Foster City, CA 94404 > (650) 242-3500 Main > www.truviso.com > > -- > Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-jdbc
Hi. As for me, github pull request could be enough. No one needs to chase down anything and at the same time everything can be easily tracked/reused with all author information. It is also can be treated as "evidence of intent to license the code". The only minus is lack of list archiving. Also note that since repository is available in github, pull requests are expected. So, for me best thing would be to send notifications from github to this list (or some new list) regarding pull requests. It seems this can be configured in github's notification center. Best regards, Vitalii Tymchyshyn 08.02.12 14:27, Dave Cramer написав(ла): > I for one would like to keep the policy that we require a context > patch to be sent to the list. > Having to chase down everyone's git repo seems like more work rather than less > > > > On Wed, Feb 8, 2012 at 1:39 AM, Maciek Sakrejda<msakrejda@truviso.com> wrote: >>>> As far as I >>>> can tell, the reason the main project requires patches was to change >>>> the *process* as little as possible in the course of changing the VCS >>>> plumbing. >>> That's *a* reason, but not the only one. Other large considerations are >>> that we consider that the act of submitting the patch to the mailing >>> list is evidence of intent to license the code under the Postgres >>> license, and further that this evidence is archived in the PG list >>> archives. >> That's an excellent point--thanks for the clarification.
Hi How does a github pull request establish "evidence of intent" ? Please keep in mind this question is out of ignorance as I am not that familiar with github. Dave Cramer dave.cramer(at)credativ(dot)ca http://www.credativ.ca On Wed, Feb 8, 2012 at 7:40 AM, Vitalii Tymchyshyn <tivv00@gmail.com> wrote: > Hi. > > As for me, github pull request could be enough. No one needs to chase down > anything and at the same time everything can be easily tracked/reused with > all author information. It is also can be treated as "evidence of intent to > license the code". The only minus is lack of list archiving. > Also note that since repository is available in github, pull requests are > expected. So, for me best thing would be to send notifications from github > to this list (or some new list) regarding pull requests. It seems this can > be configured in github's notification center. > > Best regards, Vitalii Tymchyshyn > > 08.02.12 14:27, Dave Cramer написав(ла): >> >> I for one would like to keep the policy that we require a context >> patch to be sent to the list. >> Having to chase down everyone's git repo seems like more work rather than >> less >> >> >> >> On Wed, Feb 8, 2012 at 1:39 AM, Maciek Sakrejda<msakrejda@truviso.com> >> wrote: >>>>> >>>>> As far as I >>>>> can tell, the reason the main project requires patches was to change >>>>> the *process* as little as possible in the course of changing the VCS >>>>> plumbing. >>>> >>>> That's *a* reason, but not the only one. Other large considerations are >>>> that we consider that the act of submitting the patch to the mailing >>>> list is evidence of intent to license the code under the Postgres >>>> license, and further that this evidence is archived in the PG list >>>> archives. >>> >>> That's an excellent point--thanks for the clarification. > > > > -- > Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-jdbc
Hello. GitHub pull request along with the code has something like forum thread that may have comments attached. Initial pull request has title and description. So it does not differ much from mailing list. The problem is that IMHO it's not good to have multiple places for discussion, that's why as for me mailing list is good place, but pull request discussions should be mirrored here much like bugzilla comments usually mirrored to -dev mailing lists. Note that programmers that are used to github can propose patches with pull requests. This should not be ignored. If there will be a message to the list, community will be able to respond. The question is if patch itself should land into mailing list archives or pull request reference with all the comments is enough. Best regards, Vitalii Tymchyshyn 08.02.12 15:55, Dave Cramer написав(ла): > Hi > > How does a github pull request establish "evidence of intent" ? Please > keep in mind this question is out of ignorance as I am not that > familiar with github. > > Dave Cramer > > dave.cramer(at)credativ(dot)ca > http://www.credativ.ca > > > > On Wed, Feb 8, 2012 at 7:40 AM, Vitalii Tymchyshyn<tivv00@gmail.com> wrote: >> Hi. >> >> As for me, github pull request could be enough. No one needs to chase down >> anything and at the same time everything can be easily tracked/reused with >> all author information. It is also can be treated as "evidence of intent to >> license the code". The only minus is lack of list archiving. >> Also note that since repository is available in github, pull requests are >> expected. So, for me best thing would be to send notifications from github >> to this list (or some new list) regarding pull requests. It seems this can >> be configured in github's notification center. >> >> Best regards, Vitalii Tymchyshyn >> >> 08.02.12 14:27, Dave Cramer написав(ла): >>> I for one would like to keep the policy that we require a context >>> patch to be sent to the list. >>> Having to chase down everyone's git repo seems like more work rather than >>> less >>> >>> >>> >>> On Wed, Feb 8, 2012 at 1:39 AM, Maciek Sakrejda<msakrejda@truviso.com> >>> wrote: >>>>>> As far as I >>>>>> can tell, the reason the main project requires patches was to change >>>>>> the *process* as little as possible in the course of changing the VCS >>>>>> plumbing. >>>>> That's *a* reason, but not the only one. Other large considerations are >>>>> that we consider that the act of submitting the patch to the mailing >>>>> list is evidence of intent to license the code under the Postgres >>>>> license, and further that this evidence is archived in the PG list >>>>> archives. >>>> That's an excellent point--thanks for the clarification. >> >> >> -- >> Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org) >> To make changes to your subscription: >> http://www.postgresql.org/mailpref/pgsql-jdbc
> How does a github pull request establish "evidence of intent" ? Please > keep in mind this question is out of ignorance as I am not that > familiar with github. They're pretty nifty: https://github.com/blog/712-pull-requests-2-0 . Although if a record of attribution is a serious concern, having these under github's control is less than ideal. If this is the main concern, perhaps there's a formal way for the project to archive github pull requests (maybe the github API: http://developer.github.com/v3/pulls/ ), but that's extra work and somewhat more nebulous (as evidence) than a straight mailing list archive. --- Maciek Sakrejda | System Architect | Truviso 1065 E. Hillsdale Blvd., Suite 215 Foster City, CA 94404 (650) 242-3500 Main www.truviso.com
2012/2/8 Maciek Sakrejda <msakrejda@truviso.com>
> How does a github pull request establish "evidence of intent" ? PleaseThey're pretty nifty: https://github.com/blog/712-pull-requests-2-0 .
> keep in mind this question is out of ignorance as I am not that
> familiar with github.
Although if a record of attribution is a serious concern, having these
under github's control is less than ideal. If this is the main
concern, perhaps there's a formal way for the project to archive
github pull requests (maybe the github API:
http://developer.github.com/v3/pulls/ ), but that's extra work and
somewhat more nebulous (as evidence) than a straight mailing list
archive.
That's why I propose for github to send notifications to this list. This can be simply configurable and will be more or less much like before.
Best regards,
Vitalii Tymchyshyn
2012/2/8 Віталій Тимчишин <tivv00@gmail.com>: > > > 2012/2/8 Maciek Sakrejda <msakrejda@truviso.com> >> >> > How does a github pull request establish "evidence of intent" ? Please >> > keep in mind this question is out of ignorance as I am not that >> > familiar with github. >> >> They're pretty nifty: https://github.com/blog/712-pull-requests-2-0 . >> Although if a record of attribution is a serious concern, having these >> under github's control is less than ideal. If this is the main >> concern, perhaps there's a formal way for the project to archive >> github pull requests (maybe the github API: >> http://developer.github.com/v3/pulls/ ), but that's extra work and >> somewhat more nebulous (as evidence) than a straight mailing list >> archive. > > > That's why I propose for github to send notifications to this list. This can > be simply configurable and will be more or less much like before. OK, I see the first pull request came to my gmail address. What has to be done to get it to the list ? I imagine we need to add the list as a user to the project ? Getting github as a subscribed user to the list will be more difficult, but manageable ? Can someone elucidate the steps to get pull requests going to the list ? Also it seems that post-receive hooks are designed to push data to a website as opposed to simply emailing ??? Is there an easy way to get email notifications ? Dave
Hello. Yep, I think it should be possible to add this list email as email for pgjdbc github user with https://github.com/account/email Later https://github.com/account/notifications can be used to regulate which emails should be in the list 10.02.12 13:35, Dave Cramer написав(ла): > 2012/2/8 Віталій Тимчишин<tivv00@gmail.com>: >> >> 2012/2/8 Maciek Sakrejda<msakrejda@truviso.com> >>>> How does a github pull request establish "evidence of intent" ? Please >>>> keep in mind this question is out of ignorance as I am not that >>>> familiar with github. >>> They're pretty nifty: https://github.com/blog/712-pull-requests-2-0 . >>> Although if a record of attribution is a serious concern, having these >>> under github's control is less than ideal. If this is the main >>> concern, perhaps there's a formal way for the project to archive >>> github pull requests (maybe the github API: >>> http://developer.github.com/v3/pulls/ ), but that's extra work and >>> somewhat more nebulous (as evidence) than a straight mailing list >>> archive. >> >> That's why I propose for github to send notifications to this list. This can >> be simply configurable and will be more or less much like before. > > OK, I see the first pull request came to my gmail address. What has to > be done to get it to the list ? > > I imagine we need to add the list as a user to the project ? Getting > github as a subscribed user to the list will be more difficult, but > manageable ? > > Can someone elucidate the steps to get pull requests going to the list ? > > > Also it seems that post-receive hooks are designed to push data to a > website as opposed to simply emailing ??? Is there an easy way to get > email notifications ? > > Dave
Hi Vitalii, This is what the pull request email address for Steven's pull came in as Steven Schlansker <reply+i-3165615-a9adaf19c31f0ad7919226777365c7fb396d186b-406518@reply.github.com> Unless the list accepts everything at reply.github.com I don't see how it can work unless I am missing something ? Dave Cramer dave.cramer(at)credativ(dot)ca http://www.credativ.ca 2012/2/10 Vitalii Tymchyshyn <tivv00@gmail.com>: > Hello. > > Yep, I think it should be possible to add this list email as email for > pgjdbc github user with https://github.com/account/email > > Later https://github.com/account/notifications can be used to regulate which > emails should be in the list > > 10.02.12 13:35, Dave Cramer написав(ла): > >> 2012/2/8 Віталій Тимчишин<tivv00@gmail.com>: >>> >>> >>> 2012/2/8 Maciek Sakrejda<msakrejda@truviso.com> >>>>> >>>>> How does a github pull request establish "evidence of intent" ? Please >>>>> keep in mind this question is out of ignorance as I am not that >>>>> familiar with github. >>>> >>>> They're pretty nifty: https://github.com/blog/712-pull-requests-2-0 . >>>> Although if a record of attribution is a serious concern, having these >>>> under github's control is less than ideal. If this is the main >>>> concern, perhaps there's a formal way for the project to archive >>>> github pull requests (maybe the github API: >>>> http://developer.github.com/v3/pulls/ ), but that's extra work and >>>> somewhat more nebulous (as evidence) than a straight mailing list >>>> archive. >>> >>> >>> That's why I propose for github to send notifications to this list. This >>> can >>> be simply configurable and will be more or less much like before. >> >> >> OK, I see the first pull request came to my gmail address. What has to >> be done to get it to the list ? >> >> I imagine we need to add the list as a user to the project ? Getting >> github as a subscribed user to the list will be more difficult, but >> manageable ? >> >> Can someone elucidate the steps to get pull requests going to the list ? >> >> >> Also it seems that post-receive hooks are designed to push data to a >> website as opposed to simply emailing ??? Is there an easy way to get >> email notifications ? >> >> Dave > >
The GitHub notification email is SPF-authenticated, so if Majordomo allows checking that it it would be best. Florent 2012/2/10 Dave Cramer <pg@fastcrypt.com>: > Hi Vitalii, > > This is what the pull request email address for Steven's pull came in > as Steven Schlansker > <reply+i-3165615-a9adaf19c31f0ad7919226777365c7fb396d186b-406518@reply.github.com> > > Unless the list accepts everything at reply.github.com I don't see how > it can work unless I am missing something ? > > Dave Cramer > > dave.cramer(at)credativ(dot)ca > http://www.credativ.ca > > > > 2012/2/10 Vitalii Tymchyshyn <tivv00@gmail.com>: >> Hello. >> >> Yep, I think it should be possible to add this list email as email for >> pgjdbc github user with https://github.com/account/email >> >> Later https://github.com/account/notifications can be used to regulate which >> emails should be in the list >> >> 10.02.12 13:35, Dave Cramer написав(ла): >> >>> 2012/2/8 Віталій Тимчишин<tivv00@gmail.com>: >>>> >>>> >>>> 2012/2/8 Maciek Sakrejda<msakrejda@truviso.com> >>>>>> >>>>>> How does a github pull request establish "evidence of intent" ? Please >>>>>> keep in mind this question is out of ignorance as I am not that >>>>>> familiar with github. >>>>> >>>>> They're pretty nifty: https://github.com/blog/712-pull-requests-2-0 . >>>>> Although if a record of attribution is a serious concern, having these >>>>> under github's control is less than ideal. If this is the main >>>>> concern, perhaps there's a formal way for the project to archive >>>>> github pull requests (maybe the github API: >>>>> http://developer.github.com/v3/pulls/ ), but that's extra work and >>>>> somewhat more nebulous (as evidence) than a straight mailing list >>>>> archive. >>>> >>>> >>>> That's why I propose for github to send notifications to this list. This >>>> can >>>> be simply configurable and will be more or less much like before. >>> >>> >>> OK, I see the first pull request came to my gmail address. What has to >>> be done to get it to the list ? >>> >>> I imagine we need to add the list as a user to the project ? Getting >>> github as a subscribed user to the list will be more difficult, but >>> manageable ? >>> >>> Can someone elucidate the steps to get pull requests going to the list ? >>> >>> >>> Also it seems that post-receive hooks are designed to push data to a >>> website as opposed to simply emailing ??? Is there an easy way to get >>> email notifications ? >>> >>> Dave >> >> > > -- > Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-jdbc -- Florent Guillaume, Director of R&D, Nuxeo Open Source, Java EE based, Enterprise Content Management (ECM) http://www.nuxeo.com http://www.nuxeo.org +33 1 40 33 79 87
On Feb 10, 2012, at 5:08 AM, Dave Cramer wrote: > Hi Vitalii, > > This is what the pull request email address for Steven's pull came in > as Steven Schlansker > <reply+i-3165615-a9adaf19c31f0ad7919226777365c7fb396d186b-406518@reply.github.com> > > Unless the list accepts everything at reply.github.com I don't see how > it can work unless I am missing something ? > It's my understanding that anything after the '+' is considered to not be part of the identity of the email address, but instead used for internal routing or filtering. So reply+x@… should be treated the same as reply+y@… Maybe adding reply@reply.github.com is sufficient and it 'just works'? Alternately, I know at least Mailman supports regular expression matching for sender filters, and writing a regex to match the above shouldn't be too hard. > > 2012/2/10 Vitalii Tymchyshyn <tivv00@gmail.com>: >> Hello. >> >> Yep, I think it should be possible to add this list email as email for >> pgjdbc github user with https://github.com/account/email >> >> Later https://github.com/account/notifications can be used to regulate which >> emails should be in the list >> >> 10.02.12 13:35, Dave Cramer написав(ла): >> >>> 2012/2/8 Віталій Тимчишин<tivv00@gmail.com>: >>>> >>>> >>>> 2012/2/8 Maciek Sakrejda<msakrejda@truviso.com> >>>>>> >>>>>> How does a github pull request establish "evidence of intent" ? Please >>>>>> keep in mind this question is out of ignorance as I am not that >>>>>> familiar with github. >>>>> >>>>> They're pretty nifty: https://github.com/blog/712-pull-requests-2-0 . >>>>> Although if a record of attribution is a serious concern, having these >>>>> under github's control is less than ideal. If this is the main >>>>> concern, perhaps there's a formal way for the project to archive >>>>> github pull requests (maybe the github API: >>>>> http://developer.github.com/v3/pulls/ ), but that's extra work and >>>>> somewhat more nebulous (as evidence) than a straight mailing list >>>>> archive. >>>> >>>> >>>> That's why I propose for github to send notifications to this list. This >>>> can >>>> be simply configurable and will be more or less much like before. >>> >>> >>> OK, I see the first pull request came to my gmail address. What has to >>> be done to get it to the list ? >>> >>> I imagine we need to add the list as a user to the project ? Getting >>> github as a subscribed user to the list will be more difficult, but >>> manageable ? >>> >>> Can someone elucidate the steps to get pull requests going to the list ? >>> >>> >>> Also it seems that post-receive hooks are designed to push data to a >>> website as opposed to simply emailing ??? Is there an easy way to get >>> email notifications ? >>> >>> Dave >> >> > > -- > Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-jdbc