Re: [VOTE] move the website bits to a Git repo

2016-04-20 Thread Gordon Sim

On 20/04/16 01:03, Robbie Gemmell wrote:

As per the title, I'd like to vote on moving the website bits to a Git
repo, specifically "qpid-site".


+1

-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org



Re: [VOTE] move the website bits to a Git repo

2016-04-20 Thread Lorenz Quack

seems reasonable.

+1


On 20/04/16 01:03, Robbie Gemmell wrote:

Hi folks,

Short version:
As per the title, I'd like to vote on moving the website bits to a Git
repo, specifically "qpid-site".

Further info:
The site is one of the single largest groups of stuff we have, both
with regard to its previous release content and for the additions of
various new releases as they occur. That's in terms of both overall
file size and especially the overall number of files. On the latter
point, this makes using Subversion particularly slow; for example it
took well over 30mins just to check in the website updates I made
yesterday. I literally had to leave and come back later because it
took so long.

Support for Git based sites have been offered by infra for some time
now [1]. Things work in essentially the same manner to our current
Subversion based site, whereby upon checkin the 'content' bits then
get published to the web servers. The only real difference is that the
site stuff must exist in the 'asf-site' branch of a particular git
repo, either the same one as general code or just a dedicated separate
repo. In our case a dedicated repo seems to makes the most sense, and
again it seems to be what various other projects do (even the
otherwise single-repo projects).

[1] https://blogs.apache.org/infra/entry/git_based_websites_available

Robbie

-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org



Re: [VOTE] move the website bits to a Git repo

2016-04-20 Thread Ted Ross

+1

On 04/19/2016 08:03 PM, Robbie Gemmell wrote:

Hi folks,

Short version:
As per the title, I'd like to vote on moving the website bits to a Git
repo, specifically "qpid-site".

Further info:
The site is one of the single largest groups of stuff we have, both
with regard to its previous release content and for the additions of
various new releases as they occur. That's in terms of both overall
file size and especially the overall number of files. On the latter
point, this makes using Subversion particularly slow; for example it
took well over 30mins just to check in the website updates I made
yesterday. I literally had to leave and come back later because it
took so long.

Support for Git based sites have been offered by infra for some time
now [1]. Things work in essentially the same manner to our current
Subversion based site, whereby upon checkin the 'content' bits then
get published to the web servers. The only real difference is that the
site stuff must exist in the 'asf-site' branch of a particular git
repo, either the same one as general code or just a dedicated separate
repo. In our case a dedicated repo seems to makes the most sense, and
again it seems to be what various other projects do (even the
otherwise single-repo projects).

[1] https://blogs.apache.org/infra/entry/git_based_websites_available

Robbie

-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org



Re: [VOTE] move the website bits to a Git repo

2016-04-20 Thread Alan Conway
+1

Yes pleease!

On Wed, 2016-04-20 at 01:03 +0100, Robbie Gemmell wrote:
> Hi folks,
> 
> Short version:
> As per the title, I'd like to vote on moving the website bits to a
> Git
> repo, specifically "qpid-site".
> 
> Further info:
> The site is one of the single largest groups of stuff we have, both
> with regard to its previous release content and for the additions of
> various new releases as they occur. That's in terms of both overall
> file size and especially the overall number of files. On the latter
> point, this makes using Subversion particularly slow; for example it
> took well over 30mins just to check in the website updates I made
> yesterday. I literally had to leave and come back later because it
> took so long.
> 
> Support for Git based sites have been offered by infra for some time
> now [1]. Things work in essentially the same manner to our current
> Subversion based site, whereby upon checkin the 'content' bits then
> get published to the web servers. The only real difference is that
> the
> site stuff must exist in the 'asf-site' branch of a particular git
> repo, either the same one as general code or just a dedicated
> separate
> repo. In our case a dedicated repo seems to makes the most sense, and
> again it seems to be what various other projects do (even the
> otherwise single-repo projects).
> 
> [1] https://blogs.apache.org/infra/entry/git_based_websites_available
> 
> Robbie
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
> 

-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org



Re: [VOTE] move the website bits to a Git repo

2016-04-20 Thread Chuck Rolke
+1

- Original Message -
> From: "Robbie Gemmell" 
> To: users@qpid.apache.org
> Sent: Tuesday, April 19, 2016 8:03:02 PM
> Subject: [VOTE] move the website bits to a Git repo
> 
> Hi folks,
> 
> Short version:
> As per the title, I'd like to vote on moving the website bits to a Git
> repo, specifically "qpid-site".
> 
> Further info:
> The site is one of the single largest groups of stuff we have, both
> with regard to its previous release content and for the additions of
> various new releases as they occur. That's in terms of both overall
> file size and especially the overall number of files. On the latter
> point, this makes using Subversion particularly slow; for example it
> took well over 30mins just to check in the website updates I made
> yesterday. I literally had to leave and come back later because it
> took so long.
> 
> Support for Git based sites have been offered by infra for some time
> now [1]. Things work in essentially the same manner to our current
> Subversion based site, whereby upon checkin the 'content' bits then
> get published to the web servers. The only real difference is that the
> site stuff must exist in the 'asf-site' branch of a particular git
> repo, either the same one as general code or just a dedicated separate
> repo. In our case a dedicated repo seems to makes the most sense, and
> again it seems to be what various other projects do (even the
> otherwise single-repo projects).
> 
> [1] https://blogs.apache.org/infra/entry/git_based_websites_available
> 
> Robbie
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
> 
> 

-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org



Re: [Qpid Dispatcher] Runtime behavior on SunOS

2016-04-20 Thread Adel Boutros
Here they are:

Solaris:
1)  qdpn_driver_wait_3:  idx=2, d->fds[idx].revents=*4*, POLLIN=1
*Test dies here*
 
Linux:
1)  qdpn_driver_wait_3:  idx=2, d->fds[idx].revents=*0*, POLLIN=1
2)  qdpn_driver_wait_3:  idx=2, d->fds[idx].revents=*1*, POLLIN=1
3)  … same as last one until end of test …



--
View this message in context: 
http://qpid.2158936.n2.nabble.com/Qpid-Dispatcher-Runtime-behavior-on-SunOS-tp7641941p7642368.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org



Re: [VOTE] move the website bits to a Git repo

2016-04-20 Thread Oleksandr Rudyy
+1

On 20 April 2016 at 01:03, Robbie Gemmell  wrote:
> Hi folks,
>
> Short version:
> As per the title, I'd like to vote on moving the website bits to a Git
> repo, specifically "qpid-site".
>
> Further info:
> The site is one of the single largest groups of stuff we have, both
> with regard to its previous release content and for the additions of
> various new releases as they occur. That's in terms of both overall
> file size and especially the overall number of files. On the latter
> point, this makes using Subversion particularly slow; for example it
> took well over 30mins just to check in the website updates I made
> yesterday. I literally had to leave and come back later because it
> took so long.
>
> Support for Git based sites have been offered by infra for some time
> now [1]. Things work in essentially the same manner to our current
> Subversion based site, whereby upon checkin the 'content' bits then
> get published to the web servers. The only real difference is that the
> site stuff must exist in the 'asf-site' branch of a particular git
> repo, either the same one as general code or just a dedicated separate
> repo. In our case a dedicated repo seems to makes the most sense, and
> again it seems to be what various other projects do (even the
> otherwise single-repo projects).
>
> [1] https://blogs.apache.org/infra/entry/git_based_websites_available
>
> Robbie
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>

-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org



Re: [VOTE] move the website bits to a Git repo

2016-04-20 Thread Andrew Stitcher
+1

On Wed, 2016-04-20 at 01:03 +0100, Robbie Gemmell wrote:
> Hi folks,
> 
> Short version:
> As per the title, I'd like to vote on moving the website bits to a
> Git
> repo, specifically "qpid-site".


-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org



Re: [Qpid Dispatcher] Runtime behavior on SunOS

2016-04-20 Thread Andrew Stitcher
On Wed, 2016-04-20 at 08:03 -0700, Adel Boutros wrote:
> Here they are:
> 
> Solaris:
> 1)  qdpn_driver_wait_3:  idx=2, d->fds[idx].revents=*4*, POLLIN=1
> *Test dies here*

revents=4 seems to be POLLOUT.

Since this is the read end of a pipe (if I understood correctly) I'm
not sure why POLLOUT is true, or even why that bit is in the interest
set. But in any case it can just be ignored as dispatch is never going
to write to the read end of the pipe.

Andrew


-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org



Re: [Qpid Dispatcher] Runtime behavior on SunOS

2016-04-20 Thread adelboutros


Thanks Andrew! We were also amazed at the fact it was a POLLOUT but it's not 
the first time Solaris has an inexplicable behavior ...


I will try to fix the code to ignore Pollout flag and let you know if it works.


Would it interest you if i provide a patch also in case it works?



Sent from Outlook Mobile



From: Andrew Stitcher

Sent: Wednesday, April 20, 19:31

Subject: Re: [Qpid Dispatcher] Runtime behavior on SunOS

To: users@qpid.apache.org



On Wed, 2016-04-20 at 08:03 -0700, Adel Boutros wrote:

> Here they are:

> 

> Solaris:

> 1)  qdpn_driver_wait_3:  idx=2, d->fds[idx].revents=*4*, POLLIN=1

> *Test dies here*


revents=4 seems to be POLLOUT.


Since this is the read end of a pipe (if I understood correctly) I'm

not sure why POLLOUT is true, or even why that bit is in the interest

set. But in any case it can just be ignored as dispatch is never going

to write to the read end of the pipe.


Andrew



-

To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org

For additional commands, e-mail: users-h...@qpid.apache.org




Re: [Qpid Dispatcher] Runtime behavior on SunOS

2016-04-20 Thread Adel Boutros
After checking the help of pipe, the behavior is different between Solaris
and Linux.

On Linux, pipe returns 2 file descriptors: *one *for reading and *one *for
writing.
On Solaris, pipe returns 2 file descriptors: *both *are for reading and
writing.

So in the case of Solaris, the POLLOUT is valid as there is no data to read
but the file descriptor is ready to write.

Linux pipe ref: http://linux.die.net/man/2/pipe
Solaris pipe ref:
https://docs.oracle.com/cd/E53394_01/html/E54765/pipe-2.html

I think the test code which calls pipe should make the fd[0] read-only to
make the test work.

PS: The *revents *for the "write file descriptor" is actually POLLOUT on
both Solaris and Linux which makes sense with the explanation I just
provided.



--
View this message in context: 
http://qpid.2158936.n2.nabble.com/Qpid-Dispatcher-Runtime-behavior-on-SunOS-tp7641941p7642395.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org