1 |
On Wed, 18 Nov 2015 06:59:19 -0500 |
2 |
Rich Freeman <rich0@g.o> wrote: |
3 |
|
4 |
> On Wed, Nov 18, 2015 at 6:05 AM, Ulrich Mueller <ulm@g.o> |
5 |
> wrote: |
6 |
> > |
7 |
> > And on what basis would you stabilise Portage, when there are no |
8 |
> > ebuilds in the tree to test its EAPI 6 code? |
9 |
> > |
10 |
> |
11 |
> As long as the EAPI6 code in the new portage is no more broken than |
12 |
> the EAPI6 code in the current stable version of portage (which doesn't |
13 |
> work/exist at all), it isn't much of a regression. What would be more |
14 |
> of a pain is dealing with fixes in stable. |
15 |
> |
16 |
> But, I don't have a problem with starting to use EAPI6 now, mainly |
17 |
> because the ~arch version of portage does not require any new ~arch |
18 |
> dependencies that would create a mess for stable users. So, if a user |
19 |
> needs to switch to a newer portage for a month or two it shouldn't be |
20 |
> that big of a deal. |
21 |
> |
22 |
|
23 |
The above part is fine :) |
24 |
|
25 |
|
26 |
But this next bit... |
27 |
|
28 |
> Actually, what is less clear to me is how portage versioning actually |
29 |
> works, or if we attach any meaning to the version numbers at all. |
30 |
> Both the stable and unstable series are on 2.2.x, but there are no |
31 |
> versions in the tree between 2.2.20 and 2.2.23. |
32 |
> |
33 |
|
34 |
So, we have 2 user groups, stable and unstable. |
35 |
|
36 |
Current stable is 2.2.20.1 |
37 |
current unstable is 2.2.25 <==just released |
38 |
|
39 |
So, when we release a new unstable version, unstable users upgrade, |
40 |
what do you think happens to the older unstable version at that point. |
41 |
It no longer receives much testing as the unstable users upgrade to the |
42 |
newer unstable version. |
43 |
|
44 |
If we feel that there is enough bugs in those that we do not want to |
45 |
stabilize it. Why would we keep it in the tree? Just so more users |
46 |
can potentially come across those bugs and open new bugs, since the old |
47 |
bugs for those were closed with the newer release that contains the fix? |
48 |
Are the bug wranglers low on work? |
49 |
|
50 |
Here is a current example: |
51 |
|
52 |
portage-2.2.23 is now old enough to consider stabilizing it. It |
53 |
contains a new cgroup feature. It has a bug making it difficult for |
54 |
people unless they again disable that feature. |
55 |
|
56 |
portage-2.2.24 has no new features, just a bunch of bug fixes. |
57 |
|
58 |
We decided that we will wait a few weeks and call for 2.2.24 to be |
59 |
stabilized, maybe we will wait just one week (not the normal 30 days), |
60 |
since 2.2.23 is out of consideration, 2.2.24 testing will dwindle to |
61 |
nothing in the next week as people upgrade to 2.2.25. |
62 |
|
63 |
With 2.2.4 becoming stable, why would we keep the buggy ~ 2.2.3 in the |
64 |
tree taking up space? We already established that ~ users will have |
65 |
migrated away from it. |
66 |
|
67 |
|
68 |
|
69 |
> The main thing I find painful in following ~arch on the odd package is |
70 |
> when maintainers drop versions quickly after bumping them. |
71 |
|
72 |
You want a package version with known serious bugs left in the tree so |
73 |
more people can experience them? |
74 |
|
75 |
> That tends |
76 |
> to result in a situation where if you follow ~arch you end up having |
77 |
> to accept lots of updates because none of the versions stay in the |
78 |
> tree long enough to actually get stabilized. |
79 |
|
80 |
that happens for some pkgs, if it happens too much for you, update less |
81 |
often. |
82 |
|
83 |
> Unless a ~arch package |
84 |
> version is so broken that it could never be stabilized it is probably |
85 |
> better to leave them there so that it is easier for users to drop back |
86 |
> from ~arch to stable without downgrading. |
87 |
> |
88 |
|
89 |
Rich, please re-read your above statements until you see the total |
90 |
failure in your logic. |
91 |
|
92 |
-- |
93 |
Brian Dolbec <dolsen> |