> 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
