You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nuttx.apache.org by David Sidrane <Da...@nscdg.com> on 2019/12/13 08:20:14 UTC
Workflow and Release strategy Proposal (Was RE: Project Emails)
Precisely! We cut a branch as a Release Candidate. nuttx-MM.mm.rr-rcnn.
During the release cycle it can have back ports from master if a new feature
or bug fix is found it is added if deemed necessary to the release.
Workflow Proposal
I would ask that we adopt a workflow similar to PX4. [1] - see page 16. Or
parts of it that work for us.
All development would be done on branches and only squashed atomic commits
would be done to master. (Think constantly working bisect on master)
Branches can be rebased - to reduce noise until review [1] see page 17
All commit message would have context. [1] - see page 16 (Think emails
subject tells me what happed, Filter out noise)
Regards,
David
[1] https://drive.google.com/open?id=1XHaNB3nTarjPL-CzO9CpZTl1NgX_kpqY
-----Original Message-----
From: spudaneco [mailto:spudaneco@gmail.com]
Sent: Thursday, December 12, 2019 9:16 PM
To: dev@nuttx.apache.org
Subject: Re: Project Emails
Sent from Samsung tablet.
I think we should use release branches, unless we want to lock downthe repo
against all changes for the duration of the release prep ->release
candidate -> testing -> debating -> voting cycle, which couldtake a non
trivial amount of time.You could carry on business as usual on a temporary
branch, but that feels awkward.
Re: Workflow and Release strategy Proposal (Was RE: Project Emails)
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Does Apache have any requirements that we must follow for how releases are made available?
Yes they need to be placed in the ASF mirrors. Note that the word release has a particular meaning at the ASF and must contain only source code and voted on by a PMC.
Here’s the full release and distribution policies. [1][2]
Short version is that they need to be placed on http://www.apache.org/dist/incubator, the release candidates can go on https://dist.apache.org/repos/dist/dev/incubator/. Once voted on by the PPMC and the IPMC you can use svn mv to move a RC to the release area.
Thanks,
Justin
1. http://www.apache.org/legal/release-policy.html
2. https://www.apache.org/dev/release-distribution.html
Re: Workflow and Release strategy Proposal (Was RE: Project Emails)
Posted by Gregory Nutt <sp...@gmail.com>.
> I think this emphasizes the point that we need to understand and
> document a release requirements and procedure that is 100% consistent
> with Apache requirements BEFORE we begin having low level discussions
> on how to implement that release procedure. ...
I think that the first question we would need to answer in a discussion
of the releases is, "What is the form of the release that is seen by the
user?" In the past, that was:
1. Two separate versioned tarballs, one for apps/ and one for nutts/
2. ReleaseNotes, and
3. A tagged repository.
The creation of the tarballs was done by the script tools/zipme.sh.
That script requires the version number and the commit UID at the HEAD
of the nuttx/ repository (addressing Justin's concern with tags). It
generates the tarballs and also a .version file in the root. That
.version file contains the versioning information in various formats as
well as the UID. The .version file is directly include-able by scripts
and Makefile fragments. At build time, the .version is used to create
an include/nuttx/version.h header file making the version information
available to C and C++ code as well.
Releases were posted on SourceForge and Bitbucket download areas.
Release announcements were made in the NuttX Google group and in the
LinkedIn NuttX group.
That is what the world is used to. Do you see things that should
change? Probably the repository tags would become branches and
locations where releases are available would change. But other than
that, is there any reason why anything else change? Certainly, there
should be no artificial coupling been apps/ and nuttx/. I believe that
those must stay independent.
Does Apache have any requirements that we must follow for how releases
are made available?
Greg
Re: Workflow and Release strategy Proposal (Was RE: Project Emails)
Posted by Gregory Nutt <sp...@gmail.com>.
> The proposal looks good but we should also consider if we want to support
> LTS maintenance releases containing bugfixed backported from mainline
It is the usual case that after you release code that within one or two
weeks after you release code, you discover embarrassing, gaping bugs. I
solved that in the past by just distributing a patch file with the
release tarballs. But I also got a lot of complaints about that; people
would prefer another one off release.
I think this emphasizes the point that we need to understand and
document a release requirements and procedure that is 100% consistent
with Apache requirements BEFORE we begin having low level discussions on
how to implement that release procedure. Alin's suggestion here could be
one of those requirements.
In the short term, it is more important to focus on the workflow for
accepting, qualifying, approving, and incorporating changes to the OS.
Those changes will be coming soon.. within days. We can defer the first
Apache NuttX release has long as we have to in order to get it right.
Getting it right is more important than getting it rapidly or getting it
easily. It is not the end of the world if we miss a release cycle.
When we discuss that patch-to-merge work flow, I think that the idea of
a repository with nuttx/ and apps/ as sub-modules makes perfectly good
sense, at least as a starting point for discussion. I personally don't
think it makes any sense for starting a discussion of the release
process. Perhaps it fits into the release process down the road, but it
makes a bad conversation starter.
+
Re: Workflow and Release strategy Proposal (Was RE: Project Emails)
Posted by Justin Mclean <ju...@me.com.INVALID>.
Hi,
> I think this is of secondary importance, but certainly any change to the documented use of NuttX should a factor that is taken into consideration. Ideally, the only user impact should be the URL used with the 'git clone' (or download).
In general you want to point users to official releases and not unreleased code. [1]
Thanks,
Justin
1. http://www.apache.org/legal/release-policy.html#publication
Re: Workflow and Release strategy Proposal (Was RE: Project Emails)
Posted by Justin Mclean <ju...@me.com.INVALID>.
Hi
We can have as many repos as we need and they are easy to set up via ASF self-serve. [1]
Thanks,
Justin
1. https://selfserve.apache.org
Re: Workflow and Release strategy Proposal (Was RE: Project Emails)
Posted by Xiang Xiao <xi...@gmail.com>.
I think we can keep apps and nuttx as two separate gits, mynewt even has dozen:
https://gitbox.apache.org/repos/asf?s=mynewt
It's enough to just change tag to branch for incoperating the potential bugfix.
Thanks
Xiang
On Fri, Dec 13, 2019 at 9:53 PM Gregory Nutt <sp...@gmail.com> wrote:
>
> Another thing to consider with the form of the release is that there an
> many, many documents, Wikis, READMEs, HowTos, blogs, and videos
> describing how to get started with NuttX. They all begin either 'git
> clone' apps/ and nuttx/ (or download the tarballs). Changing that means
> breaking a lot of things.
>
> I think this is of secondary importance, but certainly any change to the
> documented use of NuttX should a factor that is taken into
> consideration. Ideally, the only user impact should be the URL used
> with the 'git clone' (or download).
>
>
Re: Workflow and Release strategy Proposal (Was RE: Project Emails)
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> I did create a #nuttx channel in the ASF slack: https://app.slack.com/client/, but it has been recommended that we not use that Slack for communication either.
It’s fine to talk there but decisions need to be made on the mailing list. Real time communication excludes people who may not be in your time zone or may not be able to work on the project during their $dayjob, asynchronous communication (i.e email) is preferred as it allows everyone a chance to be involved. There are other good reason as well previously discussed.
While I'm a user of Slack and follow about 20 slack workspaces I'm not going to closely follow any NuttX slack channel, following the mailing list is all that should be needed o know what is going on in a project.
Thanks,
Justin
Re: Workflow and Release strategy Proposal (Was RE: Project Emails)
Posted by Gregory Nutt <sp...@gmail.com>.
>> Why would you want to shut down your slack space? Some projects use a
>> slack space and even the ASF has one: the-asf.slack.com
> I was asked to shut down all NuttX project communications that are not
> publicly visible. I have done that. It was a slow gradual phase out,
> described in the Google group.
I did create a #nuttx channel in the ASF slack:
https://app.slack.com/client/, but it has been recommended that we not
use that Slack for communication either.
Re: Workflow and Release strategy Proposal (Was RE: Project Emails)
Posted by Justin Mclean <ju...@classsoftware.com>.
HI,
> By who? Where is the vote?
Conversation in Apache projects need to be in the open, so I’m not sure that a vote in needed to shut down something not controlled by the Apache project that privately run.
Thanks,
Justin
RE: Workflow and Release strategy Proposal (Was RE: Project Emails)
Posted by David Sidrane <Da...@nscdg.com>.
By who? Where is the vote?
-----Original Message-----
From: Gregory Nutt [mailto:spudaneco@gmail.com]
Sent: Thursday, December 19, 2019 5:45 AM
To: dev@nuttx.apache.org
Subject: Re: Workflow and Release strategy Proposal (Was RE: Project Emails)
> Why would you want to shut down your slack space? Some projects use a
> slack space and even the ASF has one: the-asf.slack.com
I was asked to shut down all NuttX project communications that are not
publicly visible. I have done that. It was a slow gradual phase out,
described in the Google group.
Re: Workflow and Release strategy Proposal (Was RE: Project Emails)
Posted by Gregory Nutt <sp...@gmail.com>.
> Why would you want to shut down your slack space? Some projects use a slack space and even the ASF has one: the-asf.slack.com
I was asked to shut down all NuttX project communications that are not
publicly visible. I have done that. It was a slow gradual phase out,
described in the Google group.
Re: Workflow and Release strategy Proposal (Was RE: Project Emails)
Posted by Flavio Junqueira <fp...@apache.org>.
Greg,
Why would you want to shut down your slack space? Some projects use a slack space and even the ASF has one: the-asf.slack.com
-Flavio
> On 14 Dec 2019, at 00:46, Gregory Nutt <sp...@gmail.com> wrote:
>
>
>>> I suggest that we really need to get all discussions, participation,
>>> and contributions "under one roof" so to speak, at
>>> dev@nuttx.apache.org. I think the Slack, the Google Group, the
>>> LinkedIn Group, and any other forums that fragment participants,
>>> should wind up soon. Whenever we reply to a message there, we should
>>> remind people that those forums are deprecated and that they should
>>> join dev@nuttx.apache.org.
>>>
>> I think at least the LinkedIn group is not in this category of
>> removing users from the mailing list, quite the opposite. The LinkedIn
>> group goal is to advertise and show projects and products using NuttX.
>> Many people discovered NuttX thanks our announcements there. There is
>> not a discussion group in the Linkedin, but only a showcase for NuttX.
>
> The LinkedIn group really is a different creature. It has thousands of subscribers and close to no participation. Alan is essentially the only poster there.
>
> I am willing to shut down the Slack right now, at this moment. Every time I proposed doing that, people balk because there might be something of importance there. There might be, but it would be in a closed channel or a person-to-person conversation. I think it should go now, but I need support and concurrence to take that step.
>
> Just speak the words and it is gone.
>
Re: Workflow and Release strategy Proposal (Was RE: Project Emails)
Posted by Gregory Nutt <sp...@gmail.com>.
>> I suggest that we really need to get all discussions, participation,
>> and contributions "under one roof" so to speak, at
>> dev@nuttx.apache.org. I think the Slack, the Google Group, the
>> LinkedIn Group, and any other forums that fragment participants,
>> should wind up soon. Whenever we reply to a message there, we should
>> remind people that those forums are deprecated and that they should
>> join dev@nuttx.apache.org.
>>
> I think at least the LinkedIn group is not in this category of
> removing users from the mailing list, quite the opposite. The LinkedIn
> group goal is to advertise and show projects and products using NuttX.
> Many people discovered NuttX thanks our announcements there. There is
> not a discussion group in the Linkedin, but only a showcase for NuttX.
The LinkedIn group really is a different creature. It has thousands of
subscribers and close to no participation. Alan is essentially the only
poster there.
I am willing to shut down the Slack right now, at this moment. Every
time I proposed doing that, people balk because there might be something
of importance there. There might be, but it would be in a closed
channel or a person-to-person conversation. I think it should go now,
but I need support and concurrence to take that step.
Just speak the words and it is gone.
Re: Workflow and Release strategy Proposal (Was RE: Project Emails)
Posted by Nathan Hartman <ha...@gmail.com>.
On Fri, Dec 13, 2019 at 6:52 PM Alan Carvalho de Assis <ac...@gmail.com>
wrote:
> HI Justin,
>
> On 12/13/19, Justin Mclean <ju...@classsoftware.com> wrote:
> > Hi,
> >
> > I would have no issue with keeping the linked in group, especially it
> used
> > like that. It would be best to share ownership of it to all the PPMC.
> Many
> > project have twitter accounts. facebook pages, stack overflow accounts
> etc
> > etc. What important is the he main discussion happens on this mailing
> list
> > and that the decisions are made here.
> >
>
> I agree! Currently only I and Greg are the Managers of the group, but
> we can extent it to all PPMC interested to advertise about this great
> project.
>
> So, if someone here want to help us in the LinkedIn group, please just
> inform your LinkedIn account and we will add you as Manager as well
Okay, I understand better the purpose of the LinkedIn and I agree that it
should stay.
I'm all in favor of advertising the existence of NuttX far and wide.
By the same token, can we keep the Google Group and use it the same way,
I.e., post a copy of all announcements there but if anyone new comes along
and asks questions we should point them to the official discussion channel?
Nathan
Re: Workflow and Release strategy Proposal (Was RE: Project Emails)
Posted by Alan Carvalho de Assis <ac...@gmail.com>.
HI Justin,
On 12/13/19, Justin Mclean <ju...@classsoftware.com> wrote:
> Hi,
>
> I would have no issue with keeping the linked in group, especially it used
> like that. It would be best to share ownership of it to all the PPMC. Many
> project have twitter accounts. facebook pages, stack overflow accounts etc
> etc. What important is the he main discussion happens on this mailing list
> and that the decisions are made here.
>
I agree! Currently only I and Greg are the Managers of the group, but
we can extent it to all PPMC interested to advertise about this great
project.
So, if someone here want to help us in the LinkedIn group, please just
inform your LinkedIn account and we will add you as Manager as well.
BR,
Alan
Re: Workflow and Release strategy Proposal (Was RE: Project Emails)
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
I would have no issue with keeping the linked in group, especially it used like that. It would be best to share ownership of it to all the PPMC. Many project have twitter accounts. facebook pages, stack overflow accounts etc etc. What important is the he main discussion happens on this mailing list and that the decisions are made here.
Thanks,
Justin
Re: Workflow and Release strategy Proposal (Was RE: Project Emails)
Posted by Alan Carvalho de Assis <ac...@gmail.com>.
Hi Nathan,
On 12/13/19, Nathan Hartman <ha...@gmail.com> wrote:
> On Fri, Dec 13, 2019 at 8:53 AM Gregory Nutt <sp...@gmail.com> wrote:
>
>> Another thing to consider with the form of the release is that there an
>> many, many documents, Wikis, READMEs, HowTos, blogs, and videos
>> describing how to get started with NuttX. They all begin either 'git
>> clone' apps/ and nuttx/ (or download the tarballs). Changing that means
>> breaking a lot of things.
>
>
> There is no reason to change that.
>
> Releases should be in the form of tarballs and those who wish to hack
> on NuttX or be on the bleeding edge can clone the git repos. Nothing
> changes there except the URL where you download those things (and the
> fact that the PMC members will digitally sign the release tarballs
> with our PGP/GPG keys). To minimize confusion, all the places that
> have until now hosted NuttX tarballs and git repos should have a big
> "WE HAVE MOVED!" message with our new address.
>
> Not directly related but Greg mentioned Google and LinkedIn:
>
> I suggest that we really need to get all discussions, participation,
> and contributions "under one roof" so to speak, at
> dev@nuttx.apache.org. I think the Slack, the Google Group, the
> LinkedIn Group, and any other forums that fragment participants,
> should wind up soon. Whenever we reply to a message there, we should
> remind people that those forums are deprecated and that they should
> join dev@nuttx.apache.org.
>
I think at least the LinkedIn group is not in this category of
removing users from the mailing list, quite the opposite. The LinkedIn
group goal is to advertise and show projects and products using NuttX.
Many people discovered NuttX thanks our announcements there. There is
not a discussion group in the Linkedin, but only a showcase for NuttX.
We can turn it off is all people here decide to do so, but I think we
will shoot the foot if we do it.
Just my two cents.
BR,
Alan
Re: Workflow and Release strategy Proposal (Was RE: Project Emails)
Posted by Nathan Hartman <ha...@gmail.com>.
On Fri, Dec 13, 2019 at 8:53 AM Gregory Nutt <sp...@gmail.com> wrote:
> Another thing to consider with the form of the release is that there an
> many, many documents, Wikis, READMEs, HowTos, blogs, and videos
> describing how to get started with NuttX. They all begin either 'git
> clone' apps/ and nuttx/ (or download the tarballs). Changing that means
> breaking a lot of things.
There is no reason to change that.
Releases should be in the form of tarballs and those who wish to hack
on NuttX or be on the bleeding edge can clone the git repos. Nothing
changes there except the URL where you download those things (and the
fact that the PMC members will digitally sign the release tarballs
with our PGP/GPG keys). To minimize confusion, all the places that
have until now hosted NuttX tarballs and git repos should have a big
"WE HAVE MOVED!" message with our new address.
Not directly related but Greg mentioned Google and LinkedIn:
I suggest that we really need to get all discussions, participation,
and contributions "under one roof" so to speak, at
dev@nuttx.apache.org. I think the Slack, the Google Group, the
LinkedIn Group, and any other forums that fragment participants,
should wind up soon. Whenever we reply to a message there, we should
remind people that those forums are deprecated and that they should
join dev@nuttx.apache.org.
If there is any valuable information on the Slack or LinkedIn that is
of use to NuttX and shouldn't be lost, I suggest asking whoever posted
it if they'll kindly copy and paste into an email to dev@, to bring it
under the one roof and also to open it up to anyone who wants to get
involved in the project.
Nathan
Re: Workflow and Release strategy Proposal (Was RE: Project Emails)
Posted by Gregory Nutt <sp...@gmail.com>.
Another thing to consider with the form of the release is that there an
many, many documents, Wikis, READMEs, HowTos, blogs, and videos
describing how to get started with NuttX. They all begin either 'git
clone' apps/ and nuttx/ (or download the tarballs). Changing that means
breaking a lot of things.
I think this is of secondary importance, but certainly any change to the
documented use of NuttX should a factor that is taken into
consideration. Ideally, the only user impact should be the URL used
with the 'git clone' (or download).
Re: Workflow and Release strategy Proposal (Was RE: Project Emails)
Posted by Alin Jerpelea <je...@gmail.com>.
The proposal looks good but we should also consider if we want to support
LTS maintenance releases containing bugfixed backported from mainline
Regards
Alin
On Fri, Dec 13, 2019, 09:27 David Sidrane <Da...@nscdg.com> wrote:
> Precisely! We cut a branch as a Release Candidate. nuttx-MM.mm.rr-rcnn.
> During the release cycle it can have back ports from master if a new
> feature
> or bug fix is found it is added if deemed necessary to the release.
>
> Workflow Proposal
>
> I would ask that we adopt a workflow similar to PX4. [1] - see page 16. Or
> parts of it that work for us.
>
> All development would be done on branches and only squashed atomic commits
> would be done to master. (Think constantly working bisect on master)
>
> Branches can be rebased - to reduce noise until review [1] see page 17
>
> All commit message would have context. [1] - see page 16 (Think emails
> subject tells me what happed, Filter out noise)
>
> Regards,
>
> David
>
> [1] https://drive.google.com/open?id=1XHaNB3nTarjPL-CzO9CpZTl1NgX_kpqY
>
>
> -----Original Message-----
> From: spudaneco [mailto:spudaneco@gmail.com]
> Sent: Thursday, December 12, 2019 9:16 PM
> To: dev@nuttx.apache.org
> Subject: Re: Project Emails
>
> Sent from Samsung tablet.
> I think we should use release branches, unless we want to lock downthe repo
> against all changes for the duration of the release prep ->release
> candidate -> testing -> debating -> voting cycle, which couldtake a non
> trivial amount of time.You could carry on business as usual on a temporary
> branch, but that feels awkward.
>