1 |
On Wed, 2006-11-29 at 06:37 +0000, Steve Long wrote: |
2 |
> <snip> .. The one |
3 |
> > disadvantage to my design is it needs infra. It needs it's own |
4 |
> > repository and rsync. |
5 |
> > |
6 |
> What does that entail? Would a co-located server suffice? |
7 |
|
8 |
Sure. It would be much better to simply use what we currently have, |
9 |
though. Honestly, I was pursuing this with Infra a few months back, and |
10 |
have since dropped it, due to time constraints. I plan on picking it |
11 |
back up, as I said, so I don't know what is necessary at this point. |
12 |
|
13 |
> > Now, the release trees are non-moving. The 2007.0-release tree is |
14 |
> > *always* the 2007.0-release tree for as long as we decide to support it. |
15 |
> > Likely, this support period would begin as a single release and get |
16 |
> > extended as volunteers came around to support it. New releases get |
17 |
> > their own tree. |
18 |
> > |
19 |
> Well count me in as a volunteer to help set this up and maintain an x86 |
20 |
> release. I'm a pretty good coder if that helps. |
21 |
|
22 |
There wouldn't be an "x86 release" or anything. It would be the whole |
23 |
thing. All or nothing. |
24 |
|
25 |
> > Users who want to use the current portage tree get what they want. |
26 |
> > Users who want a more stable tree get what they want. Basically, |
27 |
> > everyone (hopefully) is happy, or at least as happy as we can feasibly |
28 |
> > make them. |
29 |
> > |
30 |
> This all sounds great. Respect for the work you've already put in. |
31 |
|
32 |
Well, Andrew Gaffney really helped out, as he's been doing the python |
33 |
work to utilize portage to get the proper information to strip the tree. |
34 |
Since these scripts were originally written and subsequently abandoned, |
35 |
they've needed a little work. Andrew and I are working on this now to |
36 |
try to get everything back to working order. |
37 |
|
38 |
> From your post we need to add: |
39 |
> > - strip all USE flags that aren't used from use.mask (per-profile) |
40 |
> > - strip all packages that aren't available from package.mask |
41 |
> > (per-profile) |
42 |
> |
43 |
> What language is the script implemented in? |
44 |
|
45 |
There are several scripts. They are written in either python or bash. |
46 |
|
47 |
> Wrt security updates, is it possible to tie into GLSAs so that we could |
48 |
> automate updating packages that need it? By updating I mean adding the |
49 |
> ebuilds and any dependencies (or dependants that might require updating.) |
50 |
|
51 |
What were you expecting that we would do? |
52 |
|
53 |
> Would that help in terms of having say, up to date GUI packages, or is it |
54 |
> just easier to use overlays? |
55 |
|
56 |
I have no desire to support any packages that weren't in the original |
57 |
tree. If you want something we aren't providing, use an overlay. |
58 |
|
59 |
> Chris Gianelloni wrote: |
60 |
> |
61 |
> > No version changes on any packages, except those which are necessary due |
62 |
> > to a security violation, or a vulnerable package's dependencies. |
63 |
> > |
64 |
> I could imagine a situation where a dependant package (ie one using the |
65 |
> package updated) would also require an update. It'd be rare though, so I |
66 |
> guess it wouldn't need automating. |
67 |
|
68 |
"or a vulnerable package's dependencies" |
69 |
|
70 |
> > Something that would be useful would be for package maintainers that |
71 |
> > wish to participate to perform further testing and validation on |
72 |
> > packages in the release snapshot prior to its final freeze. This would |
73 |
> > give us even more eyes on the tree and hopefully provide a much higher |
74 |
> > quality snapshot once we're done. |
75 |
> |
76 |
> It sounds like it'd also make the releases in general have better QA. What |
77 |
> do package/ herd maintainers think? |
78 |
|
79 |
Absolutely. |
80 |
|
81 |
One thing that I am working on doing with agaffney is building more and |
82 |
more automated systems for doing testing. We have our Release |
83 |
Engineering build box doing weekly builds of all of the stages from |
84 |
scratch for i686. I plan on doing the same for i586/no-nptl, to cover |
85 |
that facet, as well as amd64. Currently, I am testing against the |
86 |
dev/2007.0 profile, but plan on testing against dev/2007.0/desktop and |
87 |
dev/2007.0/server in addition to the dev/2007.0 profile. |
88 |
|
89 |
I will also be adding a test suite on my Alpha and PPC machines at home. |
90 |
Aside from this, I will be running catalyst tinderbox builds on at least |
91 |
x86/amd64 for many packages that aren't included in the LiveCD/LiveDVD |
92 |
sets. At some point, I'll likely be asking for suggestions on packages |
93 |
to add to this testing. |
94 |
|
95 |
-- |
96 |
Chris Gianelloni |
97 |
Release Engineering Strategic Lead |
98 |
Alpha/AMD64/x86 Architecture Teams |
99 |
Games Developer/Council Member/Foundation Trustee |
100 |
Gentoo Foundation |