Patches against Releases? (Was Re: Contributions (PR or patches))

[Gregory Nutt <sp...@gmail.com>]

>> 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