| 2008-12-16 18:16:51 |
Pantelis Koukousoulas |
bug |
|
|
added bug |
| 2009-01-30 12:57:42 |
gumptravels |
description |
A major reason that currently the effort for debian packages is halted is lack of documentation.
* We don't know the constraints fully. What depends on what, what is contrary to debian policy etc
* We don't (fully) know the role of the fileinitializer app, or why ecf-filetransfer is a standalone package
* We don't fully understand P2 and its peculiarities
* We don't fully understand pdebuild, releng, basebuilder, eclipsebuilder and all this building paraphernalia, why
are they needed, which improvements would be acceptable by upstream etc. Also what are our options towards
a long-term maintainable solution.
* We don't yet understand the way things work for native libraries (.so). Where can we place them so they can
be shared by other packages as well but at the same time without breaking things.
The answers to all the above are scattered throughout bugzilla entries (redhat's and eclipse's mostly), Fedora wiki, debian wiki, mail list archives and even IRC logs or ultimately the code itself. It would be great if we could
organize a usable subset of this information to something readable that we can point new members of the
team to, in order to get them up to speed quickly.
The best place for this is the linux-distro project's wiki imho, since the problems are mostly common for all
distros and thus documentation will be helpful to most maintainers. |
A major reason that currently the effort for debian packages is halted is lack of documentation.
* We don't know the constraints fully. What depends on what, what is contrary to debian policy etc
* We don't (fully) know the role of the fileinitializer app, or why ecf-filetransfer is a standalone package
* We don't fully understand P2 and its peculiarities
* We don't fully understand pdebuild, releng, basebuilder, eclipsebuilder and all this building paraphernalia, why are they needed, which improvements would be acceptable by upstream etc. Also what are our options towards a long-term maintainable solution.
* We don't yet understand the way things work for native libraries (.so). Where can we place them so they can be shared by other packages as well but at the same time without breaking things.
(edited for readability)
The answers to all the above are scattered throughout bugzilla entries (redhat's and eclipse's mostly), Fedora wiki, debian wiki, mail list archives and even IRC logs or ultimately the code itself. It would be great if we could organize a usable subset of this information to something readable that we can point new members of the team to, in order to get them up to speed quickly.
The best place for this is the linux-distro project's wiki imho, since the problems are mostly common for all distros and thus documentation will be helpful to most maintainers. |
|
| 2009-01-30 12:58:23 |
gumptravels |
description |
A major reason that currently the effort for debian packages is halted is lack of documentation.
* We don't know the constraints fully. What depends on what, what is contrary to debian policy etc
* We don't (fully) know the role of the fileinitializer app, or why ecf-filetransfer is a standalone package
* We don't fully understand P2 and its peculiarities
* We don't fully understand pdebuild, releng, basebuilder, eclipsebuilder and all this building paraphernalia, why are they needed, which improvements would be acceptable by upstream etc. Also what are our options towards a long-term maintainable solution.
* We don't yet understand the way things work for native libraries (.so). Where can we place them so they can be shared by other packages as well but at the same time without breaking things.
(edited for readability)
The answers to all the above are scattered throughout bugzilla entries (redhat's and eclipse's mostly), Fedora wiki, debian wiki, mail list archives and even IRC logs or ultimately the code itself. It would be great if we could organize a usable subset of this information to something readable that we can point new members of the team to, in order to get them up to speed quickly.
The best place for this is the linux-distro project's wiki imho, since the problems are mostly common for all distros and thus documentation will be helpful to most maintainers. |
A major reason that currently the effort for debian packages is halted is lack of documentation.
* We don't know the constraints fully. What depends on what, what is contrary to debian policy etc
* We don't (fully) know the role of the fileinitializer app, or why ecf-filetransfer is a standalone package
* We don't fully understand P2 and its peculiarities
* We don't fully understand pdebuild, releng, basebuilder, eclipsebuilder and all this building paraphernalia, why are they needed, which improvements would be acceptable by upstream etc. Also what are our options towards a long-term maintainable solution.
* We don't yet understand the way things work for native libraries (.so). Where can we place them so they can be shared by other packages as well but at the same time without breaking things.
The answers to all the above are scattered throughout bugzilla entries (redhat's and eclipse's mostly), Fedora wiki, debian wiki, mail list archives and even IRC logs or ultimately the code itself. It would be great if we could organize a usable subset of this information to something readable that we can point new members of the team to, in order to get them up to speed quickly.
The best place for this is the linux-distro project's wiki imho, since the problems are mostly common for all distros and thus documentation will be helpful to most maintainers.
(edited for readability, or so I thought)
|
|
| 2009-01-30 13:29:33 |
gumptravels |
eclipse-debian: status |
New |
Confirmed |
|
| 2009-01-30 13:29:33 |
gumptravels |
eclipse-debian: statusexplanation |
|
|
|
| 2022-04-20 16:29:51 |
Immaculate Atim |
eclipse-debian: assignee |
|
Immaculate Atim (immaculate-atim) |
|
| 2022-04-20 16:35:25 |
Immaculate Atim |
eclipse-debian: status |
Confirmed |
In Progress |
|
