Обсуждение: 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 Віталій Тимчишин <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