Hi, Nathan,
I remember promising to help you with the workflow document a few days
ago. I am having a little trouble following your outline. Fleshing it
out a little more would probably be helpful to keep us on track.
Anyway... I did make some first small changes today and I am addressing
this particular topic. Please review.
Option 3: For those who do not use git or have git at all, how to get
changes based on a release to us. Greg can hopefully enlighten us as to how
those customers are currently doing that (are they just zipping their
entire nuttx tree and sending it? are they using some other
patch-generating program? what?). Once we know, we document exactly what to
do.
I have accepted changes in most any form that people want to send them
to me. But never while zipped trees. I have no idea what I would do
with that. For small changes, it is the content that matters, not so
much the form. I have accepted emails just indicating in discussion one
or two line changes. I don't like those very much but I have accepted them.
Form does matter for larger changes. Some people send diffs generated
with the Linux command line 'diff -r ' command. Those work fine. GIT
patches work too. No one has sent a 'git request-pull' but I suppose
you will deal with that as with a patch. Basically diffs, patches, and
textual pull requests are all the same thing just with varying amounts
of metadata.
For me, PRs were less used. I would get 20 patches per each PR. I did
not like to accept PRs in the old Bitbucket repositories because they
went directly to master which is not a good practice. I did not have a
development branch and I don't know if Bitbucket supported changing the
base of a PR like github does. But PRs were a nightmare in that
environment. I think they will work better for us because we have more
process in place to deal with them.
When you are set up to handle PRs they are sweet.
When any of those things reach us (by PR or email) we, the committers, do
whatever is necessary to process them through accept&merge, rework, or
reject. And again, we have to document for ourselves, the committers,
exactly how to do that, including git incantations. This is necessary to
ensure that current committers know what to do and also to lower barriers
to entry for new committers in the future.
I think most of us are getting on the same page. DavidS is still the
outlier. David has a lot of knowledge, it would be good if we could get
him on board with the rest of us. We could do so much better if we
worked together.
Greg
