Forums : Technical Issue Help
Dear Open Hub Users,
We’re excited to announce that we will be moving the Open Hub Forum to
https://community.blackduck.com/s/black-duck-open-hub.
Beginning immediately, users can head over,
register,
get technical help and discuss issue pertinent to the Open Hub. Registered users can also subscribe to Open Hub announcements here.
On May 1, 2020, we will be freezing https://www.openhub.net/forums and users will not be able to create new discussions. If you have any questions and concerns, please email us at
[email protected]
Some GNOME enlistments are stuck
A number of GNOME enlistments are stuck in the 'Waiting in queue' state and not updating:
- git://git.gnome.org/anjuta
- git://git.gnome.org/atkmm
- git://git.gnome.org/epiphany
- git://git.gnome.org/gcalctool
- git://git.gnome.org/gconf
- git://git.gnome.org/gnome-keyring
- git://git.gnome.org/gnome-nettool
- git://git.gnome.org/gnome-power-manager
- git://git.gnome.org/gnome-screensaver
- git://git.gnome.org/gobject-introspection
- git://git.gnome.org/libipoddevice
- git://git.gnome.org/librsvg
- git://git.gnome.org/pygtksourceview
And one failed:
- git://git.gnome.org/libart_lgpl
Kalev,
The failed job has been cleared for now. Will try to see what the delay has been for the enlistments 'Waiting in queue'. I notice many of the enlistments are updating within minutes to an hour.
Thanks!
Kalev,
In monitoring the jobs, I noticed a number of them that were waiting in the queue have been waiting quite a while and I have tried to accelerate them as I can. I also found an additional failed job. I believe that one is now moving forward.
Please note that with 145 enlistments, simple random error will become a large factor in the update process. I'll continue to monitor the progress of this through at least one more update but project management should try to also monitor the project closely to guard against problems.
Thanks!
Very nice, thanks for your help! What caused the enlistments to stay in the 'Waiting in queue' state for so long?
Looks like the ones that were 'in queue' are all cleared up now, except for two that failed:
- git://git.gnome.org/pygtksourceview repo is gone and I removed the enlistment;
- git://git.gnome.org/gnome-screensaver failed, but this repo is working fine when I try to clone it locally, so I'd suspect a temporary failure on either side.
Kalev,
We have a tiered process for dealing with enlistments which are failing. The more retries a job requires, the longer the back-off time until the next attempt. Most issues can be fixed with only a couple of retries and a short back-off but I noted that several enlistments had been through up to 9 retries which represents a very long back-off time indeed.
I will continue to monitor and push on the troubled enlistments to get them to the state where a full update will be completed.
I am currently writing an e-mail to enlist some of the major contributors to Gnome to keep an eye on the project either as managers or informally and let us know when problems crop up. I encourage you to do that as well.
Thanks!
Kalev,
Update seems to be complete. Analysis is now at Apr 06 2011. Will monitor for one additional update cycle.
Thanks!
Thank you!
Kalev,
One additional issue: the enlistment libipoddevice
has been moved to archive (the last commit was 2007-04-19). Please update or delete this enlistment.
Thanks!
Done, thanks.
The web UI showed libipoddevice
in the 'Waiting in queue' state. I find it very confusing if failing enlistments are shown like that; would it perhaps be possible to instead display that it had failed?
Kalev,
Thanks for taking care of that. For the time being, we aren't able to discriminate between failures that can be solved with a simple reschedule and ones that won't ever be fixed that way. So in this case it isn't completely dishonest to call it 'Waiting in queue'.
The error was: fatal: The remote end hung up unexpectedly
which can be caused by many failures. Perhaps after a pre-set number of retries, it should be marked as a persistent failure. Will have to ponder that...
Thanks!
Several GNOME enlistments are in the failed state again; could you take a look please and reschedule the failed ones?
The algorithm for updating enlistments doesn't work particularly well for projects with a huge number of enlistments. Ohloh keeps updating the working ones, but avoids updating the ones that have failed. With such strategy, we get a number of enlistments that are updated daily, but also a number of enlistments that have been failing for weeks. However, updating the working ones does not help, because it's the failed ones that are keeping the stats from updating.
I would instead suggest to slightly alter the algorithm in the presence of failed enlistments: Avoid updating the ones with a known good state and retry the failed ones more often. Keep doing that until all the enlistments are back in the good state. This will save resources on the Ohloh server and will avoid introducing new enlistment failures.
Kalev,
Good morning! (well, it's good for me so far...) I am on the case and will start on the task.
Thanks!
Kalev,
All the failed jobs have run now. Analysis is in-progress. Most (11) were due to a known bug and responded quickly to reschedules. One was an internet problem and also was rescheduled while the last was a different internal error and needed a quick re-fetch. Will let you know when the analysis is done.
Thanks!
Kalev,
Analysis has finished and expect an update to start Any Minute Now... Analysis page is at Aug 12 2011.
Excellent, thanks!