| 1 |
On sob, 2017-05-06 at 19:36 +0200, Andreas K. Huettel wrote: |
| 2 |
> Am Samstag, 6. Mai 2017, 18:35:08 CEST schrieb Michał Górny: |
| 3 |
> > |
| 4 |
> > > An implementation is still missing though. |
| 5 |
> > |
| 6 |
> > ...and a rationale section to describe why you did the things this way. |
| 7 |
> |
| 8 |
> Well, that's more or less the Motivation section. Should I rename it? |
| 9 |
|
| 10 |
No. Motivation answers the question 'what is the problem being solved?', |
| 11 |
and in your case it serves that purpose well. Rationale is 'why did I |
| 12 |
choose this specific solution?' -- e.g. choice of file format, keywords |
| 13 |
and basically answers to every useful question that has been raised. |
| 14 |
|
| 15 |
> > 2. I can't say I like using magical keywords like 'testing' |
| 16 |
> > and 'unstable'; they're going to be confusing long-term (compare: |
| 17 |
> > the mess with stable/exp/dev for profiles). But I don't have a very good |
| 18 |
> > idea how to it better right now. |
| 19 |
> |
| 20 |
> Well, I pulled the two terms that are tradidionally used for ~arch... |
| 21 |
> "testing" and "unstable". Testing implied to me that a transition is taking |
| 22 |
> place, so that went to the "mixed state". |
| 23 |
|
| 24 |
I should point out that those terms are frequently used interchangeably, |
| 25 |
and adding disjoint meanings to them is least misleading. Perhaps a name |
| 26 |
like 'transitional' for the middle state would be better? |
| 27 |
|
| 28 |
> There's also Kent's proposal where some more indirection is introduced (see |
| 29 |
> the discussion threads). It more or less achives the same with even more |
| 30 |
> flexibility. I dont like it so much because I want to keep things simple. |
| 31 |
|
| 32 |
Yes, we don't need yet another python.eclass. |
| 33 |
|
| 34 |
> > 3. What is the use case for 'broken'? Are we ever going to use that? |
| 35 |
> |
| 36 |
> None that I know of. I only added it because it was suggested on the list (and |
| 37 |
> because it's simple to define and implement). |
| 38 |
|
| 39 |
Well, I was mostly asking because: |
| 40 |
|
| 41 |
a. without that, there would be no reason to repeat that dev/exp repoman |
| 42 |
magic in all three definitions, |
| 43 |
|
| 44 |
b. I fail to see any reason to have stable/exp/dev profile split for |
| 45 |
arch where even the most basic package integrity is not guaranteed. It's |
| 46 |
like having repoman check the profiles for nothing... |
| 47 |
|
| 48 |
-- |
| 49 |
Best regards, |
| 50 |
Michał Górny |
Archives