1 |
On 20/08/16 08:30 PM, Daniel Campbell wrote: |
2 |
> On 08/15/2016 12:42 PM, Rich Freeman wrote: |
3 |
>> On Mon, Aug 15, 2016 at 3:30 PM, Andreas K. Hüttel <dilfridge@g.o> wrote: |
4 |
>>> 1) Stabilization is a simpler and much more formalized process compared to |
5 |
>>> normal bug resolution. |
6 |
>>> * There is one version to be stabilized. |
7 |
>>> * One precise package version |
8 |
>> |
9 |
>> Can you clarify what this means? Do you mean that at any time only |
10 |
>> one version of any particular package/slot is marked stable? |
11 |
>> |
12 |
>> That seems like it would be problematic for ranged deps. Granted, |
13 |
>> those are problematic in and of themselves since they can create |
14 |
>> conflicts that are hard to resolve. However, this extends conflicts |
15 |
>> between package you might not want to install at the same time to |
16 |
>> situations where you don't even need both of the conflicting packages. |
17 |
>> |
18 |
> I believe he's just talking about a per-bug or per-stablereq basis. So |
19 |
> each version gets its own opportunity to have bugs surface or |
20 |
> stabilization issues instead of attempting to stabilize a bunch of |
21 |
> versions at once. |
22 |
> |
23 |
> (Correct me if I'm wrong; I don't see the value of a single stable |
24 |
> version for each package and it would create a lot of noise in git log) |
25 |
> |
26 |
|
27 |
Even though some projects (mozilla, for instance) do request |
28 |
stabilizations of multiple packages and/or versions in a single go, |
29 |
that doesn't mean we should and I have no issues changing our process |
30 |
to something more atomic. |
31 |
|
32 |
What should be noted here is that if we work towards adopting new |
33 |
tools or methods here, we absolutely need to do so in a way that is |
34 |
beneficial to the workflow of our AT's, especially those that perform |
35 |
large numbers of stabilizations like ago. If this new process doesn't |
36 |
make things at least incrementally easier for them, it needs to be |
37 |
re-thought. |