OK, that's probably what happened. I deleted the broken enlistment on that theory, in fact. Someone else had added the broken enlistment. This would seem to mean that anyone can break updating for ... [More] any of my packages simply by adding broken enlistments. This doesn't seem desirable to me. [Less]

Take a look at HDBC. There are two enlistments: mine, and someone else's. The other person's has apparently started failing. Mine works fine, but was last updated 3 months (!!) ago. Is that really normal?

OK, so maybe I'm a little paranoid, but I like to not reveal my Jabber status any more than I have to. It is quite possible to send me a message without knowing my status, and it's also quite ... [More] possible to have me in your roster without knowing my status. Ohloh, however, refuses to send me messages (responses to help, even) unless I authorize it to see my status. It re-requests authorization before sending me a response even if I have removed authorization. I don't know why it needs to know my status, and really, it shouldn't need to. Can that requirement be removed? [Less]

Yes, it does appear to be OK now. Thanks for checking.

Hi, Two new projects to Ohloh -- libarchive and offlineimap -- aren't updating properly. As I noted on http://www.ohloh.net/forums/10/topics/1651, OfflineIMAP is generating a "failed" for the ... [More] counting lines of code stage. I observed it do that at least twice on the master branch last night (I had deleted and re-added that particular enlistment to see if it would help). Oddly, the v7 branch has not had a problem. By today, OfflineIMAP is in step 3 "waiting in queue". OfflineIMAP is written in Python and its source is in Git. libarchive is written in C and is stored in CVS. It has still not updated its CVS enlistment; it has been stalled in the queue for step 2 for more than 14 hours. I do maintain a Git branch for my Debian integration of libarchive, and it was processed normally 14 hours ago. Is it normally this slow for new projects? [Less]

It's now happened a second time with OfflineIMAP. Oddly enough, one branch worked...

I think that an alias may have been involved here. It renamed jgoerzen to John Goerzen. Editing the experience record with the John Goerzen name seems to have fixed it.

The same just happened on OfflineIMAP. OfflineIMAP is hosted with Git on my own server, which should be quite speedy. It is a rather routine Python package. Any ideas?

This is weird. If you go to the vcs-load-dirs project, you will see a "John Goerzen" contributor listed twice. One with 203 commits, the other with 0. The one with 0 is tied to my account. When I ... [More] try to click "I am this person" on the other one, it takes me to the create alias screen, but "John Goerzen" is not an option. Very strange. I think I may have done this by joining the project before adding the enlistment, but not sure. [Less]

Yes indeed, that does appear to be correct. In fact, it appears that a person can sign up as a contributor immediately to a project that has no enlistments (such as Debian). Once an enlistment is ... [More] created, the contributor button disappears until it is processed (an hour or so maybe?) Thanks again for the answer. Yes, in fact I had forgotten my contributions to some projects until I searched for my name over here and they all came up. It did jog my memory and it was all correct, but it was somewhat of a surprising thing that Ohloh knew about things I had forgotten. [Less]