committing changes

[Connor Imes]

Hi Dan, see my responses in line.

On 09/24/2010 11:21 PM, Dan 'Da Man' wrote:
> Now that I have been so graciously granted the ability to commit
> changes, I have some questions regarding the exact methods to commit
> changes.  First, does committing changes differ greatly than how I
> have already been committing changes?  
No, from the point where you have previously taken your diffs, you can
commit rather than posting the patch to an LP bug.  After your commit,
you can mark the bug as Fix Committed.  For fixes that are for specific
bugs, you can use the --fixes option in the commit command.  e.g.:
    bzr commit -m "fix for xyz" --fixes lp:12345

> Second, if I find something
> that needs to be changed, should I file a bug before making and
> committing the fix to the bug?  
This is not needed.  Before the package is built, Matthew (or somebody
else) will update the debian changelog based on the commit messages.  If
you are making large changes, it's not a bad idea to run it by the
mailing list or file a bug report as a place to post a big patch for review.

> Third, after making the changes/fixes,
> should I push the commits to my own branch (lp:~heymrdjd/...) before
> committing to the trunk.  
This is also not needed.  Per best practices with version control
systems, each commit should be for a separate fix so they can be rolled
back if needed or applied to other branches individually.

> Fourth, does committing to the trunk make
> actual changes to the (x/k/edu)ubuntu-docs package?
>   
No, the changes you commit will become available after the package is
built and pushed into the Ubuntu repos.  This usually means there are
multiple fixes each time a new version of the package is released.  When
the package is built and pushed to the Ubuntu repos is also the point
where bugs fixed be marked as Fix Released.

Finally, also see [1]

[1] https://wiki.ubuntu.com/DocumentationTeam/SystemDocumentation/Submitting

Cheers,
-Connor