| 1 |
On Thu, Jul 26, 2018 at 8:45 AM Grand Duet <grand.duet@×××××.com> wrote: |
| 2 |
> |
| 3 |
> Anyway, it is a good idea to write a news on changing python_targets |
| 4 |
> and major version of gcc, even if no developper expects any troubles, |
| 5 |
> because we already know their predictive (dis)ability. :) |
| 6 |
> |
| 7 |
|
| 8 |
You won't get any argument from me there - more news is usually |
| 9 |
better. If nothing else people want to know they don't have to do |
| 10 |
something when they see 200 packages being upgraded. |
| 11 |
|
| 12 |
> > Did this even impact the stable branch? |
| 13 |
> |
| 14 |
> Yes. |
| 15 |
|
| 16 |
Hmm, I suspect I didn't sync before it was reverted. Either that or I |
| 17 |
noticed the noise on the lists and waited a day. |
| 18 |
|
| 19 |
This is one issue with our news - it isn't really realtime. If we |
| 20 |
want people to hold the presses and re-sync they don't get that notice |
| 21 |
until they've already re-synced. |
| 22 |
|
| 23 |
> May be, adding some additional "almost stable" level between |
| 24 |
> "stable" and "unstable" one to make "stable" stable indeed? |
| 25 |
|
| 26 |
If anything it seems like the proposal to drop stable comes along |
| 27 |
every few years. I don't see anybody being eager to add another level |
| 28 |
of QA. A big practical issue would be that unless people are actually |
| 29 |
using the two lower levels significantly then nothing is actually |
| 30 |
getting checked before going to stable. |
| 31 |
|
| 32 |
There is really no reason you couldn't have a release-based Gentoo |
| 33 |
derivative. Everything is in git. All "somebody" needs to do is |
| 34 |
start a repo with a release-driven workflow that treats Gentoo as the |
| 35 |
upstream master branch, targeting changes for release branches and |
| 36 |
then doing release candidates and QA/etc. Then those release-based |
| 37 |
users would sync from there instead of the upstream Gentoo repo. |
| 38 |
Ideally somebody would bundle it with a reference binary repo that |
| 39 |
people could optionally sync from to speed installs for packages where |
| 40 |
they're not changing USE flags. |
| 41 |
|
| 42 |
The problem is that this all takes quite a bit of work, and I'm |
| 43 |
skeptical that it would ever happen. However, for larger Gentoo |
| 44 |
deployments in production environments I suspect most are doing things |
| 45 |
more-or-less in this fashion, but just with the packages they care |
| 46 |
about. If somebody has 100 production servers running Gentoo I doubt |
| 47 |
they are set to just sync from us. Rather they would set up their own |
| 48 |
mirror and carefully test portage snapshots before they go rolling |
| 49 |
them out. |
| 50 |
|
| 51 |
-- |
| 52 |
Rich |
Archives