Will we receive a patch, which I'm assuming will come to dev@ in the
form
of email attachments, then a NuttX committer looks at it, sees if it
looks
reasonable, then converts that into a GitHub PR.
Or would we take PRs. PRs would, mostly likely, be directly against
the master. Is that an issue?
Would we merge patches onto master? Or onto a development branch?
What would be do with PRs against master?
One problem with patches is the they have dependencies. Applying one
patch, may cause a subsequent patch that affects the same file to fail
to apply. The solution would be to put each patch on a branch so that
it can be merged back in without conflicts (or at least with conflicts
that can be resolved with GIT help).
We need to spell out the branching.
Here is a follow-on question. We have not addressed releases yet, but I
assume that we will be making releases on branches. This offers us
another opportunity to make life easier for NuttX users too (which
should always be one or our primary objectives in all things):
Most businesses will use the GIT-less release versions and will avoid
code du jour. When they fix bugs or add features, the changes will be
against the release versions not the current GIT HEAD. In the past, I
have asked people who submit patches against a release to update the
patch so that it applies to the current HEAD. I imagine that this is an
onerous task if you don't use GIT at all.
Wouldn't it be better for such users to be able to accept patches
against releases too? These might have to be applied to branches off of
the release branch, but could still be cherry-picked back to master if
they check out.
This is not a critical issue now. Let's deal with the more important
organizational issues at hand, but tuck this this idea away for
consideration later when we fully refine the workflow.
Greg
