Case in point: My $company uses a really awesome SCM: Apache Subversion :-)
All very large corporations I have worked for use commercial SCM
suites. GIT is a great thing for open source projects and small
businesses, but for those companies with essentially unlimited resources
you will often see very different commercial tools .. and also RTOSs 8(
So the process is something along these lines:
(Please fill in any gaps...)
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.
Which begs the question: how do we keep track of emailed patches being
processed? Perhaps as simple as a committer replying to the email to say
that it's being processed?
Is Jira an option?
Once at GitHub then automated tests run (including nxstyle), then ... ???
In certain parts of the system, I think we should have reasonably low
barriers to getting contributions in. Drivers for adding, say, SPI support
to some chip shouldn't require too much scrutiny provided they meet the
coding standard...
But:
In some critical parts, including the build system and OS internals like
the scheduler, we need a process whereby several pairs of eyes will look at
the PR and agree that it should be merged. For example, say, we need N +1s
and zero -1s for any changes that affect those parts... (the value of N
will need discussion but that is a subject for another day).
+1
Changes to "leaf" software can not create widespread problems but still
need to be taken seriously.
Greg
