Agree. Shit happens, we'll deal with it. For now let's just lock it down to one 
machine. We can also just setup individual builds on the separate machines. No 
big deal.

jvz

On 2012-11-26, at 11:18 AM, Kristian Rosenvold <kristian.rosenv...@gmail.com> 
wrote:

>> There is also
>> https://issues.jenkins-ci.org/browse/JENKINS-15367
>> which went into Jenkins 1.492 that was released yesterday, that may or
>> may not be a factor in this depending who you talk to.
> 
> Additionally, there is
> https://issues.jenkins-ci.org/browse/JENKINS-6604 which was fixed in
> remoting
> 4 days ago. According to the issue text it renders the slaves
> "unusable". To which extent that makes the
> remote poller crash out is also unknown. But it's "known" that we have
> a *lot* of 6604 on the nodes,
> especially right after a restart. I am unsure what effect a single
> "bad apple" among the remote nodes
> has and to what extent we would detect it.
> 
> 
> Reading the jenkins code makes me quite sure that any build that is locked to
> 1 specific node will not encounter any of the network-down issues. I
> don't really understand
> how to get "assignedNode"
> (https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/model/AbstractProject.java#L354)
> to be non-null but that should stop the random reallocations. I assume we 
> could
> lock a few of the jobs down to given nodes and keep some open while we
> continue to track the problem ?
> 
>> 
>> Apart from these issues I proposed that we release a couple of our own
>> products using git, before we move the core over to git. Just so that we
>> have a good grasp of how a Maven release using git is done and get it
>> properly documented. I'm not up to date on the progress here though.
>> Would those of you that have done such releases please let us know?
> 
> I believe all wagon, surefire and scm have all been released from git,
> so I think we're in the clear on /that/ particular aspect.
> 
> Personally I think we should go ahead and convert core too.
> 
> 
> Kristian
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

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

Reply via email to