Single Committer

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

Recent events have made me reconsider some decisions I made.  I threw 
off the single committer mantle when I saw the abuse of privilege in the 
repositories.  If the PPMC agrees to it, I will take up that role again.

But let's be frank.  Here is what I think that means:

  * I would be sole committer of changes.  The repositories would have
    to be treated as read-only just as back in the Bitbucket days.
  * I would grandfather in the i.MXRT changes.
  * I will decline all workflow related changes until workflow
    requirements are established (that is my only real motivation for
    suggesting this:  To make certain that we have proper requirements
    in place before we accept PX4 workflow into our repositories.  We
    need to do this right and I am willing to protect the repositories
    until the workflow requirements are established.  I expect that to
    take about two weeks.)
  * I would create a dev branch and expect all PRs to be against that
    dev branch.
  * As soon as the PPMC is confident that it has the processes in place
    to handle the commit workload I will gladly relinquish this role.
  * THIS IS NOT THE APACHE WAY.  This is an interim dictatorship role to
    expedite the avalanche of commits expected after the holidays.

If any of this concerns people, please "Just Say No."  I am not married 
to the idea and I am not forcefully advocating it.  This is what people 
wanted me to do a few days ago and if I can protect our right to define 
the workflow, then I will do it.  For me it is a sacrifice that I would 
take with no pleasure in.

Pros:  This will provide project continuity until the PPMC is fully 
functional.  Having workflow requirements will be a huge step in that 
direction.  People stressed about the commit process can relax with 
confidence.  This will protect the code base from premature work flow 
changes until we have an understanding of what we want.  No harm is done 
by deferring workflow changes until we as a team are prepared to deal 
with them.

Cons:  This is not the Apache way.  People who are trying to bulldoze 
the PX4 work flow into the repositories will hate the idea.  Mentors 
will hate the idea.  An approach more consistent with the Apache way 
would just be to let the chaos prevail.  That is fine with me too as 
long as we do not let PX4 advocates take away our group right to define 
our own workflow.  We can still just put all workflow changes on hold 
until we have the requirements in hand.

I am not pushing anything.  Think about it and let me know what you 
would like to do.

Greg

Re: Single Committer

[Disruptive Solutions <di...@gmail.com>]

+1

Verstuurd vanaf mijn iPhone

> Op 24 dec. 2019 om 06:07 heeft Nathan Hartman <ha...@gmail.com> het volgende geschreven:
> 
> On Mon, Dec 23, 2019 at 7:51 PM Gregory Nutt <sp...@gmail.com> wrote:
>> 
>> Recent events have made me reconsider some decisions I made.  I threw
>> off the single committer mantle when I saw the abuse of privilege in the
>> repositories.  If the PPMC agrees to it, I will take up that role again.
>> 
>> But let's be frank.  Here is what I think that means:
>> 
>>  * I would be sole committer of changes.  The repositories would have
>>    to be treated as read-only just as back in the Bitbucket days.
>>  * I would grandfather in the i.MXRT changes.
>>  * I will decline all workflow related changes until workflow
>>    requirements are established (that is my only real motivation for
>>    suggesting this:  To make certain that we have proper requirements
>>    in place before we accept PX4 workflow into our repositories.  We
>>    need to do this right and I am willing to protect the repositories
>>    until the workflow requirements are established.  I expect that to
>>    take about two weeks.)
>>  * I would create a dev branch and expect all PRs to be against that
>>    dev branch.
>>  * As soon as the PPMC is confident that it has the processes in place
>>    to handle the commit workload I will gladly relinquish this role.
>>  * THIS IS NOT THE APACHE WAY.  This is an interim dictatorship role to
>>    expedite the avalanche of commits expected after the holidays.
>> 
>> If any of this concerns people, please "Just Say No."  I am not married
>> to the idea and I am not forcefully advocating it.  This is what people
>> wanted me to do a few days ago and if I can protect our right to define
>> the workflow, then I will do it.  For me it is a sacrifice that I would
>> take with no pleasure in.
>> 
>> Pros:  This will provide project continuity until the PPMC is fully
>> functional.  Having workflow requirements will be a huge step in that
>> direction.  People stressed about the commit process can relax with
>> confidence.  This will protect the code base from premature work flow
>> changes until we have an understanding of what we want.  No harm is done
>> by deferring workflow changes until we as a team are prepared to deal
>> with them.
>> 
>> Cons:  This is not the Apache way.  People who are trying to bulldoze
>> the PX4 work flow into the repositories will hate the idea.  Mentors
>> will hate the idea.  An approach more consistent with the Apache way
>> would just be to let the chaos prevail.  That is fine with me too as
>> long as we do not let PX4 advocates take away our group right to define
>> our own workflow.  We can still just put all workflow changes on hold
>> until we have the requirements in hand.
>> 
>> I am not pushing anything.  Think about it and let me know what you
>> would like to do.
> 
> I agree with this because it is premature to change the way we work
> before there is a documented workflow that helps us understand what to
> do.
> 
> Over the next two weeks, we should focus on designing the top-down
> workflow. It doesn't have to be final and it doesn't have to be
> perfect. We can improve it over time. But right now it's not ready,
> so I appreciate Greg's offer to do that, while the workflow is prepared.
> 
> Thanks to Greg and everyone,
> Nathan

Re: Single Committer

[Sebastien Lorquet <se...@lorquet.fr>]

Not sure throwing more tools at the current mess will fix anthing.

Full support to Greg for benevolent dictatorship extension until things are settled.

Sebastien

Le 24/12/2019 à 08:03, Disruptive Solutions a écrit :
> A platform like this could help? Samsung seems to use it? Does Apache has something like this “Helix Core” and “Swarm” ??
>
> https://www.perforce.com/products/helix-swarm
>
> Benefit drom these ideas? And you could start with 1 commiter and scale up later. The way of working will be getting more clear and get to the “standards” Greg sees??
>
>
> Verstuurd vanaf mijn iPhone
>
>> Op 24 dec. 2019 om 06:07 heeft Nathan Hartman <ha...@gmail.com> het volgende geschreven:
>>
>> On Mon, Dec 23, 2019 at 7:51 PM Gregory Nutt <sp...@gmail.com> wrote:
>>> Recent events have made me reconsider some decisions I made.  I threw
>>> off the single committer mantle when I saw the abuse of privilege in the
>>> repositories.  If the PPMC agrees to it, I will take up that role again.
>>>
>>> But let's be frank.  Here is what I think that means:
>>>
>>>  * I would be sole committer of changes.  The repositories would have
>>>    to be treated as read-only just as back in the Bitbucket days.
>>>  * I would grandfather in the i.MXRT changes.
>>>  * I will decline all workflow related changes until workflow
>>>    requirements are established (that is my only real motivation for
>>>    suggesting this:  To make certain that we have proper requirements
>>>    in place before we accept PX4 workflow into our repositories.  We
>>>    need to do this right and I am willing to protect the repositories
>>>    until the workflow requirements are established.  I expect that to
>>>    take about two weeks.)
>>>  * I would create a dev branch and expect all PRs to be against that
>>>    dev branch.
>>>  * As soon as the PPMC is confident that it has the processes in place
>>>    to handle the commit workload I will gladly relinquish this role.
>>>  * THIS IS NOT THE APACHE WAY.  This is an interim dictatorship role to
>>>    expedite the avalanche of commits expected after the holidays.
>>>
>>> If any of this concerns people, please "Just Say No."  I am not married
>>> to the idea and I am not forcefully advocating it.  This is what people
>>> wanted me to do a few days ago and if I can protect our right to define
>>> the workflow, then I will do it.  For me it is a sacrifice that I would
>>> take with no pleasure in.
>>>
>>> Pros:  This will provide project continuity until the PPMC is fully
>>> functional.  Having workflow requirements will be a huge step in that
>>> direction.  People stressed about the commit process can relax with
>>> confidence.  This will protect the code base from premature work flow
>>> changes until we have an understanding of what we want.  No harm is done
>>> by deferring workflow changes until we as a team are prepared to deal
>>> with them.
>>>
>>> Cons:  This is not the Apache way.  People who are trying to bulldoze
>>> the PX4 work flow into the repositories will hate the idea.  Mentors
>>> will hate the idea.  An approach more consistent with the Apache way
>>> would just be to let the chaos prevail.  That is fine with me too as
>>> long as we do not let PX4 advocates take away our group right to define
>>> our own workflow.  We can still just put all workflow changes on hold
>>> until we have the requirements in hand.
>>>
>>> I am not pushing anything.  Think about it and let me know what you
>>> would like to do.
>> I agree with this because it is premature to change the way we work
>> before there is a documented workflow that helps us understand what to
>> do.
>>
>> Over the next two weeks, we should focus on designing the top-down
>> workflow. It doesn't have to be final and it doesn't have to be
>> perfect. We can improve it over time. But right now it's not ready,
>> so I appreciate Greg's offer to do that, while the workflow is prepared.
>>
>> Thanks to Greg and everyone,
>> Nathan

RE: Single Committer

[David Sidrane <Da...@nscdg.com>]

Hi Ben,

If you deep dive into this you will see that perforce is a SCM[1] that
predates git. The tools are to perforce as, github is to git.

[1] software configuration management (SCM or S/W CM)

David

-----Original Message-----
From: Disruptive Solutions [mailto:disruptivesolutionsnl@gmail.com]
Sent: Monday, December 23, 2019 11:03 PM
To: dev@nuttx.apache.org
Subject: Re: Single Committer

A platform like this could help? Samsung seems to use it? Does Apache has
something like this “Helix Core” and “Swarm” ??

https://www.perforce.com/products/helix-swarm

Benefit drom these ideas? And you could start with 1 commiter and scale up
later. The way of working will be getting more clear and get to the
“standards” Greg sees??


Verstuurd vanaf mijn iPhone

> Op 24 dec. 2019 om 06:07 heeft Nathan Hartman <ha...@gmail.com>
> het volgende geschreven:
>
> On Mon, Dec 23, 2019 at 7:51 PM Gregory Nutt <sp...@gmail.com> wrote:
>>
>> Recent events have made me reconsider some decisions I made.  I threw
>> off the single committer mantle when I saw the abuse of privilege in the
>> repositories.  If the PPMC agrees to it, I will take up that role again.
>>
>> But let's be frank.  Here is what I think that means:
>>
>>  * I would be sole committer of changes.  The repositories would have
>>    to be treated as read-only just as back in the Bitbucket days.
>>  * I would grandfather in the i.MXRT changes.
>>  * I will decline all workflow related changes until workflow
>>    requirements are established (that is my only real motivation for
>>    suggesting this:  To make certain that we have proper requirements
>>    in place before we accept PX4 workflow into our repositories.  We
>>    need to do this right and I am willing to protect the repositories
>>    until the workflow requirements are established.  I expect that to
>>    take about two weeks.)
>>  * I would create a dev branch and expect all PRs to be against that
>>    dev branch.
>>  * As soon as the PPMC is confident that it has the processes in place
>>    to handle the commit workload I will gladly relinquish this role.
>>  * THIS IS NOT THE APACHE WAY.  This is an interim dictatorship role to
>>    expedite the avalanche of commits expected after the holidays.
>>
>> If any of this concerns people, please "Just Say No."  I am not married
>> to the idea and I am not forcefully advocating it.  This is what people
>> wanted me to do a few days ago and if I can protect our right to define
>> the workflow, then I will do it.  For me it is a sacrifice that I would
>> take with no pleasure in.
>>
>> Pros:  This will provide project continuity until the PPMC is fully
>> functional.  Having workflow requirements will be a huge step in that
>> direction.  People stressed about the commit process can relax with
>> confidence.  This will protect the code base from premature work flow
>> changes until we have an understanding of what we want.  No harm is done
>> by deferring workflow changes until we as a team are prepared to deal
>> with them.
>>
>> Cons:  This is not the Apache way.  People who are trying to bulldoze
>> the PX4 work flow into the repositories will hate the idea.  Mentors
>> will hate the idea.  An approach more consistent with the Apache way
>> would just be to let the chaos prevail.  That is fine with me too as
>> long as we do not let PX4 advocates take away our group right to define
>> our own workflow.  We can still just put all workflow changes on hold
>> until we have the requirements in hand.
>>
>> I am not pushing anything.  Think about it and let me know what you
>> would like to do.
>
> I agree with this because it is premature to change the way we work
> before there is a documented workflow that helps us understand what to
> do.
>
> Over the next two weeks, we should focus on designing the top-down
> workflow. It doesn't have to be final and it doesn't have to be
> perfect. We can improve it over time. But right now it's not ready,
> so I appreciate Greg's offer to do that, while the workflow is prepared.
>
> Thanks to Greg and everyone,
> Nathan

RE: Single Committer

[David Sidrane <Da...@nscdg.com>]

+1

-----Original Message-----
From: Abdelatif Guettouche [mailto:abdelatif.guettouche@gmail.com]
Sent: Monday, December 23, 2019 11:48 PM
To: dev@nuttx.apache.org
Subject: Re: Single Committer

This makes sense giving the circumstances. It will get us going.
We can still help reviewing PRs.

On Tue, Dec 24, 2019, 08:03 Disruptive Solutions <
disruptivesolutionsnl@gmail.com> wrote:

> A platform like this could help? Samsung seems to use it? Does Apache has
> something like this “Helix Core” and “Swarm” ??
>
> https://www.perforce.com/products/helix-swarm
>
> Benefit drom these ideas? And you could start with 1 commiter and scale up
> later. The way of working will be getting more clear and get to the
> “standards” Greg sees??
>
>
> Verstuurd vanaf mijn iPhone
>
> > Op 24 dec. 2019 om 06:07 heeft Nathan Hartman <ha...@gmail.com>
> het volgende geschreven:
> >
> > On Mon, Dec 23, 2019 at 7:51 PM Gregory Nutt <sp...@gmail.com>
> wrote:
> >>
> >> Recent events have made me reconsider some decisions I made.  I threw
> >> off the single committer mantle when I saw the abuse of privilege in
> >> the
> >> repositories.  If the PPMC agrees to it, I will take up that role
> >> again.
> >>
> >> But let's be frank.  Here is what I think that means:
> >>
> >>  * I would be sole committer of changes.  The repositories would have
> >>    to be treated as read-only just as back in the Bitbucket days.
> >>  * I would grandfather in the i.MXRT changes.
> >>  * I will decline all workflow related changes until workflow
> >>    requirements are established (that is my only real motivation for
> >>    suggesting this:  To make certain that we have proper requirements
> >>    in place before we accept PX4 workflow into our repositories.  We
> >>    need to do this right and I am willing to protect the repositories
> >>    until the workflow requirements are established.  I expect that to
> >>    take about two weeks.)
> >>  * I would create a dev branch and expect all PRs to be against that
> >>    dev branch.
> >>  * As soon as the PPMC is confident that it has the processes in place
> >>    to handle the commit workload I will gladly relinquish this role.
> >>  * THIS IS NOT THE APACHE WAY.  This is an interim dictatorship role to
> >>    expedite the avalanche of commits expected after the holidays.
> >>
> >> If any of this concerns people, please "Just Say No."  I am not married
> >> to the idea and I am not forcefully advocating it.  This is what people
> >> wanted me to do a few days ago and if I can protect our right to define
> >> the workflow, then I will do it.  For me it is a sacrifice that I would
> >> take with no pleasure in.
> >>
> >> Pros:  This will provide project continuity until the PPMC is fully
> >> functional.  Having workflow requirements will be a huge step in that
> >> direction.  People stressed about the commit process can relax with
> >> confidence.  This will protect the code base from premature work flow
> >> changes until we have an understanding of what we want.  No harm is
> >> done
> >> by deferring workflow changes until we as a team are prepared to deal
> >> with them.
> >>
> >> Cons:  This is not the Apache way.  People who are trying to bulldoze
> >> the PX4 work flow into the repositories will hate the idea.  Mentors
> >> will hate the idea.  An approach more consistent with the Apache way
> >> would just be to let the chaos prevail.  That is fine with me too as
> >> long as we do not let PX4 advocates take away our group right to define
> >> our own workflow.  We can still just put all workflow changes on hold
> >> until we have the requirements in hand.
> >>
> >> I am not pushing anything.  Think about it and let me know what you
> >> would like to do.
> >
> > I agree with this because it is premature to change the way we work
> > before there is a documented workflow that helps us understand what to
> > do.
> >
> > Over the next two weeks, we should focus on designing the top-down
> > workflow. It doesn't have to be final and it doesn't have to be
> > perfect. We can improve it over time. But right now it's not ready,
> > so I appreciate Greg's offer to do that, while the workflow is prepared.
> >
> > Thanks to Greg and everyone,
> > Nathan
>

Re: Single Committer

[Alin Jerpelea <je...@gmail.com>]

+1
the old way of working was ok but this will put pressure on Greg again.
We should define the workflow as soon as possible and work as we are
intended to.

On Tue, Dec 24, 2019, 09:48 Abdelatif Guettouche <
abdelatif.guettouche@gmail.com> wrote:

> This makes sense giving the circumstances. It will get us going.
> We can still help reviewing PRs.
>
> On Tue, Dec 24, 2019, 08:03 Disruptive Solutions <
> disruptivesolutionsnl@gmail.com> wrote:
>
> > A platform like this could help? Samsung seems to use it? Does Apache has
> > something like this “Helix Core” and “Swarm” ??
> >
> > https://www.perforce.com/products/helix-swarm
> >
> > Benefit drom these ideas? And you could start with 1 commiter and scale
> up
> > later. The way of working will be getting more clear and get to the
> > “standards” Greg sees??
> >
> >
> > Verstuurd vanaf mijn iPhone
> >
> > > Op 24 dec. 2019 om 06:07 heeft Nathan Hartman <
> hartman.nathan@gmail.com>
> > het volgende geschreven:
> > >
> > > On Mon, Dec 23, 2019 at 7:51 PM Gregory Nutt <sp...@gmail.com>
> > wrote:
> > >>
> > >> Recent events have made me reconsider some decisions I made.  I threw
> > >> off the single committer mantle when I saw the abuse of privilege in
> the
> > >> repositories.  If the PPMC agrees to it, I will take up that role
> again.
> > >>
> > >> But let's be frank.  Here is what I think that means:
> > >>
> > >>  * I would be sole committer of changes.  The repositories would have
> > >>    to be treated as read-only just as back in the Bitbucket days.
> > >>  * I would grandfather in the i.MXRT changes.
> > >>  * I will decline all workflow related changes until workflow
> > >>    requirements are established (that is my only real motivation for
> > >>    suggesting this:  To make certain that we have proper requirements
> > >>    in place before we accept PX4 workflow into our repositories.  We
> > >>    need to do this right and I am willing to protect the repositories
> > >>    until the workflow requirements are established.  I expect that to
> > >>    take about two weeks.)
> > >>  * I would create a dev branch and expect all PRs to be against that
> > >>    dev branch.
> > >>  * As soon as the PPMC is confident that it has the processes in place
> > >>    to handle the commit workload I will gladly relinquish this role.
> > >>  * THIS IS NOT THE APACHE WAY.  This is an interim dictatorship role
> to
> > >>    expedite the avalanche of commits expected after the holidays.
> > >>
> > >> If any of this concerns people, please "Just Say No."  I am not
> married
> > >> to the idea and I am not forcefully advocating it.  This is what
> people
> > >> wanted me to do a few days ago and if I can protect our right to
> define
> > >> the workflow, then I will do it.  For me it is a sacrifice that I
> would
> > >> take with no pleasure in.
> > >>
> > >> Pros:  This will provide project continuity until the PPMC is fully
> > >> functional.  Having workflow requirements will be a huge step in that
> > >> direction.  People stressed about the commit process can relax with
> > >> confidence.  This will protect the code base from premature work flow
> > >> changes until we have an understanding of what we want.  No harm is
> done
> > >> by deferring workflow changes until we as a team are prepared to deal
> > >> with them.
> > >>
> > >> Cons:  This is not the Apache way.  People who are trying to bulldoze
> > >> the PX4 work flow into the repositories will hate the idea.  Mentors
> > >> will hate the idea.  An approach more consistent with the Apache way
> > >> would just be to let the chaos prevail.  That is fine with me too as
> > >> long as we do not let PX4 advocates take away our group right to
> define
> > >> our own workflow.  We can still just put all workflow changes on hold
> > >> until we have the requirements in hand.
> > >>
> > >> I am not pushing anything.  Think about it and let me know what you
> > >> would like to do.
> > >
> > > I agree with this because it is premature to change the way we work
> > > before there is a documented workflow that helps us understand what to
> > > do.
> > >
> > > Over the next two weeks, we should focus on designing the top-down
> > > workflow. It doesn't have to be final and it doesn't have to be
> > > perfect. We can improve it over time. But right now it's not ready,
> > > so I appreciate Greg's offer to do that, while the workflow is
> prepared.
> > >
> > > Thanks to Greg and everyone,
> > > Nathan
> >
>

Re: Single Committer

[Abdelatif Guettouche <ab...@gmail.com>]

This makes sense giving the circumstances. It will get us going.
We can still help reviewing PRs.

On Tue, Dec 24, 2019, 08:03 Disruptive Solutions <
disruptivesolutionsnl@gmail.com> wrote:

> A platform like this could help? Samsung seems to use it? Does Apache has
> something like this “Helix Core” and “Swarm” ??
>
> https://www.perforce.com/products/helix-swarm
>
> Benefit drom these ideas? And you could start with 1 commiter and scale up
> later. The way of working will be getting more clear and get to the
> “standards” Greg sees??
>
>
> Verstuurd vanaf mijn iPhone
>
> > Op 24 dec. 2019 om 06:07 heeft Nathan Hartman <ha...@gmail.com>
> het volgende geschreven:
> >
> > On Mon, Dec 23, 2019 at 7:51 PM Gregory Nutt <sp...@gmail.com>
> wrote:
> >>
> >> Recent events have made me reconsider some decisions I made.  I threw
> >> off the single committer mantle when I saw the abuse of privilege in the
> >> repositories.  If the PPMC agrees to it, I will take up that role again.
> >>
> >> But let's be frank.  Here is what I think that means:
> >>
> >>  * I would be sole committer of changes.  The repositories would have
> >>    to be treated as read-only just as back in the Bitbucket days.
> >>  * I would grandfather in the i.MXRT changes.
> >>  * I will decline all workflow related changes until workflow
> >>    requirements are established (that is my only real motivation for
> >>    suggesting this:  To make certain that we have proper requirements
> >>    in place before we accept PX4 workflow into our repositories.  We
> >>    need to do this right and I am willing to protect the repositories
> >>    until the workflow requirements are established.  I expect that to
> >>    take about two weeks.)
> >>  * I would create a dev branch and expect all PRs to be against that
> >>    dev branch.
> >>  * As soon as the PPMC is confident that it has the processes in place
> >>    to handle the commit workload I will gladly relinquish this role.
> >>  * THIS IS NOT THE APACHE WAY.  This is an interim dictatorship role to
> >>    expedite the avalanche of commits expected after the holidays.
> >>
> >> If any of this concerns people, please "Just Say No."  I am not married
> >> to the idea and I am not forcefully advocating it.  This is what people
> >> wanted me to do a few days ago and if I can protect our right to define
> >> the workflow, then I will do it.  For me it is a sacrifice that I would
> >> take with no pleasure in.
> >>
> >> Pros:  This will provide project continuity until the PPMC is fully
> >> functional.  Having workflow requirements will be a huge step in that
> >> direction.  People stressed about the commit process can relax with
> >> confidence.  This will protect the code base from premature work flow
> >> changes until we have an understanding of what we want.  No harm is done
> >> by deferring workflow changes until we as a team are prepared to deal
> >> with them.
> >>
> >> Cons:  This is not the Apache way.  People who are trying to bulldoze
> >> the PX4 work flow into the repositories will hate the idea.  Mentors
> >> will hate the idea.  An approach more consistent with the Apache way
> >> would just be to let the chaos prevail.  That is fine with me too as
> >> long as we do not let PX4 advocates take away our group right to define
> >> our own workflow.  We can still just put all workflow changes on hold
> >> until we have the requirements in hand.
> >>
> >> I am not pushing anything.  Think about it and let me know what you
> >> would like to do.
> >
> > I agree with this because it is premature to change the way we work
> > before there is a documented workflow that helps us understand what to
> > do.
> >
> > Over the next two weeks, we should focus on designing the top-down
> > workflow. It doesn't have to be final and it doesn't have to be
> > perfect. We can improve it over time. But right now it's not ready,
> > so I appreciate Greg's offer to do that, while the workflow is prepared.
> >
> > Thanks to Greg and everyone,
> > Nathan
>

Re: Single Committer

[Disruptive Solutions <di...@gmail.com>]

A platform like this could help? Samsung seems to use it? Does Apache has something like this “Helix Core” and “Swarm” ??

https://www.perforce.com/products/helix-swarm

Benefit drom these ideas? And you could start with 1 commiter and scale up later. The way of working will be getting more clear and get to the “standards” Greg sees??


Verstuurd vanaf mijn iPhone

> Op 24 dec. 2019 om 06:07 heeft Nathan Hartman <ha...@gmail.com> het volgende geschreven:
> 
> On Mon, Dec 23, 2019 at 7:51 PM Gregory Nutt <sp...@gmail.com> wrote:
>> 
>> Recent events have made me reconsider some decisions I made.  I threw
>> off the single committer mantle when I saw the abuse of privilege in the
>> repositories.  If the PPMC agrees to it, I will take up that role again.
>> 
>> But let's be frank.  Here is what I think that means:
>> 
>>  * I would be sole committer of changes.  The repositories would have
>>    to be treated as read-only just as back in the Bitbucket days.
>>  * I would grandfather in the i.MXRT changes.
>>  * I will decline all workflow related changes until workflow
>>    requirements are established (that is my only real motivation for
>>    suggesting this:  To make certain that we have proper requirements
>>    in place before we accept PX4 workflow into our repositories.  We
>>    need to do this right and I am willing to protect the repositories
>>    until the workflow requirements are established.  I expect that to
>>    take about two weeks.)
>>  * I would create a dev branch and expect all PRs to be against that
>>    dev branch.
>>  * As soon as the PPMC is confident that it has the processes in place
>>    to handle the commit workload I will gladly relinquish this role.
>>  * THIS IS NOT THE APACHE WAY.  This is an interim dictatorship role to
>>    expedite the avalanche of commits expected after the holidays.
>> 
>> If any of this concerns people, please "Just Say No."  I am not married
>> to the idea and I am not forcefully advocating it.  This is what people
>> wanted me to do a few days ago and if I can protect our right to define
>> the workflow, then I will do it.  For me it is a sacrifice that I would
>> take with no pleasure in.
>> 
>> Pros:  This will provide project continuity until the PPMC is fully
>> functional.  Having workflow requirements will be a huge step in that
>> direction.  People stressed about the commit process can relax with
>> confidence.  This will protect the code base from premature work flow
>> changes until we have an understanding of what we want.  No harm is done
>> by deferring workflow changes until we as a team are prepared to deal
>> with them.
>> 
>> Cons:  This is not the Apache way.  People who are trying to bulldoze
>> the PX4 work flow into the repositories will hate the idea.  Mentors
>> will hate the idea.  An approach more consistent with the Apache way
>> would just be to let the chaos prevail.  That is fine with me too as
>> long as we do not let PX4 advocates take away our group right to define
>> our own workflow.  We can still just put all workflow changes on hold
>> until we have the requirements in hand.
>> 
>> I am not pushing anything.  Think about it and let me know what you
>> would like to do.
> 
> I agree with this because it is premature to change the way we work
> before there is a documented workflow that helps us understand what to
> do.
> 
> Over the next two weeks, we should focus on designing the top-down
> workflow. It doesn't have to be final and it doesn't have to be
> perfect. We can improve it over time. But right now it's not ready,
> so I appreciate Greg's offer to do that, while the workflow is prepared.
> 
> Thanks to Greg and everyone,
> Nathan

Re: Single Committer

[Nathan Hartman <ha...@gmail.com>]

On Mon, Dec 23, 2019 at 7:51 PM Gregory Nutt <sp...@gmail.com> wrote:
>
> Recent events have made me reconsider some decisions I made.  I threw
> off the single committer mantle when I saw the abuse of privilege in the
> repositories.  If the PPMC agrees to it, I will take up that role again.
>
> But let's be frank.  Here is what I think that means:
>
>   * I would be sole committer of changes.  The repositories would have
>     to be treated as read-only just as back in the Bitbucket days.
>   * I would grandfather in the i.MXRT changes.
>   * I will decline all workflow related changes until workflow
>     requirements are established (that is my only real motivation for
>     suggesting this:  To make certain that we have proper requirements
>     in place before we accept PX4 workflow into our repositories.  We
>     need to do this right and I am willing to protect the repositories
>     until the workflow requirements are established.  I expect that to
>     take about two weeks.)
>   * I would create a dev branch and expect all PRs to be against that
>     dev branch.
>   * As soon as the PPMC is confident that it has the processes in place
>     to handle the commit workload I will gladly relinquish this role.
>   * THIS IS NOT THE APACHE WAY.  This is an interim dictatorship role to
>     expedite the avalanche of commits expected after the holidays.
>
> If any of this concerns people, please "Just Say No."  I am not married
> to the idea and I am not forcefully advocating it.  This is what people
> wanted me to do a few days ago and if I can protect our right to define
> the workflow, then I will do it.  For me it is a sacrifice that I would
> take with no pleasure in.
>
> Pros:  This will provide project continuity until the PPMC is fully
> functional.  Having workflow requirements will be a huge step in that
> direction.  People stressed about the commit process can relax with
> confidence.  This will protect the code base from premature work flow
> changes until we have an understanding of what we want.  No harm is done
> by deferring workflow changes until we as a team are prepared to deal
> with them.
>
> Cons:  This is not the Apache way.  People who are trying to bulldoze
> the PX4 work flow into the repositories will hate the idea.  Mentors
> will hate the idea.  An approach more consistent with the Apache way
> would just be to let the chaos prevail.  That is fine with me too as
> long as we do not let PX4 advocates take away our group right to define
> our own workflow.  We can still just put all workflow changes on hold
> until we have the requirements in hand.
>
> I am not pushing anything.  Think about it and let me know what you
> would like to do.

I agree with this because it is premature to change the way we work
before there is a documented workflow that helps us understand what to
do.

Over the next two weeks, we should focus on designing the top-down
workflow. It doesn't have to be final and it doesn't have to be
perfect. We can improve it over time. But right now it's not ready,
so I appreciate Greg's offer to do that, while the workflow is prepared.

Thanks to Greg and everyone,
Nathan

Re: Single Committer

[Justin Mclean <ju...@classsoftware.com>]

Hi,

> I don't want the job so I have no problem going back the way things were.

I'm sure you (and others) can review patches that come in, and as long as patches get reviewed before being committed all will be good. I would suggest in this transition period you allow some time and have several people to review each PR or patch.

Thanks,
Justin

Re: Single Committer

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

I don't want the job so I have no problem going back the way things were.

I would ask only the we avoid controversial workflow-related commits 
until we have workflow requirements requirements in place.  We cannot 
deal with that kind of power politics while we are trying to get this 
fragile group working.  If the pain level gets that high again, I will 
have to resign myself for health reasons and save the IPMC the trouble.

With no defined workflow we actually should not take any commits or 
PRs.  There is no harm in letting them build up as backlog.

So I resign the single committer role effective immediately and may God 
help us.

Everyone enjoy the holidays.

Greg

On 12/24/2019 4:42 PM, Justin Mclean wrote:
> Hi,
>
> -1 (from me)
>
>> Recent events have made me reconsider some decisions I made.  I threw off the single committer mantle when I saw the abuse of privilege in the repositories.  If the PPMC agrees to it, I will take up that role again.
> I would suggest you listen to your mentors, that have mentored many projects and have seen the sort of issues that can occur. If the project continued down this path and this continued for some time without correction, the IPMC would ask the project to leave the ASF.
>
>> * THIS IS NOT THE APACHE WAY.  This is an interim dictatorship role to
>>    expedite the avalanche of commits expected after the holidays.
> It certainly is not and I strongly suggest that you do not go down this path.
>
>> If any of this concerns people, please "Just Say No.”
> I have many concerns.
>
>> Pros:  This will provide project continuity until the PPMC is fully functional.
> And this will delay them doing that.
>
> Thanks,
> Justin

Re: Single Committer

[Justin Mclean <ju...@classsoftware.com>]

Hi,

-1 (from me)

> Recent events have made me reconsider some decisions I made.  I threw off the single committer mantle when I saw the abuse of privilege in the repositories.  If the PPMC agrees to it, I will take up that role again.

I would suggest you listen to your mentors, that have mentored many projects and have seen the sort of issues that can occur. If the project continued down this path and this continued for some time without correction, the IPMC would ask the project to leave the ASF.

> * THIS IS NOT THE APACHE WAY.  This is an interim dictatorship role to
>   expedite the avalanche of commits expected after the holidays.

It certainly is not and I strongly suggest that you do not go down this path.

> If any of this concerns people, please "Just Say No.” 

I have many concerns.

> 
> Pros:  This will provide project continuity until the PPMC is fully functional.

And this will delay them doing that.

Thanks,
Justin

Re: Single Committer

["张铎 (Duo Zhang)" <pa...@gmail.com>]

+1.

I think it is reasonable to just keep the original workflow as is for now,
as we still need to make progress on the project. I do not think the ASF
will 'hate' this, you can not graduate if you keep doing things like this,
that's all, fair enough.

And on the workflow part, I suggest you start another thread sir, to
explain the checks you have done when verifying a patch, and also the
requirements. I think first we should reach an agreement on the checks and
requirements, and then we could see which parts can be automate and which
parts can only be handled by human, and see how can we enforce them, by a
'workflow'.

Thanks.

Gregory Nutt <sp...@gmail.com> 于2019年12月24日周二 上午8:51写道：

> Recent events have made me reconsider some decisions I made.  I threw
> off the single committer mantle when I saw the abuse of privilege in the
> repositories.  If the PPMC agrees to it, I will take up that role again.
>
> But let's be frank.  Here is what I think that means:
>
>   * I would be sole committer of changes.  The repositories would have
>     to be treated as read-only just as back in the Bitbucket days.
>   * I would grandfather in the i.MXRT changes.
>   * I will decline all workflow related changes until workflow
>     requirements are established (that is my only real motivation for
>     suggesting this:  To make certain that we have proper requirements
>     in place before we accept PX4 workflow into our repositories.  We
>     need to do this right and I am willing to protect the repositories
>     until the workflow requirements are established.  I expect that to
>     take about two weeks.)
>   * I would create a dev branch and expect all PRs to be against that
>     dev branch.
>   * As soon as the PPMC is confident that it has the processes in place
>     to handle the commit workload I will gladly relinquish this role.
>   * THIS IS NOT THE APACHE WAY.  This is an interim dictatorship role to
>     expedite the avalanche of commits expected after the holidays.
>
> If any of this concerns people, please "Just Say No."  I am not married
> to the idea and I am not forcefully advocating it.  This is what people
> wanted me to do a few days ago and if I can protect our right to define
> the workflow, then I will do it.  For me it is a sacrifice that I would
> take with no pleasure in.
>
> Pros:  This will provide project continuity until the PPMC is fully
> functional.  Having workflow requirements will be a huge step in that
> direction.  People stressed about the commit process can relax with
> confidence.  This will protect the code base from premature work flow
> changes until we have an understanding of what we want.  No harm is done
> by deferring workflow changes until we as a team are prepared to deal
> with them.
>
> Cons:  This is not the Apache way.  People who are trying to bulldoze
> the PX4 work flow into the repositories will hate the idea.  Mentors
> will hate the idea.  An approach more consistent with the Apache way
> would just be to let the chaos prevail.  That is fine with me too as
> long as we do not let PX4 advocates take away our group right to define
> our own workflow.  We can still just put all workflow changes on hold
> until we have the requirements in hand.
>
> I am not pushing anything.  Think about it and let me know what you
> would like to do.
>
> Greg
>
>
>

Re: Single Committer

[Xiang Xiao <xi...@gmail.com>]

I definitely support this approach: keep the original workflow before
the new workflow setup.
We have enough time to achieve "THE APACHE WAY" step by step before
NuttX graduate to the top level project.

On Tue, Dec 24, 2019 at 8:51 AM Gregory Nutt <sp...@gmail.com> wrote:
>
> Recent events have made me reconsider some decisions I made.  I threw
> off the single committer mantle when I saw the abuse of privilege in the
> repositories.  If the PPMC agrees to it, I will take up that role again.
>
> But let's be frank.  Here is what I think that means:
>
>   * I would be sole committer of changes.  The repositories would have
>     to be treated as read-only just as back in the Bitbucket days.
>   * I would grandfather in the i.MXRT changes.
>   * I will decline all workflow related changes until workflow
>     requirements are established (that is my only real motivation for
>     suggesting this:  To make certain that we have proper requirements
>     in place before we accept PX4 workflow into our repositories.  We
>     need to do this right and I am willing to protect the repositories
>     until the workflow requirements are established.  I expect that to
>     take about two weeks.)
>   * I would create a dev branch and expect all PRs to be against that
>     dev branch.
>   * As soon as the PPMC is confident that it has the processes in place
>     to handle the commit workload I will gladly relinquish this role.
>   * THIS IS NOT THE APACHE WAY.  This is an interim dictatorship role to
>     expedite the avalanche of commits expected after the holidays.
>
> If any of this concerns people, please "Just Say No."  I am not married
> to the idea and I am not forcefully advocating it.  This is what people
> wanted me to do a few days ago and if I can protect our right to define
> the workflow, then I will do it.  For me it is a sacrifice that I would
> take with no pleasure in.
>
> Pros:  This will provide project continuity until the PPMC is fully
> functional.  Having workflow requirements will be a huge step in that
> direction.  People stressed about the commit process can relax with
> confidence.  This will protect the code base from premature work flow
> changes until we have an understanding of what we want.  No harm is done
> by deferring workflow changes until we as a team are prepared to deal
> with them.
>
> Cons:  This is not the Apache way.  People who are trying to bulldoze
> the PX4 work flow into the repositories will hate the idea.  Mentors
> will hate the idea.  An approach more consistent with the Apache way
> would just be to let the chaos prevail.  That is fine with me too as
> long as we do not let PX4 advocates take away our group right to define
> our own workflow.  We can still just put all workflow changes on hold
> until we have the requirements in hand.
>
> I am not pushing anything.  Think about it and let me know what you
> would like to do.
>
> Greg
>
>

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

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

> I think we should strive to keep master as close to "releasable" as
> possible at all times, do development on dev branch(es), and create release
> branches to which changes are only made by backporting from master. I think
> this is closer to a CI/CD (Continuous Integration / Continuous Delivery)
> style.

I tend to agree with, especially if we have the ability to change the 
base of PRs against master to dev.  To me, that would solve any 
usability problems with keeping master the master and dev the 
development branch.

I agree with your other points as well.  There have been a couple of 
times where I downloaded applications sources and built them on master 
assuming that is the correct place... why wouldn't it be? Then finding 
that they do not work and that you really have to build on some branch.  
It would be best for every one if we didn't have to make things any more 
complex for the end-user.

Greg

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[Nathan Hartman <ha...@gmail.com>]

On Tue, Dec 24, 2019 at 9:47 AM Gregory Nutt <sp...@gmail.com> wrote:

> That would simplify accepting PRs since the uniformed will probably
> continue to submit against master.  This would make that behavior
> workable.  Semantically, I would have to wrap my head around the notion
> that the master is not the master but a development branch.  But even
> old dogs can learn new tricks with enough time.


On the issue of whether master should be a dev branch or not, my 2 cents:

I think we should strive to keep master as close to "releasable" as
possible at all times, do development on dev branch(es), and create release
branches to which changes are only made by backporting from master. I think
this is closer to a CI/CD (Continuous Integration / Continuous Delivery)
style.

Why we would want that:

(1)
I think most users will assume that master should be buildable and usable.

(2)
If master is buildable and usable at all times, it will probably get wider
testing and therefore any new problems should be detected quickly. (Case in
point: I caught a few issues the same day they were introduced by using
master every day.)

(3)
If master becomes a dumping ground for any changes and then we have to sift
through them to decide what to port to a stable branch, it might become a
mess. I think it's best to review before it comes into the tree, and then
if approved, bring it in decisively.

Just food for (collective) thought.

Nathan

RE: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[David Sidrane <Da...@nscdg.com>]

What is  https://codersrank.io/ ? I am not failure with it.

Do you have a screen shot that relates to this discussion?

-----Original Message-----
From: Gregory Nutt [mailto:spudaneco@gmail.com]
Sent: Wednesday, December 25, 2019 7:58 AM
To: dev@nuttx.apache.org
Subject: Re: Software release life cycle choices could have implications on
workflow (was RE: Single Committer)

Doesn't do any good at social bragging sites like https://codersrank.io/

On 12/25/2019 9:47 AM, David Sidrane wrote:
> Even on a squashed merge there is traceability back to the PR and
> therefore
> ALL the history will be on the mailing list and publically available on
> GH.
>
> This is why a rebase work flow has to stop after review. (With some
> exceptions)  but we always attribute to the Authors
>
> -----Original Message-----
> From: Gregory Nutt [mailto:spudaneco@gmail.com]
> Sent: Wednesday, December 25, 2019 6:44 AM
> To: dev@nuttx.apache.org
> Subject: Re: Software release life cycle choices could have implications
> on
> workflow (was RE: Single Committer)
>
>
>> If they are related / dependent on each other, then I think those
>> kinds of patchsets should be encapsulated in one branch.
> That would work fine provided that the branch is not squashed to
> master.  That loses authorship of individual contributions.

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

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

Doesn't do any good at social bragging sites like https://codersrank.io/

On 12/25/2019 9:47 AM, David Sidrane wrote:
> Even on a squashed merge there is traceability back to the PR and therefore
> ALL the history will be on the mailing list and publically available on GH.
>
> This is why a rebase work flow has to stop after review. (With some
> exceptions)  but we always attribute to the Authors
>
> -----Original Message-----
> From: Gregory Nutt [mailto:spudaneco@gmail.com]
> Sent: Wednesday, December 25, 2019 6:44 AM
> To: dev@nuttx.apache.org
> Subject: Re: Software release life cycle choices could have implications on
> workflow (was RE: Single Committer)
>
>
>> If they are related / dependent on each other, then I think those
>> kinds of patchsets should be encapsulated in one branch.
> That would work fine provided that the branch is not squashed to
> master.  That loses authorship of individual contributions.

RE: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[David Sidrane <Da...@nscdg.com>]

Even on a squashed merge there is traceability back to the PR and therefore
ALL the history will be on the mailing list and publically available on GH.

This is why a rebase work flow has to stop after review. (With some
exceptions)  but we always attribute to the Authors

-----Original Message-----
From: Gregory Nutt [mailto:spudaneco@gmail.com]
Sent: Wednesday, December 25, 2019 6:44 AM
To: dev@nuttx.apache.org
Subject: Re: Software release life cycle choices could have implications on
workflow (was RE: Single Committer)


> If they are related / dependent on each other, then I think those
> kinds of patchsets should be encapsulated in one branch.
That would work fine provided that the branch is not squashed to
master.  That loses authorship of individual contributions.

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

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

> If they are related / dependent on each other, then I think those
> kinds of patchsets should be encapsulated in one branch.
That would work fine provided that the branch is not squashed to 
master.  That loses authorship of individual contributions.

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

["张铎 (Duo Zhang)" <pa...@gmail.com>]

I do not think it is a big deal to force the base branch for a PR. You are
free to choose the way you like, just tell users which branch to use when
creating a PR.

In ASF, like Hadoop and HBase, maser is the dev branch and by default all
PR must be created against the master branch. There are users open a PR
against other branches, then we just tell them to open a new PR against
master, and close the current one (and for hadoop, the 'master' branch is
actually called 'trunk'...). And IIRC, there are other projects in the ASF
want user to open PR against the current release branch, and the commiters
will cherry-pick the commit back to master branch.

Of course sometimes the user will just leave and not open the PR as his/her
code base is not against the master branch and he/she do not want to spend
much time on porting, that's fine. This is open source, people come and go.

In general, just start a vote and let PPMC decided the branching strategy.
And do we have a wiki page to record the discussion result? I think we'd
better reach agreement step by step, and this is good sign to the IPMC,
that we are making progress. For other things, like whether we should
squash all the commits in a PR into one when merging, or there are
dependencis between PRs, we can discuess them in another thread.

Thanks.

Brennan Ashton <ba...@brennanashton.com> 于2019年12月25日周三 上午8:05写道：

> On Tue, Dec 24, 2019, 3:13 PM Gregory Nutt <sp...@gmail.com> wrote:
>
> >
> > >
> > >> If they are related / dependent on each other, then I think those
> > >> kinds of patchsets should be encapsulated in one branch.
> > >
> > > The need to be applied and committed in sequence.  Sometimes the final
> > > patch is the one that fixes the coding style.  This is inherently very
> > > manual.
> > They need to be merged separately too since the author is often
> > different on each patch.
> >
>
> Why does the authors matter. There is no reason a patchset or PR needs to
> be squashed into a single commit, they just should not be broken along the
> way.
>
> Also order in a patch set is usually defined by a number prefix for example
> this is how it is defined by the Linux kernel, but is inline with most
> projects that do mailing list patches.
>
>
> https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html#the-canonical-patch-format
>
>
> There is really nothing so unique about this project that we need to get
> too creative.
>
> --Brennan
>
> >
>

RE: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[David Sidrane <Da...@nscdg.com>]

+1

-----Original Message-----
From: Gregory Nutt [mailto:spudaneco@gmail.com]
Sent: Wednesday, December 25, 2019 6:41 AM
To: dev@nuttx.apache.org
Subject: Re: Software release life cycle choices could have implications on
workflow (was RE: Single Committer)


> Why does the authors matter. There is no reason a patchset or PR needs to
> be squashed into a single commit, they just should not be broken along the
> way.

It does not matter to the project.  But it matters very much to some
contributors.  Especially young or newbie contributors who see this a
recognition by the technical community.  I have even seen people share
there commits proudly in social media.

For those of us who have been doing this for a long time, we don't need
that recognition (I have around 36,000 commits to the project), but that
is not true of others.  So I think we need to be respectful of
contributors.  I believe that we owe contributors of patches to the OS
the public recognition that they deserve.

Greg

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

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

> Why does the authors matter. There is no reason a patchset or PR needs to
> be squashed into a single commit, they just should not be broken along the
> way.

It does not matter to the project.  But it matters very much to some 
contributors.  Especially young or newbie contributors who see this a 
recognition by the technical community.  I have even seen people share 
there commits proudly in social media.

For those of us who have been doing this for a long time, we don't need 
that recognition (I have around 36,000 commits to the project), but that 
is not true of others.  So I think we need to be respectful of 
contributors.  I believe that we owe contributors of patches to the OS 
the public recognition that they deserve.

Greg

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

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

> Yes, feature branch is another story, but I still need to say that, we
> should not just exclude normal contributors. They do not have the
> permission to push to a feature branch either...
Yes, and that is basically what is said at that reference too.  We need 
to squash this notion of an uninhibited, unfettered code development 
like a bug.

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

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

> Again, think of you are a contributor, not a commiter. Not all contributors
> are committers, you should not use a different (official) workflow
> comparing to them. That's my point.
Everything falls into place neatly when you consider the workflow from 
the point of view of the NuttX end-user / contributor.

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

["张铎 (Duo Zhang)" <pa...@gmail.com>]

Again, think of you are a contributor, not a commiter. Not all contributors
are committers, you should not use a different (official) workflow
comparing to them. That's my point.

David Sidrane <Da...@nscdg.com> 于2019年12月27日周五 下午10:59写道：

> Hi Greg,
>
> I have used Bit bucket and Github and others SCM. I have had more positive
> Github experiences
>
> For me Github has always been a better tool except for the killer feature
> on
> BB of meld like diff.
>
> I am not working against anyone. I am trying to share what I know about GH,
> the mistakes I have made with it and do not want to repeat.
>
> I do not want to limit anyone's ability to do their work their way [GREEN
> and CLEAN]
>
> Can we all agree: That we do not want a github NOOB  to define a github
> work
> flow?
> Can we all agree: That we do not want a patch NOOB  to define a patch work
> flow?
>
>
> > 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.
>
> If we are using github, yes they are. The argument about pr braches in the
> repo is pointless.
>
> Look at the website repos. Look what github does for a committer vs a
> contributor.
>
> Committer - 2 options commit to master or branch in it the repo
> Contributor - fork is created.
>
> When I (as a committer) did a PR via the web UI - which is 100% appropriate
> for what it was doing.
>
> Notice what happened in the repo.
>
> See https://github.com/apache/incubator-nuttx-website/branches
>
> Now do you see why the argument makes sense?
>
> Are we going to prohibit this? Think about the ramification. We as
> committers will not be able to use the UI when it makes sense.
>
> David
>
> -----Original Message-----
> From: Gregory Nutt [mailto:spudaneco@gmail.com]
> Sent: Friday, December 27, 2019 6:27 AM
> To: dev@nuttx.apache.org
> Subject: Re: Software release life cycle choices could have implications on
> workflow (was RE: Single Committer)
>
> 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
>

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[Alin Jerpelea <je...@gmail.com>]

I use GH on all projects that accept it and it is a breeze to work with PR.

I clone the project add my commit and make a PR that can be reviewed and
amended depending on the case.

BB was harder to use and I felt that the edit and review in place were some
of the drawbacks.

I agree that with good documentation the PR flow should be easy to handle
and review.



On Fri, Dec 27, 2019, 16:59 David Sidrane <Da...@nscdg.com> wrote:

> Hi Greg,
>
> I have used Bit bucket and Github and others SCM. I have had more positive
> Github experiences
>
> For me Github has always been a better tool except for the killer feature
> on
> BB of meld like diff.
>
> I am not working against anyone. I am trying to share what I know about GH,
> the mistakes I have made with it and do not want to repeat.
>
> I do not want to limit anyone's ability to do their work their way [GREEN
> and CLEAN]
>
> Can we all agree: That we do not want a github NOOB  to define a github
> work
> flow?
> Can we all agree: That we do not want a patch NOOB  to define a patch work
> flow?
>
>
> > 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.
>
> If we are using github, yes they are. The argument about pr braches in the
> repo is pointless.
>
> Look at the website repos. Look what github does for a committer vs a
> contributor.
>
> Committer - 2 options commit to master or branch in it the repo
> Contributor - fork is created.
>
> When I (as a committer) did a PR via the web UI - which is 100% appropriate
> for what it was doing.
>
> Notice what happened in the repo.
>
> See https://github.com/apache/incubator-nuttx-website/branches
>
> Now do you see why the argument makes sense?
>
> Are we going to prohibit this? Think about the ramification. We as
> committers will not be able to use the UI when it makes sense.
>
> David
>
> -----Original Message-----
> From: Gregory Nutt [mailto:spudaneco@gmail.com]
> Sent: Friday, December 27, 2019 6:27 AM
> To: dev@nuttx.apache.org
> Subject: Re: Software release life cycle choices could have implications on
> workflow (was RE: Single Committer)
>
> 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
>

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[Disruptive Solutions <di...@gmail.com>]

This sounds like it was... clone the repo to local. Do our thing making a feature branch.. commit to our own private repo ... Send patch (format patch) in (after nxstyle, indent, etc and README addition) and let it reviewed by sending it to central channel (was Google Group) and checkout locally to master, pull the latest patches from origin/master and do another feature... same proces again.

Ben

Verstuurd vanaf mijn iPhone

> Op 27 dec. 2019 om 21:28 heeft Nathan Hartman <ha...@gmail.com> het volgende geschreven:
> 
> On Fri, Dec 27, 2019 at 10:45 AM Xiang Xiao <xi...@gmail.com> wrote:
>>> On Fri, Dec 27, 2019 at 10:59 PM David Sidrane <Da...@nscdg.com> wrote:
>>> Notice what happened in the repo.
>> 
>> Yes, you manually create a branch in official repo without any review process.
>> 
>>> See https://github.com/apache/incubator-nuttx-website/branches
>>> 
>>> Now do you see why the argument makes sense?
>>> 
>> 
>> No, since the normal contributor even don't have right to modify
>> anything in official repo. Only committer can hit this issue, you just
>> abuse the committer power.
>> This also demonstrate PX4 workflow encourage people modify the
>> official repo directly just like local fork, I don't think it's a good
>> habit.
>> 
>>> Are we going to prohibit this? Think about the ramification. We as
>>> committers will not be able to use the UI when it makes sense.
>> 
>> Of course, we should prohibit any modification which doesn't pass the
>> review process like this enter the repo.
>> You can do anything in your fork with UI, but shouldn't mess up the
>> official repo.
>> Many people will sync up with the official repo, any partial or stale
>> work just make the newbie confusion.
> 
> Exactly.
> 
> Any changes you want to make (whether you are a committer or not):
> * If you are using GitHub, make a fork, make your changes in your
> fork, open a PR.
> * If you are using git, make a clone, make your changes in your clone,
> send a 'git request-pull' or 'git format-patch'.
> * If you are using no SCM / other SCM, get the release tarball, make
> your changes, produce a patch.
> 
> Committers are not allowed to bypass the above and put stuff directly
> in the repo without going through the same process and review as
> everyone else.
> 
> Nathan

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[Alin Jerpelea <je...@gmail.com>]

this is a simple workflow that can fit everybody
+1

On Fri, Dec 27, 2019, 22:28 Nathan Hartman <ha...@gmail.com> wrote:

> On Fri, Dec 27, 2019 at 10:45 AM Xiang Xiao <xi...@gmail.com>
> wrote:
> > On Fri, Dec 27, 2019 at 10:59 PM David Sidrane <Da...@nscdg.com>
> wrote:
> > > Notice what happened in the repo.
> >
> > Yes, you manually create a branch in official repo without any review
> process.
> >
> > > See https://github.com/apache/incubator-nuttx-website/branches
> > >
> > > Now do you see why the argument makes sense?
> > >
> >
> > No, since the normal contributor even don't have right to modify
> > anything in official repo. Only committer can hit this issue, you just
> > abuse the committer power.
> > This also demonstrate PX4 workflow encourage people modify the
> > official repo directly just like local fork, I don't think it's a good
> > habit.
> >
> > > Are we going to prohibit this? Think about the ramification. We as
> > > committers will not be able to use the UI when it makes sense.
> >
> > Of course, we should prohibit any modification which doesn't pass the
> > review process like this enter the repo.
> > You can do anything in your fork with UI, but shouldn't mess up the
> > official repo.
> > Many people will sync up with the official repo, any partial or stale
> > work just make the newbie confusion.
>
> Exactly.
>
> Any changes you want to make (whether you are a committer or not):
> * If you are using GitHub, make a fork, make your changes in your
> fork, open a PR.
> * If you are using git, make a clone, make your changes in your clone,
> send a 'git request-pull' or 'git format-patch'.
> * If you are using no SCM / other SCM, get the release tarball, make
> your changes, produce a patch.
>
> Committers are not allowed to bypass the above and put stuff directly
> in the repo without going through the same process and review as
> everyone else.
>
> Nathan
>

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[Nathan Hartman <ha...@gmail.com>]

On Fri, Dec 27, 2019 at 10:45 AM Xiang Xiao <xi...@gmail.com> wrote:
> On Fri, Dec 27, 2019 at 10:59 PM David Sidrane <Da...@nscdg.com> wrote:
> > Notice what happened in the repo.
>
> Yes, you manually create a branch in official repo without any review process.
>
> > See https://github.com/apache/incubator-nuttx-website/branches
> >
> > Now do you see why the argument makes sense?
> >
>
> No, since the normal contributor even don't have right to modify
> anything in official repo. Only committer can hit this issue, you just
> abuse the committer power.
> This also demonstrate PX4 workflow encourage people modify the
> official repo directly just like local fork, I don't think it's a good
> habit.
>
> > Are we going to prohibit this? Think about the ramification. We as
> > committers will not be able to use the UI when it makes sense.
>
> Of course, we should prohibit any modification which doesn't pass the
> review process like this enter the repo.
> You can do anything in your fork with UI, but shouldn't mess up the
> official repo.
> Many people will sync up with the official repo, any partial or stale
> work just make the newbie confusion.

Exactly.

Any changes you want to make (whether you are a committer or not):
* If you are using GitHub, make a fork, make your changes in your
fork, open a PR.
* If you are using git, make a clone, make your changes in your clone,
send a 'git request-pull' or 'git format-patch'.
* If you are using no SCM / other SCM, get the release tarball, make
your changes, produce a patch.

Committers are not allowed to bypass the above and put stuff directly
in the repo without going through the same process and review as
everyone else.

Nathan

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[Xiang Xiao <xi...@gmail.com>]

On Fri, Dec 27, 2019 at 10:59 PM David Sidrane <Da...@nscdg.com> wrote:
>
> Hi Greg,
>
> I have used Bit bucket and Github and others SCM. I have had more positive
> Github experiences
>
> For me Github has always been a better tool except for the killer feature on
> BB of meld like diff.
>
> I am not working against anyone. I am trying to share what I know about GH,
> the mistakes I have made with it and do not want to repeat.
>
> I do not want to limit anyone's ability to do their work their way [GREEN
> and CLEAN]
>
> Can we all agree: That we do not want a github NOOB  to define a github work
> flow?
> Can we all agree: That we do not want a patch NOOB  to define a patch work
> flow?
>
>
> > 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.
>
> If we are using github, yes they are. The argument about pr braches in the
> repo is pointless.
>
> Look at the website repos. Look what github does for a committer vs a
> contributor.
>
> Committer - 2 options commit to master or branch in it the repo

Even committer shouldn't modify anything inside official repo without
the review process.
Committer can merge patch just because the patch pass all workflow criteria.
Committer can create branch just because the workflow allow this for
some special case(to be discussed).
Committer shouldn't abuse his/her power inside official repo just
because he/she like to do so.
Committer just has one option fork, committer's patch need pass
through the same workflow just like the contributor.

> Contributor - fork is created.
>
> When I (as a committer) did a PR via the web UI - which is 100% appropriate
> for what it was doing.
>
> Notice what happened in the repo.

Yes, you manually create a branch in official repo without any review process.

> See https://github.com/apache/incubator-nuttx-website/branches
>
> Now do you see why the argument makes sense?
>

No, since the normal contributor even don't have right to modify
anything in official repo. Only committer can hit this issue, you just
abuse the committer power.
This also demonstrate PX4 workflow encourage people modify the
official repo directly just like local fork, I don't think it's a good
habit.

> Are we going to prohibit this? Think about the ramification. We as
> committers will not be able to use the UI when it makes sense.

Of course, we should prohibit any modification which doesn't pass the
review process like this enter the repo.
You can do anything in your fork with UI, but shouldn't mess up the
official repo.
Many people will sync up with the official repo, any partial or stale
work just make the newbie confusion.

>
> David
>
> -----Original Message-----
> From: Gregory Nutt [mailto:spudaneco@gmail.com]
> Sent: Friday, December 27, 2019 6:27 AM
> To: dev@nuttx.apache.org
> Subject: Re: Software release life cycle choices could have implications on
> workflow (was RE: Single Committer)
>
> 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

RE: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[David Sidrane <Da...@nscdg.com>]

Hi Greg,

I have used Bit bucket and Github and others SCM. I have had more positive
Github experiences

For me Github has always been a better tool except for the killer feature on
BB of meld like diff.

I am not working against anyone. I am trying to share what I know about GH,
the mistakes I have made with it and do not want to repeat.

I do not want to limit anyone's ability to do their work their way [GREEN
and CLEAN]

Can we all agree: That we do not want a github NOOB  to define a github work
flow?
Can we all agree: That we do not want a patch NOOB  to define a patch work
flow?


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

If we are using github, yes they are. The argument about pr braches in the
repo is pointless.

Look at the website repos. Look what github does for a committer vs a
contributor.

Committer - 2 options commit to master or branch in it the repo
Contributor - fork is created.

When I (as a committer) did a PR via the web UI - which is 100% appropriate
for what it was doing.

Notice what happened in the repo.

See https://github.com/apache/incubator-nuttx-website/branches

Now do you see why the argument makes sense?

Are we going to prohibit this? Think about the ramification. We as
committers will not be able to use the UI when it makes sense.

David

-----Original Message-----
From: Gregory Nutt [mailto:spudaneco@gmail.com]
Sent: Friday, December 27, 2019 6:27 AM
To: dev@nuttx.apache.org
Subject: Re: Software release life cycle choices could have implications on
workflow (was RE: Single Committer)

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

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[Nathan Hartman <ha...@gmail.com>]

On Fri, Dec 27, 2019 at 9:26 AM Gregory Nutt <sp...@gmail.com> wrote:

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


I just saw the changes in the email notification. Thanks so much for
helping with that!! It looks good and I will review more carefully soon.
Also I'll flesh out the outline more. Unfortunately it might take me until
Sunday to do it, but I'll work on it as soon as I can.

Thanks again for your help!

Nathan

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

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

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

RE: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[David Sidrane <Da...@nscdg.com>]

+1 I agree with all that you have said.

I would just add the WHY.  Let's not teach bad habits (HAM Story)

Yes document them all and describe why fall a back may be needed.

We might even want to rate them as preferred and acceptable (Just like the
NuttX Coding Standard document does)

David

-----Original Message-----
From: Nathan Hartman [mailto:hartman.nathan@gmail.com]
Sent: Friday, December 27, 2019 6:01 AM
To: dev@nuttx.apache.org
Subject: Re: Software release life cycle choices could have implications on
workflow (was RE: Single Committer)

On Fri, Dec 27, 2019 at 8:26 AM David Sidrane <Da...@nscdg.com>
wrote:

> Nathan,
>
> I am not sure if this is a terminology issue or just being new to github.
> (I
> feel you. We have all been there!)
>
> Where do they submit the PR from?
>
>
> https://stackoverflow.com/questions/14906187/how-to-submit-a-pull-request-from-a-cloned-repo
>
> The only other option is to email patches.
>
> I do not have any expertise with patches in git other than I can run ' git
> format-patch <my branch point>'
>
> Can anyone tell me what repo, what branch the following is to/from and
> where
> it should be applied to?
>
> (snip)
>
> PRs add rich content and context (what branch this applies to at a
> minimum)-
> that is why they are today's "best practices"


GitHub is great, but as Justin points out some people cannot use it, and as
Greg points out, we need to be considerate of ALL users, it's in the
INVIOLABLES. So we must support non-GitHub-based contributions regardless
of what we do internally within the project.

In addition to 'git format-patch' there is also 'git request-pull'. All we
need to do in our Workflow is to document exactly how a contributor gets
changes to us, and we have to provide 3 options:

Option 1: A GitHub pull request

Option 2: Email a pull request to dev@ using git request-pull (and we have
to document exactly what sequence of git incantations to use)

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.

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.

The more committers we have and the easier we make it for committers to
succeed, the stronger the project will be and the more its longevity is
ensured.

Nathan

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[Nathan Hartman <ha...@gmail.com>]

On Fri, Dec 27, 2019 at 8:26 AM David Sidrane <Da...@nscdg.com>
wrote:

> Nathan,
>
> I am not sure if this is a terminology issue or just being new to github.
> (I
> feel you. We have all been there!)
>
> Where do they submit the PR from?
>
>
> https://stackoverflow.com/questions/14906187/how-to-submit-a-pull-request-from-a-cloned-repo
>
> The only other option is to email patches.
>
> I do not have any expertise with patches in git other than I can run ' git
> format-patch <my branch point>'
>
> Can anyone tell me what repo, what branch the following is to/from and
> where
> it should be applied to?
>
> (snip)
>
> PRs add rich content and context (what branch this applies to at a
> minimum)-
> that is why they are today's "best practices"


GitHub is great, but as Justin points out some people cannot use it, and as
Greg points out, we need to be considerate of ALL users, it's in the
INVIOLABLES. So we must support non-GitHub-based contributions regardless
of what we do internally within the project.

In addition to 'git format-patch' there is also 'git request-pull'. All we
need to do in our Workflow is to document exactly how a contributor gets
changes to us, and we have to provide 3 options:

Option 1: A GitHub pull request

Option 2: Email a pull request to dev@ using git request-pull (and we have
to document exactly what sequence of git incantations to use)

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.

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.

The more committers we have and the easier we make it for committers to
succeed, the stronger the project will be and the more its longevity is
ensured.

Nathan

RE: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[David Sidrane <Da...@nscdg.com>]

>I do not know what is the problem for receiving patch from email. Obviously
most people will just use git and GitHub but providing another way is also
fine?

It is not have a problem with the project taking patches. It is just not the
ONLY option.

> I do not fully get what is the point of your story as I'm not good at
reading English stories but if you mean that people should move on to new
things, think of Amish.

Amish ROFLMAO[1]

I am sorry if it does not read well. But I think you got it!

Let's embrace it, but not force it.

[1]  https://en.wikipedia.org/wiki/ROFLMAO

-----Original Message-----
From: 张铎(Duo Zhang) [mailto:palomino219@gmail.com]
Sent: Friday, December 27, 2019 6:16 AM
To: dev@nuttx.apache.org
Subject: Re: Software release life cycle choices could have implications on
workflow (was RE: Single Committer)

I do not know what is the problem for receiving patch from email. Obviously
most people will just use git and GitHub but providing another way is also
fine?

I do not fully get what is the point of your story as I'm not good at
reading English stories but if you mean that people should move on to new
things, think of Amish.

Thanks.

David Sidrane <Da...@nscdg.com> 于2019年12月27日周五 下午9:26写道：

> Nathan,
>
> I am not sure if this is a terminology issue or just being new to github.
> (I
> feel you. We have all been there!)
>
> Where do they submit the PR from?
>
>
> https://stackoverflow.com/questions/14906187/how-to-submit-a-pull-request-from-a-cloned-repo
>
> The only other option is to email patches.
>
> I do not have any expertise with patches in git other than I can run ' git
> format-patch <my branch point>'
>
> Can anyone tell me what repo, what branch the following is to/from and
> where
> it should be applied to?
>
> From 2d7920055f96f5734d5166e2c58daa16c6dff2f5 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Beat=20K=C3=BCng?= <be...@gmx.net>
> Date: Thu, 28 Nov 2019 13:08:28 +0100
> Subject: [PATCH 01/19] [BACKPORT] fix stm32h7x3xx_dmamux.h: add missing
>  underscore to defines
>
> ---
>  .../src/stm32h7/hardware/stm32h7x3xx_dmamux.h | 140 +++++++++---------
>  1 file changed, 70 insertions(+), 70 deletions(-)
>
> diff --git a/arch/arm/src/stm32h7/hardware/stm32h7x3xx_dmamux.h
> b/arch/arm/src/stm32h7/hardware/stm32h7x3xx_dmamux.h
> index 7c1f575a86..6c94addc31 100644
> --- a/arch/arm/src/stm32h7/hardware/stm32h7x3xx_dmamux.h
> +++ b/arch/arm/src/stm32h7/hardware/stm32h7x3xx_dmamux.h
> @@ -276,50 +276,50 @@
> ....
>
> PRs add rich content and context (what branch this applies to at a
> minimum)-
> that is why they are today's "best practices"
>
> I would ask all of us to think about new tools[1] and not be doing things
> just because[2]
>
> [1] https://quoteinvestigator.com/2014/05/08/hammer-nail/
> [2]
>
> https://lists.apache.org/thread.html/98ddb6fcf5a744f3b65f81d850cb535764f16fa207fd883c557fbf4f%40%3Cdev.nuttx.apache.org%3E
>
> David
>
>
>
> -----Original Message-----
> From: Nathan Hartman [mailto:hartman.nathan@gmail.com]
> Sent: Thursday, December 26, 2019 7:34 PM
> To: dev@nuttx.apache.org
> Subject: Re: Software release life cycle choices could have implications
> on
> workflow (was RE: Single Committer)
>
> On Thu, Dec 26, 2019 at 7:31 PM 张铎(Duo Zhang) <pa...@gmail.com>
> wrote:
>
> > Yes, feature branch is another story, but I still need to say that, we
> > should not just exclude normal contributors. They do not have the
> > permission to push to a feature branch either...
>
>
> There is no problem here. Anyone can clone the repo, work on the feature
> branch, and submit PR or patch for the upstream feature branch.
>

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

["张铎 (Duo Zhang)" <pa...@gmail.com>]

I do not know what is the problem for receiving patch from email. Obviously
most people will just use git and GitHub but providing another way is also
fine?

I do not fully get what is the point of your story as I'm not good at
reading English stories but if you mean that people should move on to new
things, think of Amish.

Thanks.

David Sidrane <Da...@nscdg.com> 于2019年12月27日周五 下午9:26写道：

> Nathan,
>
> I am not sure if this is a terminology issue or just being new to github.
> (I
> feel you. We have all been there!)
>
> Where do they submit the PR from?
>
>
> https://stackoverflow.com/questions/14906187/how-to-submit-a-pull-request-from-a-cloned-repo
>
> The only other option is to email patches.
>
> I do not have any expertise with patches in git other than I can run ' git
> format-patch <my branch point>'
>
> Can anyone tell me what repo, what branch the following is to/from and
> where
> it should be applied to?
>
> From 2d7920055f96f5734d5166e2c58daa16c6dff2f5 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Beat=20K=C3=BCng?= <be...@gmx.net>
> Date: Thu, 28 Nov 2019 13:08:28 +0100
> Subject: [PATCH 01/19] [BACKPORT] fix stm32h7x3xx_dmamux.h: add missing
>  underscore to defines
>
> ---
>  .../src/stm32h7/hardware/stm32h7x3xx_dmamux.h | 140 +++++++++---------
>  1 file changed, 70 insertions(+), 70 deletions(-)
>
> diff --git a/arch/arm/src/stm32h7/hardware/stm32h7x3xx_dmamux.h
> b/arch/arm/src/stm32h7/hardware/stm32h7x3xx_dmamux.h
> index 7c1f575a86..6c94addc31 100644
> --- a/arch/arm/src/stm32h7/hardware/stm32h7x3xx_dmamux.h
> +++ b/arch/arm/src/stm32h7/hardware/stm32h7x3xx_dmamux.h
> @@ -276,50 +276,50 @@
> ....
>
> PRs add rich content and context (what branch this applies to at a
> minimum)-
> that is why they are today's "best practices"
>
> I would ask all of us to think about new tools[1] and not be doing things
> just because[2]
>
> [1] https://quoteinvestigator.com/2014/05/08/hammer-nail/
> [2]
>
> https://lists.apache.org/thread.html/98ddb6fcf5a744f3b65f81d850cb535764f16fa207fd883c557fbf4f%40%3Cdev.nuttx.apache.org%3E
>
> David
>
>
>
> -----Original Message-----
> From: Nathan Hartman [mailto:hartman.nathan@gmail.com]
> Sent: Thursday, December 26, 2019 7:34 PM
> To: dev@nuttx.apache.org
> Subject: Re: Software release life cycle choices could have implications on
> workflow (was RE: Single Committer)
>
> On Thu, Dec 26, 2019 at 7:31 PM 张铎(Duo Zhang) <pa...@gmail.com>
> wrote:
>
> > Yes, feature branch is another story, but I still need to say that, we
> > should not just exclude normal contributors. They do not have the
> > permission to push to a feature branch either...
>
>
> There is no problem here. Anyone can clone the repo, work on the feature
> branch, and submit PR or patch for the upstream feature branch.
>

RE: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[David Sidrane <Da...@nscdg.com>]

Nathan,

I am not sure if this is a terminology issue or just being new to github. (I
feel you. We have all been there!)

Where do they submit the PR from?

https://stackoverflow.com/questions/14906187/how-to-submit-a-pull-request-from-a-cloned-repo

The only other option is to email patches.

I do not have any expertise with patches in git other than I can run ' git
format-patch <my branch point>'

Can anyone tell me what repo, what branch the following is to/from and where
it should be applied to?

From 2d7920055f96f5734d5166e2c58daa16c6dff2f5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beat=20K=C3=BCng?= <be...@gmx.net>
Date: Thu, 28 Nov 2019 13:08:28 +0100
Subject: [PATCH 01/19] [BACKPORT] fix stm32h7x3xx_dmamux.h: add missing
 underscore to defines

---
 .../src/stm32h7/hardware/stm32h7x3xx_dmamux.h | 140 +++++++++---------
 1 file changed, 70 insertions(+), 70 deletions(-)

diff --git a/arch/arm/src/stm32h7/hardware/stm32h7x3xx_dmamux.h
b/arch/arm/src/stm32h7/hardware/stm32h7x3xx_dmamux.h
index 7c1f575a86..6c94addc31 100644
--- a/arch/arm/src/stm32h7/hardware/stm32h7x3xx_dmamux.h
+++ b/arch/arm/src/stm32h7/hardware/stm32h7x3xx_dmamux.h
@@ -276,50 +276,50 @@
....

PRs add rich content and context (what branch this applies to at a minimum)-
that is why they are today's "best practices"

I would ask all of us to think about new tools[1] and not be doing things
just because[2]

[1] https://quoteinvestigator.com/2014/05/08/hammer-nail/
[2]
https://lists.apache.org/thread.html/98ddb6fcf5a744f3b65f81d850cb535764f16fa207fd883c557fbf4f%40%3Cdev.nuttx.apache.org%3E

David



-----Original Message-----
From: Nathan Hartman [mailto:hartman.nathan@gmail.com]
Sent: Thursday, December 26, 2019 7:34 PM
To: dev@nuttx.apache.org
Subject: Re: Software release life cycle choices could have implications on
workflow (was RE: Single Committer)

On Thu, Dec 26, 2019 at 7:31 PM 张铎(Duo Zhang) <pa...@gmail.com> wrote:

> Yes, feature branch is another story, but I still need to say that, we
> should not just exclude normal contributors. They do not have the
> permission to push to a feature branch either...


There is no problem here. Anyone can clone the repo, work on the feature
branch, and submit PR or patch for the upstream feature branch.

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[Nathan Hartman <ha...@gmail.com>]

On Thu, Dec 26, 2019 at 7:31 PM 张铎(Duo Zhang) <pa...@gmail.com> wrote:

> Yes, feature branch is another story, but I still need to say that, we
> should not just exclude normal contributors. They do not have the
> permission to push to a feature branch either...


There is no problem here. Anyone can clone the repo, work on the feature
branch, and submit PR or patch for the upstream feature branch.

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

["张铎 (Duo Zhang)" <pa...@gmail.com>]

Yes, feature branch is another story, but I still need to say that, we
should not just exclude normal contributors. They do not have the
permission to push to a feature branch either...

Gregory Nutt <sp...@gmail.com>于2019年12月27日 周五07:52写道：

>
> > Still, not every contributors are committers, they do not have the
> > permission to create branches. How can they let others know they are
> > working on something? Open an issue or send an email to the mailing list
> > right? And usually, the contributor set is much larger than the committer
> > set for a project in ASF, so do not always stand at the position with
> > committer to think of the workflow.
>
> I believe that any un-authorized, un-approved, un-reviewed writes to the
> repository should never be permitted by anyone unless it is in full
> compliance with the work flow requirements.  All development is in the
> public eye and subject to review and comment from the PPMC and the whole
> world.
>
> But I do think we have not discussed how collaborative feature branches
> should work under the workflow requirements.  That is really what we are
> talking about here.  I made an initial stab at feature branch
> requirements in the last comment at
>
> https://cwiki.apache.org/confluence/display/NUTTXTEST/Code+Contribution+Workflow+--+Brennan+Ashton
> under "*Extended Development on a Feature Branch*"
>
> Greg*
> *
>
>

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

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

> Still, not every contributors are committers, they do not have the
> permission to create branches. How can they let others know they are
> working on something? Open an issue or send an email to the mailing list
> right? And usually, the contributor set is much larger than the committer
> set for a project in ASF, so do not always stand at the position with
> committer to think of the workflow.

I believe that any un-authorized, un-approved, un-reviewed writes to the 
repository should never be permitted by anyone unless it is in full 
compliance with the work flow requirements.  All development is in the 
public eye and subject to review and comment from the PPMC and the whole 
world.

But I do think we have not discussed how collaborative feature branches 
should work under the workflow requirements.  That is really what we are 
talking about here.  I made an initial stab at feature branch 
requirements in the last comment at 
https://cwiki.apache.org/confluence/display/NUTTXTEST/Code+Contribution+Workflow+--+Brennan+Ashton 
under "*Extended Development on a Feature Branch*"

Greg*
*

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

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

On 12/26/2019 7:49 AM, 张铎(Duo Zhang) wrote:
> ...
Duo should also have access to any external, third party repositories 
for workflow development.  He has also offered to contribute to the 
NuttX workflow in the past.

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

["张铎 (Duo Zhang)" <pa...@gmail.com>]

OK, confirmed. You are thinking we are like a company, but actually, we are
not.

We are from all around the world and there are no way to force others to do
works for you. If this PR is opened by you, then it is your duty to finish
it. No one else will touch it except review and comment, unless you
explicitly say that you can not finish the work, and committers will close
your PR and open a new one based on your patch.

And usually for a company which contribute to an open source project, the
people there will maintain an in house or open source repo of the project,
and they are free to use any workflow they like, and once they are don3,
then upstream the things to the official open source repo.

So I think, you can maintain another repo, with your PX4 folks, to use the
workflow you like, and then upstream.

And finally, I still suggest that, open an issue before you want to do
something. If you want others to know you are doing something, it is your
duty to let others know, not other’s duty to find out what you are doing.
And you even do not want to share your thoughts before writing the code?
Especially for a big feature, you even do not have a design doc first?

Still, not every contributors are committers, they do not have the
permission to create branches. How can they let others know they are
working on something? Open an issue or send an email to the mailing list
right? And usually, the contributor set is much larger than the committer
set for a project in ASF, so do not always stand at the position with
committer to think of the workflow.

Thank you very much.

David Sidrane <Da...@nscdg.com>于2019年12月26日 周四23:51写道：

> >Why I have to visit every fork to see what is happening in the project? I
> just need to check the PRs and issues.
>
> Because before a Branch becomes a PR you will not know it is a Work in
> Progress (WIP)
>
> > Open a issue before you do this please?
>
> You could but, because it is not an issue that carries the wrong messge.
> How
> about it goes on the project board in Github. In the repo [1]
>
> > What do you mean by 'help get in a PR'?
>
> I work from 2:00 AM PST until 4:00 PM - I tell my team  what is left at the
> end of my day and they pick up the work,  push commits to the branch to
> finish the PR
> From 4:00 PM until 2:00 AM. To get the PR into master. We also yes
> XXXX/Tests to thell them the PR is ready (in our case to Fly)  and they
> test
> and put results in PR
> BUT they can also fix something, if need be, and PUSH commits.
> No one is blocked and it is a team effort.
>
> [1]
>
> https://www.google.com/search?q=how+to+use+GitHub+project+boards&gs_ivs=1#tts=0
> David
>
> -----Original Message-----
> From: 张铎(Duo Zhang) [mailto:palomino219@gmail.com]
> Sent: Thursday, December 26, 2019 7:21 AM
> To: dev@nuttx.apache.org
> Subject: Re: Software release life cycle choices could have implications on
> workflow (was RE: Single Committer)
>
> David Sidrane <Da...@nscdg.com> 于2019年12月26日周四 下午10:06写道：
>
> > >Then why committers have a different workflow comparing to contributors?
> >
> > It is the same work flow just different locations and rights.
> >
> > >Why not also create branches in your own forked repo?
> >
> > They can, nothing is stopping them.  If their role:contributors that is
> > the
> > only option and the one they should use do not work on master in your own
> > repo keep it in sync with upstream!
> >
> > But it is better because there is a single repo that is the nuttx
> > development not fragmented forks.
> >
> > Do you want to have to visit every fork (before a PR come in) is to see
> > what
> > is happing in the project?
> >
> Why I have to visit every fork to see what is happening in the project? I
> just need to check the PRs and issues.
>
> >
> > Say you look and see a branch master-pr-XYZ - you will ask the owner a
> > PPMC/committer member before you try to add the same thing or ask to work
> > on
> > it with them.
>
> Open a issue before you do this please?
>
> >
>
>
>
> You can fork it , duo/master-pr-XYZ, branch it master-pr-XYZ-DZ,  - Or you
> > can just push commits to it.
> >
> > Think of the repo like a semaphore and a point of collaboration.  Think
> 24
> > hr a day hand offs to get a pr in.  We can all help get in a PR.
> >
> What do you mean by 'help get in a PR'?
>
> >
> > David
> >
> > -----Original Message-----
> > From: 张铎(Duo Zhang) [mailto:palomino219@gmail.com]
> > Sent: Thursday, December 26, 2019 5:49 AM
> > To: dev@nuttx.apache.org
> > Subject: Re: Software release life cycle choices could have implications
> > on
> > workflow (was RE: Single Committer)
> >
> > Then why committers have a different workflow comparing to contributors?
> > Why not also create branches in your own forked repo?
> >
> > David Sidrane <Da...@nscdg.com> 于2019年12月26日周四 下午9:36写道：
> >
> > > Hi Duo,
> > >
> > >
> > > Sure - I just do not which above questions you are referring too, there
> > > are
> > > 67 ? in the post
> > >
> > > I guess this one?
> > >
> > > > For contributors other than committers, especial it is not their
> > > projects,
> > > the repo is not writable to them, and how can they create branches on
> > > the
> > > repo?
> > >
> > > Contributors |  <    committers < PPMC
> > > Rights------|----------------------------------->
> > >
> > > No Write   | Have Write access
> > > Access     | Do PR in upstream
> > > Do PR      | on Branches
> > > Against    |
> > > Upstream|
> > > On            |
> > > Branches |
> > > in own     |
> > > account  |
> > >
> > >
> > > David
> > >
> > > -----Original Message-----
> > > From: 张铎(Duo Zhang) [mailto:palomino219@gmail.com]
> > > Sent: Thursday, December 26, 2019 5:10 AM
> > > To: dev@nuttx.apache.org
> > > Subject: Re: Software release life cycle choices could have
> implications
> > > on
> > > workflow (was RE: Single Committer)
> > >
> > > Hey David, could you please explain the above questions a bit?
> > >
> > > Since you want to create PR branches at the official repo, then how
> > > could
> > > a
> > > contributor other than committer contribute code? He/she just does not
> > > have
> > > the permission to create a branch.
> > >
> > > Thanks.
> > >
> > > David Sidrane <Da...@nscdg.com> 于2019年12月26日周四 下午4:45写道：
> > >
> > > > Hi Nathan,
> > > >
> > > > This is very aligned with the Apache way - thank you so much for
> > > > thinking
> > > > along these lines.
> > > >
> > > > Please start with git.
> > > >
> > > > Then use the star wars prequel maneuver and feed everything into a
> > > > pipeline
> > > > to git.
> > > >
> > > > You can be the champion of the conversion team and propose
> development
> > > > of
> > > > zip and rar and svn and USB drive, etc streams to the git repo.
> > > >
> > > > But let's not stick this in front of the job of getting us functional
> > > > while
> > > > at the same time let's all keep this in mind in what we do settle on.
> > > >
> > > > David
> > > >
> > > > -----Original Message-----
> > > > From: Nathan Hartman [mailto:hartman.nathan@gmail.com]
> > > > Sent: Wednesday, December 25, 2019 7:28 PM
> > > > To: dev@nuttx.apache.org
> > > > Subject: Re: Software release life cycle choices could have
> > implications
> > > > on
> > > > workflow (was RE: Single Committer)
> > > >
> > > > On Wed, Dec 25, 2019 at 6:45 PM Justin Mclean <
> > justin@classsoftware.com>
> > > > wrote:
> > > >
> > > > > > People on this list have indicated that they use NuttX released
> > with
> > > > > Apache SVN.
> > > > >
> > > > > The releases are placed in a ASF SVN system to be distributed by
> the
> > > > > mirror system yes.
> > > >
> > > >
> > > > I think Greg means that users are getting the release tarballs and
> > > > checking
> > > > the code into their own version control system, which may be
> > Subversion,
> > > > Git, proprietary SCM software, etc., or possibly no version control
> at
> > > all
> > > > (think "installing" NuttX to disk like a library). Therefore the
> > release
> > > > must be SCM-agnostic. (This is why it was a bug when a recent change
> > > > to
> > > > the
> > > > build system assumed that git was available. I detected that because
> I
> > > > keep
> > > > NuttX in Subversion.)
> > > >
> > > > For this discussion, it's irrelevant that ASF puts release tarballs
> in
> > > > Subversion. Users who download the tarballs need not know or care
> > > > because
> > > > from their perspective it's like any other download. Subversion is
> > > > just
> > > > the
> > > > back end storage for this.
> > > >
> > > > As far as contributors, some may use Git, create a Git clone, and
> then
> > > > generate either a patch or a PR. But we do *not* want to require
> using
> > > > Git.
> > > >
> > > > What's not clear to me is how do contributors who *don't* use Git
> send
> > > > changes to us? Do they use plain 'diff'? Do they use their SCM to
> > > generate
> > > > git-compatible patches? Do they zip up their entire tree?
> > > >
> > > > Also I'd like to emphasize that ANYONE can contribute whether they
> can
> > > > commit to the NuttX repository or not. What we need to do is document
> > > what
> > > > steps to take, in the Confluence document that we are working on
> right
> > > > now.
> > > > And we want everyone who is interested to participate so that our
> > > workflow
> > > > will be a product of the whole community. You'll find it much easier
> > > > to
> > > > adopt the workflow if you helped create it!!!
> > > >
> > > > Thanks,
> > > > Nathan
> > > >
> > >
> >
>

RE: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[David Sidrane <Da...@nscdg.com>]

>Why I have to visit every fork to see what is happening in the project? I
just need to check the PRs and issues.

Because before a Branch becomes a PR you will not know it is a Work in
Progress (WIP)

> Open a issue before you do this please?

You could but, because it is not an issue that carries the wrong messge. How
about it goes on the project board in Github. In the repo [1]

> What do you mean by 'help get in a PR'?

I work from 2:00 AM PST until 4:00 PM - I tell my team  what is left at the
end of my day and they pick up the work,  push commits to the branch to
finish the PR
From 4:00 PM until 2:00 AM. To get the PR into master. We also yes
XXXX/Tests to thell them the PR is ready (in our case to Fly)  and they test
and put results in PR
BUT they can also fix something, if need be, and PUSH commits.
No one is blocked and it is a team effort.

[1]
https://www.google.com/search?q=how+to+use+GitHub+project+boards&gs_ivs=1#tts=0
David

-----Original Message-----
From: 张铎(Duo Zhang) [mailto:palomino219@gmail.com]
Sent: Thursday, December 26, 2019 7:21 AM
To: dev@nuttx.apache.org
Subject: Re: Software release life cycle choices could have implications on
workflow (was RE: Single Committer)

David Sidrane <Da...@nscdg.com> 于2019年12月26日周四 下午10:06写道：

> >Then why committers have a different workflow comparing to contributors?
>
> It is the same work flow just different locations and rights.
>
> >Why not also create branches in your own forked repo?
>
> They can, nothing is stopping them.  If their role:contributors that is
> the
> only option and the one they should use do not work on master in your own
> repo keep it in sync with upstream!
>
> But it is better because there is a single repo that is the nuttx
> development not fragmented forks.
>
> Do you want to have to visit every fork (before a PR come in) is to see
> what
> is happing in the project?
>
Why I have to visit every fork to see what is happening in the project? I
just need to check the PRs and issues.

>
> Say you look and see a branch master-pr-XYZ - you will ask the owner a
> PPMC/committer member before you try to add the same thing or ask to work
> on
> it with them.

Open a issue before you do this please?

>



You can fork it , duo/master-pr-XYZ, branch it master-pr-XYZ-DZ,  - Or you
> can just push commits to it.
>
> Think of the repo like a semaphore and a point of collaboration.  Think 24
> hr a day hand offs to get a pr in.  We can all help get in a PR.
>
What do you mean by 'help get in a PR'?

>
> David
>
> -----Original Message-----
> From: 张铎(Duo Zhang) [mailto:palomino219@gmail.com]
> Sent: Thursday, December 26, 2019 5:49 AM
> To: dev@nuttx.apache.org
> Subject: Re: Software release life cycle choices could have implications
> on
> workflow (was RE: Single Committer)
>
> Then why committers have a different workflow comparing to contributors?
> Why not also create branches in your own forked repo?
>
> David Sidrane <Da...@nscdg.com> 于2019年12月26日周四 下午9:36写道：
>
> > Hi Duo,
> >
> >
> > Sure - I just do not which above questions you are referring too, there
> > are
> > 67 ? in the post
> >
> > I guess this one?
> >
> > > For contributors other than committers, especial it is not their
> > projects,
> > the repo is not writable to them, and how can they create branches on
> > the
> > repo?
> >
> > Contributors |  <    committers < PPMC
> > Rights------|----------------------------------->
> >
> > No Write   | Have Write access
> > Access     | Do PR in upstream
> > Do PR      | on Branches
> > Against    |
> > Upstream|
> > On            |
> > Branches |
> > in own     |
> > account  |
> >
> >
> > David
> >
> > -----Original Message-----
> > From: 张铎(Duo Zhang) [mailto:palomino219@gmail.com]
> > Sent: Thursday, December 26, 2019 5:10 AM
> > To: dev@nuttx.apache.org
> > Subject: Re: Software release life cycle choices could have implications
> > on
> > workflow (was RE: Single Committer)
> >
> > Hey David, could you please explain the above questions a bit?
> >
> > Since you want to create PR branches at the official repo, then how
> > could
> > a
> > contributor other than committer contribute code? He/she just does not
> > have
> > the permission to create a branch.
> >
> > Thanks.
> >
> > David Sidrane <Da...@nscdg.com> 于2019年12月26日周四 下午4:45写道：
> >
> > > Hi Nathan,
> > >
> > > This is very aligned with the Apache way - thank you so much for
> > > thinking
> > > along these lines.
> > >
> > > Please start with git.
> > >
> > > Then use the star wars prequel maneuver and feed everything into a
> > > pipeline
> > > to git.
> > >
> > > You can be the champion of the conversion team and propose development
> > > of
> > > zip and rar and svn and USB drive, etc streams to the git repo.
> > >
> > > But let's not stick this in front of the job of getting us functional
> > > while
> > > at the same time let's all keep this in mind in what we do settle on.
> > >
> > > David
> > >
> > > -----Original Message-----
> > > From: Nathan Hartman [mailto:hartman.nathan@gmail.com]
> > > Sent: Wednesday, December 25, 2019 7:28 PM
> > > To: dev@nuttx.apache.org
> > > Subject: Re: Software release life cycle choices could have
> implications
> > > on
> > > workflow (was RE: Single Committer)
> > >
> > > On Wed, Dec 25, 2019 at 6:45 PM Justin Mclean <
> justin@classsoftware.com>
> > > wrote:
> > >
> > > > > People on this list have indicated that they use NuttX released
> with
> > > > Apache SVN.
> > > >
> > > > The releases are placed in a ASF SVN system to be distributed by the
> > > > mirror system yes.
> > >
> > >
> > > I think Greg means that users are getting the release tarballs and
> > > checking
> > > the code into their own version control system, which may be
> Subversion,
> > > Git, proprietary SCM software, etc., or possibly no version control at
> > all
> > > (think "installing" NuttX to disk like a library). Therefore the
> release
> > > must be SCM-agnostic. (This is why it was a bug when a recent change
> > > to
> > > the
> > > build system assumed that git was available. I detected that because I
> > > keep
> > > NuttX in Subversion.)
> > >
> > > For this discussion, it's irrelevant that ASF puts release tarballs in
> > > Subversion. Users who download the tarballs need not know or care
> > > because
> > > from their perspective it's like any other download. Subversion is
> > > just
> > > the
> > > back end storage for this.
> > >
> > > As far as contributors, some may use Git, create a Git clone, and then
> > > generate either a patch or a PR. But we do *not* want to require using
> > > Git.
> > >
> > > What's not clear to me is how do contributors who *don't* use Git send
> > > changes to us? Do they use plain 'diff'? Do they use their SCM to
> > generate
> > > git-compatible patches? Do they zip up their entire tree?
> > >
> > > Also I'd like to emphasize that ANYONE can contribute whether they can
> > > commit to the NuttX repository or not. What we need to do is document
> > what
> > > steps to take, in the Confluence document that we are working on right
> > > now.
> > > And we want everyone who is interested to participate so that our
> > workflow
> > > will be a product of the whole community. You'll find it much easier
> > > to
> > > adopt the workflow if you helped create it!!!
> > >
> > > Thanks,
> > > Nathan
> > >
> >
>

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

["张铎 (Duo Zhang)" <pa...@gmail.com>]

David Sidrane <Da...@nscdg.com> 于2019年12月26日周四 下午10:06写道：

> >Then why committers have a different workflow comparing to contributors?
>
> It is the same work flow just different locations and rights.
>
> >Why not also create branches in your own forked repo?
>
> They can, nothing is stopping them.  If their role:contributors that is the
> only option and the one they should use do not work on master in your own
> repo keep it in sync with upstream!
>
> But it is better because there is a single repo that is the nuttx
> development not fragmented forks.
>
> Do you want to have to visit every fork (before a PR come in) is to see
> what
> is happing in the project?
>
Why I have to visit every fork to see what is happening in the project? I
just need to check the PRs and issues.

>
> Say you look and see a branch master-pr-XYZ - you will ask the owner a
> PPMC/committer member before you try to add the same thing or ask to work
> on
> it with them.

Open a issue before you do this please?

>



You can fork it , duo/master-pr-XYZ, branch it master-pr-XYZ-DZ,  - Or you
> can just push commits to it.
>
> Think of the repo like a semaphore and a point of collaboration.  Think 24
> hr a day hand offs to get a pr in.  We can all help get in a PR.
>
What do you mean by 'help get in a PR'?

>
> David
>
> -----Original Message-----
> From: 张铎(Duo Zhang) [mailto:palomino219@gmail.com]
> Sent: Thursday, December 26, 2019 5:49 AM
> To: dev@nuttx.apache.org
> Subject: Re: Software release life cycle choices could have implications on
> workflow (was RE: Single Committer)
>
> Then why committers have a different workflow comparing to contributors?
> Why not also create branches in your own forked repo?
>
> David Sidrane <Da...@nscdg.com> 于2019年12月26日周四 下午9:36写道：
>
> > Hi Duo,
> >
> >
> > Sure - I just do not which above questions you are referring too, there
> > are
> > 67 ? in the post
> >
> > I guess this one?
> >
> > > For contributors other than committers, especial it is not their
> > projects,
> > the repo is not writable to them, and how can they create branches on the
> > repo?
> >
> > Contributors |  <    committers < PPMC
> > Rights------|----------------------------------->
> >
> > No Write   | Have Write access
> > Access     | Do PR in upstream
> > Do PR      | on Branches
> > Against    |
> > Upstream|
> > On            |
> > Branches |
> > in own     |
> > account  |
> >
> >
> > David
> >
> > -----Original Message-----
> > From: 张铎(Duo Zhang) [mailto:palomino219@gmail.com]
> > Sent: Thursday, December 26, 2019 5:10 AM
> > To: dev@nuttx.apache.org
> > Subject: Re: Software release life cycle choices could have implications
> > on
> > workflow (was RE: Single Committer)
> >
> > Hey David, could you please explain the above questions a bit?
> >
> > Since you want to create PR branches at the official repo, then how could
> > a
> > contributor other than committer contribute code? He/she just does not
> > have
> > the permission to create a branch.
> >
> > Thanks.
> >
> > David Sidrane <Da...@nscdg.com> 于2019年12月26日周四 下午4:45写道：
> >
> > > Hi Nathan,
> > >
> > > This is very aligned with the Apache way - thank you so much for
> > > thinking
> > > along these lines.
> > >
> > > Please start with git.
> > >
> > > Then use the star wars prequel maneuver and feed everything into a
> > > pipeline
> > > to git.
> > >
> > > You can be the champion of the conversion team and propose development
> > > of
> > > zip and rar and svn and USB drive, etc streams to the git repo.
> > >
> > > But let's not stick this in front of the job of getting us functional
> > > while
> > > at the same time let's all keep this in mind in what we do settle on.
> > >
> > > David
> > >
> > > -----Original Message-----
> > > From: Nathan Hartman [mailto:hartman.nathan@gmail.com]
> > > Sent: Wednesday, December 25, 2019 7:28 PM
> > > To: dev@nuttx.apache.org
> > > Subject: Re: Software release life cycle choices could have
> implications
> > > on
> > > workflow (was RE: Single Committer)
> > >
> > > On Wed, Dec 25, 2019 at 6:45 PM Justin Mclean <
> justin@classsoftware.com>
> > > wrote:
> > >
> > > > > People on this list have indicated that they use NuttX released
> with
> > > > Apache SVN.
> > > >
> > > > The releases are placed in a ASF SVN system to be distributed by the
> > > > mirror system yes.
> > >
> > >
> > > I think Greg means that users are getting the release tarballs and
> > > checking
> > > the code into their own version control system, which may be
> Subversion,
> > > Git, proprietary SCM software, etc., or possibly no version control at
> > all
> > > (think "installing" NuttX to disk like a library). Therefore the
> release
> > > must be SCM-agnostic. (This is why it was a bug when a recent change to
> > > the
> > > build system assumed that git was available. I detected that because I
> > > keep
> > > NuttX in Subversion.)
> > >
> > > For this discussion, it's irrelevant that ASF puts release tarballs in
> > > Subversion. Users who download the tarballs need not know or care
> > > because
> > > from their perspective it's like any other download. Subversion is just
> > > the
> > > back end storage for this.
> > >
> > > As far as contributors, some may use Git, create a Git clone, and then
> > > generate either a patch or a PR. But we do *not* want to require using
> > > Git.
> > >
> > > What's not clear to me is how do contributors who *don't* use Git send
> > > changes to us? Do they use plain 'diff'? Do they use their SCM to
> > generate
> > > git-compatible patches? Do they zip up their entire tree?
> > >
> > > Also I'd like to emphasize that ANYONE can contribute whether they can
> > > commit to the NuttX repository or not. What we need to do is document
> > what
> > > steps to take, in the Confluence document that we are working on right
> > > now.
> > > And we want everyone who is interested to participate so that our
> > workflow
> > > will be a product of the whole community. You'll find it much easier to
> > > adopt the workflow if you helped create it!!!
> > >
> > > Thanks,
> > > Nathan
> > >
> >
>

RE: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[David Sidrane <Da...@nscdg.com>]

>Then why committers have a different workflow comparing to contributors?

It is the same work flow just different locations and rights.

>Why not also create branches in your own forked repo?

They can, nothing is stopping them.  If their role:contributors that is the
only option and the one they should use do not work on master in your own
repo keep it in sync with upstream!

But it is better because there is a single repo that is the nuttx
development not fragmented forks.

Do you want to have to visit every fork (before a PR come in) is to see what
is happing in the project?

Say you look and see a branch master-pr-XYZ - you will ask the owner a
PPMC/committer member before you try to add the same thing or ask to work on
it with them.
You can fork it , duo/master-pr-XYZ, branch it master-pr-XYZ-DZ,  - Or you
can just push commits to it.

Think of the repo like a semaphore and a point of collaboration.  Think 24
hr a day hand offs to get a pr in.  We can all help get in a PR.

David

-----Original Message-----
From: 张铎(Duo Zhang) [mailto:palomino219@gmail.com]
Sent: Thursday, December 26, 2019 5:49 AM
To: dev@nuttx.apache.org
Subject: Re: Software release life cycle choices could have implications on
workflow (was RE: Single Committer)

Then why committers have a different workflow comparing to contributors?
Why not also create branches in your own forked repo?

David Sidrane <Da...@nscdg.com> 于2019年12月26日周四 下午9:36写道：

> Hi Duo,
>
>
> Sure - I just do not which above questions you are referring too, there
> are
> 67 ? in the post
>
> I guess this one?
>
> > For contributors other than committers, especial it is not their
> projects,
> the repo is not writable to them, and how can they create branches on the
> repo?
>
> Contributors |  <    committers < PPMC
> Rights------|----------------------------------->
>
> No Write   | Have Write access
> Access     | Do PR in upstream
> Do PR      | on Branches
> Against    |
> Upstream|
> On            |
> Branches |
> in own     |
> account  |
>
>
> David
>
> -----Original Message-----
> From: 张铎(Duo Zhang) [mailto:palomino219@gmail.com]
> Sent: Thursday, December 26, 2019 5:10 AM
> To: dev@nuttx.apache.org
> Subject: Re: Software release life cycle choices could have implications
> on
> workflow (was RE: Single Committer)
>
> Hey David, could you please explain the above questions a bit?
>
> Since you want to create PR branches at the official repo, then how could
> a
> contributor other than committer contribute code? He/she just does not
> have
> the permission to create a branch.
>
> Thanks.
>
> David Sidrane <Da...@nscdg.com> 于2019年12月26日周四 下午4:45写道：
>
> > Hi Nathan,
> >
> > This is very aligned with the Apache way - thank you so much for
> > thinking
> > along these lines.
> >
> > Please start with git.
> >
> > Then use the star wars prequel maneuver and feed everything into a
> > pipeline
> > to git.
> >
> > You can be the champion of the conversion team and propose development
> > of
> > zip and rar and svn and USB drive, etc streams to the git repo.
> >
> > But let's not stick this in front of the job of getting us functional
> > while
> > at the same time let's all keep this in mind in what we do settle on.
> >
> > David
> >
> > -----Original Message-----
> > From: Nathan Hartman [mailto:hartman.nathan@gmail.com]
> > Sent: Wednesday, December 25, 2019 7:28 PM
> > To: dev@nuttx.apache.org
> > Subject: Re: Software release life cycle choices could have implications
> > on
> > workflow (was RE: Single Committer)
> >
> > On Wed, Dec 25, 2019 at 6:45 PM Justin Mclean <ju...@classsoftware.com>
> > wrote:
> >
> > > > People on this list have indicated that they use NuttX released with
> > > Apache SVN.
> > >
> > > The releases are placed in a ASF SVN system to be distributed by the
> > > mirror system yes.
> >
> >
> > I think Greg means that users are getting the release tarballs and
> > checking
> > the code into their own version control system, which may be Subversion,
> > Git, proprietary SCM software, etc., or possibly no version control at
> all
> > (think "installing" NuttX to disk like a library). Therefore the release
> > must be SCM-agnostic. (This is why it was a bug when a recent change to
> > the
> > build system assumed that git was available. I detected that because I
> > keep
> > NuttX in Subversion.)
> >
> > For this discussion, it's irrelevant that ASF puts release tarballs in
> > Subversion. Users who download the tarballs need not know or care
> > because
> > from their perspective it's like any other download. Subversion is just
> > the
> > back end storage for this.
> >
> > As far as contributors, some may use Git, create a Git clone, and then
> > generate either a patch or a PR. But we do *not* want to require using
> > Git.
> >
> > What's not clear to me is how do contributors who *don't* use Git send
> > changes to us? Do they use plain 'diff'? Do they use their SCM to
> generate
> > git-compatible patches? Do they zip up their entire tree?
> >
> > Also I'd like to emphasize that ANYONE can contribute whether they can
> > commit to the NuttX repository or not. What we need to do is document
> what
> > steps to take, in the Confluence document that we are working on right
> > now.
> > And we want everyone who is interested to participate so that our
> workflow
> > will be a product of the whole community. You'll find it much easier to
> > adopt the workflow if you helped create it!!!
> >
> > Thanks,
> > Nathan
> >
>

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

["张铎 (Duo Zhang)" <pa...@gmail.com>]

Then why committers have a different workflow comparing to contributors?
Why not also create branches in your own forked repo?

David Sidrane <Da...@nscdg.com> 于2019年12月26日周四 下午9:36写道：

> Hi Duo,
>
>
> Sure - I just do not which above questions you are referring too, there are
> 67 ? in the post
>
> I guess this one?
>
> > For contributors other than committers, especial it is not their
> projects,
> the repo is not writable to them, and how can they create branches on the
> repo?
>
> Contributors |  <    committers < PPMC
> Rights------|----------------------------------->
>
> No Write   | Have Write access
> Access     | Do PR in upstream
> Do PR      | on Branches
> Against    |
> Upstream|
> On            |
> Branches |
> in own     |
> account  |
>
>
> David
>
> -----Original Message-----
> From: 张铎(Duo Zhang) [mailto:palomino219@gmail.com]
> Sent: Thursday, December 26, 2019 5:10 AM
> To: dev@nuttx.apache.org
> Subject: Re: Software release life cycle choices could have implications on
> workflow (was RE: Single Committer)
>
> Hey David, could you please explain the above questions a bit?
>
> Since you want to create PR branches at the official repo, then how could a
> contributor other than committer contribute code? He/she just does not have
> the permission to create a branch.
>
> Thanks.
>
> David Sidrane <Da...@nscdg.com> 于2019年12月26日周四 下午4:45写道：
>
> > Hi Nathan,
> >
> > This is very aligned with the Apache way - thank you so much for thinking
> > along these lines.
> >
> > Please start with git.
> >
> > Then use the star wars prequel maneuver and feed everything into a
> > pipeline
> > to git.
> >
> > You can be the champion of the conversion team and propose development of
> > zip and rar and svn and USB drive, etc streams to the git repo.
> >
> > But let's not stick this in front of the job of getting us functional
> > while
> > at the same time let's all keep this in mind in what we do settle on.
> >
> > David
> >
> > -----Original Message-----
> > From: Nathan Hartman [mailto:hartman.nathan@gmail.com]
> > Sent: Wednesday, December 25, 2019 7:28 PM
> > To: dev@nuttx.apache.org
> > Subject: Re: Software release life cycle choices could have implications
> > on
> > workflow (was RE: Single Committer)
> >
> > On Wed, Dec 25, 2019 at 6:45 PM Justin Mclean <ju...@classsoftware.com>
> > wrote:
> >
> > > > People on this list have indicated that they use NuttX released with
> > > Apache SVN.
> > >
> > > The releases are placed in a ASF SVN system to be distributed by the
> > > mirror system yes.
> >
> >
> > I think Greg means that users are getting the release tarballs and
> > checking
> > the code into their own version control system, which may be Subversion,
> > Git, proprietary SCM software, etc., or possibly no version control at
> all
> > (think "installing" NuttX to disk like a library). Therefore the release
> > must be SCM-agnostic. (This is why it was a bug when a recent change to
> > the
> > build system assumed that git was available. I detected that because I
> > keep
> > NuttX in Subversion.)
> >
> > For this discussion, it's irrelevant that ASF puts release tarballs in
> > Subversion. Users who download the tarballs need not know or care because
> > from their perspective it's like any other download. Subversion is just
> > the
> > back end storage for this.
> >
> > As far as contributors, some may use Git, create a Git clone, and then
> > generate either a patch or a PR. But we do *not* want to require using
> > Git.
> >
> > What's not clear to me is how do contributors who *don't* use Git send
> > changes to us? Do they use plain 'diff'? Do they use their SCM to
> generate
> > git-compatible patches? Do they zip up their entire tree?
> >
> > Also I'd like to emphasize that ANYONE can contribute whether they can
> > commit to the NuttX repository or not. What we need to do is document
> what
> > steps to take, in the Confluence document that we are working on right
> > now.
> > And we want everyone who is interested to participate so that our
> workflow
> > will be a product of the whole community. You'll find it much easier to
> > adopt the workflow if you helped create it!!!
> >
> > Thanks,
> > Nathan
> >
>

RE: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[David Sidrane <Da...@nscdg.com>]

Hi Duo,


Sure - I just do not which above questions you are referring too, there are
67 ? in the post

I guess this one?

> For contributors other than committers, especial it is not their projects,
the repo is not writable to them, and how can they create branches on the
repo?

Contributors |  <    committers < PPMC
Rights------|----------------------------------->

No Write   | Have Write access
Access     | Do PR in upstream
Do PR      | on Branches
Against    |
Upstream|
On            |
Branches |
in own     |
account  |


David

-----Original Message-----
From: 张铎(Duo Zhang) [mailto:palomino219@gmail.com]
Sent: Thursday, December 26, 2019 5:10 AM
To: dev@nuttx.apache.org
Subject: Re: Software release life cycle choices could have implications on
workflow (was RE: Single Committer)

Hey David, could you please explain the above questions a bit?

Since you want to create PR branches at the official repo, then how could a
contributor other than committer contribute code? He/she just does not have
the permission to create a branch.

Thanks.

David Sidrane <Da...@nscdg.com> 于2019年12月26日周四 下午4:45写道：

> Hi Nathan,
>
> This is very aligned with the Apache way - thank you so much for thinking
> along these lines.
>
> Please start with git.
>
> Then use the star wars prequel maneuver and feed everything into a
> pipeline
> to git.
>
> You can be the champion of the conversion team and propose development of
> zip and rar and svn and USB drive, etc streams to the git repo.
>
> But let's not stick this in front of the job of getting us functional
> while
> at the same time let's all keep this in mind in what we do settle on.
>
> David
>
> -----Original Message-----
> From: Nathan Hartman [mailto:hartman.nathan@gmail.com]
> Sent: Wednesday, December 25, 2019 7:28 PM
> To: dev@nuttx.apache.org
> Subject: Re: Software release life cycle choices could have implications
> on
> workflow (was RE: Single Committer)
>
> On Wed, Dec 25, 2019 at 6:45 PM Justin Mclean <ju...@classsoftware.com>
> wrote:
>
> > > People on this list have indicated that they use NuttX released with
> > Apache SVN.
> >
> > The releases are placed in a ASF SVN system to be distributed by the
> > mirror system yes.
>
>
> I think Greg means that users are getting the release tarballs and
> checking
> the code into their own version control system, which may be Subversion,
> Git, proprietary SCM software, etc., or possibly no version control at all
> (think "installing" NuttX to disk like a library). Therefore the release
> must be SCM-agnostic. (This is why it was a bug when a recent change to
> the
> build system assumed that git was available. I detected that because I
> keep
> NuttX in Subversion.)
>
> For this discussion, it's irrelevant that ASF puts release tarballs in
> Subversion. Users who download the tarballs need not know or care because
> from their perspective it's like any other download. Subversion is just
> the
> back end storage for this.
>
> As far as contributors, some may use Git, create a Git clone, and then
> generate either a patch or a PR. But we do *not* want to require using
> Git.
>
> What's not clear to me is how do contributors who *don't* use Git send
> changes to us? Do they use plain 'diff'? Do they use their SCM to generate
> git-compatible patches? Do they zip up their entire tree?
>
> Also I'd like to emphasize that ANYONE can contribute whether they can
> commit to the NuttX repository or not. What we need to do is document what
> steps to take, in the Confluence document that we are working on right
> now.
> And we want everyone who is interested to participate so that our workflow
> will be a product of the whole community. You'll find it much easier to
> adopt the workflow if you helped create it!!!
>
> Thanks,
> Nathan
>

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

["张铎 (Duo Zhang)" <pa...@gmail.com>]

Hey David, could you please explain the above questions a bit?

Since you want to create PR branches at the official repo, then how could a
contributor other than committer contribute code? He/she just does not have
the permission to create a branch.

Thanks.

David Sidrane <Da...@nscdg.com> 于2019年12月26日周四 下午4:45写道：

> Hi Nathan,
>
> This is very aligned with the Apache way - thank you so much for thinking
> along these lines.
>
> Please start with git.
>
> Then use the star wars prequel maneuver and feed everything into a pipeline
> to git.
>
> You can be the champion of the conversion team and propose development of
> zip and rar and svn and USB drive, etc streams to the git repo.
>
> But let's not stick this in front of the job of getting us functional while
> at the same time let's all keep this in mind in what we do settle on.
>
> David
>
> -----Original Message-----
> From: Nathan Hartman [mailto:hartman.nathan@gmail.com]
> Sent: Wednesday, December 25, 2019 7:28 PM
> To: dev@nuttx.apache.org
> Subject: Re: Software release life cycle choices could have implications on
> workflow (was RE: Single Committer)
>
> On Wed, Dec 25, 2019 at 6:45 PM Justin Mclean <ju...@classsoftware.com>
> wrote:
>
> > > People on this list have indicated that they use NuttX released with
> > Apache SVN.
> >
> > The releases are placed in a ASF SVN system to be distributed by the
> > mirror system yes.
>
>
> I think Greg means that users are getting the release tarballs and checking
> the code into their own version control system, which may be Subversion,
> Git, proprietary SCM software, etc., or possibly no version control at all
> (think "installing" NuttX to disk like a library). Therefore the release
> must be SCM-agnostic. (This is why it was a bug when a recent change to the
> build system assumed that git was available. I detected that because I keep
> NuttX in Subversion.)
>
> For this discussion, it's irrelevant that ASF puts release tarballs in
> Subversion. Users who download the tarballs need not know or care because
> from their perspective it's like any other download. Subversion is just the
> back end storage for this.
>
> As far as contributors, some may use Git, create a Git clone, and then
> generate either a patch or a PR. But we do *not* want to require using Git.
>
> What's not clear to me is how do contributors who *don't* use Git send
> changes to us? Do they use plain 'diff'? Do they use their SCM to generate
> git-compatible patches? Do they zip up their entire tree?
>
> Also I'd like to emphasize that ANYONE can contribute whether they can
> commit to the NuttX repository or not. What we need to do is document what
> steps to take, in the Confluence document that we are working on right now.
> And we want everyone who is interested to participate so that our workflow
> will be a product of the whole community. You'll find it much easier to
> adopt the workflow if you helped create it!!!
>
> Thanks,
> Nathan
>

RE: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[David Sidrane <Da...@nscdg.com>]

Hi Nathan,

This is very aligned with the Apache way - thank you so much for thinking
along these lines.

Please start with git.

Then use the star wars prequel maneuver and feed everything into a pipeline
to git.

You can be the champion of the conversion team and propose development of
zip and rar and svn and USB drive, etc streams to the git repo.

But let's not stick this in front of the job of getting us functional while
at the same time let's all keep this in mind in what we do settle on.

David

-----Original Message-----
From: Nathan Hartman [mailto:hartman.nathan@gmail.com]
Sent: Wednesday, December 25, 2019 7:28 PM
To: dev@nuttx.apache.org
Subject: Re: Software release life cycle choices could have implications on
workflow (was RE: Single Committer)

On Wed, Dec 25, 2019 at 6:45 PM Justin Mclean <ju...@classsoftware.com>
wrote:

> > People on this list have indicated that they use NuttX released with
> Apache SVN.
>
> The releases are placed in a ASF SVN system to be distributed by the
> mirror system yes.


I think Greg means that users are getting the release tarballs and checking
the code into their own version control system, which may be Subversion,
Git, proprietary SCM software, etc., or possibly no version control at all
(think "installing" NuttX to disk like a library). Therefore the release
must be SCM-agnostic. (This is why it was a bug when a recent change to the
build system assumed that git was available. I detected that because I keep
NuttX in Subversion.)

For this discussion, it's irrelevant that ASF puts release tarballs in
Subversion. Users who download the tarballs need not know or care because
from their perspective it's like any other download. Subversion is just the
back end storage for this.

As far as contributors, some may use Git, create a Git clone, and then
generate either a patch or a PR. But we do *not* want to require using Git.

What's not clear to me is how do contributors who *don't* use Git send
changes to us? Do they use plain 'diff'? Do they use their SCM to generate
git-compatible patches? Do they zip up their entire tree?

Also I'd like to emphasize that ANYONE can contribute whether they can
commit to the NuttX repository or not. What we need to do is document what
steps to take, in the Confluence document that we are working on right now.
And we want everyone who is interested to participate so that our workflow
will be a product of the whole community. You'll find it much easier to
adopt the workflow if you helped create it!!!

Thanks,
Nathan

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[Nathan Hartman <ha...@gmail.com>]

On Wed, Dec 25, 2019 at 6:45 PM Justin Mclean <ju...@classsoftware.com>
wrote:

> > People on this list have indicated that they use NuttX released with
> Apache SVN.
>
> The releases are placed in a ASF SVN system to be distributed by the
> mirror system yes.


I think Greg means that users are getting the release tarballs and checking
the code into their own version control system, which may be Subversion,
Git, proprietary SCM software, etc., or possibly no version control at all
(think "installing" NuttX to disk like a library). Therefore the release
must be SCM-agnostic. (This is why it was a bug when a recent change to the
build system assumed that git was available. I detected that because I keep
NuttX in Subversion.)

For this discussion, it's irrelevant that ASF puts release tarballs in
Subversion. Users who download the tarballs need not know or care because
from their perspective it's like any other download. Subversion is just the
back end storage for this.

As far as contributors, some may use Git, create a Git clone, and then
generate either a patch or a PR. But we do *not* want to require using Git.

What's not clear to me is how do contributors who *don't* use Git send
changes to us? Do they use plain 'diff'? Do they use their SCM to generate
git-compatible patches? Do they zip up their entire tree?

Also I'd like to emphasize that ANYONE can contribute whether they can
commit to the NuttX repository or not. What we need to do is document what
steps to take, in the Confluence document that we are working on right now.
And we want everyone who is interested to participate so that our workflow
will be a product of the whole community. You'll find it much easier to
adopt the workflow if you helped create it!!!

Thanks,
Nathan

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[Justin Mclean <ju...@classsoftware.com>]

Hi,

> The majority of users do not use GIT at all.  NuttX distributions are SCM neutral (all GIT information has been used). 

User and contributors are different (but overlapping) groups, I believe we were talking about contributors here. Users will be using the releases which are available from the project website (via the ASF mirrors) as a downloadable bundle of source and not touch any SCM system. 

> People on this list have indicated that they use NuttX released with Apache SVN. 

The releases are placed in a ASF SVN system to be distributed by the mirror system yes.

Thanks,
Justin

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

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

>
>> As long as you stick to git only features you can have everyone work 
>> on it, so branch bases workflow would be best. You can still use 
>> GitHub only features but just don’t make them compulsory.
> WRONG!
>> Not also that some more advanced features or options for GItHub that 
>> have been discussed here e.g admin access, adding bots may or may not 
>> be possible under the ASF. Infra is the admin of all repo and they 
>> need to ensure that we know who has contributed code (which generally 
>> means bots can’t have write access)and that  git history can not be 
>> altered.
>
> The majority of users do not use GIT at all.  NuttX distributions are 
> SCM neutral (all GIT information has been used).  People on this list 
> have indicated that they use NuttX released with Apache SVN.  I am are 
> of corporation that use proprietary SCMs with NuttX releases.
>
> So the whole assumption is wrong.  Assume that the NuttX user does not 
> use GIT, does not have GIT, and does not keep NuttX released under GIT 
> control.  Nothing in the workflow must ever make that decision or we 
> screw a major part of the NuttX user base.  Most companies will not 
> user Code due Jour from the GIT repositiies, they use the SCM-independ 
> NuttX releases.

Users get get release versions from the repository by checkout out or 
branching from the Release tag.  But the the release tarballs are SCM 
agnostic.

Greg

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

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

> As long as you stick to git only features you can have everyone work on it, so branch bases workflow would be best. You can still use GitHub only features but just don’t make them compulsory.
WRONG!
> Not also that some more advanced features or options for GItHub that have been discussed here e.g admin access, adding bots may or may not be possible under the ASF. Infra is the admin of all repo and they need to ensure that we know who has contributed code (which generally means bots can’t have write access)and that  git history can not be altered.

The majority of users do not use GIT at all.  NuttX distributions are 
SCM neutral (all GIT information has been used).  People on this list 
have indicated that they use NuttX released with Apache SVN.  I am are 
of corporation that use proprietary SCMs with NuttX releases.

So the whole assumption is wrong.  Assume that the NuttX user does not 
use GIT, does not have GIT, and does not keep NuttX released under GIT 
control.  Nothing in the workflow must ever make that decision or we 
screw a major part of the NuttX user base.  Most companies will not user 
Code due Jour from the GIT repositiies, they use the SCM-independ NuttX 
releases.

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[Abdelatif Guettouche <ab...@gmail.com>]

> For me on HBase, this depends on lots of things. If it is only a typo then
> I will merge it immediately. If it is a simple bug fix, I will wait a bit
> long and if some committers are familiar with this part, I will try to ask
> their opinions. And if this is a very big new feature, sometimes people
> will even send an email to the mailing list to attract more reviews before
> committing.

Some ASF projects define Obvious Fixes and Emergency Merges.
Obvious Fixes are the like of typos, cosmetics, CS violations that
slipped by the review, etc.
Emergency merges are where nobody is around to review the change and
some subsystem is broken and needs it.
These can be merged by a committer without waiting for another review.

Obvious fixes can be frequent during the release branch period.


On Wed, Dec 25, 2019 at 12:59 PM 张铎(Duo Zhang) <pa...@gmail.com> wrote:
>
> What I mean is that, nobody wants its patch to be reverted right? So you
> will find a proper way to archive this. There is no straight forward rule
> on how much time to wait.
>
> For me on HBase, this depends on lots of things. If it is only a typo then
> I will merge it immediately. If it is a simple bug fix, I will wait a bit
> long and if some committers are familiar with this part, I will try to ask
> their opinions. And if this is a very big new feature, sometimes people
> will even send an email to the mailing list to attract more reviews before
> committing.
>
> So in general, I do not think there is an one-for-all rule. NuttX community
> has its own culture, and the ‘rule’ will be set up though practice.
>
> Thanks.
>
> Xiang Xiao <xi...@gmail.com>于2019年12月25日 周三19:50写道：
>
> > On Wed, Dec 25, 2019 at 2:30 PM 张铎(Duo Zhang) <pa...@gmail.com>
> > wrote:
> > >
> > > Xiang Xiao <xi...@gmail.com> 于2019年12月25日周三 下午1:36写道：
> > >
> > > > Yes, I agree that we shouldn't make the workflow too hard to scare
> > > > people for contribution.
> > > > NuttX isn't a new project, it's open source for more than ten years
> > > > and has a mature workflow, the whole community is already familiar
> > > > with it.
> > > > Let me summary the current workflow:
> > > > 1.User send patch against master to
> > > > https://groups.google.com/forum/#!forum/nuttx or
> > > > 2.User send PR against master to
> > > > https://bitbucket.org/nuttx/nuttx/src/master/
> > > > 3.Greg review and merge the change to master(with some modification if
> > > > needed)
> > > > 4.Greg make a official release and create a tag to mark the point
> > > > every two(or three?) months
> > > > To "be apache way", the required change is only item 3&4: all
> > > > committer need involve the reviewing and release process.
> > > > So, I suggest that we adapter the current workflow with as minimal
> > > > changes as possible:
> > > > 1.User send patch against master to dev@nuttx.apache.org or
> > > > 2.User send PR against master to
> > https://github.com/apache/incubator-nuttx
> > > > 3.Committer review and merge the change to master(with some
> > > > modification if needed)
> > > > 4.Committer make a official release and create a tag to mark the point
> > > > every two(or three?) months
> > > > We only need to disscuss how committer review the change and make the
> > > > release.
> > > > Since we have two month for the next release, let's focus on the
> > > > review process in this time.
> > > > Here are some questions I have, other may add more:
> > > > a.How many committers need approve the patch before it can merge?
> > > >
> > > Usually one committer is enough, the only different is that, if the patch
> > > is proposed by a committer, then you need another committer to approve
> > it.
> > > We need to make sure that a patch has to be reviewed by a committer other
> > > than the author.
> > >
> > > > b.How much time give the committer the chance to say no?
> > > >
> > > This depends. In general, if a committer thinks it is fine to merge then
> > it
> > > can merge the patch/PR. But other committers have the rights to revert
> > the
> > > patch/PR, for example if you are not an expert of this area but he/she
> > is,
> > > and you even do not ask for his/her comments. So I think
> > > during collaboration, you will find the suitable way to decide whether it
> > > is OK to merge a PR. We do not need to define everything explicitly.
> > >
> >
> > But since people work at the different timezone, it's better to hold
> > the patch for one day at least, so people have a chance to review the
> > change and express the different opinion if they want.
> > It isn't a good practice to submit and then revert patch frequently, I
> > think.
> >
> > > > Once all questions get the resonable answer, we can make a vote.
> > > > If anyone has a new idea(e.g. submodule, dev/pr/release branch,
> > > > backport, LTS) send your proprosal to dev list and let community
> > > > discuss and vote.
> > > > But before the proprosal is accepted by the community, why we stop to
> > > > use the current workflow and make our work stuck?
> > > >
> > > > Thanks
> > > > Xiang
> > > >
> > > > On Wed, Dec 25, 2019 at 10:48 AM Justin Mclean <
> > justin@classsoftware.com>
> > > > wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > Some observations that might apply.
> > > > >
> > > > > I've used GitFlow on a few projects here at Apache and elsewhere, it
> > > > does have some downsides, it’s overly complex and confuses beginners
> > > > (particularly those unfamiliar with git),tends to create long lived
> > > > branches (which are hard to merge), master and develop (or whatever you
> > > > call the main two branches) tend to subtly get out of sync over time.
> > > > >
> > > > > You can change the GitHub default branch (you need to ask infra). A
> > > > bigger issue with having master / develop and if you don’t merge
> > frequently
> > > > is that people don’t think the committers are that active, external
> > people
> > > > don't tend to look at activity on the branches.
> > > > >
> > > > > Note that Apache Git/GitHub has some restrictions, we don’t want
> > history
> > > > to be rewritten for legal and provenance reasons so a couple of things
> > you
> > > > may be used to doing outside of Apache may not be possible. Squashing
> > > > commits in some projects tends to be frowned on for this reasons.
> > Similarly
> > > > we need to know the author of any change.
> > > > >
> > > > > Thanks,
> > > > > Justin
> > > > >
> > > > >
> > > >
> >

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

["张铎 (Duo Zhang)" <pa...@gmail.com>]

What I mean is that, nobody wants its patch to be reverted right? So you
will find a proper way to archive this. There is no straight forward rule
on how much time to wait.

For me on HBase, this depends on lots of things. If it is only a typo then
I will merge it immediately. If it is a simple bug fix, I will wait a bit
long and if some committers are familiar with this part, I will try to ask
their opinions. And if this is a very big new feature, sometimes people
will even send an email to the mailing list to attract more reviews before
committing.

So in general, I do not think there is an one-for-all rule. NuttX community
has its own culture, and the ‘rule’ will be set up though practice.

Thanks.

Xiang Xiao <xi...@gmail.com>于2019年12月25日 周三19:50写道：

> On Wed, Dec 25, 2019 at 2:30 PM 张铎(Duo Zhang) <pa...@gmail.com>
> wrote:
> >
> > Xiang Xiao <xi...@gmail.com> 于2019年12月25日周三 下午1:36写道：
> >
> > > Yes, I agree that we shouldn't make the workflow too hard to scare
> > > people for contribution.
> > > NuttX isn't a new project, it's open source for more than ten years
> > > and has a mature workflow, the whole community is already familiar
> > > with it.
> > > Let me summary the current workflow:
> > > 1.User send patch against master to
> > > https://groups.google.com/forum/#!forum/nuttx or
> > > 2.User send PR against master to
> > > https://bitbucket.org/nuttx/nuttx/src/master/
> > > 3.Greg review and merge the change to master(with some modification if
> > > needed)
> > > 4.Greg make a official release and create a tag to mark the point
> > > every two(or three?) months
> > > To "be apache way", the required change is only item 3&4: all
> > > committer need involve the reviewing and release process.
> > > So, I suggest that we adapter the current workflow with as minimal
> > > changes as possible:
> > > 1.User send patch against master to dev@nuttx.apache.org or
> > > 2.User send PR against master to
> https://github.com/apache/incubator-nuttx
> > > 3.Committer review and merge the change to master(with some
> > > modification if needed)
> > > 4.Committer make a official release and create a tag to mark the point
> > > every two(or three?) months
> > > We only need to disscuss how committer review the change and make the
> > > release.
> > > Since we have two month for the next release, let's focus on the
> > > review process in this time.
> > > Here are some questions I have, other may add more:
> > > a.How many committers need approve the patch before it can merge?
> > >
> > Usually one committer is enough, the only different is that, if the patch
> > is proposed by a committer, then you need another committer to approve
> it.
> > We need to make sure that a patch has to be reviewed by a committer other
> > than the author.
> >
> > > b.How much time give the committer the chance to say no?
> > >
> > This depends. In general, if a committer thinks it is fine to merge then
> it
> > can merge the patch/PR. But other committers have the rights to revert
> the
> > patch/PR, for example if you are not an expert of this area but he/she
> is,
> > and you even do not ask for his/her comments. So I think
> > during collaboration, you will find the suitable way to decide whether it
> > is OK to merge a PR. We do not need to define everything explicitly.
> >
>
> But since people work at the different timezone, it's better to hold
> the patch for one day at least, so people have a chance to review the
> change and express the different opinion if they want.
> It isn't a good practice to submit and then revert patch frequently, I
> think.
>
> > > Once all questions get the resonable answer, we can make a vote.
> > > If anyone has a new idea(e.g. submodule, dev/pr/release branch,
> > > backport, LTS) send your proprosal to dev list and let community
> > > discuss and vote.
> > > But before the proprosal is accepted by the community, why we stop to
> > > use the current workflow and make our work stuck?
> > >
> > > Thanks
> > > Xiang
> > >
> > > On Wed, Dec 25, 2019 at 10:48 AM Justin Mclean <
> justin@classsoftware.com>
> > > wrote:
> > > >
> > > > Hi,
> > > >
> > > > Some observations that might apply.
> > > >
> > > > I've used GitFlow on a few projects here at Apache and elsewhere, it
> > > does have some downsides, it’s overly complex and confuses beginners
> > > (particularly those unfamiliar with git),tends to create long lived
> > > branches (which are hard to merge), master and develop (or whatever you
> > > call the main two branches) tend to subtly get out of sync over time.
> > > >
> > > > You can change the GitHub default branch (you need to ask infra). A
> > > bigger issue with having master / develop and if you don’t merge
> frequently
> > > is that people don’t think the committers are that active, external
> people
> > > don't tend to look at activity on the branches.
> > > >
> > > > Note that Apache Git/GitHub has some restrictions, we don’t want
> history
> > > to be rewritten for legal and provenance reasons so a couple of things
> you
> > > may be used to doing outside of Apache may not be possible. Squashing
> > > commits in some projects tends to be frowned on for this reasons.
> Similarly
> > > we need to know the author of any change.
> > > >
> > > > Thanks,
> > > > Justin
> > > >
> > > >
> > >
>

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[Xiang Xiao <xi...@gmail.com>]

On Wed, Dec 25, 2019 at 2:30 PM 张铎(Duo Zhang) <pa...@gmail.com> wrote:
>
> Xiang Xiao <xi...@gmail.com> 于2019年12月25日周三 下午1:36写道：
>
> > Yes, I agree that we shouldn't make the workflow too hard to scare
> > people for contribution.
> > NuttX isn't a new project, it's open source for more than ten years
> > and has a mature workflow, the whole community is already familiar
> > with it.
> > Let me summary the current workflow:
> > 1.User send patch against master to
> > https://groups.google.com/forum/#!forum/nuttx or
> > 2.User send PR against master to
> > https://bitbucket.org/nuttx/nuttx/src/master/
> > 3.Greg review and merge the change to master(with some modification if
> > needed)
> > 4.Greg make a official release and create a tag to mark the point
> > every two(or three?) months
> > To "be apache way", the required change is only item 3&4: all
> > committer need involve the reviewing and release process.
> > So, I suggest that we adapter the current workflow with as minimal
> > changes as possible:
> > 1.User send patch against master to dev@nuttx.apache.org or
> > 2.User send PR against master to https://github.com/apache/incubator-nuttx
> > 3.Committer review and merge the change to master(with some
> > modification if needed)
> > 4.Committer make a official release and create a tag to mark the point
> > every two(or three?) months
> > We only need to disscuss how committer review the change and make the
> > release.
> > Since we have two month for the next release, let's focus on the
> > review process in this time.
> > Here are some questions I have, other may add more:
> > a.How many committers need approve the patch before it can merge?
> >
> Usually one committer is enough, the only different is that, if the patch
> is proposed by a committer, then you need another committer to approve it.
> We need to make sure that a patch has to be reviewed by a committer other
> than the author.
>
> > b.How much time give the committer the chance to say no?
> >
> This depends. In general, if a committer thinks it is fine to merge then it
> can merge the patch/PR. But other committers have the rights to revert the
> patch/PR, for example if you are not an expert of this area but he/she is,
> and you even do not ask for his/her comments. So I think
> during collaboration, you will find the suitable way to decide whether it
> is OK to merge a PR. We do not need to define everything explicitly.
>

But since people work at the different timezone, it's better to hold
the patch for one day at least, so people have a chance to review the
change and express the different opinion if they want.
It isn't a good practice to submit and then revert patch frequently, I think.

> > Once all questions get the resonable answer, we can make a vote.
> > If anyone has a new idea(e.g. submodule, dev/pr/release branch,
> > backport, LTS) send your proprosal to dev list and let community
> > discuss and vote.
> > But before the proprosal is accepted by the community, why we stop to
> > use the current workflow and make our work stuck?
> >
> > Thanks
> > Xiang
> >
> > On Wed, Dec 25, 2019 at 10:48 AM Justin Mclean <ju...@classsoftware.com>
> > wrote:
> > >
> > > Hi,
> > >
> > > Some observations that might apply.
> > >
> > > I've used GitFlow on a few projects here at Apache and elsewhere, it
> > does have some downsides, it’s overly complex and confuses beginners
> > (particularly those unfamiliar with git),tends to create long lived
> > branches (which are hard to merge), master and develop (or whatever you
> > call the main two branches) tend to subtly get out of sync over time.
> > >
> > > You can change the GitHub default branch (you need to ask infra). A
> > bigger issue with having master / develop and if you don’t merge frequently
> > is that people don’t think the committers are that active, external people
> > don't tend to look at activity on the branches.
> > >
> > > Note that Apache Git/GitHub has some restrictions, we don’t want history
> > to be rewritten for legal and provenance reasons so a couple of things you
> > may be used to doing outside of Apache may not be possible. Squashing
> > commits in some projects tends to be frowned on for this reasons. Similarly
> > we need to know the author of any change.
> > >
> > > Thanks,
> > > Justin
> > >
> > >
> >

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[Justin Mclean <ju...@classsoftware.com>]

Hi,

> Usually one committer is enough, the only different is that, if the patch
> is proposed by a committer, then you need another committer to approve it.
> We need to make sure that a patch has to be reviewed by a committer other
> than the author.

This depends on the projects, some don’t have reviews and the committer can commit straight to master. It’s going to vary project by project.

> But other committers have the rights to revert the
> patch/PR

This is referred to a a veto and all projects allow this that I’m aware of. They are however very rare or non-existent, as changes are usually discussed and agree on before hand. They must have a valid technical reason or they are invalid.

>> Once all questions get the resonable answer, we can make a vote.
>> If anyone has a new idea(e.g. submodule, dev/pr/release branch,
>> backport, LTS) send your proprosal to dev list and let community
>> discuss and vote.

I would try to reduce the amount of voting for things like this, just discuss and reach consensus rather than voting. Voting can make winners and looser and split communities.

Thanks,
Justin

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

["张铎 (Duo Zhang)" <pa...@gmail.com>]

Xiang Xiao <xi...@gmail.com> 于2019年12月25日周三 下午1:36写道：

> Yes, I agree that we shouldn't make the workflow too hard to scare
> people for contribution.
> NuttX isn't a new project, it's open source for more than ten years
> and has a mature workflow, the whole community is already familiar
> with it.
> Let me summary the current workflow:
> 1.User send patch against master to
> https://groups.google.com/forum/#!forum/nuttx or
> 2.User send PR against master to
> https://bitbucket.org/nuttx/nuttx/src/master/
> 3.Greg review and merge the change to master(with some modification if
> needed)
> 4.Greg make a official release and create a tag to mark the point
> every two(or three?) months
> To "be apache way", the required change is only item 3&4: all
> committer need involve the reviewing and release process.
> So, I suggest that we adapter the current workflow with as minimal
> changes as possible:
> 1.User send patch against master to dev@nuttx.apache.org or
> 2.User send PR against master to https://github.com/apache/incubator-nuttx
> 3.Committer review and merge the change to master(with some
> modification if needed)
> 4.Committer make a official release and create a tag to mark the point
> every two(or three?) months
> We only need to disscuss how committer review the change and make the
> release.
> Since we have two month for the next release, let's focus on the
> review process in this time.
> Here are some questions I have, other may add more:
> a.How many committers need approve the patch before it can merge?
>
Usually one committer is enough, the only different is that, if the patch
is proposed by a committer, then you need another committer to approve it.
We need to make sure that a patch has to be reviewed by a committer other
than the author.

> b.How much time give the committer the chance to say no?
>
This depends. In general, if a committer thinks it is fine to merge then it
can merge the patch/PR. But other committers have the rights to revert the
patch/PR, for example if you are not an expert of this area but he/she is,
and you even do not ask for his/her comments. So I think
during collaboration, you will find the suitable way to decide whether it
is OK to merge a PR. We do not need to define everything explicitly.

> Once all questions get the resonable answer, we can make a vote.
> If anyone has a new idea(e.g. submodule, dev/pr/release branch,
> backport, LTS) send your proprosal to dev list and let community
> discuss and vote.
> But before the proprosal is accepted by the community, why we stop to
> use the current workflow and make our work stuck?
>
> Thanks
> Xiang
>
> On Wed, Dec 25, 2019 at 10:48 AM Justin Mclean <ju...@classsoftware.com>
> wrote:
> >
> > Hi,
> >
> > Some observations that might apply.
> >
> > I've used GitFlow on a few projects here at Apache and elsewhere, it
> does have some downsides, it’s overly complex and confuses beginners
> (particularly those unfamiliar with git),tends to create long lived
> branches (which are hard to merge), master and develop (or whatever you
> call the main two branches) tend to subtly get out of sync over time.
> >
> > You can change the GitHub default branch (you need to ask infra). A
> bigger issue with having master / develop and if you don’t merge frequently
> is that people don’t think the committers are that active, external people
> don't tend to look at activity on the branches.
> >
> > Note that Apache Git/GitHub has some restrictions, we don’t want history
> to be rewritten for legal and provenance reasons so a couple of things you
> may be used to doing outside of Apache may not be possible. Squashing
> commits in some projects tends to be frowned on for this reasons. Similarly
> we need to know the author of any change.
> >
> > Thanks,
> > Justin
> >
> >
>

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[David Sidrane <da...@apache.org>]

Hi Duo,

I am sorry I broke my own rule. I should have defined it. 

BD: Benevolent dictator for life (BDFL) is a title given to a small number of open-source software development leaders, typically project founders who retain the final say in disputes or arguments within the community.

On 2019/12/25 14:26:47, 张铎(Duo Zhang) <pa...@gmail.com> wrote: 
> Pardon me, what is a BD model? I do not get your point why requiring users
> to send a patch or open a PR against master will hindered the community
> growth? 

I was speaking of the past (pre ASF) model and the last few days, 

Specifically not acting like a team and having PR closed without consideration of taking the commit that was not in dispute that made the tool more useful by adding parse-able output. That does not foster community, it stifles it. 

 > Or you say #3 and #4? These are what we want to change.

This 3 & 4?

3.Committer review and merge the change to master(with some modification if needed)

(with some modification if needed) - this should only happen on a PR as one separate commit to be traceable. There is nothing more off putting the 250 style changes to a users 2 line PR.

The changes I want are to support collaboration in the repo.

1) Is to be able to put pr-branches, for the sake of PPMC collaboration in
the upstream repo.

This works well  for "drive-by PRs". This is the term given to what you described as a PR with value, that Author does not want to take the effort to make changes to do it the best way for the system.
We can tag team on getting things like this in. 

If we do not do this we have to give N committers write access to N committers repos. That does not scale well and will encourage forks.

2)  Have the **option*** to use github's well know and document WF 
 Give the people the freedom to work in the most efficient way a person chooses  (GREEN and CLEAN)[1] 

3)  add branch protection to master 

Avoid any accidents - we are all human. 

4.Committer make a official release and create a tag to mark the point
every two(or three?) months

This is fine, but we will need the process documents to be consistent results. We have time for that.

> 
> Thanks.
> 
> David Sidrane <da...@apache.org> 于2019年12月25日周三 下午9:55写道：
> 
> > Hi Xiang,
> >
> > On 2019/12/25 05:36:14, Xiang Xiao <xi...@gmail.com> wrote:
> > > Yes, I agree that we shouldn't make the workflow too hard to scare
> > > people for contribution.
> > > NuttX isn't a new project, it's open source for more than ten years
> > > and has a mature workflow, the whole community is already familiar
> > > with it.
> > > Let me summary the current workflow:
> > > 1.User send patch against master to
> > > https://groups.google.com/forum/#!forum/nuttx or
> > > 2.User send PR against master to
> > https://bitbucket.org/nuttx/nuttx/src/master/
> > > 3.Greg review and merge the change to master(with some modification if
> > needed)
> > > 4.Greg make a official release and create a tag to mark the point
> > > every two(or three?) months
> > > To "be apache way", the required change is only item 3&4: all
> > > committer need involve the reviewing and release process.
> > > So, I suggest that we adapter the current workflow with as minimal
> > > changes as possible:
> >
> > The above workflow was in support of a BD model who preferred to use
> > patches and refused to use github. (no disrespect intended). The value it
> > added was incredible quality (but in reality only in the areas  important
> > to the BD). At the same time hindered community growth.  This has got to
> > stop under ASF "Community before code".
> > We all have pressure driving our needs to get changes into master. We can
> > do this and it does not have to be the old way or no way or even only one
> > way.  That is too controlling and it hinders Community.
> >
> > My old boss (Circa 1994's) was faced with fixing highly dysfunctional SW &
> > HW group dynamics. He asked us to think about, and ask yourself "How can I
> > add value to any situation?"  When thinking from this perspective it
> > removes Not Invented Here (NIH) and ego from the thinking. Some times the
> > answer is "I can not add value" let the others who can do it and trust
> > them.
> >
> > We have time to fine tune this. But we must keep it moving.
> >
> > The only thing I am suggestion
> > 1) Is to be able to put pr-branches, for the sake of PPMC collaboration in
> > the upstream repo..
> > 2)  Have the option to use github's well know and document WF
> > 3)  add branch protection to master
> >
> > This will not EXCLUDE anyone from doing it the OLD way or as you suggest
> > below.
> >
> > > 1.User send patch against master to dev@nuttx.apache.org or
> > > 2.User send PR against master to
> > https://github.com/apache/incubator-nuttx
> > > 3.Committer review and merge the change to master(with some
> > > modification if needed)
> > > 4.Committer make a official release and create a tag to mark the point
> > > every two(or three?) months
> > > We only need to disscuss how committer review the change and make the
> > release.
> > > Since we have two month for the next release, let's focus on the
> > > review process in this time.
> > > Here are some questions I have, other may add more:
> > > a.How many committers need approve the patch before it can merge?
> > > b.How much time give the committer the chance to say no?
> > > Once all questions get the resonable answer, we can make a vote.
> > > If anyone has a new idea(e.g. submodule, dev/pr/release branch,
> > > backport, LTS) send your proprosal to dev list and let community
> > > discuss and vote.
> > > But before the proprosal is accepted by the community, why we stop to
> > > use the current workflow and make our work stuck?
> > >
> > > Thanks
> > > Xiang
> > >
> > > On Wed, Dec 25, 2019 at 10:48 AM Justin Mclean <ju...@classsoftware.com>
> > wrote:
> > > >
> > > > Hi,
> > > >
> > > > Some observations that might apply.
> > > >
> > > > I've used GitFlow on a few projects here at Apache and elsewhere, it
> > does have some downsides, it’s overly complex and confuses beginners
> > (particularly those unfamiliar with git),tends to create long lived
> > branches (which are hard to merge), master and develop (or whatever you
> > call the main two branches) tend to subtly get out of sync over time.
> > > >
> > > > You can change the GitHub default branch (you need to ask infra). A
> > bigger issue with having master / develop and if you don’t merge frequently
> > is that people don’t think the committers are that active, external people
> > don't tend to look at activity on the branches.
> > > >
> > > > Note that Apache Git/GitHub has some restrictions, we don’t want
> > history to be rewritten for legal and provenance reasons so a couple of
> > things you may be used to doing outside of Apache may not be possible.
> > Squashing commits in some projects tends to be frowned on for this reasons.
> > Similarly we need to know the author of any change.
> > > >
> > > > Thanks,
> > > > Justin
> > > >
> > > >
> > >
> >
> > David
> >
> 
[1] https://www.youtube.com/watch?v=z8MylQ_VPUI

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

["张铎 (Duo Zhang)" <pa...@gmail.com>]

Pardon me, what is a BD model? I do not get your point why requiring users
to send a patch or open a PR against master will hindered the community
growth? Or you say #3 and #4? These are what we want to change.

Thanks.

David Sidrane <da...@apache.org> 于2019年12月25日周三 下午9:55写道：

> Hi Xiang,
>
> On 2019/12/25 05:36:14, Xiang Xiao <xi...@gmail.com> wrote:
> > Yes, I agree that we shouldn't make the workflow too hard to scare
> > people for contribution.
> > NuttX isn't a new project, it's open source for more than ten years
> > and has a mature workflow, the whole community is already familiar
> > with it.
> > Let me summary the current workflow:
> > 1.User send patch against master to
> > https://groups.google.com/forum/#!forum/nuttx or
> > 2.User send PR against master to
> https://bitbucket.org/nuttx/nuttx/src/master/
> > 3.Greg review and merge the change to master(with some modification if
> needed)
> > 4.Greg make a official release and create a tag to mark the point
> > every two(or three?) months
> > To "be apache way", the required change is only item 3&4: all
> > committer need involve the reviewing and release process.
> > So, I suggest that we adapter the current workflow with as minimal
> > changes as possible:
>
> The above workflow was in support of a BD model who preferred to use
> patches and refused to use github. (no disrespect intended). The value it
> added was incredible quality (but in reality only in the areas  important
> to the BD). At the same time hindered community growth.  This has got to
> stop under ASF "Community before code".
> We all have pressure driving our needs to get changes into master. We can
> do this and it does not have to be the old way or no way or even only one
> way.  That is too controlling and it hinders Community.
>
> My old boss (Circa 1994's) was faced with fixing highly dysfunctional SW &
> HW group dynamics. He asked us to think about, and ask yourself "How can I
> add value to any situation?"  When thinking from this perspective it
> removes Not Invented Here (NIH) and ego from the thinking. Some times the
> answer is "I can not add value" let the others who can do it and trust
> them.
>
> We have time to fine tune this. But we must keep it moving.
>
> The only thing I am suggestion
> 1) Is to be able to put pr-branches, for the sake of PPMC collaboration in
> the upstream repo..
> 2)  Have the option to use github's well know and document WF
> 3)  add branch protection to master
>
> This will not EXCLUDE anyone from doing it the OLD way or as you suggest
> below.
>
> > 1.User send patch against master to dev@nuttx.apache.org or
> > 2.User send PR against master to
> https://github.com/apache/incubator-nuttx
> > 3.Committer review and merge the change to master(with some
> > modification if needed)
> > 4.Committer make a official release and create a tag to mark the point
> > every two(or three?) months
> > We only need to disscuss how committer review the change and make the
> release.
> > Since we have two month for the next release, let's focus on the
> > review process in this time.
> > Here are some questions I have, other may add more:
> > a.How many committers need approve the patch before it can merge?
> > b.How much time give the committer the chance to say no?
> > Once all questions get the resonable answer, we can make a vote.
> > If anyone has a new idea(e.g. submodule, dev/pr/release branch,
> > backport, LTS) send your proprosal to dev list and let community
> > discuss and vote.
> > But before the proprosal is accepted by the community, why we stop to
> > use the current workflow and make our work stuck?
> >
> > Thanks
> > Xiang
> >
> > On Wed, Dec 25, 2019 at 10:48 AM Justin Mclean <ju...@classsoftware.com>
> wrote:
> > >
> > > Hi,
> > >
> > > Some observations that might apply.
> > >
> > > I've used GitFlow on a few projects here at Apache and elsewhere, it
> does have some downsides, it’s overly complex and confuses beginners
> (particularly those unfamiliar with git),tends to create long lived
> branches (which are hard to merge), master and develop (or whatever you
> call the main two branches) tend to subtly get out of sync over time.
> > >
> > > You can change the GitHub default branch (you need to ask infra). A
> bigger issue with having master / develop and if you don’t merge frequently
> is that people don’t think the committers are that active, external people
> don't tend to look at activity on the branches.
> > >
> > > Note that Apache Git/GitHub has some restrictions, we don’t want
> history to be rewritten for legal and provenance reasons so a couple of
> things you may be used to doing outside of Apache may not be possible.
> Squashing commits in some projects tends to be frowned on for this reasons.
> Similarly we need to know the author of any change.
> > >
> > > Thanks,
> > > Justin
> > >
> > >
> >
>
> David
>

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[Justin Mclean <ju...@classsoftware.com>]

Hi,

As long as you stick to git only features you can have everyone work on it, so branch bases workflow would be best. You can still use GitHub only features but just don’t make them compulsory.

Not also that some more advanced features or options for GItHub that have been discussed here e.g admin access, adding bots may or may not be possible under the ASF. Infra is the admin of all repo and they need to ensure that we know who has contributed code (which generally means bots can’t have write access)and that  git history can not be altered.

Thanks,
Justin

RE: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[David Sidrane <Da...@nscdg.com>]

That is a great question. I am not the one to answer it.

Perhaps one of the people who cannot get to github can answer it for you.

David

-----Original Message-----
From: Nathan Hartman [mailto:hartman.nathan@gmail.com]
Sent: Wednesday, December 25, 2019 12:30 PM
To: dev@nuttx.apache.org
Subject: Re: Software release life cycle choices could have implications on
workflow (was RE: Single Committer)

On Wed, Dec 25, 2019 at 2:18 PM David Sidrane <Da...@nscdg.com>
wrote:

> Github issues and PR work sooooo well together and are cross linked
> auto-magically.


Justin points out that some people cannot use GitHub and Apache strives to
include everyone. I have no opposition to using GitHub and the tools and
conveniences it offers, but it's important that we all keep conscious of
those concerns when designing our processes so that everyone can
participate. For example how can a committer accomplish similar tasks with
gitbox? Will doing so violate assumptions that any GitHub-based flow
depends on? How to mitigate that?

Nathan

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[Nathan Hartman <ha...@gmail.com>]

On Wed, Dec 25, 2019 at 2:18 PM David Sidrane <Da...@nscdg.com>
wrote:

> Github issues and PR work sooooo well together and are cross linked
> auto-magically.


Justin points out that some people cannot use GitHub and Apache strives to
include everyone. I have no opposition to using GitHub and the tools and
conveniences it offers, but it's important that we all keep conscious of
those concerns when designing our processes so that everyone can
participate. For example how can a committer accomplish similar tasks with
gitbox? Will doing so violate assumptions that any GitHub-based flow
depends on? How to mitigate that?

Nathan

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

["张铎 (Duo Zhang)" <pa...@gmail.com>]

This page explicitly says ‘your project’.

For contributors other than committers, especial it is not their projects,
the repo is not writable to them, and how can they create branches on the
repo?

David Sidrane <Da...@nscdg.com>于2019年12月26日 周四03:18写道：

> Hi Duo,
>
> > What is the well known and documented WF of github? I've never heard
> about
> >it. Please be specific.
>
> https://guides.github.com/introduction/flow/
>
> All I add on top of the above is the naming to keep it easy for me to
> remember where the contributions was from and where it will go. (I have 8+
> remotes) and work on many branches at the same time all for nuttx.
>
> For this ASF project I would use:
>
> <parent name>-pr-<feature/bugfix/>
>
> master-pr-stm32h7_TX_DMA
> master-pr-imxrt_bugfixes
>
> > What do you mean by pr-branches?
>
> See above link and my naming suggestions.
>
> >I still do not get your point why you
> >stick to create branches in the offical repo? Why not just use your own
> >fork? If you need multiple continuous commits to finish a big feature, you
> >can open a branch, we call it a 'feature branch'.
>
> Can you push to my repo? No. Can I push to yours No.
>
> Let me ask you the counter question: What are you concerns with working in
> the projects repo?
>
> Is it repo hygiene. There are simple rules (guidelines)
>
> 1) Use clear un ambiguous naming for branches and branch protection.
> 2) pr branches when merge get deteted.
> 3) Always ask the branch before delete not you own content.
> 4) Add a bot it will help
>
> >And this usually requires more powerful issue tracker system such as JIRA.
>
> Here is the question I would ask: Why re-invent the wheel or use disjoint
> tools (I have used Jira with github - To me, there was not value add that
> made it more it compelling, then issues and Project board in github[1]).
>
> Github issues and PR work sooooo well together and are cross linked
> auto-magically.
>
> [1]
>
> https://help.github.com/en/github/managing-your-work-on-github/about-project-boards
>
>
>
> David
>
>
> -----Original Message-----
> From: 张铎(Duo Zhang) [mailto:palomino219@gmail.com]
> Sent: Wednesday, December 25, 2019 6:37 AM
> To: dev@nuttx.apache.org
> Subject: Re: Software release life cycle choices could have implications on
> workflow (was RE: Single Committer)
>
> David Sidrane <da...@apache.org> 于2019年12月25日周三 下午9:55写道：
>
> > Hi Xiang,
> >
> > On 2019/12/25 05:36:14, Xiang Xiao <xi...@gmail.com> wrote:
> > > Yes, I agree that we shouldn't make the workflow too hard to scare
> > > people for contribution.
> > > NuttX isn't a new project, it's open source for more than ten years
> > > and has a mature workflow, the whole community is already familiar
> > > with it.
> > > Let me summary the current workflow:
> > > 1.User send patch against master to
> > > https://groups.google.com/forum/#!forum/nuttx or
> > > 2.User send PR against master to
> > https://bitbucket.org/nuttx/nuttx/src/master/
> > > 3.Greg review and merge the change to master(with some modification if
> > needed)
> > > 4.Greg make a official release and create a tag to mark the point
> > > every two(or three?) months
> > > To "be apache way", the required change is only item 3&4: all
> > > committer need involve the reviewing and release process.
> > > So, I suggest that we adapter the current workflow with as minimal
> > > changes as possible:
> >
> > The above workflow was in support of a BD model who preferred to use
> > patches and refused to use github. (no disrespect intended). The value it
> > added was incredible quality (but in reality only in the areas  important
> > to the BD). At the same time hindered community growth.  This has got to
> > stop under ASF "Community before code".
> > We all have pressure driving our needs to get changes into master. We can
> > do this and it does not have to be the old way or no way or even only one
> > way.  That is too controlling and it hinders Community.
> >
> > My old boss (Circa 1994's) was faced with fixing highly dysfunctional SW
> &
> > HW group dynamics. He asked us to think about, and ask yourself "How can
> I
> > add value to any situation?"  When thinking from this perspective it
> > removes Not Invented Here (NIH) and ego from the thinking. Some times the
> > answer is "I can not add value" let the others who can do it and trust
> > them.
> >
> > We have time to fine tune this. But we must keep it moving.
> >
> > The only thing I am suggestion
> > 1) Is to be able to put pr-branches, for the sake of PPMC collaboration
> in
> > the upstream repo..
> >
> What do you mean by pr-branches? I still do not get your point why you
> stick to create branches in the offical repo? Why not just use your own
> fork? If you need multiple continuous commits to finish a big feature, you
> can open a branch, we call it a 'feature branch'. And this usually requires
> more powerful issue tracker system such as JIRA.
>
> > 2)  Have the option to use github's well know and document WF
> >
> What is the well known and documented WF of github? I've never heard about
> it. Please be specific.
>
> > 3)  add branch protection to master
> >
> Agree if the branch protection here means disable force push.
>
> >
> > This will not EXCLUDE anyone from doing it the OLD way or as you suggest
> > below.
> >
> > > 1.User send patch against master to dev@nuttx.apache.org or
> > > 2.User send PR against master to
> > https://github.com/apache/incubator-nuttx
> > > 3.Committer review and merge the change to master(with some
> > > modification if needed)
> > > 4.Committer make a official release and create a tag to mark the point
> > > every two(or three?) months
> > > We only need to disscuss how committer review the change and make the
> > release.
> > > Since we have two month for the next release, let's focus on the
> > > review process in this time.
> > > Here are some questions I have, other may add more:
> > > a.How many committers need approve the patch before it can merge?
> > > b.How much time give the committer the chance to say no?
> > > Once all questions get the resonable answer, we can make a vote.
> > > If anyone has a new idea(e.g. submodule, dev/pr/release branch,
> > > backport, LTS) send your proprosal to dev list and let community
> > > discuss and vote.
> > > But before the proprosal is accepted by the community, why we stop to
> > > use the current workflow and make our work stuck?
> > >
> > > Thanks
> > > Xiang
> > >
> > > On Wed, Dec 25, 2019 at 10:48 AM Justin Mclean
> > > <ju...@classsoftware.com>
> > wrote:
> > > >
> > > > Hi,
> > > >
> > > > Some observations that might apply.
> > > >
> > > > I've used GitFlow on a few projects here at Apache and elsewhere, it
> > does have some downsides, it’s overly complex and confuses beginners
> > (particularly those unfamiliar with git),tends to create long lived
> > branches (which are hard to merge), master and develop (or whatever you
> > call the main two branches) tend to subtly get out of sync over time.
> > > >
> > > > You can change the GitHub default branch (you need to ask infra). A
> > bigger issue with having master / develop and if you don’t merge
> > frequently
> > is that people don’t think the committers are that active, external
> people
> > don't tend to look at activity on the branches.
> > > >
> > > > Note that Apache Git/GitHub has some restrictions, we don’t want
> > history to be rewritten for legal and provenance reasons so a couple of
> > things you may be used to doing outside of Apache may not be possible.
> > Squashing commits in some projects tends to be frowned on for this
> > reasons.
> > Similarly we need to know the author of any change.
> > > >
> > > > Thanks,
> > > > Justin
> > > >
> > > >
> > >
> >
> > David
> >
>

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

["张铎 (Duo Zhang)" <pa...@gmail.com>]

David Sidrane <Da...@nscdg.com>于2019年12月26日 周四03:18写道：

> Hi Duo,
>
> > What is the well known and documented WF of github? I've never heard
> about
> >it. Please be specific.
>
> https://guides.github.com/introduction/flow/
>
> All I add on top of the above is the naming to keep it easy for me to
> remember where the contributions was from and where it will go. (I have 8+
> remotes) and work on many branches at the same time all for nuttx.
>
> For this ASF project I would use:
>
> <parent name>-pr-<feature/bugfix/>
>
> master-pr-stm32h7_TX_DMA
> master-pr-imxrt_bugfixes
>
> > What do you mean by pr-branches?
>
> See above link and my naming suggestions.
>
> >I still do not get your point why you
> >stick to create branches in the offical repo? Why not just use your own
> >fork? If you need multiple continuous commits to finish a big feature, you
> >can open a branch, we call it a 'feature branch'.
>
> Can you push to my repo? No. Can I push to yours No.

Why I need to push to your repo? I just push to my own forked repo and then
I can create PR to your repo and you can decide whether to accept the PR.
I’ve never created something like pr-branches when contributing to open
source projects. And for NuttX, since I’m not a committer, I can not push
to the repo directly then I can not contribute to the project?

>
> Let me ask you the counter question: What are you concerns with working in
> the projects repo?

Because contributors can not create branches on the repo. They do not have
permission. And the project I’ve worked on do not use way either.

>
>
> Is it repo hygiene. There are simple rules (guidelines)
>
> 1) Use clear un ambiguous naming for branches and branch protection.
> 2) pr branches when merge get deteted.
> 3) Always ask the branch before delete not you own content.
> 4) Add a bot it will help
>
> >And this usually requires more powerful issue tracker system such as JIRA.
>
> Here is the question I would ask: Why re-invent the wheel or use disjoint
> tools (I have used Jira with github - To me, there was not value add that
> made it more it compelling, then issues and Project board in github[1]).

Maybe GitHub issue is fine, not sure. Anyway, this is not important. Let’s
stop.

>
>
> Github issues and PR work sooooo well together and are cross linked
> auto-magically.
>
> [1]
>
> https://help.github.com/en/github/managing-your-work-on-github/about-project-boards
>
>
>
> David
>
>
> -----Original Message-----
> From: 张铎(Duo Zhang) [mailto:palomino219@gmail.com]
> Sent: Wednesday, December 25, 2019 6:37 AM
> To: dev@nuttx.apache.org
> Subject: Re: Software release life cycle choices could have implications on
> workflow (was RE: Single Committer)
>
> David Sidrane <da...@apache.org> 于2019年12月25日周三 下午9:55写道：
>
> > Hi Xiang,
> >
> > On 2019/12/25 05:36:14, Xiang Xiao <xi...@gmail.com> wrote:
> > > Yes, I agree that we shouldn't make the workflow too hard to scare
> > > people for contribution.
> > > NuttX isn't a new project, it's open source for more than ten years
> > > and has a mature workflow, the whole community is already familiar
> > > with it.
> > > Let me summary the current workflow:
> > > 1.User send patch against master to
> > > https://groups.google.com/forum/#!forum/nuttx or
> > > 2.User send PR against master to
> > https://bitbucket.org/nuttx/nuttx/src/master/
> > > 3.Greg review and merge the change to master(with some modification if
> > needed)
> > > 4.Greg make a official release and create a tag to mark the point
> > > every two(or three?) months
> > > To "be apache way", the required change is only item 3&4: all
> > > committer need involve the reviewing and release process.
> > > So, I suggest that we adapter the current workflow with as minimal
> > > changes as possible:
> >
> > The above workflow was in support of a BD model who preferred to use
> > patches and refused to use github. (no disrespect intended). The value it
> > added was incredible quality (but in reality only in the areas  important
> > to the BD). At the same time hindered community growth.  This has got to
> > stop under ASF "Community before code".
> > We all have pressure driving our needs to get changes into master. We can
> > do this and it does not have to be the old way or no way or even only one
> > way.  That is too controlling and it hinders Community.
> >
> > My old boss (Circa 1994's) was faced with fixing highly dysfunctional SW
> &
> > HW group dynamics. He asked us to think about, and ask yourself "How can
> I
> > add value to any situation?"  When thinking from this perspective it
> > removes Not Invented Here (NIH) and ego from the thinking. Some times the
> > answer is "I can not add value" let the others who can do it and trust
> > them.
> >
> > We have time to fine tune this. But we must keep it moving.
> >
> > The only thing I am suggestion
> > 1) Is to be able to put pr-branches, for the sake of PPMC collaboration
> in
> > the upstream repo..
> >
> What do you mean by pr-branches? I still do not get your point why you
> stick to create branches in the offical repo? Why not just use your own
> fork? If you need multiple continuous commits to finish a big feature, you
> can open a branch, we call it a 'feature branch'. And this usually requires
> more powerful issue tracker system such as JIRA.
>
> > 2)  Have the option to use github's well know and document WF
> >
> What is the well known and documented WF of github? I've never heard about
> it. Please be specific.
>
> > 3)  add branch protection to master
> >
> Agree if the branch protection here means disable force push.
>
> >
> > This will not EXCLUDE anyone from doing it the OLD way or as you suggest
> > below.
> >
> > > 1.User send patch against master to dev@nuttx.apache.org or
> > > 2.User send PR against master to
> > https://github.com/apache/incubator-nuttx
> > > 3.Committer review and merge the change to master(with some
> > > modification if needed)
> > > 4.Committer make a official release and create a tag to mark the point
> > > every two(or three?) months
> > > We only need to disscuss how committer review the change and make the
> > release.
> > > Since we have two month for the next release, let's focus on the
> > > review process in this time.
> > > Here are some questions I have, other may add more:
> > > a.How many committers need approve the patch before it can merge?
> > > b.How much time give the committer the chance to say no?
> > > Once all questions get the resonable answer, we can make a vote.
> > > If anyone has a new idea(e.g. submodule, dev/pr/release branch,
> > > backport, LTS) send your proprosal to dev list and let community
> > > discuss and vote.
> > > But before the proprosal is accepted by the community, why we stop to
> > > use the current workflow and make our work stuck?
> > >
> > > Thanks
> > > Xiang
> > >
> > > On Wed, Dec 25, 2019 at 10:48 AM Justin Mclean
> > > <ju...@classsoftware.com>
> > wrote:
> > > >
> > > > Hi,
> > > >
> > > > Some observations that might apply.
> > > >
> > > > I've used GitFlow on a few projects here at Apache and elsewhere, it
> > does have some downsides, it’s overly complex and confuses beginners
> > (particularly those unfamiliar with git),tends to create long lived
> > branches (which are hard to merge), master and develop (or whatever you
> > call the main two branches) tend to subtly get out of sync over time.
> > > >
> > > > You can change the GitHub default branch (you need to ask infra). A
> > bigger issue with having master / develop and if you don’t merge
> > frequently
> > is that people don’t think the committers are that active, external
> people
> > don't tend to look at activity on the branches.
> > > >
> > > > Note that Apache Git/GitHub has some restrictions, we don’t want
> > history to be rewritten for legal and provenance reasons so a couple of
> > things you may be used to doing outside of Apache may not be possible.
> > Squashing commits in some projects tends to be frowned on for this
> > reasons.
> > Similarly we need to know the author of any change.
> > > >
> > > > Thanks,
> > > > Justin
> > > >
> > > >
> > >
> >
> > David
> >
>

RE: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[David Sidrane <Da...@nscdg.com>]

Hi Duo,

> What is the well known and documented WF of github? I've never heard about
>it. Please be specific.

https://guides.github.com/introduction/flow/

All I add on top of the above is the naming to keep it easy for me to
remember where the contributions was from and where it will go. (I have 8+
remotes) and work on many branches at the same time all for nuttx.

For this ASF project I would use:

<parent name>-pr-<feature/bugfix/>

master-pr-stm32h7_TX_DMA
master-pr-imxrt_bugfixes

> What do you mean by pr-branches?

See above link and my naming suggestions.

>I still do not get your point why you
>stick to create branches in the offical repo? Why not just use your own
>fork? If you need multiple continuous commits to finish a big feature, you
>can open a branch, we call it a 'feature branch'.

Can you push to my repo? No. Can I push to yours No.

Let me ask you the counter question: What are you concerns with working in
the projects repo?

Is it repo hygiene. There are simple rules (guidelines)

1) Use clear un ambiguous naming for branches and branch protection.
2) pr branches when merge get deteted.
3) Always ask the branch before delete not you own content.
4) Add a bot it will help

>And this usually requires more powerful issue tracker system such as JIRA.

Here is the question I would ask: Why re-invent the wheel or use disjoint
tools (I have used Jira with github - To me, there was not value add that
made it more it compelling, then issues and Project board in github[1]).

Github issues and PR work sooooo well together and are cross linked
auto-magically.

[1]
https://help.github.com/en/github/managing-your-work-on-github/about-project-boards



David


-----Original Message-----
From: 张铎(Duo Zhang) [mailto:palomino219@gmail.com]
Sent: Wednesday, December 25, 2019 6:37 AM
To: dev@nuttx.apache.org
Subject: Re: Software release life cycle choices could have implications on
workflow (was RE: Single Committer)

David Sidrane <da...@apache.org> 于2019年12月25日周三 下午9:55写道：

> Hi Xiang,
>
> On 2019/12/25 05:36:14, Xiang Xiao <xi...@gmail.com> wrote:
> > Yes, I agree that we shouldn't make the workflow too hard to scare
> > people for contribution.
> > NuttX isn't a new project, it's open source for more than ten years
> > and has a mature workflow, the whole community is already familiar
> > with it.
> > Let me summary the current workflow:
> > 1.User send patch against master to
> > https://groups.google.com/forum/#!forum/nuttx or
> > 2.User send PR against master to
> https://bitbucket.org/nuttx/nuttx/src/master/
> > 3.Greg review and merge the change to master(with some modification if
> needed)
> > 4.Greg make a official release and create a tag to mark the point
> > every two(or three?) months
> > To "be apache way", the required change is only item 3&4: all
> > committer need involve the reviewing and release process.
> > So, I suggest that we adapter the current workflow with as minimal
> > changes as possible:
>
> The above workflow was in support of a BD model who preferred to use
> patches and refused to use github. (no disrespect intended). The value it
> added was incredible quality (but in reality only in the areas  important
> to the BD). At the same time hindered community growth.  This has got to
> stop under ASF "Community before code".
> We all have pressure driving our needs to get changes into master. We can
> do this and it does not have to be the old way or no way or even only one
> way.  That is too controlling and it hinders Community.
>
> My old boss (Circa 1994's) was faced with fixing highly dysfunctional SW &
> HW group dynamics. He asked us to think about, and ask yourself "How can I
> add value to any situation?"  When thinking from this perspective it
> removes Not Invented Here (NIH) and ego from the thinking. Some times the
> answer is "I can not add value" let the others who can do it and trust
> them.
>
> We have time to fine tune this. But we must keep it moving.
>
> The only thing I am suggestion
> 1) Is to be able to put pr-branches, for the sake of PPMC collaboration in
> the upstream repo..
>
What do you mean by pr-branches? I still do not get your point why you
stick to create branches in the offical repo? Why not just use your own
fork? If you need multiple continuous commits to finish a big feature, you
can open a branch, we call it a 'feature branch'. And this usually requires
more powerful issue tracker system such as JIRA.

> 2)  Have the option to use github's well know and document WF
>
What is the well known and documented WF of github? I've never heard about
it. Please be specific.

> 3)  add branch protection to master
>
Agree if the branch protection here means disable force push.

>
> This will not EXCLUDE anyone from doing it the OLD way or as you suggest
> below.
>
> > 1.User send patch against master to dev@nuttx.apache.org or
> > 2.User send PR against master to
> https://github.com/apache/incubator-nuttx
> > 3.Committer review and merge the change to master(with some
> > modification if needed)
> > 4.Committer make a official release and create a tag to mark the point
> > every two(or three?) months
> > We only need to disscuss how committer review the change and make the
> release.
> > Since we have two month for the next release, let's focus on the
> > review process in this time.
> > Here are some questions I have, other may add more:
> > a.How many committers need approve the patch before it can merge?
> > b.How much time give the committer the chance to say no?
> > Once all questions get the resonable answer, we can make a vote.
> > If anyone has a new idea(e.g. submodule, dev/pr/release branch,
> > backport, LTS) send your proprosal to dev list and let community
> > discuss and vote.
> > But before the proprosal is accepted by the community, why we stop to
> > use the current workflow and make our work stuck?
> >
> > Thanks
> > Xiang
> >
> > On Wed, Dec 25, 2019 at 10:48 AM Justin Mclean
> > <ju...@classsoftware.com>
> wrote:
> > >
> > > Hi,
> > >
> > > Some observations that might apply.
> > >
> > > I've used GitFlow on a few projects here at Apache and elsewhere, it
> does have some downsides, it’s overly complex and confuses beginners
> (particularly those unfamiliar with git),tends to create long lived
> branches (which are hard to merge), master and develop (or whatever you
> call the main two branches) tend to subtly get out of sync over time.
> > >
> > > You can change the GitHub default branch (you need to ask infra). A
> bigger issue with having master / develop and if you don’t merge
> frequently
> is that people don’t think the committers are that active, external people
> don't tend to look at activity on the branches.
> > >
> > > Note that Apache Git/GitHub has some restrictions, we don’t want
> history to be rewritten for legal and provenance reasons so a couple of
> things you may be used to doing outside of Apache may not be possible.
> Squashing commits in some projects tends to be frowned on for this
> reasons.
> Similarly we need to know the author of any change.
> > >
> > > Thanks,
> > > Justin
> > >
> > >
> >
>
> David
>

RE: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[David Sidrane <Da...@nscdg.com>]

Branch protection

https://help.github.com/en/github/administering-a-repository/about-protected-branches

About protected branches. Protected branches ensure that collaborators on
your repository cannot make irrevocable changes to branches. Enabling
protected branches also allows you to enable other optional checks and
requirements, like required status checks and required reviews.
About protected branches - GitHub Help
https://help.github.com › github › administering-a-repository ›
about-protect...

David

-----Original Message-----
From: 张铎(Duo Zhang) [mailto:palomino219@gmail.com]
Sent: Wednesday, December 25, 2019 6:37 AM
To: dev@nuttx.apache.org
Subject: Re: Software release life cycle choices could have implications on
workflow (was RE: Single Committer)

David Sidrane <da...@apache.org> 于2019年12月25日周三 下午9:55写道：

> Hi Xiang,
>
> On 2019/12/25 05:36:14, Xiang Xiao <xi...@gmail.com> wrote:
> > Yes, I agree that we shouldn't make the workflow too hard to scare
> > people for contribution.
> > NuttX isn't a new project, it's open source for more than ten years
> > and has a mature workflow, the whole community is already familiar
> > with it.
> > Let me summary the current workflow:
> > 1.User send patch against master to
> > https://groups.google.com/forum/#!forum/nuttx or
> > 2.User send PR against master to
> https://bitbucket.org/nuttx/nuttx/src/master/
> > 3.Greg review and merge the change to master(with some modification if
> needed)
> > 4.Greg make a official release and create a tag to mark the point
> > every two(or three?) months
> > To "be apache way", the required change is only item 3&4: all
> > committer need involve the reviewing and release process.
> > So, I suggest that we adapter the current workflow with as minimal
> > changes as possible:
>
> The above workflow was in support of a BD model who preferred to use
> patches and refused to use github. (no disrespect intended). The value it
> added was incredible quality (but in reality only in the areas  important
> to the BD). At the same time hindered community growth.  This has got to
> stop under ASF "Community before code".
> We all have pressure driving our needs to get changes into master. We can
> do this and it does not have to be the old way or no way or even only one
> way.  That is too controlling and it hinders Community.
>
> My old boss (Circa 1994's) was faced with fixing highly dysfunctional SW &
> HW group dynamics. He asked us to think about, and ask yourself "How can I
> add value to any situation?"  When thinking from this perspective it
> removes Not Invented Here (NIH) and ego from the thinking. Some times the
> answer is "I can not add value" let the others who can do it and trust
> them.
>
> We have time to fine tune this. But we must keep it moving.
>
> The only thing I am suggestion
> 1) Is to be able to put pr-branches, for the sake of PPMC collaboration in
> the upstream repo..
>
What do you mean by pr-branches? I still do not get your point why you
stick to create branches in the offical repo? Why not just use your own
fork? If you need multiple continuous commits to finish a big feature, you
can open a branch, we call it a 'feature branch'. And this usually requires
more powerful issue tracker system such as JIRA.

> 2)  Have the option to use github's well know and document WF
>
What is the well known and documented WF of github? I've never heard about
it. Please be specific.

> 3)  add branch protection to master
>
Agree if the branch protection here means disable force push.

>
> This will not EXCLUDE anyone from doing it the OLD way or as you suggest
> below.
>
> > 1.User send patch against master to dev@nuttx.apache.org or
> > 2.User send PR against master to
> https://github.com/apache/incubator-nuttx
> > 3.Committer review and merge the change to master(with some
> > modification if needed)
> > 4.Committer make a official release and create a tag to mark the point
> > every two(or three?) months
> > We only need to disscuss how committer review the change and make the
> release.
> > Since we have two month for the next release, let's focus on the
> > review process in this time.
> > Here are some questions I have, other may add more:
> > a.How many committers need approve the patch before it can merge?
> > b.How much time give the committer the chance to say no?
> > Once all questions get the resonable answer, we can make a vote.
> > If anyone has a new idea(e.g. submodule, dev/pr/release branch,
> > backport, LTS) send your proprosal to dev list and let community
> > discuss and vote.
> > But before the proprosal is accepted by the community, why we stop to
> > use the current workflow and make our work stuck?
> >
> > Thanks
> > Xiang
> >
> > On Wed, Dec 25, 2019 at 10:48 AM Justin Mclean
> > <ju...@classsoftware.com>
> wrote:
> > >
> > > Hi,
> > >
> > > Some observations that might apply.
> > >
> > > I've used GitFlow on a few projects here at Apache and elsewhere, it
> does have some downsides, it’s overly complex and confuses beginners
> (particularly those unfamiliar with git),tends to create long lived
> branches (which are hard to merge), master and develop (or whatever you
> call the main two branches) tend to subtly get out of sync over time.
> > >
> > > You can change the GitHub default branch (you need to ask infra). A
> bigger issue with having master / develop and if you don’t merge
> frequently
> is that people don’t think the committers are that active, external people
> don't tend to look at activity on the branches.
> > >
> > > Note that Apache Git/GitHub has some restrictions, we don’t want
> history to be rewritten for legal and provenance reasons so a couple of
> things you may be used to doing outside of Apache may not be possible.
> Squashing commits in some projects tends to be frowned on for this
> reasons.
> Similarly we need to know the author of any change.
> > >
> > > Thanks,
> > > Justin
> > >
> > >
> >
>
> David
>

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

["张铎 (Duo Zhang)" <pa...@gmail.com>]

David Sidrane <da...@apache.org> 于2019年12月25日周三 下午9:55写道：

> Hi Xiang,
>
> On 2019/12/25 05:36:14, Xiang Xiao <xi...@gmail.com> wrote:
> > Yes, I agree that we shouldn't make the workflow too hard to scare
> > people for contribution.
> > NuttX isn't a new project, it's open source for more than ten years
> > and has a mature workflow, the whole community is already familiar
> > with it.
> > Let me summary the current workflow:
> > 1.User send patch against master to
> > https://groups.google.com/forum/#!forum/nuttx or
> > 2.User send PR against master to
> https://bitbucket.org/nuttx/nuttx/src/master/
> > 3.Greg review and merge the change to master(with some modification if
> needed)
> > 4.Greg make a official release and create a tag to mark the point
> > every two(or three?) months
> > To "be apache way", the required change is only item 3&4: all
> > committer need involve the reviewing and release process.
> > So, I suggest that we adapter the current workflow with as minimal
> > changes as possible:
>
> The above workflow was in support of a BD model who preferred to use
> patches and refused to use github. (no disrespect intended). The value it
> added was incredible quality (but in reality only in the areas  important
> to the BD). At the same time hindered community growth.  This has got to
> stop under ASF "Community before code".
> We all have pressure driving our needs to get changes into master. We can
> do this and it does not have to be the old way or no way or even only one
> way.  That is too controlling and it hinders Community.
>
> My old boss (Circa 1994's) was faced with fixing highly dysfunctional SW &
> HW group dynamics. He asked us to think about, and ask yourself "How can I
> add value to any situation?"  When thinking from this perspective it
> removes Not Invented Here (NIH) and ego from the thinking. Some times the
> answer is "I can not add value" let the others who can do it and trust
> them.
>
> We have time to fine tune this. But we must keep it moving.
>
> The only thing I am suggestion
> 1) Is to be able to put pr-branches, for the sake of PPMC collaboration in
> the upstream repo..
>
What do you mean by pr-branches? I still do not get your point why you
stick to create branches in the offical repo? Why not just use your own
fork? If you need multiple continuous commits to finish a big feature, you
can open a branch, we call it a 'feature branch'. And this usually requires
more powerful issue tracker system such as JIRA.

> 2)  Have the option to use github's well know and document WF
>
What is the well known and documented WF of github? I've never heard about
it. Please be specific.

> 3)  add branch protection to master
>
Agree if the branch protection here means disable force push.

>
> This will not EXCLUDE anyone from doing it the OLD way or as you suggest
> below.
>
> > 1.User send patch against master to dev@nuttx.apache.org or
> > 2.User send PR against master to
> https://github.com/apache/incubator-nuttx
> > 3.Committer review and merge the change to master(with some
> > modification if needed)
> > 4.Committer make a official release and create a tag to mark the point
> > every two(or three?) months
> > We only need to disscuss how committer review the change and make the
> release.
> > Since we have two month for the next release, let's focus on the
> > review process in this time.
> > Here are some questions I have, other may add more:
> > a.How many committers need approve the patch before it can merge?
> > b.How much time give the committer the chance to say no?
> > Once all questions get the resonable answer, we can make a vote.
> > If anyone has a new idea(e.g. submodule, dev/pr/release branch,
> > backport, LTS) send your proprosal to dev list and let community
> > discuss and vote.
> > But before the proprosal is accepted by the community, why we stop to
> > use the current workflow and make our work stuck?
> >
> > Thanks
> > Xiang
> >
> > On Wed, Dec 25, 2019 at 10:48 AM Justin Mclean <ju...@classsoftware.com>
> wrote:
> > >
> > > Hi,
> > >
> > > Some observations that might apply.
> > >
> > > I've used GitFlow on a few projects here at Apache and elsewhere, it
> does have some downsides, it’s overly complex and confuses beginners
> (particularly those unfamiliar with git),tends to create long lived
> branches (which are hard to merge), master and develop (or whatever you
> call the main two branches) tend to subtly get out of sync over time.
> > >
> > > You can change the GitHub default branch (you need to ask infra). A
> bigger issue with having master / develop and if you don’t merge frequently
> is that people don’t think the committers are that active, external people
> don't tend to look at activity on the branches.
> > >
> > > Note that Apache Git/GitHub has some restrictions, we don’t want
> history to be rewritten for legal and provenance reasons so a couple of
> things you may be used to doing outside of Apache may not be possible.
> Squashing commits in some projects tends to be frowned on for this reasons.
> Similarly we need to know the author of any change.
> > >
> > > Thanks,
> > > Justin
> > >
> > >
> >
>
> David
>

RE: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[David Sidrane <Da...@nscdg.com>]

-----Original Message-----
From: Xiang Xiao [mailto:xiaoxiang781216@gmail.com]
Sent: Wednesday, December 25, 2019 6:55 AM
To: dev@nuttx.apache.org
Subject: Re: Software release life cycle choices could have implications on
workflow (was RE: Single Committer)



On Wed, Dec 25, 2019 at 9:55 PM David Sidrane <da...@apache.org> wrote:

>

> Hi Xiang,

>

> On 2019/12/25 05:36:14, Xiang Xiao <xi...@gmail.com> wrote:

> > Yes, I agree that we shouldn't make the workflow too hard to scare

> > people for contribution.

> > NuttX isn't a new project, it's open source for more than ten years

> > and has a mature workflow, the whole community is already familiar

> > with it.

> > Let me summary the current workflow:

> > 1.User send patch against master to

> > https://groups.google.com/forum/#!forum/nuttx or

> > 2.User send PR against master to
https://bitbucket.org/nuttx/nuttx/src/master/

> > 3.Greg review and merge the change to master(with some modification if
needed)

> > 4.Greg make a official release and create a tag to mark the point

> > every two(or three?) months

> > To "be apache way", the required change is only item 3&4: all

> > committer need involve the reviewing and release process.

> > So, I suggest that we adapter the current workflow with as minimal

> > changes as possible:

>

> The above workflow was in support of a BD model who preferred to use
patches and refused to use github. (no disrespect intended). The value it
added was incredible quality (but in reality only in the areas  important
to the BD). At the same time hindered community growth.  This has got to
stop under ASF "Community before code".

> We all have pressure driving our needs to get changes into master. We can
do this and it does not have to be the old way or no way or even only one
way.  That is too controlling and it hinders Community.

>



Why is it become BD mode without PR branch? almost github project I

contributed before don't create the branch for PR, here are some

examples:

https://github.com/curl/curl/pull/4756

https://github.com/esnet/iperf/pull/935

https://github.com/OpenAMP/open-amp/pull/184



I was referring to the past. Patches were directly applied to master.



Anyone could make the comment and suggestion for PR through github UI

directly, I don't think we can't review code without PR branch here.



Even PX4 doesn't create the PR branch for each patch, for example:

https://github.com/PX4/Firmware/pull/13787

you just send it 19 hours ago which against master but without PR branch.



No. That is not the case

Note its location the BRANCH is here
https://github.com/PX4/Firmware/tree/master_SDIO_pu_fixes





> My old boss (Circa 1994's) was faced with fixing highly dysfunctional SW
& HW group dynamics. He asked us to think about, and ask yourself "How can
I add value to any situation?"  When thinking from this perspective it
removes Not Invented Here (NIH) and ego from the thinking. Some times the
answer is "I can not add value" let the others who can do it and trust them.

>

> We have time to fine tune this. But we must keep it moving.

>

> The only thing I am suggestion

> 1) Is to be able to put pr-branches, for the sake of PPMC collaboration
in the upstream repo..



I don't reject the branch on the official repo: if some big feature

need to develop or some modification need involve multiple people, the

new branch can be created for that after the disscussion. What I don't

like is create the branch for every patch, which just make the process

more complicated and mess the official repo.

I just count PX4 repo: total 272 branches, 64 branches is old than 1

year, 150 branches is old than 1 month.



> 2)  Have the option to use github's well know and document WF

> 3)  add branch protection to master

>



Yes, before patch merge into master, it should go through the review

process documented by the workflow.

Of course, as Abdelatif note that we have to bypass the workflow in

some special case.



[DBS] Even in the extreme case You can still do the correct thing. Create a
branch, open a PR and use the ADMIN override to merge it.!!











> This will not EXCLUDE anyone from doing it the OLD way or as you suggest
below.

>

> > 1.User send patch against master to dev@nuttx.apache.org or

> > 2.User send PR against master to
https://github.com/apache/incubator-nuttx

> > 3.Committer review and merge the change to master(with some

> > modification if needed)

> > 4.Committer make a official release and create a tag to mark the point

> > every two(or three?) months

> > We only need to disscuss how committer review the change and make the
release.

> > Since we have two month for the next release, let's focus on the

> > review process in this time.

> > Here are some questions I have, other may add more:

> > a.How many committers need approve the patch before it can merge?

> > b.How much time give the committer the chance to say no?

> > Once all questions get the resonable answer, we can make a vote.

> > If anyone has a new idea(e.g. submodule, dev/pr/release branch,

> > backport, LTS) send your proprosal to dev list and let community

> > discuss and vote.

> > But before the proprosal is accepted by the community, why we stop to

> > use the current workflow and make our work stuck?

> >

> > Thanks

> > Xiang

> >

> > On Wed, Dec 25, 2019 at 10:48 AM Justin Mclean <ju...@classsoftware.com>
wrote:

> > >

> > > Hi,

> > >

> > > Some observations that might apply.

> > >

> > > I've used GitFlow on a few projects here at Apache and elsewhere, it
does have some downsides, it’s overly complex and confuses beginners
(particularly those unfamiliar with git),tends to create long lived
branches (which are hard to merge), master and develop (or whatever you
call the main two branches) tend to subtly get out of sync over time.

> > >

> > > You can change the GitHub default branch (you need to ask infra). A
bigger issue with having master / develop and if you don’t merge frequently
is that people don’t think the committers are that active, external people
don't tend to look at activity on the branches.

> > >

> > > Note that Apache Git/GitHub has some restrictions, we don’t want
history to be rewritten for legal and provenance reasons so a couple of
things you may be used to doing outside of Apache may not be possible.
Squashing commits in some projects tends to be frowned on for this reasons.
Similarly we need to know the author of any change.

> > >

> > > Thanks,

> > > Justin

> > >

> > >

> >

>

> David

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[Xiang Xiao <xi...@gmail.com>]

On Wed, Dec 25, 2019 at 9:55 PM David Sidrane <da...@apache.org> wrote:
>
> Hi Xiang,
>
> On 2019/12/25 05:36:14, Xiang Xiao <xi...@gmail.com> wrote:
> > Yes, I agree that we shouldn't make the workflow too hard to scare
> > people for contribution.
> > NuttX isn't a new project, it's open source for more than ten years
> > and has a mature workflow, the whole community is already familiar
> > with it.
> > Let me summary the current workflow:
> > 1.User send patch against master to
> > https://groups.google.com/forum/#!forum/nuttx or
> > 2.User send PR against master to https://bitbucket.org/nuttx/nuttx/src/master/
> > 3.Greg review and merge the change to master(with some modification if needed)
> > 4.Greg make a official release and create a tag to mark the point
> > every two(or three?) months
> > To "be apache way", the required change is only item 3&4: all
> > committer need involve the reviewing and release process.
> > So, I suggest that we adapter the current workflow with as minimal
> > changes as possible:
>
> The above workflow was in support of a BD model who preferred to use patches and refused to use github. (no disrespect intended). The value it added was incredible quality (but in reality only in the areas  important to the BD). At the same time hindered community growth.  This has got to stop under ASF "Community before code".
> We all have pressure driving our needs to get changes into master. We can do this and it does not have to be the old way or no way or even only one way.  That is too controlling and it hinders Community.
>

Why is it become BD mode without PR branch? almost github project I
contributed before don't create the branch for PR, here are some
examples:
https://github.com/curl/curl/pull/4756
https://github.com/esnet/iperf/pull/935
https://github.com/OpenAMP/open-amp/pull/184

Anyone could make the comment and suggestion for PR through github UI
directly, I don't think we can't review code without PR branch here.

Even PX4 doesn't create the PR branch for each patch, for example:
https://github.com/PX4/Firmware/pull/13787
you just send it 19 hours ago which against master but without PR branch.

> My old boss (Circa 1994's) was faced with fixing highly dysfunctional SW & HW group dynamics. He asked us to think about, and ask yourself "How can I add value to any situation?"  When thinking from this perspective it removes Not Invented Here (NIH) and ego from the thinking. Some times the answer is "I can not add value" let the others who can do it and trust them.
>
> We have time to fine tune this. But we must keep it moving.
>
> The only thing I am suggestion
> 1) Is to be able to put pr-branches, for the sake of PPMC collaboration in the upstream repo..

I don't reject the branch on the official repo: if some big feature
need to develop or some modification need involve multiple people, the
new branch can be created for that after the disscussion. What I don't
like is create the branch for every patch, which just make the process
more complicated and mess the official repo.
I just count PX4 repo: total 272 branches, 64 branches is old than 1
year, 150 branches is old than 1 month.

> 2)  Have the option to use github's well know and document WF
> 3)  add branch protection to master
>

Yes, before patch merge into master, it should go through the review
process documented by the workflow.
Of course, as Abdelatif note that we have to bypass the workflow in
some special case.

> This will not EXCLUDE anyone from doing it the OLD way or as you suggest below.
>
> > 1.User send patch against master to dev@nuttx.apache.org or
> > 2.User send PR against master to https://github.com/apache/incubator-nuttx
> > 3.Committer review and merge the change to master(with some
> > modification if needed)
> > 4.Committer make a official release and create a tag to mark the point
> > every two(or three?) months
> > We only need to disscuss how committer review the change and make the release.
> > Since we have two month for the next release, let's focus on the
> > review process in this time.
> > Here are some questions I have, other may add more:
> > a.How many committers need approve the patch before it can merge?
> > b.How much time give the committer the chance to say no?
> > Once all questions get the resonable answer, we can make a vote.
> > If anyone has a new idea(e.g. submodule, dev/pr/release branch,
> > backport, LTS) send your proprosal to dev list and let community
> > discuss and vote.
> > But before the proprosal is accepted by the community, why we stop to
> > use the current workflow and make our work stuck?
> >
> > Thanks
> > Xiang
> >
> > On Wed, Dec 25, 2019 at 10:48 AM Justin Mclean <ju...@classsoftware.com> wrote:
> > >
> > > Hi,
> > >
> > > Some observations that might apply.
> > >
> > > I've used GitFlow on a few projects here at Apache and elsewhere, it does have some downsides, it’s overly complex and confuses beginners (particularly those unfamiliar with git),tends to create long lived branches (which are hard to merge), master and develop (or whatever you call the main two branches) tend to subtly get out of sync over time.
> > >
> > > You can change the GitHub default branch (you need to ask infra). A bigger issue with having master / develop and if you don’t merge frequently is that people don’t think the committers are that active, external people don't tend to look at activity on the branches.
> > >
> > > Note that Apache Git/GitHub has some restrictions, we don’t want history to be rewritten for legal and provenance reasons so a couple of things you may be used to doing outside of Apache may not be possible. Squashing commits in some projects tends to be frowned on for this reasons. Similarly we need to know the author of any change.
> > >
> > > Thanks,
> > > Justin
> > >
> > >
> >
>
> David

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[David Sidrane <da...@apache.org>]

Hi Xiang,

On 2019/12/25 05:36:14, Xiang Xiao <xi...@gmail.com> wrote: 
> Yes, I agree that we shouldn't make the workflow too hard to scare
> people for contribution.
> NuttX isn't a new project, it's open source for more than ten years
> and has a mature workflow, the whole community is already familiar
> with it.
> Let me summary the current workflow:
> 1.User send patch against master to
> https://groups.google.com/forum/#!forum/nuttx or
> 2.User send PR against master to https://bitbucket.org/nuttx/nuttx/src/master/
> 3.Greg review and merge the change to master(with some modification if needed)
> 4.Greg make a official release and create a tag to mark the point
> every two(or three?) months
> To "be apache way", the required change is only item 3&4: all
> committer need involve the reviewing and release process.
> So, I suggest that we adapter the current workflow with as minimal
> changes as possible:

The above workflow was in support of a BD model who preferred to use patches and refused to use github. (no disrespect intended). The value it added was incredible quality (but in reality only in the areas  important to the BD). At the same time hindered community growth.  This has got to stop under ASF "Community before code".  
We all have pressure driving our needs to get changes into master. We can do this and it does not have to be the old way or no way or even only one way.  That is too controlling and it hinders Community. 

My old boss (Circa 1994's) was faced with fixing highly dysfunctional SW & HW group dynamics. He asked us to think about, and ask yourself "How can I add value to any situation?"  When thinking from this perspective it removes Not Invented Here (NIH) and ego from the thinking. Some times the answer is "I can not add value" let the others who can do it and trust them. 

We have time to fine tune this. But we must keep it moving. 

The only thing I am suggestion 
1) Is to be able to put pr-branches, for the sake of PPMC collaboration in the upstream repo..
2)  Have the option to use github's well know and document WF 
3)  add branch protection to master 

This will not EXCLUDE anyone from doing it the OLD way or as you suggest below. 

> 1.User send patch against master to dev@nuttx.apache.org or
> 2.User send PR against master to https://github.com/apache/incubator-nuttx
> 3.Committer review and merge the change to master(with some
> modification if needed)
> 4.Committer make a official release and create a tag to mark the point
> every two(or three?) months
> We only need to disscuss how committer review the change and make the release.
> Since we have two month for the next release, let's focus on the
> review process in this time.
> Here are some questions I have, other may add more:
> a.How many committers need approve the patch before it can merge?
> b.How much time give the committer the chance to say no?
> Once all questions get the resonable answer, we can make a vote.
> If anyone has a new idea(e.g. submodule, dev/pr/release branch,
> backport, LTS) send your proprosal to dev list and let community
> discuss and vote.
> But before the proprosal is accepted by the community, why we stop to
> use the current workflow and make our work stuck?
> 
> Thanks
> Xiang
> 
> On Wed, Dec 25, 2019 at 10:48 AM Justin Mclean <ju...@classsoftware.com> wrote:
> >
> > Hi,
> >
> > Some observations that might apply.
> >
> > I've used GitFlow on a few projects here at Apache and elsewhere, it does have some downsides, it’s overly complex and confuses beginners (particularly those unfamiliar with git),tends to create long lived branches (which are hard to merge), master and develop (or whatever you call the main two branches) tend to subtly get out of sync over time.
> >
> > You can change the GitHub default branch (you need to ask infra). A bigger issue with having master / develop and if you don’t merge frequently is that people don’t think the committers are that active, external people don't tend to look at activity on the branches.
> >
> > Note that Apache Git/GitHub has some restrictions, we don’t want history to be rewritten for legal and provenance reasons so a couple of things you may be used to doing outside of Apache may not be possible. Squashing commits in some projects tends to be frowned on for this reasons. Similarly we need to know the author of any change.
> >
> > Thanks,
> > Justin
> >
> >
> 

David

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[Xiang Xiao <xi...@gmail.com>]

Yes, I agree that we shouldn't make the workflow too hard to scare
people for contribution.
NuttX isn't a new project, it's open source for more than ten years
and has a mature workflow, the whole community is already familiar
with it.
Let me summary the current workflow:
1.User send patch against master to
https://groups.google.com/forum/#!forum/nuttx or
2.User send PR against master to https://bitbucket.org/nuttx/nuttx/src/master/
3.Greg review and merge the change to master(with some modification if needed)
4.Greg make a official release and create a tag to mark the point
every two(or three?) months
To "be apache way", the required change is only item 3&4: all
committer need involve the reviewing and release process.
So, I suggest that we adapter the current workflow with as minimal
changes as possible:
1.User send patch against master to dev@nuttx.apache.org or
2.User send PR against master to https://github.com/apache/incubator-nuttx
3.Committer review and merge the change to master(with some
modification if needed)
4.Committer make a official release and create a tag to mark the point
every two(or three?) months
We only need to disscuss how committer review the change and make the release.
Since we have two month for the next release, let's focus on the
review process in this time.
Here are some questions I have, other may add more:
a.How many committers need approve the patch before it can merge?
b.How much time give the committer the chance to say no?
Once all questions get the resonable answer, we can make a vote.
If anyone has a new idea(e.g. submodule, dev/pr/release branch,
backport, LTS) send your proprosal to dev list and let community
discuss and vote.
But before the proprosal is accepted by the community, why we stop to
use the current workflow and make our work stuck?

Thanks
Xiang

On Wed, Dec 25, 2019 at 10:48 AM Justin Mclean <ju...@classsoftware.com> wrote:
>
> Hi,
>
> Some observations that might apply.
>
> I've used GitFlow on a few projects here at Apache and elsewhere, it does have some downsides, it’s overly complex and confuses beginners (particularly those unfamiliar with git),tends to create long lived branches (which are hard to merge), master and develop (or whatever you call the main two branches) tend to subtly get out of sync over time.
>
> You can change the GitHub default branch (you need to ask infra). A bigger issue with having master / develop and if you don’t merge frequently is that people don’t think the committers are that active, external people don't tend to look at activity on the branches.
>
> Note that Apache Git/GitHub has some restrictions, we don’t want history to be rewritten for legal and provenance reasons so a couple of things you may be used to doing outside of Apache may not be possible. Squashing commits in some projects tends to be frowned on for this reasons. Similarly we need to know the author of any change.
>
> Thanks,
> Justin
>
>

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[Justin Mclean <ju...@classsoftware.com>]

Hi,

Some observations that might apply.

I've used GitFlow on a few projects here at Apache and elsewhere, it does have some downsides, it’s overly complex and confuses beginners (particularly those unfamiliar with git),tends to create long lived branches (which are hard to merge), master and develop (or whatever you call the main two branches) tend to subtly get out of sync over time.

You can change the GitHub default branch (you need to ask infra). A bigger issue with having master / develop and if you don’t merge frequently is that people don’t think the committers are that active, external people don't tend to look at activity on the branches.

Note that Apache Git/GitHub has some restrictions, we don’t want history to be rewritten for legal and provenance reasons so a couple of things you may be used to doing outside of Apache may not be possible. Squashing commits in some projects tends to be frowned on for this reasons. Similarly we need to know the author of any change.

Thanks,
Justin

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[Brennan Ashton <ba...@brennanashton.com>]

On Tue, Dec 24, 2019, 3:13 PM Gregory Nutt <sp...@gmail.com> wrote:

>
> >
> >> If they are related / dependent on each other, then I think those
> >> kinds of patchsets should be encapsulated in one branch.
> >
> > The need to be applied and committed in sequence.  Sometimes the final
> > patch is the one that fixes the coding style.  This is inherently very
> > manual.
> They need to be merged separately too since the author is often
> different on each patch.
>

Why does the authors matter. There is no reason a patchset or PR needs to
be squashed into a single commit, they just should not be broken along the
way.

Also order in a patch set is usually defined by a number prefix for example
this is how it is defined by the Linux kernel, but is inline with most
projects that do mailing list patches.

https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html#the-canonical-patch-format


There is really nothing so unique about this project that we need to get
too creative.

--Brennan

>

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

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

>
>> If they are related / dependent on each other, then I think those
>> kinds of patchsets should be encapsulated in one branch.
>
> The need to be applied and committed in sequence.  Sometimes the final 
> patch is the one that fixes the coding style.  This is inherently very 
> manual.
They need to be merged separately too since the author is often 
different on each patch.

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[Justin Mclean <ju...@me.com.INVALID>]

Hi,

> The style fix should be in one patch not the separated patch. If the
> new code has the style problem, contributor should fix it and resend
> PR again.

While generally if you broke something (like a build) you should be the one to fix it, it’s more encouraging to help out new contributors. In some cases that may mean a committer or PMC member needs to fix a patch to show them what to do in future patches. The users and contributors should be your primary focus. Telling someone to jump through hoops they don’t understand may drive them away, helping them understand what required for future patches/PRs is often better. A poor quality patch can be better than no patch at all, as it may contain a great idea or an important fix, people can collaborate and fine tune it and fix it before it is committed / merged.

> Nobody has the right bypass the criticia we will define in the
> workflow document and merge the patch(even it just fix the style
> issue) directly.

Like all guidelines there may be some cases, when this needs to be bypassed e.g urgent security issue or broken build. It certainly should come with a good explanation to why this was needed, but it's better to follow good guideline than have absolute rules.

Thanks,
Justin

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[David Sidrane <da...@nscdg.com>]

I think there may be 2 schools of thought on style fixes. Imagine up  front
creating a commit before changing code in files that fixes ONLY all of the
style issues.  Essentially this commit should contain only white space
changes. If the commit is marked as such.  It can be mechanically validated
by comparing the binary result of the build Before & After the application
Of the style commit.

 The next commit in the set would have the actual changes to the code. This
is where experts in the subject matter can add value reviewing it.

Monster PRs ( Lots of files changed with lots of lines of changed) are very
difficult to review. If the majority of the changes are style only. The
above method  Reduces the possibility of error  While minimizing the burden
on subject matter experts.


On Tue, Dec 24, 2019, 6:18 PM Xiang Xiao <xi...@gmail.com> wrote:

> On Wed, Dec 25, 2019 at 6:52 AM Gregory Nutt <sp...@gmail.com> wrote:
> >
> >
> > > If they are related / dependent on each other, then I think those
> > > kinds of patchsets should be encapsulated in one branch.
> >
> > The need to be applied and committed in sequence.  Sometimes the final
> > patch is the one that fixes the coding style.  This is inherently very
> > manual.
> >
>
> The style fix should be in one patch not the separated patch. If the
> new code has the style problem, contributor should fix it and resend
> PR again.
> If the code base has the style issue, we should send new PR to fix the
> whole style issue.
>
> Of course, some committer may want to help fix the issue. It's fine,
> but the new change still need pass all check and reviewed by other
> committer before merge.
> Nobody has the right bypass the criticia we will define in the
> workflow document and merge the patch(even it just fix the style
> issue) directly.
>

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[Xiang Xiao <xi...@gmail.com>]

On Wed, Dec 25, 2019 at 6:52 AM Gregory Nutt <sp...@gmail.com> wrote:
>
>
> > If they are related / dependent on each other, then I think those
> > kinds of patchsets should be encapsulated in one branch.
>
> The need to be applied and committed in sequence.  Sometimes the final
> patch is the one that fixes the coding style.  This is inherently very
> manual.
>

The style fix should be in one patch not the separated patch. If the
new code has the style problem, contributor should fix it and resend
PR again.
If the code base has the style issue, we should send new PR to fix the
whole style issue.

Of course, some committer may want to help fix the issue. It's fine,
but the new change still need pass all check and reviewed by other
committer before merge.
Nobody has the right bypass the criticia we will define in the
workflow document and merge the patch(even it just fix the style
issue) directly.

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[David Sidrane <da...@nscdg.com>]

I think you have landed on the very motivation behind, and the very benefit
that pull requests offer over patches. The submitter(s) is/are the one(s)
who know how the pieces fit together. It is they that are responsible for
creating something that's mergeabel. A set or PRs with a "No conflicts"
status.

Just imagine the streams of patches that come in chunks as individual PR.
If after 1 PR comes in it causes a second PR of the groups to become
conflicted. The onus is on the submitter to rebase and resolve the issues.

On past projects that I have worked on the process was to carry patches and
apply them in the build. This gave me a sense of security in that I could
see all of the deltas from upstream in the patch set.  Then other members
of the team suggested that we carry these changes as commits on top of (re
based on) upstream.  This left me totally uncomfortable because it
completely changed the why I was working. But what I learned was the key
benefit of  this methodology is that: it is far better to find the
conflicts during a rebase in a git re base session then it is to try to
decipher failed patch applications in a build. After doing it with this re
based workflow I realized  the benefits. It was super uncomfortable at 1st
but now it's 2nd nature and much, much more efficient not to mention
foolproof.

This is essentially what happens when A PR Has conflicts and the submitter
is asked to resolve them. They re base on the current master and they are
very quickly able to ensure their changes are now proper in the new context.

David

On Tue, Dec 24, 2019, 2:52 PM Gregory Nutt <sp...@gmail.com> wrote:

>
> > If they are related / dependent on each other, then I think those
> > kinds of patchsets should be encapsulated in one branch.
>
> The need to be applied and committed in sequence.  Sometimes the final
> patch is the one that fixes the coding style.  This is inherently very
> manual.
>
>
>

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

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

> If they are related / dependent on each other, then I think those
> kinds of patchsets should be encapsulated in one branch.

The need to be applied and committed in sequence.  Sometimes the final 
patch is the one that fixes the coding style.  This is inherently very 
manual.

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[Nathan Hartman <ha...@gmail.com>]

On Tue, Dec 24, 2019 at 3:44 PM Gregory Nutt <sp...@gmail.com> wrote:
> Many branches would be awkward on patch sets that consist of a dozen or
> so individual patches that cannot be squashed together because they have
> different authors.  We get lots of large patch sets from Xiaomi like
> that.  To make things more complex, there is an ordering in which the
> patches must be apply.  A given patch may not apply until a preceding
> patch by a different author is first merged.

If they are related / dependent on each other, then I think those
kinds of patchsets should be encapsulated in one branch.

Nathan

RE: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[David Sidrane <Da...@nscdg.com>]

It is OK

Look at microsoft/vscode

58,891 commits
 360 branches
 0 packages
 145 releases
 1,048 contributors
 MIT

The pr-branches are deleted on merge.
The relasease branches foreverever
WIP branches are there until merged, or superseded.

-----Original Message-----
From: Gregory Nutt [mailto:spudaneco@gmail.com]
Sent: Tuesday, December 24, 2019 12:44 PM
To: dev@nuttx.apache.org
Subject: Re: Software release life cycle choices could have implications on
workflow (was RE: Single Committer)


> Git's claim to fame is supposed to be the cheapness of branches. What if
> each PR becomes its own branch and then it either: (a) gets worked on, (b)
> applied to master, or (c) deleted?

I think that would work fine.  We need to verify that we can actually
change the PR base, but if so that would keep things more independent.

Perhaps it could help us with patches where sometimes there are patches
that depend on each other or interact with other because they modify the
same area of code.  Using git to help merge patches would be easier if
the patches were on different branches.

We would probably need some encoding of branch names to associate them
with patches or PRs.

Many branches would be awkward on patch sets that consist of a dozen or
so individual patches that cannot be squashed together because they have
different authors.  We get lots of large patch sets from Xiaomi like
that.  To make things more complex, there is an ordering in which the
patches must be apply.  A given patch may not apply until a preceding
patch by a different author is first merged.

The number should not be a big concern.  Over time, we will end up with
100's of branches eventually.  Each release will probably have to be on
a branch.

Greg

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

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

> Git's claim to fame is supposed to be the cheapness of branches. What if
> each PR becomes its own branch and then it either: (a) gets worked on, (b)
> applied to master, or (c) deleted?

I think that would work fine.  We need to verify that we can actually 
change the PR base, but if so that would keep things more independent.

Perhaps it could help us with patches where sometimes there are patches 
that depend on each other or interact with other because they modify the 
same area of code.  Using git to help merge patches would be easier if 
the patches were on different branches.

We would probably need some encoding of branch names to associate them 
with patches or PRs.

Many branches would be awkward on patch sets that consist of a dozen or 
so individual patches that cannot be squashed together because they have 
different authors.  We get lots of large patch sets from Xiaomi like 
that.  To make things more complex, there is an ordering in which the 
patches must be apply.  A given patch may not apply until a preceding 
patch by a different author is first merged.

The number should not be a big concern.  Over time, we will end up with 
100's of branches eventually.  Each release will probably have to be on 
a branch.

Greg

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[Brennan Ashton <ba...@brennanashton.com>]

>
>
>
>
> Git's claim to fame is supposed to be the cheapness of branches. What if
> each PR becomes its own branch and then it either: (a) gets worked on, (b)
> applied to master, or (c) deleted?
>

As I have already said PRs automatically are branches in GitHub even if
they are not shown in the GitHub UI (why would they, they are shown as a PR)


https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/checking-out-pull-requests-locally

--Brennan

>

RE: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[David Sidrane <Da...@nscdg.com>]

The Aha moment has arrived - You got - What is your github name?

-----Original Message-----
From: Nathan Hartman [mailto:hartman.nathan@gmail.com]
Sent: Tuesday, December 24, 2019 12:28 PM
To: dev@nuttx.apache.org
Subject: Re: Software release life cycle choices could have implications on
workflow (was RE: Single Committer)

On Tue, Dec 24, 2019 at 3:15 PM Gregory Nutt <sp...@gmail.com> wrote:

>
> >> Also, is there a way to take a PR against master and apply it as a
> >> branch?
> >
> > I generally do that by taking the PR as a patch, then applying the
> > patch on a branch.
> >
> > But it looks like you can do that with github:
> >
> https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/changing-the-base-branch-of-a-pull-request
> >
> We will need to experiment with that, but if it works then we could
> continue to use the dev branch with no PR problems.  If we get a PR on
> master, we could just change the base to dev.
>
> That, of course, depends on keeping dev fairly clean and freshly rebased
> to master.  If things are going to linger on dev, we should move them to
> another branch.


Git's claim to fame is supposed to be the cheapness of branches. What if
each PR becomes its own branch and then it either: (a) gets worked on, (b)
applied to master, or (c) deleted?

Nathan

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[Nathan Hartman <ha...@gmail.com>]

On Tue, Dec 24, 2019 at 3:15 PM Gregory Nutt <sp...@gmail.com> wrote:

>
> >> Also, is there a way to take a PR against master and apply it as a
> >> branch?
> >
> > I generally do that by taking the PR as a patch, then applying the
> > patch on a branch.
> >
> > But it looks like you can do that with github:
> >
> https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/changing-the-base-branch-of-a-pull-request
> >
> We will need to experiment with that, but if it works then we could
> continue to use the dev branch with no PR problems.  If we get a PR on
> master, we could just change the base to dev.
>
> That, of course, depends on keeping dev fairly clean and freshly rebased
> to master.  If things are going to linger on dev, we should move them to
> another branch.


Git's claim to fame is supposed to be the cheapness of branches. What if
each PR becomes its own branch and then it either: (a) gets worked on, (b)
applied to master, or (c) deleted?

Nathan

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

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

>> Also, is there a way to take a PR against master and apply it as a 
>> branch?
>
> I generally do that by taking the PR as a patch, then applying the 
> patch on a branch.
>
> But it looks like you can do that with github: 
> https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/changing-the-base-branch-of-a-pull-request
>
We will need to experiment with that, but if it works then we could 
continue to use the dev branch with no PR problems.  If we get a PR on 
master, we could just change the base to dev.

That, of course, depends on keeping dev fairly clean and freshly rebased 
to master.  If things are going to linger on dev, we should move them to 
another branch.

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

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

> Also, is there a way to take a PR against master and apply it as a branch?

I generally do that by taking the PR as a patch, then applying the patch 
on a branch.

But it looks like you can do that with github: 
https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/changing-the-base-branch-of-a-pull-request

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[Nathan Hartman <ha...@gmail.com>]

On Tue, Dec 24, 2019 at 9:47 AM Gregory Nutt <sp...@gmail.com> wrote:

>
> I have some doubts:  If an an end-user clones or forks the change, it
> would still default to creating only the master branch.  You would not
> want users working on the master branch, you would want them to be
> working in the stable branch.  There could potentially bad changes on
> the master.


I haven't yet studied what David wrote in response, but I just wanted to
say:

This is why, in the Confluence workflow document, I want to spell out:
* How to obtain the code
* What steps to take before working on a PR

Namely, those steps are: to clone git and then immediately create a branch
to work on any changes. (I never code directly on master.)

If someone doesn't do that, I think we'd need to point them to that
document.

Also, is there a way to take a PR against master and apply it as a branch?

Nathan

RE:Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[David Sidrane <Da...@nscdg.com>]

Hi Greg,



I have tried to answer some of your questions. See below:



>-----Original Message-----
>From: Gregory Nutt [mailto:spudaneco@gmail.com]
>Sent: Tuesday, December 24, 2019 6:48 AM
>To: dev@nuttx.apache.org
>Subject: Re: Software release life cycle choices could have implications
on workflow (was RE: Single Committer)





>>> An alternative way could be make master/trunk branch a dev branch and
allow

>>> all PRs to checked in, at the same time, maintain a stable branch which
you

>>> can cut release (as release manager) and pick up PRs that you carefully

>>> reviewed. - This is the Apache way and I guess can achieve the same
goal.



>That would simplify accepting PRs since the uniformed will probably

>continue to submit against master.



*[DBS] The default branch is set-able *



>This would make that behavior

>workable.  Semantically, I would have to wrap my head around the notion

>that the master is not the master but a development branch.  But even

>old dogs can learn new tricks with enough time.



>I can see how this works well into a release strategy.  But what about

>uses who want to work from clones or forks?



>I have some doubts:  If an an end-user clones or forks the change, it

>would still default to creating only the master branch.



*[DBS]  No. It is a clone\fork of ALL the branches in the repo.*



*This was a fork:*

*[image: cid:img003.jpg@01D5BA3A.F15D7100]*



>You would want users working on the master branch, you would want them to
be

>working in the stable branch.  There could potentially bad changes on

the master.



*[DBS] It is their choice to be on the Bleading edge or a stable offshoot*



*We will have give tools some special consideration because of this - a
release will have a older copy of nxstyle*



>Is there a way to force the initial branch to be the stable branch

instead of master.



*[DBS] Yes but that is not the way it should be done as the default branch
is what the PR will default against. *

*In this case development is our master and master should be the default.*



>If they make changes that they want to submit on the stable branch

>branch, it seems to me that you have essentially the same communication

>problem.  They would need to transfer their changes to the master branch

>before creating the PR.  Is that right?





*[DBS] Nope - if say we have release-nuttx-9.2.0 released branch and they
have a fix on it.*

*They have a PR against nuttx-9.2.0 (but is branch protected) We can
discuss the change and start a new branch nuttx-9.2.1-RC00 and then have
them move the PR there *

*we can do it ourselves. Pull the PR to you local repo (see githup command
line on Pr) then push to nuttx-9.2.1-RC00*

*This is the why naming matters.*



*[DBS] Most git users understand the default work flow, but a README.MD
could offer the correct*

*choice of Branches and work flow  (as can a .gitmodules when set up
correctly) but deviating from the norms*

*Is NOT a good idea as it will cause issues for everyone.*



>Another nit and this is just probably due to my fumble fingers: I often

>get weird things happening when I add changes to branches, then squash

>them into the stable branch (master in this case).



*[**DBS] Use the github in chrome (WEBUI) - it make the job simple: to
update a branch, rebase, and merge. It also has a directions to do it on
the command line correctly.*



>At that point the histories of the two branches have diverged.  I can
usually reuse the

>old branch by rebasing and pushing the branch with --force.  But the

>history will still not be 100% the same as the stable branch.  If I lose

>confidence in the content of a development branch (which is fairly

>often), I usually just delete the branch and recreate it clean.  But we

>cannot do that if master is the stable.  We can't delete master can we?

>There are ways to force to branches to be identical (in both content and

>history) but I would have to get used to doing that.



*[DBS] You can choose to use branch rebase work flow - it will be ==
[source branch] + Just your changes on top.*

*Interactively rebase it (rebase -i master and clean it up) *

*- it will dump the merge commits on your branch - we want to avoid them.*

*see mv-changes *https://github.com/MikhailGolubtsov/git-mv-changes





*Force push:*

*1) Only to your own braches (I always fetch and check the remote) or just
rebase on it.*

*2) Only on a shared branch after coordination with the team. Ask them to
push all their commit then (Do 1 above)*

* Clean it up force push. The raise the "All clear"*

*3) Never force push to master. It should be branch protected. *



>It seems that this strategy adds some nice simplifications in one area

>but at least raises some questions in others.  Perhaps GIT power users

>could answer all of those questions (but let's place not clutter up the

>list by solving the full workflow here.  Please contribute your thoughts

>directly as comments at

>
https://cwiki.apache.org/confluence/display/NUTTXTEST/Code+Contribution+Workflow+--+Brennan+Ashton
).



I hope this helps



David

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

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

>> An alternative way could be make master/trunk branch a dev branch and allow
>> all PRs to checked in, at the same time, maintain a stable branch which you
>> can cut release (as release manager) and pick up PRs that you carefully
>> reviewed. - This is the Apache way and I guess can achieve the same goal.

That would simplify accepting PRs since the uniformed will probably 
continue to submit against master.  This would make that behavior 
workable.  Semantically, I would have to wrap my head around the notion 
that the master is not the master but a development branch.  But even 
old dogs can learn new tricks with enough time.

I can see how this works well into a release strategy.  But what about 
uses who want to work from clones or forks?

I have some doubts:  If an an end-user clones or forks the change, it 
would still default to creating only the master branch.  You would not 
want users working on the master branch, you would want them to be 
working in the stable branch.  There could potentially bad changes on 
the master.

Is there a way to force the initial branch to be the stable branch 
instead of master.

If they make changes that they want to submit on the stable branch 
branch, it seems to me that you have essentially the same communication 
problem.  They would need to transfer their changes to the master branch 
before creating the PR.  Is that right?

Another nit and this is just probably due to my fumble fingers: I often 
get weird things happening when I add changes to branches, then squash 
them into the stable branch (master in this case).  At that point the 
histories of the two branches have diverged.  I can usually reuse the 
old branch by rebasing and pushing the branch with --force.  But the 
history will still not be 100% the same as the stable branch.  If I lose 
confidence in the content of a development branch (which is fairly 
often), I usually just delete the branch and recreate it clean.  But we 
cannot do that if master is the stable.  We can't delete master can we?  
There are ways to force to branches to be identical (in both content and 
history) but I would have to get used to doing that.

It seems that this strategy adds some nice simplifications in one area 
but at least raises some questions in others.  Perhaps GIT power users 
could answer all of those questions (but let's place not clutter up the 
list by solving the full workflow here.  Please contribute your thoughts 
directly as comments at 
https://cwiki.apache.org/confluence/display/NUTTXTEST/Code+Contribution+Workflow+--+Brennan+Ashton).

Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[David Sidrane <Da...@nscdg.com>]

>An alternative way could be make master/trunk branch a dev branch and allow
>all PRs to checked in, at the same time, maintain a stable branch which you
>can cut release (as release manager) and pick up PRs that you carefully
>reviewed. - This is the Apache way and I guess can achieve the same goal.

+1
I think because stable says what it is. Junping suggestion is an excellent
one.

I am not endorsing this tool, but it is really slick, even just to get the
concepts from the video.
(in the vedio replace `master` with `stable` with and `development` with
master)

https://blog.axosoft.com/gitflow/


Some questions to discuss as we move forward (no need for immediate
discussion)?

What will our Software release life cycle[1] look like?

Do we choose to do LTS[2]?
Do we do release branching?
Do we do backports [3] on to release candidates[1]?
Do we do hot fixes[5]?

David

[1] https://en.wikipedia.org/wiki/Software_release_life_cycle
[2] LTS is an abbreviation for “Long Term Support”.
[3] https://en.wikipedia.org/wiki/Backporting
[4]
https://softwareengineering.stackexchange.com/questions/288935/difference-between-hotfix-and-bugfix

-----Original Message-----
From: 俊平堵 [mailto:junping_du@apache.org]
Sent: Monday, December 23, 2019 6:27 PM
To: dev@nuttx.apache.org
Subject: Re: Single Committer

bq. I would create a dev branch and expect all PRs to be against that dev
branch.
An alternative way could be make master/trunk branch a dev branch and allow
all PRs to checked in, at the same time, maintain a stable branch which you
can cut release (as release manager) and pick up PRs that you carefully
reviewed. - This is the Apache way and I guess can achieve the same goal.

Thanks,

Junping

Gregory Nutt <sp...@gmail.com> 于2019年12月24日周二 上午8:51写道：

> Recent events have made me reconsider some decisions I made.  I threw
> off the single committer mantle when I saw the abuse of privilege in the
> repositories.  If the PPMC agrees to it, I will take up that role again.
>
> But let's be frank.  Here is what I think that means:
>
>   * I would be sole committer of changes.  The repositories would have
>     to be treated as read-only just as back in the Bitbucket days.
>   * I would grandfather in the i.MXRT changes.
>   * I will decline all workflow related changes until workflow
>     requirements are established (that is my only real motivation for
>     suggesting this:  To make certain that we have proper requirements
>     in place before we accept PX4 workflow into our repositories.  We
>     need to do this right and I am willing to protect the repositories
>     until the workflow requirements are established.  I expect that to
>     take about two weeks.)
>   * I would create a dev branch and expect all PRs to be against that
>     dev branch.
>   * As soon as the PPMC is confident that it has the processes in place
>     to handle the commit workload I will gladly relinquish this role.
>   * THIS IS NOT THE APACHE WAY.  This is an interim dictatorship role to
>     expedite the avalanche of commits expected after the holidays.
>
> If any of this concerns people, please "Just Say No."  I am not married
> to the idea and I am not forcefully advocating it.  This is what people
> wanted me to do a few days ago and if I can protect our right to define
> the workflow, then I will do it.  For me it is a sacrifice that I would
> take with no pleasure in.
>
> Pros:  This will provide project continuity until the PPMC is fully
> functional.  Having workflow requirements will be a huge step in that
> direction.  People stressed about the commit process can relax with
> confidence.  This will protect the code base from premature work flow
> changes until we have an understanding of what we want.  No harm is done
> by deferring workflow changes until we as a team are prepared to deal
> with them.
>
> Cons:  This is not the Apache way.  People who are trying to bulldoze
> the PX4 work flow into the repositories will hate the idea.  Mentors
> will hate the idea.  An approach more consistent with the Apache way
> would just be to let the chaos prevail.  That is fine with me too as
> long as we do not let PX4 advocates take away our group right to define
> our own workflow.  We can still just put all workflow changes on hold
> until we have the requirements in hand.
>
> I am not pushing anything.  Think about it and let me know what you
> would like to do.
>
> Greg
>
>
>

Re: Single Committer

[俊平堵 <ju...@apache.org>]

bq. I would create a dev branch and expect all PRs to be against that dev
branch.
An alternative way could be make master/trunk branch a dev branch and allow
all PRs to checked in, at the same time, maintain a stable branch which you
can cut release (as release manager) and pick up PRs that you carefully
reviewed. - This is the Apache way and I guess can achieve the same goal.

Thanks,

Junping

Gregory Nutt <sp...@gmail.com> 于2019年12月24日周二 上午8:51写道：

> Recent events have made me reconsider some decisions I made.  I threw
> off the single committer mantle when I saw the abuse of privilege in the
> repositories.  If the PPMC agrees to it, I will take up that role again.
>
> But let's be frank.  Here is what I think that means:
>
>   * I would be sole committer of changes.  The repositories would have
>     to be treated as read-only just as back in the Bitbucket days.
>   * I would grandfather in the i.MXRT changes.
>   * I will decline all workflow related changes until workflow
>     requirements are established (that is my only real motivation for
>     suggesting this:  To make certain that we have proper requirements
>     in place before we accept PX4 workflow into our repositories.  We
>     need to do this right and I am willing to protect the repositories
>     until the workflow requirements are established.  I expect that to
>     take about two weeks.)
>   * I would create a dev branch and expect all PRs to be against that
>     dev branch.
>   * As soon as the PPMC is confident that it has the processes in place
>     to handle the commit workload I will gladly relinquish this role.
>   * THIS IS NOT THE APACHE WAY.  This is an interim dictatorship role to
>     expedite the avalanche of commits expected after the holidays.
>
> If any of this concerns people, please "Just Say No."  I am not married
> to the idea and I am not forcefully advocating it.  This is what people
> wanted me to do a few days ago and if I can protect our right to define
> the workflow, then I will do it.  For me it is a sacrifice that I would
> take with no pleasure in.
>
> Pros:  This will provide project continuity until the PPMC is fully
> functional.  Having workflow requirements will be a huge step in that
> direction.  People stressed about the commit process can relax with
> confidence.  This will protect the code base from premature work flow
> changes until we have an understanding of what we want.  No harm is done
> by deferring workflow changes until we as a team are prepared to deal
> with them.
>
> Cons:  This is not the Apache way.  People who are trying to bulldoze
> the PX4 work flow into the repositories will hate the idea.  Mentors
> will hate the idea.  An approach more consistent with the Apache way
> would just be to let the chaos prevail.  That is fine with me too as
> long as we do not let PX4 advocates take away our group right to define
> our own workflow.  We can still just put all workflow changes on hold
> until we have the requirements in hand.
>
> I am not pushing anything.  Think about it and let me know what you
> would like to do.
>
> Greg
>
>
>

Re: Single Committer

[Adam Feuer <ad...@starcat.io>]

+1

On Tue, Dec 24, 2019 at 5:18 AM Alan Carvalho de Assis <ac...@gmail.com>
wrote:

> +1
>
> On Monday, December 23, 2019, Gregory Nutt <sp...@gmail.com> wrote:
> > Recent events have made me reconsider some decisions I made.  I threw off
> the single committer mantle when I saw the abuse of privilege in the
> repositories.  If the PPMC agrees to it, I will take up that role again.
> >
> > But let's be frank.  Here is what I think that means:
> >
> >  * I would be sole committer of changes.  The repositories would have
> >    to be treated as read-only just as back in the Bitbucket days.
> >  * I would grandfather in the i.MXRT changes.
> >  * I will decline all workflow related changes until workflow
> >    requirements are established (that is my only real motivation for
> >    suggesting this:  To make certain that we have proper requirements
> >    in place before we accept PX4 workflow into our repositories.  We
> >    need to do this right and I am willing to protect the repositories
> >    until the workflow requirements are established.  I expect that to
> >    take about two weeks.)
> >  * I would create a dev branch and expect all PRs to be against that
> >    dev branch.
> >  * As soon as the PPMC is confident that it has the processes in place
> >    to handle the commit workload I will gladly relinquish this role.
> >  * THIS IS NOT THE APACHE WAY.  This is an interim dictatorship role to
> >    expedite the avalanche of commits expected after the holidays.
> >
> > If any of this concerns people, please "Just Say No."  I am not married
> to the idea and I am not forcefully advocating it.  This is what people
> wanted me to do a few days ago and if I can protect our right to define the
> workflow, then I will do it.  For me it is a sacrifice that I would take
> with no pleasure in.
> >
> > Pros:  This will provide project continuity until the PPMC is fully
> functional.  Having workflow requirements will be a huge step in that
> direction.  People stressed about the commit process can relax with
> confidence.  This will protect the code base from premature work flow
> changes until we have an understanding of what we want.  No harm is done by
> deferring workflow changes until we as a team are prepared to deal with
> them.
> >
> > Cons:  This is not the Apache way.  People who are trying to bulldoze the
> PX4 work flow into the repositories will hate the idea.  Mentors will hate
> the idea.  An approach more consistent with the Apache way would just be to
> let the chaos prevail.  That is fine with me too as long as we do not let
> PX4 advocates take away our group right to define our own workflow.  We can
> still just put all workflow changes on hold until we have the requirements
> in hand.
> >
> > I am not pushing anything.  Think about it and let me know what you would
> like to do.
> >
> > Greg
> >
> >
> >
>


-- 
Adam Feuer <ad...@starcat.io>

Re: Single Committer

[Alan Carvalho de Assis <ac...@gmail.com>]

+1

On Monday, December 23, 2019, Gregory Nutt <sp...@gmail.com> wrote:
> Recent events have made me reconsider some decisions I made.  I threw off
the single committer mantle when I saw the abuse of privilege in the
repositories.  If the PPMC agrees to it, I will take up that role again.
>
> But let's be frank.  Here is what I think that means:
>
>  * I would be sole committer of changes.  The repositories would have
>    to be treated as read-only just as back in the Bitbucket days.
>  * I would grandfather in the i.MXRT changes.
>  * I will decline all workflow related changes until workflow
>    requirements are established (that is my only real motivation for
>    suggesting this:  To make certain that we have proper requirements
>    in place before we accept PX4 workflow into our repositories.  We
>    need to do this right and I am willing to protect the repositories
>    until the workflow requirements are established.  I expect that to
>    take about two weeks.)
>  * I would create a dev branch and expect all PRs to be against that
>    dev branch.
>  * As soon as the PPMC is confident that it has the processes in place
>    to handle the commit workload I will gladly relinquish this role.
>  * THIS IS NOT THE APACHE WAY.  This is an interim dictatorship role to
>    expedite the avalanche of commits expected after the holidays.
>
> If any of this concerns people, please "Just Say No."  I am not married
to the idea and I am not forcefully advocating it.  This is what people
wanted me to do a few days ago and if I can protect our right to define the
workflow, then I will do it.  For me it is a sacrifice that I would take
with no pleasure in.
>
> Pros:  This will provide project continuity until the PPMC is fully
functional.  Having workflow requirements will be a huge step in that
direction.  People stressed about the commit process can relax with
confidence.  This will protect the code base from premature work flow
changes until we have an understanding of what we want.  No harm is done by
deferring workflow changes until we as a team are prepared to deal with
them.
>
> Cons:  This is not the Apache way.  People who are trying to bulldoze the
PX4 work flow into the repositories will hate the idea.  Mentors will hate
the idea.  An approach more consistent with the Apache way would just be to
let the chaos prevail.  That is fine with me too as long as we do not let
PX4 advocates take away our group right to define our own workflow.  We can
still just put all workflow changes on hold until we have the requirements
in hand.
>
> I am not pushing anything.  Think about it and let me know what you would
like to do.
>
> Greg
>
>
>