[Openais] Misc Corrections
Daniel Stodden
stodden at cs.tum.edu
Wed Oct 27 17:52:03 PDT 2004
On Wed, 2004-10-27 at 15:34 -0700, Steven Dake wrote:
> Daniel,
>
> It looks like you know more about bk then I do :)
>
> You ask an excellent question...
>
> I propose we formalize your suggestion for submitting patches:
>
> 1. Developers create diff -uNr against some baseline so it may be
> reviewed on the mailing list.
>
> 2. Comments are resolved until final diff is approved.
>
> 3. Once final diff is approved, bk sendpatch is used to send a patch to
> the mailing list.
>
> 4. Patch creater requests this patch is the final patch to be applied
> and matches the diffs.
>
> 5. Maintainer of service (or me) applies patches. Any merge problems
> that cannot be resolved may require patch creator's involvement.
>
> All changes even by maintainers should be posted on the mailing list.
> If there are issues with the changes they will either not be applied or
> a bug can be opened to resolve the remaining issues later. (we have done
> something like this for logging which isn't quite complete, but its much
> better now to have something then to be perfect).
okay, this is good. i've started on a bitkeeper howto in order to
explain how this is supposed to work in bk terms.
ideally, we'd get a copy on the homepage or somewhere similar. this
should make things a little easier for anyone to join.
this won't get finished tonight, though :P. see below.
======================================================================
OpenAIS BitKeeper HOWTO
======================================================================
1. Getting the source
To get the OpenAIS source through bitkeeper, create a clone of the
OSDL bitkeeper repository:
cd ~/src
bk clone bk://bk.osdl.org/openais ais-upstream
This creates a new directory 'ais-upstream' in your current working
directory. Your naming may vary.
If you just intend to build from the head of the official bk tree,
proceed to step 3.
2. Preparing for changes
Working with BitKeeper is all about separating changes by issue. For
each item you are going to work on, create another clone of your
original clone.
# Hunt the crasher
bk clone -l ais-upstream ais-bugfixes
# Implement another service
bk clone -l ais-msg ais-msg
# Stuff nobody besides me will ever use
bk clone -l ais-upstream ais-privatehacks
The '-l' option makes BK use hard links where possible in order to
save disk space.
Conceptually, this leaves you with a tree of interconnected
repositories like the one below:
ais-upstream
/ | \
/ | \
/ | \
ais-privatehacks ais-msg ais-bugfixes
When receiving updates later on, one advantage of such a setup is that
you need to pull from the OSDL parent only once. Other repositories
are fed from their immediate, local parent.
# FIXME: steal some more stuff from linux-bk-howto
3. Where are the files?
After cloning, your tree still looks empty.
If you just want to build and/or install, the simplest way to do so is
make GET="bk get"
This will enable GNU make to checkout all the files it needs
automagically (including the missing Makefile). Note that this turns all
source files into intermediate targets, so the source will be removed
after the build process is finished with them, leaving you with a few
object files and executables afterwards.
If you want to browse the tree instead (or have use a make without
builtin SCCS support) issue the following command:
bk -r co
This checks out all the files like you are probably used to.
4. Hacking the source
The 'co' command leaves you with read-only copies. In order to edit
a file, try
bk edit <filename>
Alternatively, a
bk -r edit
will check out all the entiry tree in read/write mode. Be careful not
to mix changes which do not belong into the same category.
5. Creating a ChangeSet
If you're finished with a respective piece of work, create a
changeset. A changeset is a collection of changed files. The simple
way to collect these files is by issuing
bk citool
This starts up a graphical tool showing all the files you've changed
so far. Comment all the individual changes to files
('deltas'). Acceptance of your patch will depend on thorough
comments. Once all the desired deltas are commented and selected for
commit, you should add a ChangeSet comment. Press 'Commit' to complete
the process. More information on how to work with citool is provided
with the BitKeeper documentation:
bk help citool
6. Updating your tree
Depending on the time spent between steps 4. to 5., there may be
pending changes at the official repository other developers applied
concurrently. Use
bk pull ... # FIXME
to apply these changes. The 'bk pull' command will only proceed on a
clean tree bla bla bla...
7. Seeking review
...
bk -r diffs -u # FIXME
bk rset .. | bk diffs - # FIXME
...
8. Submit
...
bk send openais at lists.osdl.org #FIXME
...
suggestions not just welcome but begged for.
regards,
daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.linux-foundation.org/pipermail/openais/attachments/20041028/49aefb5a/attachment-0001.pgp
More information about the Openais
mailing list