#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 Changed on 10/04/17 at 16:26:14 by Amar Takhar

FYI it's possible for us to create custom ticket fields which may be a nice place to put 'target'.

comment:2 in reply to:  1 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 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 in reply to:  3 ; 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 in reply to:  4 ; 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 in reply to:  5 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 Changed on 10/05/17 at 05:32:29 by Sebastian Huber

Just, target/arm. We should not have too many components.

comment:8 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 in reply to:  7 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 in reply to:  8 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:14 Changed on 10/05/17 at 05:54:06 by Sebastian Huber

GNAT is part of GCC.

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:16 Changed on 10/05/17 at 06:09:26 by Chris Johns

Do the project tickets map across ok?

comment:17 Changed on 10/05/17 at 06:24:06 by Sebastian Huber

Description: modified (diff)

Add lib/block and lib/dl.

Note: See TracTickets for help on using tickets.