Re: A question of workflow

[Richard Purdie <rpurdie@rpsys.net>]

On Sat, 2006-12-30 at 16:16 +1100, Matthew Palmer wrote:
> I've hacked on the Ruby bitbake spec so it can build commonly-used
> extensions like zlib, socket, and openssl.  However, I'm not sure how to go
> about committing, submitting, and merging this patch with the main OE tree.
> 
> What I've done so far:
> 
> * Gotten a checkout of the org.openembedded.dev branch;
> * Made my modifications;
> * Created a key;
> * Committed my changes to my working copy.
> 
> Now I can't even manage to retrieve the diff of my changes (the 'obvious'
> step of running "mtn diff -r <SHA1>" didn't do anything useful) to submit
> them to the bugzilla.  

I'm not sure what the right command it but you should be able to extract
that diff somehow, I don't know offhand what the command would be.

> Of course, submitting a context-free patch when
> you've got a full distributed RCS at your bidding seems a bit archaic
> anyway.
> 
> So, my questions:
> 
> * How do I get my diff back?
> * How do I submit my changes to the OE project for merging?
> * Will I have problems when the change gets committed to the trunk?
> * (The biggie) is there a guide on the wiki or somewhere describing the
>   preferred workflow for making changes and working effectively with the rest
>   of the OE developer community?  (Google wasn't at all illuminating)

What you've described is how I or any other OE developer with an
authorised monotone key would work with OE. The problem is we can't just
give access to anyone as that wouldn't make any sense for obvious
reasons.

Before we give out such access, we need to have some idea of a persons
capabilities and trust them enough not to break things (too badly ;-).
We generally ask you start submitting patches via the bugzilla and then
when we're happy you might get direct commit access. This doesn't fit in
with the SCM (monotone) that well.

It does mean you shouldn't be committing changes locally via monotone.
If you do this you will have to pull and then merge every time. That
isn't a problem in itself but if you do get direct commit access, we
will not be happy adding hundreds of extra merges to the main
repository.

Richard