On 10/04/2016 10:25 AM, Ian Stakenvicius wrote: > On 20/08/16 08:30 PM, Daniel Campbell wrote: >> On 08/15/2016 12:42 PM, Rich Freeman wrote: >>> On Mon, Aug 15, 2016 at 3:30 PM, Andreas K. Hüttel wrote: >>>> 1) Stabilization is a simpler and much more formalized process compared to >>>> normal bug resolution. >>>> * There is one version to be stabilized. >>>> * One precise package version >>> >>> Can you clarify what this means? Do you mean that at any time only >>> one version of any particular package/slot is marked stable? >>> >>> That seems like it would be problematic for ranged deps. Granted, >>> those are problematic in and of themselves since they can create >>> conflicts that are hard to resolve. However, this extends conflicts >>> between package you might not want to install at the same time to >>> situations where you don't even need both of the conflicting packages. >>> >> I believe he's just talking about a per-bug or per-stablereq basis. So >> each version gets its own opportunity to have bugs surface or >> stabilization issues instead of attempting to stabilize a bunch of >> versions at once. >> >> (Correct me if I'm wrong; I don't see the value of a single stable >> version for each package and it would create a lot of noise in git log) >> > > Even though some projects (mozilla, for instance) do request > stabilizations of multiple packages and/or versions in a single go, > that doesn't mean we should and I have no issues changing our process > to something more atomic. > > What should be noted here is that if we work towards adopting new > tools or methods here, we absolutely need to do so in a way that is > beneficial to the workflow of our AT's, especially those that perform > large numbers of stabilizations like ago. If this new process doesn't > make things at least incrementally easier for them, it needs to be > re-thought. > > What sort of things would fit best into AT workflow? Different bug states make it easier to filter bugs for ourselves. Is there another mechanic you'd rather see? -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6