WIP: Jan 19

grumbling days. Builds broken on my desktop, and other people’s, but working fine on the build servers, makes me think it is more gcc-4 vs gcc-3.x issues.

I have been messing around with trying to get the Mac Builds to be able to build Intel (Universal Binaries) I think it is working, but it seems to break support for older version of 10.3 (before 10.3.9) and I have not figured out a solution to fail gracefully on platforms with the wrong version of libc. There must be something I can do in the NextStep world to send a message.

Was working on tracking down the change of the profile directory into a new heirarchy, but that is not doing well, also need to change the User-Agent, simple change but now that we are changing the version number we might as well do that .

WIP: Jan 4

today has been kind of a loss.  I have spent a innapropriatly large amount of time doing forensic analysis of our source control.  The changeset of doom is ead72eaef523553ea5155c9afe61c76e3e4fcc42 despite one of its parents having the mac/mimeTypes.rdf it does not.  How Anthony managed to do that merge without the file and without noticing it is the source of much trouble.  This means he accidently reverted Manish’s change.

Now anthony did not introduce this error, it was introduced earlier by some of the confused merging between Ian and Andy, but I am more troubled by somone merging and accidently reverting someone elses changes.  The Ian and Andy merges were many and confusing the chance of something going wrong was high, and because in mercurial doesn’t require you to explictly remove a file (if you just rm it, then commit it is then it is gone and it doesn’t show up as a modified file in the ChangeLog).

Everybody using mercurial should have hgk

I have not been able to fully reproduce what happened.  My current advice is that everyone explicitly name the changeset they are changing merging to and do a diff to make sure they are doing what they intend.

The big problem is that once you begin to branch, files that you have not touched, but somebody else on a divergent branch has touched appear to be modified and you don’t want to check in your modified (ie older files)

I wish I had a good way of making this clear to everyone, but I don’t yet.  So far everything I look at implies that our tool is working as deseigned, but we all have to be release engineers and worry about how we are handeling our branches on a much deeper level than with centralized source control.

All my bugs are out of UI complete, but that doesn’t mean that I have an easy workload.  I am taking Friday off, so I geuss I will need to be working on Saturday to take out some easy bugs.

WIP: Jan 3

Working on the confusion with multiple tips in mercurial.  The problem is not mercurial it is a problem with distributed source control.  We keep having developers who start producing an anonymous branch in their local repository.  Then there is the problem of when does that merge back to the tip on the master repository?  This doesn’t happen automagically because there is no concept of slave and master other than the way we use it.

On thing that is a bug in mercurial is that file removals are not logged.  It is just frustrating to watch your commits dissapear, and bugs reopen.

Also working on the new l10n system with gandalf.  Now we have the overlay of svn and cvs files in $b/flock/l10n, need to have gandalf finish making that work, but locale_set now does what we planned yesterday.

More sysadmin work on our build storage server, should last a few more weeks before it fills up.  Creating a thinning script would help, but we still need more disk space.  We also need a real sysadmin, our problem is that we have a bunch of work for a real unix server guy, but I think only a couple of months of work.  Some day we need to have someone in charge of IT as well.

Anthony took my ugly windows bugs yay.

Still have  bunch of work for the 15th.