Opened on 10/04/17 at 16:23:01
Last modified on 10/13/18 at 22:53:47
#3165 assigned enhancement
Rework components of the ticket system — at Version 17
Reported by: | Sebastian Huber | Owned by: | Sebastian Huber |
---|---|---|---|
Priority: | normal | Milestone: | Indefinite |
Component: | unspecified | Version: | 5 |
Severity: | normal | Keywords: | |
Cc: | Blocked By: | ||
Blocking: |
Description (last modified by Sebastian Huber)
A look at
https://devel.rtems.org/milestone/4.12.0
reveals that the components are not a big help to get an overview of the tickets since they cluster in the two components General and cpukit.
I would like to replace the existing components with:
- build
- config
- dev
- dev/i2c
- dev/serial
- dev/spi
- doc
- fs
- fs/fat
- fs/jaffs2
- fs/rfs
- lib
- lib/block
- lib/dl
- network
- network/legacy
- network/libbsd
- posix
- rtems
- score
- shell
- arch/arm
- arch/bfin
- arch/epiphany
- arch/i386
- arch/lm32
- arch/m32c
- arch/m68k
- arch/mips
- arch/moxie
- arch/nios2
- arch/or1k
- arch/powerpc
- arch/sh
- arch/sparc
- arch/sparc64
- arch/v850
- tool
- tool/binutils
- tool/gcc
- tool/gdb
- tool/newlib
- tool/rsb
- tool/tools
- tool/trac
- tool/website
- unspecified
With the following initial mapping:
- Ada -> tool/gcc
- Autoconf -> build
- Automake -> build
- Bare -> unspecified
- Binutils -> tool/binutils
- Code -> unspecified
- CrossRPM -> unspecified
- Documentation -> doc
- GCC -> tool/gcc
- GDB -> tool/gdb
- General -> unspecified
- MinGW -> tool/rsb
- Minimum Version Checks -> unspecified
- Newlib -> tool/newlib
- Other -> unspecified
- RSB -> tool/rsb
- RTEMS Configuration -> config
- SMP -> unspecified
- admin -> unspecified
- bsps -> target
- build -> build
- cpukit -> unspecified
- doc -> doc
- filesystem -> fs
- libbsd -> network/libbsd
- libcpu -> unspecified
- libdl -> lib/dl
- misc -> unspecified
- networking -> network/legacy
- patch - do not use -> unspecified
- pending -> unspecified
- pppd -> network/legacy
- shell -> shell
- testing -> unspecified
- tools -> tool
- web -> tool/website
Change History (17)
comment:1 follow-up: 2 Changed on 10/04/17 at 16:26:14 by Amar Takhar
comment:2 Changed on 10/04/17 at 23:50:53 by Chris Johns
Replying to Amar Takhar:
FYI it's possible for us to create custom ticket fields which may be a nice place to put 'target'.
What do you mean by target
, a BSP or something else?
comment:3 follow-up: 4 Changed on 10/05/17 at 04:59:57 by Sebastian Huber
Ok, "target" alone makes probably no sense. The "target/X" should catch anything which is related to a particular target architecture, e.g. CPU port and BSPs.
comment:4 follow-up: 5 Changed on 10/05/17 at 05:20:02 by Chris Johns
Replying to Sebastian Huber:
Ok, "target" alone makes probably no sense.
Agreed.
The "target/X" should catch anything which is related to a particular target architecture, e.g. CPU port and BSPs.
Could you please expand on this? It is not clear to me what this means.
comment:5 follow-up: 6 Changed on 10/05/17 at 05:28:50 by Sebastian Huber
Replying to Chris Johns:
Replying to Sebastian Huber:
The "target/X" should catch anything which is related to a particular target architecture, e.g. CPU port and BSPs.
Could you please expand on this? It is not clear to me what this means.
Bugs in a BSP, the CPU port (cpukit/score/cpu/X). Bugs that are only present for arm-rtems4.12, but not for powerpc-rtems4.12, etc.
comment:6 Changed on 10/05/17 at 05:31:09 by Chris Johns
Replying to Sebastian Huber:
Bugs in a BSP, the CPU port (cpukit/score/cpu/X). Bugs that are only present for arm-rtems4.12, but not for powerpc-rtems4.12, etc.
I understand purpose, the implementation is not clear to me and what X
means.
Do you propose target/arm
, target/arm/zedboard
, or something else?
comment:7 follow-up: 9 Changed on 10/05/17 at 05:32:29 by Sebastian Huber
Just, target/arm. We should not have too many components.
comment:8 follow-up: 10 Changed on 10/05/17 at 05:37:07 by Sebastian Huber
Maybe we should reduce
- lib
- lib/block
- lib/dl
- lib/drvmgr
to just
- lib
Also
- fs
- fs/fat
- fs/ftpfs
- fs/imfs
- fs/jaffs2
- fs/nfs
- fs/rfs
- fs/tftpfs
to
- fs
- fs/fat
- fs/jaffs2
- fs/rfs
comment:9 Changed on 10/05/17 at 05:38:22 by Chris Johns
Replying to Sebastian Huber:
Just, target/arm. We should not have too many components.
Then I propose arch/arm
and not target
. I have been attempting to make consistent the way to address a specific BSP as arch/bsp and so I would prefer we attempt to limit our usage to arch
and bsp
. A target could be defined as arch/bsp.
comment:10 Changed on 10/05/17 at 05:39:03 by Chris Johns
Replying to Sebastian Huber:
Maybe we should reduce
Yes, this is better. It help management and the milestone report is simpler.
comment:11 Changed on 10/05/17 at 05:45:29 by Sebastian Huber
Description: | modified (diff) |
---|
I updated the components. I removed the lang/* stuff, since this overlaps with tool/gcc.
comment:12 Changed on 10/05/17 at 05:50:45 by Chris Johns
lang/ada to tool/gnat ?
Is the second part of the list up to date, ie tool/web and tool/website?
comment:13 Changed on 10/05/17 at 05:53:34 by Sebastian Huber
Description: | modified (diff) |
---|
comment:15 Changed on 10/05/17 at 06:04:38 by Chris Johns
Still not sure about just lib and if we need lib/dl and lib/block. They are big pieces of code that are specific.
What about examples and testsuite?
comment:17 Changed on 10/05/17 at 06:24:06 by Sebastian Huber
Description: | modified (diff) |
---|
Add lib/block and lib/dl.
FYI it's possible for us to create custom ticket fields which may be a nice place to put 'target'.