Apart from the tool issue, what we miss the most are processes, in the sense of project management, not osdev ;). We have distributed teams and individuals that work towards their established goals. The problem is that the community doesn't know these goals. It may even be the case that the company's goal is contrary to the community's goal, or the goal of another company.
Without knowing these, we are unable to assess whether changes make sense and even if someone is willing to spend time on a review - it is unproductive. What's more, without knowledge, changes can be introduced without general consent in the community, which will later lead to problems. Ideally, each PR should have its own Issue which, after merging, is resolved in whole or in part (sub-task in issue). Of course, this is practically impossible to implement for all changes, but for large PRs or a series of PRs this could be obligatory. Any major change or series of changes planned by companies or individual contributors should be known to the community. If there are any doubts, it should be discussed and in case of disagreement, voted in the Apache way. But is it possible to implement? Are the companies working on NuttX and contributing their changes to upstream able to present in advance the topics they will be working on in the near future? In the case of individual contributors who are not affected by company policies and bureaucracies, this is probably not a problem. So this is more of a question for representatives of the most active companies in this project: Xiaomi, Sony, Espressif or Offcode (sorry if I missed anyone). Without addressing this problem, no tool will help us. You can't fix broken processes and management, even with the best tools. sob., 1 lut 2025 o 01:01 Tomek CEDRO <to...@cedro.info> napisał(a): > On Fri, Jan 31, 2025 at 11:55 PM Gregory Nutt <spudan...@gmail.com> wrote: > > On 1/31/2025 3:52 PM, Tomek CEDRO wrote: > > > Greg I do not plan to reorganize existing _repositories_ and their > > > structure nor to reorganize the _project_ in any way :-) > > > > No, I was referring to the concept of putting all Issues under one > > repository. That was the topic in 2019 and 2020. (although other > > misguided people wanted to put apps under nuttx/ too). > > > > Jira and Confluence are provided by the ASF, but no one was interested > > in that for issue tracking. > > > > I personally prefer to see each repository to be standalone as they are > > now, rather that mixing any apps stuff into the OS, even if it is only > > Issues. I would rather see Issues and PRs together in the same > > repository to which they reply. That is driven mostly by my sense a > > modularity and partitioning. > > I am sorry for not providing enough initial context in this thread. It > comes from a discussion on how to improve things from another thread > (about roadmap, task owners, etc). I prefer to keep things clean so I > started this new thread dedicated only to playing around with "new > application XYZ on GitHub" that can be used to visualize stuff from > our repositories. This XYZ is unfortunately confusingly named "GitHub > Projects"^TM. Thus "Yoda Style" subject of the thread that reads > "Roadmap testing approach with GitHub Projects tool for NuttX" :D We > can try it out and see if that fits what we were talking about, > without existing repos modification, or just delete the testing > grounds :-) > > Jira will double the work and we have to follow two different places > which is distracting and discouraging imho :-P On the other hand this > XYZ showed up recently on GitHub so we can access Code, Issues, PRs > (as part of the repo) and the XYZ application (separately in addition > to repo) on a single GitHub website using the same username. So XYZ > may be easier to use for that reason alone even if its simpler at this > point or offers less possibilities than Jira. > > Everything in our repositories and project organization remains untouched! > :-) > > The problem is just in this silly name "GitHub Projects"^TM that they > probably used to resemble "Microsoft Projects" or whatever its called, > so "managers can now also work on GitHub"^TM :D > > With this new XYZ tool we can create a "project management table". Its > only called "GitHub Project"^TM but its like separate wiki page > outside repo but still on github lets call it "table". This XYZ will > look into existing nuttx, nuttx-apps, nuttx-website repositories and > create a table where we can attach Issues or Pull Requests to > visualize them in "human readable roadmap like form". Even URL is > different and outside existing repo. Thats it, no harm done to > existing stuff :-) > > Here is an example playground: > > https://github.com/orgs/apache/projects/455 > > Yesterday I didn't know yet if I need to create a separate table for > each repo, because I didn't know yet if a single table can access > issues and prs from various other repos. Today I know it is possible > to attach Issues and PRs from all of our repos to a single table. This > was my comment that we can display stuff from all 3 repos in a single > table and we don't need 3 separate tables for each repo, so we can > "keep all items in one place" on a single table. > > Example URL above displays a table with some tasks displayed from > nuttx, nuttx-apps, and nuttx-website that is the whole project parts. > For a comparison below we can see a table dedicated only to > nuttx-website: > > https://github.com/orgs/apache/projects/457 > > Which approach is better? To have single table that displays selected > tasks from all 3 repos, or to have a separate tables for each repo? I > feel that single table display may be better because we have a clear > "roadmap" for the whole project and we can see the progress of all > three repositories :-P > > This table system also allows creating new Issues on selected repo, we > can even display issues from other relevant repos (i.e. LVGL, > Espressif, etc), creating simple tasks dependency, mark tasks state > "todo", "in progress", "done", etc etc. So its more like management > table that operates on external existing repos. Kind of management > display. Maybe a "GitHub Manager" name would be less confusing :-P > > That's my several hours fly-by experience, its a simple tool (for > now), it has some pros and cons, I think it may fit the need :-) > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > > On Fri, Jan 31, 2025 at 11:55 PM Gregory Nutt <spudan...@gmail.com> wrote: > > > > > > On 1/31/2025 3:52 PM, Tomek CEDRO wrote: > > > Greg I do not plan to reorganize existing _repositories_ and their > > > structure nor to reorganize the _project_ in any way :-) > > > > No, I was referring to the concept of putting all Issues under one > > repository. That was the topic in 2019 and 2020. (although other > > misguided people wanted to put apps under nuttx/ too). > > > > Jira and Confluence are provided by the ASF, but no one was interested > > in that for issue tracking. > > > > I personally prefer to see each repository to be standalone as they are > > now, rather that mixing any apps stuff into the OS, even if it is only > > Issues. I would rather see Issues and PRs together in the same > > repository to which they reply. That is driven mostly by my sense a > > modularity and partitioning. > > > > But ASF projects are complete anarchist democracies and people may > > choose as they like. I don't really give a flying f**k. > > > > > > > > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info >
