| 1 |
On Wed, Apr 8, 2015 at 7:51 AM, William Hubbs <williamh@g.o> wrote: |
| 2 |
> |
| 3 |
> Changing the status of the arches in repoman is all I thought we were |
| 4 |
> discussing. I wasn't saying we should revert or remove stable keywords |
| 5 |
> for them. I think that's what vapier is doing with s390, sh, etc. |
| 6 |
> |
| 7 |
> Marking the arches dev or exp in the profiles means that repoman, by |
| 8 |
> default, doesn't complain about broken depgraphs for them. |
| 9 |
|
| 10 |
Well, we really have a few options as far as imposing changes from |
| 11 |
outside the arch team goes (the arch team can clean up its own |
| 12 |
depgraph, of course, but presumably we'd be taking action only if they |
| 13 |
didn't). |
| 14 |
|
| 15 |
1. We could make the arches dev/exp as you point out, and then allow |
| 16 |
maintainers to just drop stable versions and break their depgraph. |
| 17 |
|
| 18 |
2. We could keep the arches as stable, but then allow maintainers to |
| 19 |
do massive keyword changes when they drop otherwise-stable versions. |
| 20 |
That wouldn't break the depgraph, but it would mean that at random |
| 21 |
times huge numbers of packages could have their keywords change. |
| 22 |
|
| 23 |
Neither option is really ideal. I think that #1 is the lesser evil, |
| 24 |
but that does mean that we need to make a distro-wide decision. The |
| 25 |
advantage of #2 is that it basically is a NOP unless the arch team |
| 26 |
actually reaches 90 days old. I think it is better to just have the |
| 27 |
Council make a decision rather than kicking the can, but that said if |
| 28 |
an arch team is willing to state clearly that they intend to |
| 29 |
proactively clean up their depgraph and that they want to keep stable |
| 30 |
keywords, I'm fine with checking back in a month rather than |
| 31 |
de-stabilizing them next week. |
| 32 |
|
| 33 |
-- |
| 34 |
Rich |
Archives