You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nuttx.apache.org by Gregory Nutt <sp...@gmail.com> on 2019/12/22 16:14:26 UTC
[DISCUSS] Simple Workflow Proposal
Let's get everyone's thoughts on the table
> I did not call for a vote because I did not think I could as I'm just a
> community member, I would like my proposal formally voted it on as is.
>
>
> As for the two concerns that I saw raised.
>
> 1) The timeline. Two weeks over the holiday to come to a formal agreement
> is going to be tough and I also don't think just because we have a path
> forward people will stop caring about proposing a better solution. From
> what I'm seeing the longer term proposal will likely get into the weeds of
> tooling around CI email patches etc... These take weeks to settle on. I
> trust the intentions of the people in the project and do not see a need to
> bind them to a timeline to build this out.
>
> 2) Why cut corners. Personally I don't see this as cutting corners I think
> this will in practice get us 90% of the way there and get us back into a
> cadence of improving the software. I trust the project members will use
> judgement within the structure and will actively move the project along to
> better structure.
>
Re: [DISCUSS] Simple Workflow Proposal - not so simple?
Posted by Disruptive Solutions <di...@gmail.com>.
+1 keep it simple
Verstuurd vanaf mijn iPhone
> Op 23 dec. 2019 om 17:06 heeft Sebastien Lorquet <se...@lorquet.fr> het volgende geschreven:
>
> OK.
>
> That is too much email for me, I just cant follow and understand all these
> discussions anymore. Almost 300 messages among multiple overlapping threads full
> of heated opinions in 2-3 days is insane.
>
> I just cant dedicate enough time reading any more of this. I have other things
> to do than trying to understand these multiple rebooted workflows proposals that
> span days (and nights!) of discussions.
>
> So I can't vote on anything. I dont understand what is going on anymore. I'm
> lost. Probably not important since I did not ask and choose to be a committer,
> but since opinions are asked, here are mine.
>
>
> Can someone please sum up what we have to decide in a short email, less than a page?
>
>
> To be honest, viewed from here, I just seem to understand that some opinions are
> very pushy and are trying to act before decisions are settled.
>
> Also some kind of extra-heavy decisions on a full process NO ONE has been able
> to install up to now for years.
>
> I just want to say that going to apache should not be an occasion to try to
> force the process of someone liking or another just because not everyone has an
> equally stronger opinion and voice and free time for emails.
>
> On my part, seeing too hard pushes in any specific direction just rings an alarm
> bell to be extra-cautious.
>
>
> I think the process should be as simple as possible, and improved later. Just
> select the absolute bare minimum that could start to work and discard everything
> else so this project can work again.
>
>
> We are using git so things are reversable, right? We will not get this right the
> first time, so lets keep room for errors. If I understand correctly the
> bitbucket repositories are still in a consistent pre-apache state and the apache
> ones can be reset? or is the apache->bb mirroring already active?
>
> Also, I did not see a notification that the BB repositories had been frozen.
>
>
> These workflow and reviewing discussions are just killing extremely valuable
> time for everyone without visible progress (because too many messages).
>
>
> So again, I would like to read a very short state of the union at monday
> 2019-Dec-23 17:01 UTC+1.
>
> Otherwise I cant make decisions. And I guess I am not the only one.
>
>
> Sebastien
>
>
>> Le 22/12/2019 à 17:25, Gregory Nutt a écrit :
>>
>>> Let's get everyone's thoughts on the table
>>
>> I suppose that we should keep the discussion for 72 hours then call the vote.
>> We need to allow time for everyone to comment and with the holidays, we may
>> not be able to get good feedback. Should we still call a vote if people are
>> not participating?
>>
>> I will call the vote on your behalf in 72 hours.
>>
>> Greg
>>
>>
>>
>
Re: [DISCUSS] Simple Workflow Proposal - not so simple?
Posted by Gregory Nutt <sp...@gmail.com>.
> I think the process should be as simple as possible, and improved later. Just
> select the absolute bare minimum that could start to work and discard everything
> else so this project can work again.
Depends on what you mean by simple. Using some less-than-simple tools
can make the workflow very simple. I believe that we need to establish
a set of very high-level workflow requirements. Then we have the top
level roadmap that could guide a simple initial implementation and
could be improved later with the same objective in mind.
That does not preclude any change in direction, requirements can change
too. But the roadmap would be controlled by consensus approval (not the
implementation! only the roadmap). Such a roadmap would unify our
mindset and unify our sense of purpose. There is anarchy, rogue
behaviors, and distrust now that could be fixed by a simple
roadmap/high-level requirements that makes sense to everyone.
Re: [DISCUSS] Simple Workflow Proposal - not so simple?
Posted by Gregory Nutt <sp...@gmail.com>.
Agreed.. It is painful and awkward and I am not so optimistic at the
moment. We will have to give it more time and see if people and learn
to cooperate in groups or not.
> Also, I did not see a notification that the BB repositories had been frozen.
https://groups.google.com/forum/#!topic/nuttx/ISmgZAftm4o
Re: [DISCUSS] Simple Workflow Proposal - not so simple?
Posted by Gregory Nutt <sp...@gmail.com>.
> Brennan created a page in the Confluence for the workflow document. I
> know that only committers can edit the Confluence wiki directly but
> that is not a problem: Anyone can write some text and email it to this
> list, and a committer can edit it into the Confluence page. (Hint:
> People who participate often become good candidates to become
> committers too!)
>
> The Workflow Work-In-Progress Confluence Page is here:
> https://cwiki.apache.org/confluence/display/NUTTXTEST/Code+Contribution+Workflow+--+Brennan+Ashton
There is a thread on
https://mail-archives.apache.org/mod_mbox/nuttx-dev/ called [CALL for
TOP Down workflow Requirements]. Currently it contains all workflow
thoughts. Please feel free to comment there mostly forwarded from other
discussion threads. There is not a lot there :'(, but that is what we
have to work with. We should probably keep discussion as terse as
possiblethere. These threads with 100's of responses are, as you note,
pretty difficult to follow. If we keep things terse then there is less
chance that you input will be lost in the clutter.
Re: [DISCUSS] Simple Workflow Proposal - not so simple?
Posted by Disruptive Solutions <di...@gmail.com>.
Ow and:
https://gerrit-review.googlesource.com/Documentation/intro-user.html
And not about tools... but they have implemented workflow...
Op ma 23 dec. 2019 om 23:24 schreef Disruptive Solutions <
disruptivesolutionsnl@gmail.com>:
> Did you look at https://www.atlassian.com/nl/software/crucible ??
> And: https://www.perforce.com/solutions/static-analysis
>
> https://www.atlassian.com/git/tutorials/comparing-workflows
>
> The concept "The Centralized Workflow" was the "old" workflow, but now
> maybe the concept "Feature branching" is maybe a way to go? Say there are
> people working on "features" in Nuttx? Drivers, Kernel, Apps, etc?? Or is
> "Gitflow" already" choosen?
>
> Ben
>
>
>
>
>
> Op ma 23 dec. 2019 om 20:27 schreef Justin Mclean
> <ju...@me.com.invalid>:
>
>> Hi,
>>
>> > Brennan created a page in the Confluence for the workflow document. I
>> > know that only committers can edit the Confluence wiki directly but
>> > that is not a problem: Anyone can write some text and email it to this
>> > list, and a committer can edit it into the Confluence page.
>>
>> Non committers can also ask for access.
>>
>> Thanks,
>> Justin
>>
>
Re: [DISCUSS] Simple Workflow Proposal - not so simple?
Posted by Disruptive Solutions <di...@gmail.com>.
Did you look at https://www.atlassian.com/nl/software/crucible ??
And: https://www.perforce.com/solutions/static-analysis
https://www.atlassian.com/git/tutorials/comparing-workflows
The concept "The Centralized Workflow" was the "old" workflow, but now
maybe the concept "Feature branching" is maybe a way to go? Say there are
people working on "features" in Nuttx? Drivers, Kernel, Apps, etc?? Or is
"Gitflow" already" choosen?
Ben
Op ma 23 dec. 2019 om 20:27 schreef Justin Mclean
<ju...@me.com.invalid>:
> Hi,
>
> > Brennan created a page in the Confluence for the workflow document. I
> > know that only committers can edit the Confluence wiki directly but
> > that is not a problem: Anyone can write some text and email it to this
> > list, and a committer can edit it into the Confluence page.
>
> Non committers can also ask for access.
>
> Thanks,
> Justin
>
Re: [DISCUSS] Simple Workflow Proposal - not so simple?
Posted by Justin Mclean <ju...@me.com.INVALID>.
Hi,
> Brennan created a page in the Confluence for the workflow document. I
> know that only committers can edit the Confluence wiki directly but
> that is not a problem: Anyone can write some text and email it to this
> list, and a committer can edit it into the Confluence page.
Non committers can also ask for access.
Thanks,
Justin
Re: [DISCUSS] Simple Workflow Proposal - not so simple?
Posted by Nathan Hartman <ha...@gmail.com>.
On Mon, Dec 23, 2019 at 11:06 AM Sebastien Lorquet <se...@lorquet.fr> wrote:
>
> OK.
>
> That is too much email for me, I just cant follow and understand all these
> discussions anymore. Almost 300 messages among multiple overlapping threads full
> of heated opinions in 2-3 days is insane.
>
> I just cant dedicate enough time reading any more of this. I have other things
> to do than trying to understand these multiple rebooted workflows proposals that
> span days (and nights!) of discussions.
It helps if you have a mail client that can display messages in
threaded mode. If not, you could (for example) create a gmail account.
Gmail automatically groups related emails. This has the advantage of
separating the volume of NuttX emails from your regular email box.
Regarding the workflow:
The road is bumpy but everything will be okay. This is a learning
experience for everyone. We are in the deep end of the swimming pool
with no training wheels. It is a big change and there is some shock,
chaos, and arguments. But everything will be okay. We have version
control. If a bad commit is made it can be fixed.
Brennan created a page in the Confluence for the workflow document. I
know that only committers can edit the Confluence wiki directly but
that is not a problem: Anyone can write some text and email it to this
list, and a committer can edit it into the Confluence page. (Hint:
People who participate often become good candidates to become
committers too!)
The Workflow Work-In-Progress Confluence Page is here:
https://cwiki.apache.org/confluence/display/NUTTXTEST/Code+Contribution+Workflow+--+Brennan+Ashton
On purpose I am not writing the whole thing by myself because I do not
want to be pushy. This is a community effort. I already wrote much and
it is in the Confluence page above. My plan is to wait a week or two,
let people work, and let discussions happen.
Let's relax. Let cooler minds prevail. Trust that the Apache Way
works. And everything will be okay.
Nathan
Re: [DISCUSS] Simple Workflow Proposal - not so simple?
Posted by Sebastien Lorquet <se...@lorquet.fr>.
OK.
That is too much email for me, I just cant follow and understand all these
discussions anymore. Almost 300 messages among multiple overlapping threads full
of heated opinions in 2-3 days is insane.
I just cant dedicate enough time reading any more of this. I have other things
to do than trying to understand these multiple rebooted workflows proposals that
span days (and nights!) of discussions.
So I can't vote on anything. I dont understand what is going on anymore. I'm
lost. Probably not important since I did not ask and choose to be a committer,
but since opinions are asked, here are mine.
Can someone please sum up what we have to decide in a short email, less than a page?
To be honest, viewed from here, I just seem to understand that some opinions are
very pushy and are trying to act before decisions are settled.
Also some kind of extra-heavy decisions on a full process NO ONE has been able
to install up to now for years.
I just want to say that going to apache should not be an occasion to try to
force the process of someone liking or another just because not everyone has an
equally stronger opinion and voice and free time for emails.
On my part, seeing too hard pushes in any specific direction just rings an alarm
bell to be extra-cautious.
I think the process should be as simple as possible, and improved later. Just
select the absolute bare minimum that could start to work and discard everything
else so this project can work again.
We are using git so things are reversable, right? We will not get this right the
first time, so lets keep room for errors. If I understand correctly the
bitbucket repositories are still in a consistent pre-apache state and the apache
ones can be reset? or is the apache->bb mirroring already active?
Also, I did not see a notification that the BB repositories had been frozen.
These workflow and reviewing discussions are just killing extremely valuable
time for everyone without visible progress (because too many messages).
So again, I would like to read a very short state of the union at monday
2019-Dec-23 17:01 UTC+1.
Otherwise I cant make decisions. And I guess I am not the only one.
Sebastien
Le 22/12/2019 à 17:25, Gregory Nutt a écrit :
>
>> Let's get everyone's thoughts on the table
>
> I suppose that we should keep the discussion for 72 hours then call the vote.
> We need to allow time for everyone to comment and with the holidays, we may
> not be able to get good feedback. Should we still call a vote if people are
> not participating?
>
> I will call the vote on your behalf in 72 hours.
>
> Greg
>
>
>
Re: [DISCUSS] Simple Workflow Proposal
Posted by Gregory Nutt <sp...@gmail.com>.
> Let's get everyone's thoughts on the table
I suppose that we should keep the discussion for 72 hours then call the
vote. We need to allow time for everyone to comment and with the
holidays, we may not be able to get good feedback. Should we still call
a vote if people are not participating?
I will call the vote on your behalf in 72 hours.
Greg
Re: [DISCUSS] Simple Workflow Proposal
Posted by Gregory Nutt <sp...@gmail.com>.
> There are several things I don't like about this proposal:
>
> - It is in complete conflict with everything we have discussed
> about the commit workflow
>
> - I think is is suggest out of panic. We have plenty of times to
> do things right or to do things better. There will be no pressing
> need until the work week begins after the New Year
>
> - It is an emergency measure and absolutely must not become the
> default workflow. If we put this in place, how do we get rid of
> it? Perhaps it should expire automatically after two weeks?
>
> I will have to vote -1 on this proposal with out some assurance that
> it is not a disease that we cannot recover from /EASILY/ without
> another vote. I would vote 0 if there there is such an assurance.
>
Regardless of the vote, I will not personally merge anything into the
repositories in any event until there is an accepted workflow
requirements document in place.
Greg
RE: [DISCUSS] Simple Workflow Proposal
Posted by David Sidrane <Da...@nscdg.com>.
Well Said!
-----Original Message-----
From: Justin Mclean [mailto:justin@classsoftware.com]
Sent: Monday, December 23, 2019 1:02 AM
To: dev@nuttx.apache.org
Subject: Re: [DISCUSS] Simple Workflow Proposal
Hi,
Apache has a concept of small reversible steps, if something can move the
project forward, try it out, it it doesn’t work or you find a problem need
just make another small step in the right direction.
Many many Apache projects use CTR (commit and review later) and have simple
workflows and the sky doesn’t fall in and the code quality is still
exceptional. While that doesn’t mean this project need to go down that path,
perhaps however think about how likely the worse outcome is and how easily
it will be to fix. You have many many eyes on the codebase, attracting more
committers make that easier. Setting the committer bat too high or having a
process that is too difficult to follow can stop committers from
contributing and perhaps even kill the project. I can point to some
examples, one in particular keep denying right to the end that "code
quality” was more important than having committers until it reached a point
where it had no active committers You primary concern should be to make it
easy for people to get involved and grow the community.
I would also suggest you try to slow down the conversation here and think a
little more about what you write, that way you get higher quality responses.
There is much honour in the email not sent.
Thanks,
Justin
Re: Signal to Noise (was RE: [DISCUSS] Simple Workflow Proposal)
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> I was thinking about calling a vote on limiting the # of emails.
IMO A vote will not help, it will make things worse, perhaps try discuss but most of all just try to be a little more considerate for people who are subscribers to this list. No hard rules just guidelines and consideration of your users. Not everything needs a vote. That being said, let'd be clear that's just my opinion and carries no more weight than any other person here. (I’m not wearing my mentor, IPMC or VP Incubator hat unless I explicitly state otherwise and that is very rare).
There’s a Spark talk that might help here (by Holden Karau) on the firehose that is their mailing list and PRs they get, I see if I can find the talk. Just be aware, that for a number of reasons, what Spark does may not be the best model to follow for an incubating project but it may give some insight all the same.
Thanks,
Justin
Signal to Noise (was RE: [DISCUSS] Simple Workflow Proposal)
Posted by David Sidrane <Da...@nscdg.com>.
Hi,
>-----Original Message-----
>From: Justin Mclean [mailto:justin@classsoftware.com]
>Sent: Monday, December 23, 2019 1:09 AM
>To: dev@nuttx.apache.org
>Subject: Re: [DISCUSS] Simple Workflow Proposal
>Hi,
>> I would also suggest you try to slow down the conversation here and think
>> a little more about what you write, that way you get >higher quality
>> responses.
>It’s also allows more timid people and those who are not full time on this
>to speak up and get noticed. Some ASF people make a >self imposed rule
>(which I just broke) to only email a thread once a day.
>Thanks,
>Justin
Ok we both have no honor nor impulse control :)
I was thinking about calling a vote on limiting the # of emails. We have a
very gifted team. With that comes some strong instinctual desires for
exactness.
This really resonated with me when I first heard it.
Don't Let the Perfect Be the Enemy of the Good [1]
Voltaire: “The best is the enemy of the good.”
Confucius: "Better a diamond with a flaw than a pebble without."
Shakespeare: “Striving to better, oft we mar what's well.”
[1] https://www.entrepreneur.com/article/249676
Re: [DISCUSS] Simple Workflow Proposal
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> I would also suggest you try to slow down the conversation here and think a little more about what you write, that way you get higher quality responses.
It’s also allows more timid people and those who are not full time on this to speak up and get noticed. Some ASF people make a self imposed rule (which I just broke) to only email a thread once a day.
Thanks,
Justin
Re: [DISCUSS] Simple Workflow Proposal
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
Apache has a concept of small reversible steps, if something can move the project forward, try it out, it it doesn’t work or you find a problem need just make another small step in the right direction.
Many many Apache projects use CTR (commit and review later) and have simple workflows and the sky doesn’t fall in and the code quality is still exceptional. While that doesn’t mean this project need to go down that path, perhaps however think about how likely the worse outcome is and how easily it will be to fix. You have many many eyes on the codebase, attracting more committers make that easier. Setting the committer bat too high or having a process that is too difficult to follow can stop committers from contributing and perhaps even kill the project. I can point to some examples, one in particular keep denying right to the end that "code quality” was more important than having committers until it reached a point where it had no active committers You primary concern should be to make it easy for people to get involved and grow the community.
I would also suggest you try to slow down the conversation here and think a little more about what you write, that way you get higher quality responses. There is much honour in the email not sent.
Thanks,
Justin
Re: [DISCUSS] Simple Workflow Proposal
Posted by Brennan Ashton <ba...@brennanashton.com>.
On Sun, Dec 22, 2019 at 8:18 PM Nathan Hartman <ha...@gmail.com>
wrote:
>
> Yesterday I wrote a detailed email giving the exact outline of what needs
> to be in that workflow document.
>
> Do we really have no volunteers to bang out even a rough draft of that
> document?
>
>
You both sucked me in again... But this time I had a few hours to write
some code and clear my head a little more.
I hope it is fine, but I opened up a section on the wiki for Proposals.
There is now a draft section that I think would be a great place for people
to write something.
I have started by creating a template for mine, and I will do it in the
format from Nathan's email. There is no real content, but maybe it can be
inspiration for someone else to also click that Create button.
https://cwiki.apache.org/confluence/display/NUTTXTEST/Code+Contribution+Workflow+--+Brennan+Ashton
--Brennan
Re: [DISCUSS] Simple Workflow Proposal
Posted by Gregory Nutt <sp...@gmail.com>.
> The danger of what is happening now is that it will become grandfathered in
> with no proper workflow in place, no proper criteria for processing
> changes, and no clear documentation that helps committers or the public to
> contribute.
If that comes to pass, I think I would be forced to resign. Apache NuttX
will be a failure.
Re: [DISCUSS] Simple Workflow Proposal
Posted by Gregory Nutt <sp...@gmail.com>.
> The danger of what is happening now is that it will become grandfathered in
> with no proper workflow in place, no proper criteria for processing
> changes, and no clear documentation that helps committers or the public to
> contribute.
We have to decline any attempt to include an test framework code until
requirements are in place. People must understand that any they are
working on now will not be permitted to enter the repositories until we
can verify it against an agreed to set of requirements.
I don't know what the extent of the risk is. There is one pending
change with regard to workflow logic. I think that this particular
change is reasonable and not a hostile takeover. But it leaves you to
wonder what else could come???? I definitely have a lack of trust.
> What do we have to do? A PMC vote to put a halt and finish the workflow?
I don't think we have the authority force anyone to stop work. But we
can prohibit anything from entering the repositories prior to the
requirements definition and without approval.
I could finish the the document in a day by simply combining the
existing materials, resolving conflicts, and filling some missing
logic. But I need to have the confidence of the PPMC. I am not the
kind of person who would push ahead without concurrence.
I am persistent (if no one has noticed), but I do not take liberties.
Greg
Re: [DISCUSS] Simple Workflow Proposal
Posted by Nathan Hartman <ha...@gmail.com>.
On Sun, Dec 22, 2019 at 9:02 PM Gregory Nutt <sp...@gmail.com> wrote:
>
> > But the #1 most critical thing facing this project is adopting even
> > just the requirements for the workflow. None of the other issues have
> > any significant importance
> >
> > So I have to be opposed to any obstacles that jeopardize or distract
> > from the #1 priority thing.
>
> One of the dangers of delaying the workflow requirements is that there
> are people actually developing workflow components now ... WITHOUT any
> requirements!!! Pull unadulterated rogue behavior. There is a great risk
> of just have some workflow foisted upon us with no ability by the PPMC
> to guide or monitor.
>
> We will be giving away our right to define the workflow it we do not
> make progress on the workflow requirements. Yet another rogue workflow
> will be forced on us.
>
> I think we must decline any attempts to do commit unapproved workflow
> components. We must not allow any workflow to be put into place without
> the concurrence of the PPMC. We give our concurrence only by agreeing
> to a set of workflow requirements then enforcing those requirements.
I agree.
Yesterday I wrote a detailed email giving the exact outline of what needs
to be in that workflow document.
Do we really have no volunteers to bang out even a rough draft of that
document?
The danger of what is happening now is that it will become grandfathered in
with no proper workflow in place, no proper criteria for processing
changes, and no clear documentation that helps committers or the public to
contribute.
What do we have to do? A PMC vote to put a halt and finish the workflow?
Nathan
Re: [DISCUSS] Simple Workflow Proposal
Posted by Gregory Nutt <sp...@gmail.com>.
> Two questions:
>
> 1 Who will apply the patches?
> 2 Can we use and merge a PR that has been reviewed?
You are basically asking for the workflow requirements.
Re: [DISCUSS] Simple Workflow Proposal
Posted by "张铎 (Duo Zhang)" <pa...@gmail.com>.
Let's not start new questions for now? Be patient and let's see what other
people think. One of the most important rule in ASF is 'community over
code', so although I also think accepting patches is the most emergency
thing here, but let's see other people's opinion first.
Thanks.
David Sidrane <Da...@nscdg.com> 于2019年12月23日周一 下午8:58写道：
> Hi Duo,
>
> Well said and I am all for it.
>
> Two questions:
>
> 1 Who will apply the patches?
> 2 Can we use and merge a PR that has been reviewed?
>
> David
>
>
> -----Original Message-----
> From: 张铎(Duo Zhang) [mailto:palomino219@gmail.com]
> Sent: Monday, December 23, 2019 4:35 AM
> To: dev@nuttx.apache.org
> Subject: Re: [DISCUSS] Simple Workflow Proposal
>
> For our Chinese people we do not think starting working when the
> requirements are not very clear is a big risk, this is what happens every
> day here. You can not plan everything so just have a try, if it does not
> work then just drop it and retry, no harm :)
>
> And in my experience, if we can not agree on something, and seems the
> direction of the conversation is not going to solve the problem, then we
> should stop, and try to make consensus on something else, maybe on a higher
> level, or a precondition of the current problem. If we can not even make a
> consensus then we do not need to talk any more, honestly.
>
> And back to the discussion here, I think we all agree that, we want the
> NuttX project to be successful right? Everyone here just wants to help,
> let’s be friendly to each other.
>
> And second, what is the most emergency problem for now? I do not think it
> is the workflow. We can not accept new patches, this is the biggest problem
> I think. And since it is Christmas so as Greg said maybe we can delay it
> for two weeks, but anyway it will still be the biggest problem after we
> come back from Christmas(OK I need to say that we Chinese people do not
> have Christmas holidays...).
>
> Do we really need a new workflow for accepting patches? I do not think so,
> now the only difference is that the code has been moved from bitbucket to
> github, so follow the old workflow is an option I’d say. Let’s do things
> step by step.
>
> Anyway, I think we should make a consensus first, if we all agree that
> accepting new patches is the most emergency problem for now, then we can
> start to talk the further actions. If not, let’s first define the problem.
> We really need to start from a consensus.
>
> My two cents. Thanks.
>
> Gregory Nutt <sp...@gmail.com>于2019年12月23日 周一10:02写道：
>
> >
> > > But the #1 most critical thing facing this project is adopting even
> > > just the requirements for the workflow. None of the other issues have
> > > any significant importance
> > >
> > > So I have to be opposed to any obstacles that jeopardize or distract
> > > from the #1 priority thing.
> >
> > One of the dangers of delaying the workflow requirements is that there
> > are people actually developing workflow components now ... WITHOUT any
> > requirements!!! Pull unadulterated rogue behavior. There is a great risk
> > of just have some workflow foisted upon us with no ability by the PPMC
> > to guide or monitor.
> >
> > We will be giving away our right to define the workflow it we do not
> > make progress on the workflow requirements. Yet another rogue workflow
> > will be forced on us.
> >
> > I think we must decline any attempts to do commit unapproved workflow
> > components. We must not allow any workflow to be put into place without
> > the concurrence of the PPMC. We give our concurrence only by agreeing
> > to a set of workflow requirements then enforcing those requirements.
> >
> > Greg
> >
> >
> >
>
RE: [DISCUSS] Simple Workflow Proposal
Posted by David Sidrane <Da...@nscdg.com>.
Hi Duo,
Well said and I am all for it.
Two questions:
1 Who will apply the patches?
2 Can we use and merge a PR that has been reviewed?
David
-----Original Message-----
From: 张铎(Duo Zhang) [mailto:palomino219@gmail.com]
Sent: Monday, December 23, 2019 4:35 AM
To: dev@nuttx.apache.org
Subject: Re: [DISCUSS] Simple Workflow Proposal
For our Chinese people we do not think starting working when the
requirements are not very clear is a big risk, this is what happens every
day here. You can not plan everything so just have a try, if it does not
work then just drop it and retry, no harm :)
And in my experience, if we can not agree on something, and seems the
direction of the conversation is not going to solve the problem, then we
should stop, and try to make consensus on something else, maybe on a higher
level, or a precondition of the current problem. If we can not even make a
consensus then we do not need to talk any more, honestly.
And back to the discussion here, I think we all agree that, we want the
NuttX project to be successful right? Everyone here just wants to help,
let’s be friendly to each other.
And second, what is the most emergency problem for now? I do not think it
is the workflow. We can not accept new patches, this is the biggest problem
I think. And since it is Christmas so as Greg said maybe we can delay it
for two weeks, but anyway it will still be the biggest problem after we
come back from Christmas(OK I need to say that we Chinese people do not
have Christmas holidays...).
Do we really need a new workflow for accepting patches? I do not think so,
now the only difference is that the code has been moved from bitbucket to
github, so follow the old workflow is an option I’d say. Let’s do things
step by step.
Anyway, I think we should make a consensus first, if we all agree that
accepting new patches is the most emergency problem for now, then we can
start to talk the further actions. If not, let’s first define the problem.
We really need to start from a consensus.
My two cents. Thanks.
Gregory Nutt <sp...@gmail.com>于2019年12月23日 周一10:02写道：
>
> > But the #1 most critical thing facing this project is adopting even
> > just the requirements for the workflow. None of the other issues have
> > any significant importance
> >
> > So I have to be opposed to any obstacles that jeopardize or distract
> > from the #1 priority thing.
>
> One of the dangers of delaying the workflow requirements is that there
> are people actually developing workflow components now ... WITHOUT any
> requirements!!! Pull unadulterated rogue behavior. There is a great risk
> of just have some workflow foisted upon us with no ability by the PPMC
> to guide or monitor.
>
> We will be giving away our right to define the workflow it we do not
> make progress on the workflow requirements. Yet another rogue workflow
> will be forced on us.
>
> I think we must decline any attempts to do commit unapproved workflow
> components. We must not allow any workflow to be put into place without
> the concurrence of the PPMC. We give our concurrence only by agreeing
> to a set of workflow requirements then enforcing those requirements.
>
> Greg
>
>
>
Re: [DISCUSS] Simple Workflow Proposal
Posted by "张铎 (Duo Zhang)" <pa...@gmail.com>.
For our Chinese people we do not think starting working when the
requirements are not very clear is a big risk, this is what happens every
day here. You can not plan everything so just have a try, if it does not
work then just drop it and retry, no harm :)
And in my experience, if we can not agree on something, and seems the
direction of the conversation is not going to solve the problem, then we
should stop, and try to make consensus on something else, maybe on a higher
level, or a precondition of the current problem. If we can not even make a
consensus then we do not need to talk any more, honestly.
And back to the discussion here, I think we all agree that, we want the
NuttX project to be successful right? Everyone here just wants to help,
let’s be friendly to each other.
And second, what is the most emergency problem for now? I do not think it
is the workflow. We can not accept new patches, this is the biggest problem
I think. And since it is Christmas so as Greg said maybe we can delay it
for two weeks, but anyway it will still be the biggest problem after we
come back from Christmas(OK I need to say that we Chinese people do not
have Christmas holidays...).
Do we really need a new workflow for accepting patches? I do not think so,
now the only difference is that the code has been moved from bitbucket to
github, so follow the old workflow is an option I’d say. Let’s do things
step by step.
Anyway, I think we should make a consensus first, if we all agree that
accepting new patches is the most emergency problem for now, then we can
start to talk the further actions. If not, let’s first define the problem.
We really need to start from a consensus.
My two cents. Thanks.
Gregory Nutt <sp...@gmail.com>于2019年12月23日 周一10:02写道：
>
> > But the #1 most critical thing facing this project is adopting even
> > just the requirements for the workflow. None of the other issues have
> > any significant importance
> >
> > So I have to be opposed to any obstacles that jeopardize or distract
> > from the #1 priority thing.
>
> One of the dangers of delaying the workflow requirements is that there
> are people actually developing workflow components now ... WITHOUT any
> requirements!!! Pull unadulterated rogue behavior. There is a great risk
> of just have some workflow foisted upon us with no ability by the PPMC
> to guide or monitor.
>
> We will be giving away our right to define the workflow it we do not
> make progress on the workflow requirements. Yet another rogue workflow
> will be forced on us.
>
> I think we must decline any attempts to do commit unapproved workflow
> components. We must not allow any workflow to be put into place without
> the concurrence of the PPMC. We give our concurrence only by agreeing
> to a set of workflow requirements then enforcing those requirements.
>
> Greg
>
>
>
Re: [DISCUSS] Simple Workflow Proposal
Posted by Gregory Nutt <sp...@gmail.com>.
> But the #1 most critical thing facing this project is adopting even
> just the requirements for the workflow. None of the other issues have
> any significant importance
>
> So I have to be opposed to any obstacles that jeopardize or distract
> from the #1 priority thing.
One of the dangers of delaying the workflow requirements is that there
are people actually developing workflow components now ... WITHOUT any
requirements!!! Pull unadulterated rogue behavior. There is a great risk
of just have some workflow foisted upon us with no ability by the PPMC
to guide or monitor.
We will be giving away our right to define the workflow it we do not
make progress on the workflow requirements. Yet another rogue workflow
will be forced on us.
I think we must decline any attempts to do commit unapproved workflow
components. We must not allow any workflow to be put into place without
the concurrence of the PPMC. We give our concurrence only by agreeing
to a set of workflow requirements then enforcing those requirements.
Greg
Re: [DISCUSS] Simple Workflow Proposal
Posted by Gregory Nutt <sp...@gmail.com>.
> I will be stepping away from all further discussion on the work flow topic as I have soured on it and don't have a real vote beyond proposing it.
You are lucky that you have that option. I would too if it were
possible. This no way that anyone should have to waste there life.
But the #1 most critical thing facing this project is adopting even just
the requirements for the workflow. None of the other issues have any
significant importance
So I have to be opposed to any obstacles that jeopardize or distract
from the #1 priority thing.
Re: [DISCUSS] Simple Workflow Proposal
Posted by Gregory Nutt <sp...@gmail.com>.
I don't like it because it is not the workflow that has been discussed
and I can never support a slam dunk of any workflow that is not
described in the workflow requirements document.
I will vote -1 if we cannot be assured that this this cannot become a
disease that we cannot shake. My proposal:
* It must have time limit of, say, two weeks and require a new vote to
extend it for another two weeks.
* If must immediately become null and void when the proper workflow
requirements are place.
I will merge nothing under this agreement. I will merge nothing until
we have workflow requirements.
This is a kludge intended only for expediency. I cannot support that.
Greg
On 12/22/2019 6:14 PM, Brennan Ashton wrote:
> I proposed this because I think it is a solid flow and in alignment with
> other stable opensource projects that I contribute to including one under
> the FSF complexity.
>
> It is NOT a rush and I don't think it is out of line. Multiple +1 were
> given, so I don't think it's that far off what will work.
>
> I think much of the other discussions are far to complex, will prevent
> contributions and ignore technologies in favor of theory and principle.
>
> I will be stepping away from all further discussion on the work flow topic
> as I have soured on it and don't have a real vote beyond proposing it. As I
> said I trust the people I this project so it will workout. When there is a
> flow for contributing please announce it and I will try to contribute my
> code.
>
> --Brennan
>
> On Sun, Dec 22, 2019, 3:46 PM Gregory Nutt <sp...@gmail.com> wrote:
>
>> There are several things I don't like about this proposal:
>>
>> - It is in complete conflict with everything we have discussed about
>> the commit workflow
>>
>> - I think is is suggest out of panic. We have plenty of times to do
>> things right or to do things better. There will be no pressing need
>> until the work week begins after the New Year
>>
>> - It is an emergency measure and absolutely must not become the
>> default workflow. If we put this in place, how do we get rid of
>> it? Perhaps it should expire automatically after two weeks?
>>
>> I will have to vote -1 on this proposal with out some assurance that it
>> is not a disease that we cannot recover from /EASILY/ without another
>> vote. I would vote 0 if there there is such an assurance.
>>
>> Greg
>>
>>
>>
Re: [DISCUSS] Simple Workflow Proposal
Posted by Brennan Ashton <ba...@brennanashton.com>.
I proposed this because I think it is a solid flow and in alignment with
other stable opensource projects that I contribute to including one under
the FSF complexity.
It is NOT a rush and I don't think it is out of line. Multiple +1 were
given, so I don't think it's that far off what will work.
I think much of the other discussions are far to complex, will prevent
contributions and ignore technologies in favor of theory and principle.
I will be stepping away from all further discussion on the work flow topic
as I have soured on it and don't have a real vote beyond proposing it. As I
said I trust the people I this project so it will workout. When there is a
flow for contributing please announce it and I will try to contribute my
code.
--Brennan
On Sun, Dec 22, 2019, 3:46 PM Gregory Nutt <sp...@gmail.com> wrote:
> There are several things I don't like about this proposal:
>
> - It is in complete conflict with everything we have discussed about
> the commit workflow
>
> - I think is is suggest out of panic. We have plenty of times to do
> things right or to do things better. There will be no pressing need
> until the work week begins after the New Year
>
> - It is an emergency measure and absolutely must not become the
> default workflow. If we put this in place, how do we get rid of
> it? Perhaps it should expire automatically after two weeks?
>
> I will have to vote -1 on this proposal with out some assurance that it
> is not a disease that we cannot recover from /EASILY/ without another
> vote. I would vote 0 if there there is such an assurance.
>
> Greg
>
>
>
Re: [DISCUSS] Simple Workflow Proposal
Posted by Gregory Nutt <sp...@gmail.com>.
There are several things I don't like about this proposal:
- It is in complete conflict with everything we have discussed about
the commit workflow
- I think is is suggest out of panic. We have plenty of times to do
things right or to do things better. There will be no pressing need
until the work week begins after the New Year
- It is an emergency measure and absolutely must not become the
default workflow. If we put this in place, how do we get rid of
it? Perhaps it should expire automatically after two weeks?
I will have to vote -1 on this proposal with out some assurance that it
is not a disease that we cannot recover from /EASILY/ without another
vote. I would vote 0 if there there is such an assurance.
Greg
Re: [DISCUSS] Simple Workflow Proposal
Posted by Gregory Nutt <sp...@gmail.com>.
> I don't think that were will be much that has to be acted on during
> the holidays. And, in any event, I would rather see a backlog of work
> build up than to to see an interim, wrong workflow put in place. Doing
> things right is more important that doing things quickly.
I would add that I do not think that we need to wait for the full
workflow to be automated. I think we only need to wait until the
workflow requirements are defined. When the requirements are in place,
then the workflow can be implemented manually until the automation is in
place.
Greg
Re: [DISCUSS] Simple Workflow Proposal
Posted by Gregory Nutt <sp...@gmail.com>.
>> 1) The timeline. Two weeks over the holiday to come to a formal
>> agreement
>> is going to be tough and I also don't think just because we have a path
>> forward people will stop caring about proposing a better solution. From
>> what I'm seeing the longer term proposal will likely get into the
>> weeds of
>> tooling around CI email patches etc... These take weeks to settle on. I
>> trust the intentions of the people in the project and do not see a
>> need to
>> bind them to a timeline to build this out.
I don't think that were will be much that has to be acted on during the
holidays. And, in any event, I would rather see a backlog of work build
up than to to see an interim, wrong workflow put in place. Doing things
right is more important that doing things quickly.
>>
>> 2) Why cut corners. Personally I don't see this as cutting corners I
>> think
>> this will in practice get us 90% of the way there and get us back into a
>> cadence of improving the software. I trust the project members will use
>> judgement within the structure and will actively move the project
>> along to
>> better structure.
>>
There has been no evidence the project members will use good judgement.
I have not seen that so far. Mistakes will be made. Why not wait and
get 100%