On Wed, 2006-11-29 at 06:37 +0000, Steve Long wrote: > <snip> .. The one > > disadvantage to my design is it needs infra. It needs it's own > > repository and rsync. > > > What does that entail? Would a co-located server suffice?
Sure. It would be much better to simply use what we currently have, though. Honestly, I was pursuing this with Infra a few months back, and have since dropped it, due to time constraints. I plan on picking it back up, as I said, so I don't know what is necessary at this point. > > Now, the release trees are non-moving. The 2007.0-release tree is > > *always* the 2007.0-release tree for as long as we decide to support it. > > Likely, this support period would begin as a single release and get > > extended as volunteers came around to support it. New releases get > > their own tree. > > > Well count me in as a volunteer to help set this up and maintain an x86 > release. I'm a pretty good coder if that helps. There wouldn't be an "x86 release" or anything. It would be the whole thing. All or nothing. > > Users who want to use the current portage tree get what they want. > > Users who want a more stable tree get what they want. Basically, > > everyone (hopefully) is happy, or at least as happy as we can feasibly > > make them. > > > This all sounds great. Respect for the work you've already put in. Well, Andrew Gaffney really helped out, as he's been doing the python work to utilize portage to get the proper information to strip the tree. Since these scripts were originally written and subsequently abandoned, they've needed a little work. Andrew and I are working on this now to try to get everything back to working order. > From your post we need to add: > > - strip all USE flags that aren't used from use.mask (per-profile) > > - strip all packages that aren't available from package.mask > > (per-profile) > > What language is the script implemented in? There are several scripts. They are written in either python or bash. > Wrt security updates, is it possible to tie into GLSAs so that we could > automate updating packages that need it? By updating I mean adding the > ebuilds and any dependencies (or dependants that might require updating.) What were you expecting that we would do? > Would that help in terms of having say, up to date GUI packages, or is it > just easier to use overlays? I have no desire to support any packages that weren't in the original tree. If you want something we aren't providing, use an overlay. > Chris Gianelloni wrote: > > > No version changes on any packages, except those which are necessary due > > to a security violation, or a vulnerable package's dependencies. > > > I could imagine a situation where a dependant package (ie one using the > package updated) would also require an update. It'd be rare though, so I > guess it wouldn't need automating. "or a vulnerable package's dependencies" > > Something that would be useful would be for package maintainers that > > wish to participate to perform further testing and validation on > > packages in the release snapshot prior to its final freeze. This would > > give us even more eyes on the tree and hopefully provide a much higher > > quality snapshot once we're done. > > It sounds like it'd also make the releases in general have better QA. What > do package/ herd maintainers think? Absolutely. One thing that I am working on doing with agaffney is building more and more automated systems for doing testing. We have our Release Engineering build box doing weekly builds of all of the stages from scratch for i686. I plan on doing the same for i586/no-nptl, to cover that facet, as well as amd64. Currently, I am testing against the dev/2007.0 profile, but plan on testing against dev/2007.0/desktop and dev/2007.0/server in addition to the dev/2007.0 profile. I will also be adding a test suite on my Alpha and PPC machines at home. Aside from this, I will be running catalyst tinderbox builds on at least x86/amd64 for many packages that aren't included in the LiveCD/LiveDVD sets. At some point, I'll likely be asking for suggestions on packages to add to this testing. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation
signature.asc
Description: This is a digitally signed message part
