From Fedora Project Wiki
m (Fixed template) |
m (→The plan) |
||
| Line 13: | Line 13: | ||
The front page would be along [[DraftPageUAEL]] . | The front page would be along [[DraftPageUAEL]] . | ||
* add a wiki page with the list the packages in a Base + Core install and let | * add a wiki page with the list the packages in a Base + Core install and let people add their name if they are ready to maintain that package. A packager ready to maintain such a package should at least be approved in the package database as watchcommit and watchbugzilla for this packages for branches that are more recent than the branch he intends to maintain. | ||
people add their name if they are ready to maintain that package. A packager | * start a SIG (with, at least all the maintainers of the above packages) and a mailing list | ||
ready to maintain such a package should at least be approved in the | * discuss with releng the infrastructure bits (use the same directory than releases in cvs?...), find somebody to do the bohdi pushes | ||
package database as watchcommit and watchbugzilla for this packages for | * begin to ask for branches in cvs (based on the process discussed above) | ||
branches that are more recent than the branch he intends to maintain. | |||
* start a SIG (with, at least all the maintainers of the above packages) | |||
and a mailing list | |||
* discuss with releng the infrastructure bits (use the same directory | |||
than releases in cvs?...), find somebody to do the bohdi pushes | |||
* begin to ask for branches in cvs (based on the process discussed | |||
above) | |||
* do a script to generate the list of packages (I can volunteer for that) | * do a script to generate the list of packages (I can volunteer for that) | ||
Revision as of 18:48, 10 November 2008
this project is retired. There is no agreement on the metric used to define if a maintainer is really taking care of a package. PatriceDumas wanted to trust a packager to do his job once he has signed for the branch and that the processes of Fedora would be enough (NonResponsiveMaintainers policy, telling on mailing list and escalation to the relevant commitee) to force those who don't maintain a package to stop claiming they do. Jeff Spaleta wanted to have better metrics for maintainers of the minimal set to be sure that they don't let themselves get burned in maintaining too much packages to be sure that the branch is still maintained.
Updates After End of Life project
This is a draft explaining a possible plan for a project hosted by the Fedora project, but distinct (that is Fedora provides infrastructure, but isn't supporting the project). The aim is to have a volunteer based set of packages updated. There is a minimal set, corresponding with non optional packages from Base+Comp and the kernel, when one of this package isn't maintained anymore, the branch is discontinued after a week that can be used find a new maintainer.
Branches are not created automatically a maintainer has to step up.
The maximum time for a branch will be set by those who take care of the infrastructure with a maximum of 5 years.
The plan
The front page would be along DraftPageUAEL .
- add a wiki page with the list the packages in a Base + Core install and let people add their name if they are ready to maintain that package. A packager ready to maintain such a package should at least be approved in the package database as watchcommit and watchbugzilla for this packages for branches that are more recent than the branch he intends to maintain.
- start a SIG (with, at least all the maintainers of the above packages) and a mailing list
- discuss with releng the infrastructure bits (use the same directory than releases in cvs?...), find somebody to do the bohdi pushes
- begin to ask for branches in cvs (based on the process discussed above)
- do a script to generate the list of packages (I can volunteer for that)