Re: Hudson access for non-PMC member
Hi Philip -- it's purely because the user accounts on the Hudson machines have quite a lot of privileges. Personally I'm open to the idea of making an exception if the AVRO PMC call for it, and assuming none of the other Hudson admins are against it. --j. On Sat, Jan 23, 2010 at 01:01, Philip Zeyliger wrote: > Hi there, > > I'd like to setup a Hudson build for the AVRO subproject of Hadoop. > The current policy is to only allow such accounts for PMC/PPMC > members. Might the policy be loosened to allow accounts for > committers or an exception be made? > > Thanks, > > -- Philip > > -- --j.
RE: Hudson access for non-PMC member
Hi Justin, Grant Ingersoll and I were asking for the same before xmas and we also proposed that the Lucene PMC could vote for me to be added as a Hudson user. But we got no definitive response. It would be fine for me (only committer) to have such access as I currently fix and have fixed lots of probs in the Lucene Java build. Currently I have to ask another committer (Mike McCandless) to do the changes. We also added support for Clover 2.6.x to our Hudson builds. Uwe - Uwe Schindler uschind...@apache.org Apache Lucene Java Committer Bremen, Germany http://lucene.apache.org/java/docs/ > -Original Message- > From: jma...@gmail.com [mailto:jma...@gmail.com] On Behalf Of Justin > Mason > Sent: Wednesday, January 27, 2010 12:26 PM > To: builds@apache.org > Subject: Re: Hudson access for non-PMC member > > Hi Philip -- > it's purely because the user accounts on the Hudson machines have > quite a lot of privileges. > > Personally I'm open to the idea of making an exception if the AVRO PMC > call for it, and assuming none of the other Hudson admins are against > it. > > --j. > > On Sat, Jan 23, 2010 at 01:01, Philip Zeyliger > wrote: > > Hi there, > > > > I'd like to setup a Hudson build for the AVRO subproject of Hadoop. > > The current policy is to only allow such accounts for PMC/PPMC > > members. Might the policy be loosened to allow accounts for > > committers or an exception be made? > > > > Thanks, > > > > -- Philip > > > > > > > > -- > --j.
Re: Hudson access for non-PMC member
Hi, On Wed, Jan 27, 2010 at 12:26 PM, Justin Mason wrote: > Personally I'm open to the idea of making an exception if the AVRO PMC > call for it, and assuming none of the other Hudson admins are against it. +1 BR, Jukka Zitting
Re: Hudson access for non-PMC member
hi Uwe -- sorry for the lack of response at the time :( The same would apply in your case, IMO. On Wed, Jan 27, 2010 at 11:47, Uwe Schindler wrote: > Hi Justin, > > Grant Ingersoll and I were asking for the same before xmas and we also > proposed that the Lucene PMC could vote for me to be added as a Hudson user. > But we got no definitive response. > > It would be fine for me (only committer) to have such access as I currently > fix and have fixed lots of probs in the Lucene Java build. Currently I have > to ask another committer (Mike McCandless) to do the changes. We also added > support for Clover 2.6.x to our Hudson builds. > > Uwe > > - > Uwe Schindler > uschind...@apache.org > Apache Lucene Java Committer > Bremen, Germany > http://lucene.apache.org/java/docs/ > >> -Original Message- >> From: jma...@gmail.com [mailto:jma...@gmail.com] On Behalf Of Justin >> Mason >> Sent: Wednesday, January 27, 2010 12:26 PM >> To: builds@apache.org >> Subject: Re: Hudson access for non-PMC member >> >> Hi Philip -- >> it's purely because the user accounts on the Hudson machines have >> quite a lot of privileges. >> >> Personally I'm open to the idea of making an exception if the AVRO PMC >> call for it, and assuming none of the other Hudson admins are against >> it. >> >> --j. >> >> On Sat, Jan 23, 2010 at 01:01, Philip Zeyliger >> wrote: >> > Hi there, >> > >> > I'd like to setup a Hudson build for the AVRO subproject of Hadoop. >> > The current policy is to only allow such accounts for PMC/PPMC >> > members. Might the policy be loosened to allow accounts for >> > committers or an exception be made? >> > >> > Thanks, >> > >> > -- Philip >> > >> > >> >> >> >> -- >> --j. > > -- --j.
Re: Hudson access for non-PMC member
On 27/Jan/2010 11:26, Justin Mason wrote: > Hi Philip -- > it's purely because the user accounts on the Hudson machines have > quite a lot of privileges. Anything much more significant than people's privileges via their people.a.o accounts? > Personally I'm open to the idea of making an exception if the AVRO PMC > call for it, and assuming none of the other Hudson admins are against > it. Not against it, but if there is a flood of new account requests from committers I'd like to examine whether we can roll those machines into the existing infra routines. Regards, Tim
Re: Hudson access for non-PMC member
Perhaps there is an in-between here, too. Can't we give access to Hudson itself w/o giving access to the machine? That way, Uwe could run and configure the jobs (which is the most common task) w/o necessarily needing to deal w/ the machine level stuff. -Grant On Jan 27, 2010, at 11:04 AM, Tim Ellison wrote: > On 27/Jan/2010 11:26, Justin Mason wrote: >> Hi Philip -- >> it's purely because the user accounts on the Hudson machines have >> quite a lot of privileges. > > Anything much more significant than people's privileges via their > people.a.o accounts? > >> Personally I'm open to the idea of making an exception if the AVRO PMC >> call for it, and assuming none of the other Hudson admins are against >> it. > > Not against it, but if there is a flood of new account requests from > committers I'd like to examine whether we can roll those machines into > the existing infra routines. > > Regards, > Tim
Re: Hudson access for non-PMC member
yeah, that's an easy way to do it. +1 On Wed, Jan 27, 2010 at 17:38, Grant Ingersoll wrote: > Perhaps there is an in-between here, too. Can't we give access to Hudson > itself w/o giving access to the machine? That way, Uwe could run and > configure the jobs (which is the most common task) w/o necessarily needing to > deal w/ the machine level stuff. > > -Grant > > On Jan 27, 2010, at 11:04 AM, Tim Ellison wrote: > >> On 27/Jan/2010 11:26, Justin Mason wrote: >>> Hi Philip -- >>> it's purely because the user accounts on the Hudson machines have >>> quite a lot of privileges. >> >> Anything much more significant than people's privileges via their >> people.a.o accounts? >> >>> Personally I'm open to the idea of making an exception if the AVRO PMC >>> call for it, and assuming none of the other Hudson admins are against >>> it. >> >> Not against it, but if there is a flood of new account requests from >> committers I'd like to examine whether we can roll those machines into >> the existing infra routines. >> >> Regards, >> Tim > > > -- --j.
RE: Hudson access for non-PMC member
Hi Grant, that would be an option, but during our work, Mike and me only activated the "start new build" button in the GUI, everything else was and had to be done in the shell: - Updating lucene's private SVN tools for the new lucene rev-based backwards branch (sparse checkout) - Upgrading hudson's clover version for our new coverage reports (that work correct with backwards branch) - Killing stuck builds (to get a stack trace you have to send a SIGHUP to the stuck JVM first) You haven’t seen our IRC conversation between Mike and me where we did something like "human remote control" when changing our build scripts and so on. Something like "tell me whats in dir xyz", "hmm, ok then we have to Ah before tell me if solaris has a toolxy installed!", "yes", "ah then we can do pqrs first and tar this there". Funny, but worked, but took a day :-) On the other hand, you can always configure a job that runs with the Hudson account and does a "rm -rf /hudsoninstalldir" in it - so where is the security? Uwe - Uwe Schindler uschind...@apache.org Apache Lucene Java Committer Bremen, Germany http://lucene.apache.org/java/docs/ > -Original Message- > From: Grant Ingersoll [mailto:gsi...@gmail.com] On Behalf Of Grant > Ingersoll > Sent: Wednesday, January 27, 2010 6:38 PM > To: builds@apache.org > Subject: Re: Hudson access for non-PMC member > > Perhaps there is an in-between here, too. Can't we give access to > Hudson itself w/o giving access to the machine? That way, Uwe could > run and configure the jobs (which is the most common task) w/o > necessarily needing to deal w/ the machine level stuff. > > -Grant > > On Jan 27, 2010, at 11:04 AM, Tim Ellison wrote: > > > On 27/Jan/2010 11:26, Justin Mason wrote: > >> Hi Philip -- > >> it's purely because the user accounts on the Hudson machines have > >> quite a lot of privileges. > > > > Anything much more significant than people's privileges via their > > people.a.o accounts? > > > >> Personally I'm open to the idea of making an exception if the AVRO > PMC > >> call for it, and assuming none of the other Hudson admins are > against > >> it. > > > > Not against it, but if there is a flood of new account requests from > > committers I'd like to examine whether we can roll those machines > into > > the existing infra routines. > > > > Regards, > > Tim >
RE: Hudson access for non-PMC member
> - Updating lucene's private SVN tools for the new lucene rev-based > backwards branch (sparse checkout) By the way, that's related to https://issues.apache.org/jira/browse/INFRA-2442, we solved it with a private version extracted from the recent SVN stable branch solaris build, which is done in a workspace on lucene-zones :-) As soon as this is fixed, we will change out ANT properties to use the "official" SVN client 1.6.x. Uwe
Re: Hudson access for non-PMC member
On 28/01/10 5:45 AM, Uwe Schindler wrote: Upgrading hudson's clover version for our new coverage reports (that work correct with backwards branch) With the new Apache specific license you can now commit the key into your svn repository and therefore you might not need to do anything at the shell at all. That was my experience with the Cayenne project when setting it up with maven. Ari -- --> Aristedes Maniatis GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
RE: Hudson access for non-PMC member
> > Upgrading hudson's clover version for our new coverage reports (that > work correct with backwards branch) > > With the new Apache specific license you can now commit the key into > your svn repository and therefore you might not need to do anything at > the shell at all. That was my experience with the Cayenne project when > setting it up with maven. Yeah, I communicated this with Nick Pellow from Atlassian! But you have to place the clover JAR file somewhere if using ANT not maven. We do not want to have it in our repository, as it is rather large. The other idea (not yet implemented) is to download the JAR into the workspace from the ANT build script. For other things (get a stack trace of hung tests) you still need a shell. Uwe
