Not at this point yet but what’s the process once I have enough
tests/refactorings/suggestions on code fixes for a formal review and then
adding to the next release? None of my items I am working on are critical.
Do you also recommend re-basing periodically to keep the commit on my
branch down to a single commit for one large review? From reading the
other threads that seems to be the way that people like submitting code.
cheers
ian
ps - Submitted to debian-med as well to ask about how to start process to
get our package included in the distros. Will keep plugging away on this.
Keeping it to one commit is a very good idea for the first commit that goes into the official codebase (once you have a chunk of code that is working, then that’s all you need to ask for a review). After you get one commit in for your project, though, then it’s really up to you how many commits you break up your code into (since it’s essentially your project, it won’t really need a long-winded review for your code at that point; if you do have a question about something, though, feel free to always ask for guidance on stuff).
(I’m following the debian med thread and saw your post; they are a very nice group and they are very helpful; I’m almost done with testing and will upload the most recent package pieces so you have it as a reference) Feel free to use the wiki(create pages or edit current pages; whatever you wish) as a place to keep notes on the package building: http://www.open-emr.org/wiki/index.php/Ubuntu-Debian_Package_Developers_Page
Brady - Will try to keep the first commit to a single one but I must admit
that I am a bit baffled about times by what ‘git rebase -i’ does. Might
need some help with it in the future.
I have applied for an account for the Wiki and as I work on the project
with Andreas will update the Wiki with developments/notes for the packaging
items.
Keeping it to one commit is a very good idea for the first commit that
goes into the official codebase (once you have a chunk of code that is
working, then that’s all you need to ask for a review). After you get one
commit in for your project, though, then it’s really up to you how many
commits you break up your code into (since it’s essentially your project,
it won’t really need a long-winded review for your code at that point; if
you do have a question about something, though, feel free to always ask for
guidance on stuff).
(I’m following the debian med thread and saw your post; they are a very
nice group and they are very helpful; I’m almost done with testing and will
upload the most recent package pieces so you have it as a reference) Feel
free to use the wiki(create pages or edit current pages; whatever you wish)
as a place to keep notes on the package building:
Happy to help with git rebase -i and other git issues that arise. If get into a bind, just throw your branch onto github and we can provide direction on how to proceed for rebasing etc. (once you figure out git rebase -i, then things in git will become much easier).
Thanks. Will let you know once I need some help. I git push anything that
I think might be difficult to reproduce on my local laptop. Otherwise I
keep committing locally and then rebase before I push (to try and collapse
most of the commits into one).
Excited to start working with Andreas to get OpenEMR into the Debian distro
if possible and see how things might work from the repos.
Happy to help with git rebase -i and other git issues that arise. If get
into a bind, just throw your branch onto github and we can provide
direction on how to proceed for rebasing etc. (once you figure out git
rebase -i, then things in git will become much easier).