On 12/13/19, Justin Mclean wrote:
> Hi,
>
>> Do you know know project which did it in the past?
>
> Not from DocuWiki that I’m aware of. A search of the entire ASF mail
> archives [1] didn’t find anything.
>
> Let wait until Infra get back to us - that may take a day or two.
>
Right, thank you ag
Hi,
> Do you know know project which did it in the past?
Not from DocuWiki that I’m aware of. A search of the entire ASF mail archives
[1] didn’t find anything.
Let wait until Infra get back to us - that may take a day or two.
Thanks,
Justin
1. https://lists.apache.org/search.html
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
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 mes
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 mail
Hi Justin,
On 12/13/19, Justin Mclean wrote:
> Hi,
>
>> It appears there are a converter from DocuWiki to Confluence:
>> https://community.atlassian.com/t5/Answers-Developer-Questions/how-to-import-quot-dokuwiki-quot-to-confluence/qaq-p/526583
>
> Yep I noted that on the JIRA.
>
How could help i
Hi,
> It appears there are a converter from DocuWiki to Confluence:
> https://community.atlassian.com/t5/Answers-Developer-Questions/how-to-import-quot-dokuwiki-quot-to-confluence/qaq-p/526583
Yep I noted that on the JIRA.
Thanks,
Justin
Hi Greg,
On 12/13/19, Gregory Nutt wrote:
>
>> Absolutely, Confluence would be great -- it'd be good place to create
>> live
>> documents and tutorials that could evolve along with the code base...
>
> The original plan was to integrate the existing DocuWiki at nuttx.org to
> Confluence. If we b
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 a
Hi,
I really don’t think there will be any issues doing both in parallel so I’ve
created a confluence space here:
https://cwiki.apache.org/confluence/display/NUTTX
> I have heard that the INFRA team has some special kung-fu for importing Wikis
> into confluence. I hope they can handle an old D
I will send the SGA this weekend.
Also I am going to try to decouple better. It is not because I am
trying be the BDFL, it is just in my nature to "mother hen" software
projects. I will be detach and I will let the PPMP form itself with
less influence from me. I will try to continue to help
Hi,
> The original plan was to integrate the existing DocuWiki at nuttx.org to
> Confluence. If we begin using Confluence in an ad hoc way then I have some
> concern that it will interfere with the clean port of the existing Wiki.
I don’t think there will be any issues along those lines, any
Hi,
> No, AFAIK, no SGA's have been filed. The wording here is
> https://incubator.apache.org/guides/ip_clearance.html is unclear to me under
> "Establishing Provenance". Contributor in this case refers to copyright
> holders, I assume?
This only applies to code you are giving to the ASF (it
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 officia
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
Is there reason for me to be concerned?
Unfortunately, yes. As much as I like Confluence, if not properly
organized and managed, it can quickly grow into an unnavigable mess.
I suppose it's like anything else we do, it requires a process and
disciplined maintainer...
Then I think we should
> Is there reason for me to be concerned?
Unfortunately, yes. As much as I like Confluence, if not properly
organized and managed, it can quickly grow into an unnavigable mess.
I suppose it's like anything else we do, it requires a process and
disciplined maintainer...
On Fri, Dec 13, 2019 at 2:
Absolutely, Confluence would be great -- it'd be good place to create live
documents and tutorials that could evolve along with the code base...
The original plan was to integrate the existing DocuWiki at nuttx.org to
Confluence. If we begin using Confluence in an ad hoc way then I have
so
Absolutely, Confluence would be great -- it'd be good place to create live
documents and tutorials that could evolve along with the code base...
On Fri, Dec 13, 2019 at 2:02 PM Justin Mclean
wrote:
> Hi,
>
> > So where in Apache is an appropriate place to put shared documents, the
> Apache publi
WRT to this build issue, it used to work without a git repo. Disclaimer:
I responsible for the original commit, a portion of which Greg reverted
today...
This is a good opportunity to discuss a larger topic -- this is just one
instance of a class of problems that can be minimized [or even avoided
Has the SGA been filled in and submitted?
No, AFAIK, no SGA's have been filed. The wording here is
https://incubator.apache.org/guides/ip_clearance.html is unclear to me
under "Establishing Provenance". Contributor in this case refers to
copyright holders, I assume? The BSD headers list o
Hi,
> that we are playing chicken with putting critical processes in place and
> making the transition to Apache repositories. That transition supposed to
> happen next week, right?
It happens when the PPMC decided for it to happen. But first the SGA needs to
de accepted [1] and then we may n
So where in Apache is an appropriate place to put shared documents, the Apache
public equivalent of my shared drive? I have been trying to scare people into
action on this workflow here for days now, but I guess this a brave group or
just completely blind to what is coming.
Best place is c
Hi,
> So where in Apache is an appropriate place to put shared documents, the
> Apache public equivalent of my shared drive? I have been trying to scare
> people into action on this workflow here for days now, but I guess this a
> brave group or just completely blind to what is coming.
Best p
What is coming is 10-30 patches per day. When the Apache repositories
are set up. I will cease processing all changes. All PRs and patches
that I receive will be forwarded to this email. It is then the PPMC's
total responsibility to deal with them. Drop the ball for one day and
you will
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
So we definitely need to continue discussing what process changes to
these critical parts should undergo on their way into NuttX.
I think "continue" is generous. I don't think the discussion has
successfully even gotten off the ground. It is a looming crisis that is
going hit us like a Ts
To add to the patch-to-merge workflow discussion, an anecdote.
Earlier today I jokingly wrote "For the build system we should
require more PMC votes than we have PMC members!!"
Soon after, I grabbed the latest updates and tried to build my
configurations and... the build was broken!
I wrote:
[[
On Fri, Dec 13, 2019 at 1:40 PM David S. Alessio
wrote:
> Testing… I’ve joined.
Yup, received.
Note that with gmail you probably won't see your own email echoing back
from the group.
Testing… I’ve joined.
No, the APPSDIR is configure-able. The default configurations all use
../apps/ for APPSDIR because there are not other apps in the
repositores. There have been many discussions on the old forums on how
to use custom applications, so I know end users actually do that. I
know, for example, tha
On Fri, Dec 13, 2019 at 8:05 AM Gregory Nutt wrote:
> Let's fully understand the release process before proposing a solution.
+1.
More below...
> No, the APPSDIR is configure-able. The default configurations all use
> ../apps/ for APPSDIR because there are not other apps in the
> repositores.
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 dow
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 consi
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
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 woul
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
so
I think the below steps will do a an atomic tag/branch (Branch protections
may be needed as well)
Let's fully understand the release process before proposing a solution.
That sounds like a disaster.
However, it exemplifies why Submodules are evil but useful. A much simpler
approach is 2 fol
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 r
Greg,
I think the below steps will do a an atomic tag/branch (Branch protections
may be needed as well)
However, it exemplifies why Submodules are evil but useful. A much simpler
approach is 2 folder is the same project - I am aware of ALL the arguments -
I agree with most of them but there are
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
41 matches
Mail list logo
