[Ironruby-core] Where is help needed?
John Lam (DLR)
jflam at microsoft.com
Fri Nov 16 11:29:36 EST 2007
Peter Bacon Darwin:
> It is a shame that the code is not being developed directly against the
> RubyForge repository as this definitely gives a feeling of them and us
> makes it difficult to see what is being done, what progress is being
> and it creates extra work for the maintainers ensuring that the
> internal and
> external repositories are synched up - there have been a number of
> recently about dodgy file paths and project references.
Unfortunately, as much as we would love to make the "two repository" problem go away, the reality is that too much of our internal testing infrastructure (our SNAP queue, which is a lab of 20+ computers which run our check-in, sign-off, performance tests among others) is tightly coupled to TFS.
There's also another problem that isn't visible to external folks: the DLR is undergoing a massive refactoring. Internally, all of the projects that depend on DLR (including some unannounced projects) live inside of the same TFS repository. What this means is that if a DLR change breaks something, we have to fix it otherwise SNAP won't allow the check-in. This forcing function lets us keep all of our code sync'd with DLR changes which is goodness. It also helps us understand in real time the impact that DLR changes have on consumers. Think about this as "real time continuous integration".
The latter case explains why we haven't sync'd the SVN repository in two weeks. We had a large change (the stuff in the demos we had for RubyConf) that included some DLR changes that broke all sorts of stuff in, um, interesting ways. It's taken us this long to get the check-in through the queue (it went in yesterday), so we're preparing to push a new set of sources out today.
> Some kind of work tracking tool would be beneficial, even if it was
> just a
> priority list of things that needed to be done so that people out here
> pick up something. I suppose the problem is also that, for instance,
> no one
> knows who I am and what quality of code I can produce and so it would
> risky to allocate work to me. How could this be solved.
I think what we can do is get together at the beginning of each week with a quick 'scrum' via email (probably better since we work across all sorts of different time zones). This way we can announce the things that we're working on, so that we're sure that we're not stepping on other folks' toes. Sound reasonable? I'll kick off a scrum mail on Monday.
> b) The
> quality/style/efficiency is not accepted by the maintainers and my code
> to waste.
If this were to happen, I don't think that your code goes to waste. You've learned something valuable and the best way of improving is to get continuous, critical feedback on the progress of your work.
Like so many other things, it's about confidence - and there's no better way of building confidence (in both directions) by submitting code that you've thought about, receiving / incorporating feedback and repeating.
More information about the Ironruby-core