| 1 |
В Вск, 28/03/2010 в 07:47 +0200, Maciej Mrozowski пишет: |
| 2 |
> No, seriously - given the fact that some of my packages were even stabilized |
| 3 |
> without contacting me (app-misc/hal-cups-utils, app-admin/system-config- |
| 4 |
> printer-common) |
| 5 |
|
| 6 |
If you know packages are broken why they were not hardmasked? If they |
| 7 |
have no problems what why it was bad idea to mark them stable? |
| 8 |
|
| 9 |
> * solely up to the package maintainers to stabilize application on arches |
| 10 |
> they're using or on any arch if package is arch-agnostic (optionally, but |
| 11 |
> preferably with some peer review from other project members or arch team |
| 12 |
> members). |
| 13 |
|
| 14 |
In general package maintainer should avoid to stabilize the packages he |
| 15 |
worked on as one of the arch team's goal was to have second eyes on |
| 16 |
package before it goes stable. |
| 17 |
|
| 18 |
> Role of arch teams would be decreased to peer review and solving KEYWORD |
| 19 |
> requests. |
| 20 |
> |
| 21 |
> It's really freaking silly to wait months for stabilization of some random |
| 22 |
> php/perl library that's known to work. |
| 23 |
|
| 24 |
Why wait? amd64 team requested help and every developer who tested |
| 25 |
package on stable profile is allowed to mark package stable. For rare |
| 26 |
archs it's possible configure search filters to avoid stabilization |
| 27 |
requests. |
| 28 |
|
| 29 |
-- |
| 30 |
Peter. |
Archives