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
By who? Where is the vote?
-Original Message-
From: Gregory Nutt [mailto:spudan...@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 sl
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
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
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
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 wrote:
>
>
>>> I suggest that we really need to get all discussions, participation,
>>> and contributions
On Fri, Dec 13, 2019 at 6:52 PM Alan Carvalho de Assis
wrote:
> HI Justin,
>
> On 12/13/19, Justin Mclean 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
> >
HI Justin,
On 12/13/19, Justin Mclean 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
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
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
Hi Nathan,
On 12/13/19, Nathan Hartman wrote:
> On Fri, Dec 13, 2019 at 8:53 AM Gregory Nutt 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
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
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
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
On Fri, Dec 13, 2019 at 8:53 AM Gregory Nutt 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
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 wrote:
>
> Another thing to
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
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
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
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 wrote:
> Precisely! We cut a branch as a Release Candidate. nuttx-MM.mm.rr-rcnn.
> During the
20 matches
Mail list logo
