From: Chris Gianelloni <wolf31o2@gentoo.org>
To: gentoo-dev-announce@lists.gentoo.org
Cc: gentoo-releng@lists.gentoo.org
Subject: [gentoo-releng] Summary from Release Engineering meeting on 23 Jan 2008
Date: Thu, 24 Jan 2008 14:52:38 -0800 [thread overview]
Message-ID: <1201215158.16962.61.camel@workbox.quova.com> (raw)
This summary was written by Donnie Berkholz, so don't give me any credit
for it... ;]
You can find the complete log at:
http://www.gentoo.org/proj/en/releng/meetings/20080123_initial_2008.0.txt
2008.0 release
--------------
Tentative schedule (dates may change):
Feb. 1 Snapshot of the tree taken
Feb. 25 Docs due to GDP from release coordinators
Feb. 25 Snapshot frozen for beta
Feb. 29 Docs finalized
Mar. 3 Beta1 released
Mar. 14 Final upload
Mar. 17 Release
To make it easier for the release engineering team to collaborate,
releng lead Chris Gianelloni (wolf31o2) wants all architectures to build
their releases on public developer machines. This also means that if an
architecture's release coordinator can't finish the release, anyone else
can pick up the work and continue.
The releng team plans a few changes to profiles. Moving to multiparent
profiles will significantly reduce the profiles' maintenance effort and
code. It may happen for 2008.0; Chris said, "I am not sure that we'll
have time to do the profile switching, but I'm going to try to come up
with it. The plan will be to create 'normal' 2008.0 profiles, and I'll
work on making them multi-parent." Another suggested change to profiles
is the creation of an all-new multiparent subprofile, optimized for
Gentoo development. The 'developer' profile would be based on the
desktop profile with an additional set of FEATURES useful to developers.
Chris also proposed changes to the release process, including when
profiles are created for future releases. "As soon as we finish up a
release," he said, "I'd like to go ahead and create the new release
stuff in the repos." That includes new catalyst spec files in the releng
repository, a new development profile, and possible changes to the
handbook. Making this change means work can immediately start instead of
waiting until the next release cycle, and it's also useful for automated
builds.
Public beta releases make up a major component of the new plans. Chris
hopes beta releases will increase community participation as well as the
quality of the final release. These feature-complete public betas will
require the earlier development of release materials. To ensure
sufficient time exists for testers to take advantage of the beta, a
mandatory 2-week testing period will follow the beta release.
A comprehensive testing checklist will be developed on the gentoo-releng
mailing list, as will a list of which details of testers' machines and
environments they should turn in to developers. Since in the past,
testers often provided insufficient information to releng developers
because their instructions weren't specific enough, a new form will
include all of the required questions and details. "Sadly you almost
want a beta that phones home as to what it was successfully run on,"
said Tom Gall (tgall). Christian Faulhammer (opfer) suggested using a
hardware reporting tool such as app-admin/hwreport.
Finally, Chris wants to make himself less of a single point of failure.
Conversion of the releng repository to SVN and maintenance of a shared
release checklist there will help, he said, so everyone can make updates
as they get things done.
A question about security came from Tobias Klausmann (Blackb|rd), who
asked how to avoid the same problem that hit 2007.1. "Part of the
problem last time was that Chris was trying to update the snapshot for
*every* security bug," said x86 release coordinator Andrew Gaffney
(agaffney), "instead of just the ones that affected the media."
Automated builds
----------------
Branching profiles and specs for the next release early will enable the
releng team to begin automated and regular internal release builds.
"They'll check out the SVN for the new release and use the new dev
profile," Chris said, "so we find problems and fix them year-round
instead of just during the release cycle."
Making these internal release builds publicly accessible can be done by
individual architecture teams, but Chris said the releng team won't
distribute them automatically. This could help people with architectures
that require hardware support nonexistent in the last release.
"My long-term goal for the automatic builds is for us to be able to use
them as our initial beta," Chris said. "We pick one that's as close to
release quality as possible, release it as beta, *then* start the
release cycle."
How do we involve the community more?
-------------------------------------
Some of the most popular suggestions--addition of the public beta,
letting users help with beta testing, and explicitly asking for
feedback--were already proposed for other goals like improving release
quality. They may also help involve the community.
Another popular idea was creating a survey to ask users for the top
features they want in the next release. This might happen with simple
infrastructure like email or the forums, since Gentoo doesn't yet have
anything better.
The last idea for getting users involved is to simply do a good job of
announcing the beta. Gentoo users have many places to get information
(GMN, forums, website, planet, many mailing lists), so getting news
about the beta to anywhere more users see it will require wide
dissemination of the announcement.
In addition to users, the releng team wants to get more developers
involved. Donnie Berkholz (dberkholz) suggested appealing to their
motivations for being a developer in the first place by doing things
like testing their own packages on the LiveCD. And Chris also wants to
get developers more actively involved rather than just being consumers.
Other topics
------------
Using full-fledged project-management software like dotproject was
proposed by developer Preston Cody (codeman). Chris said he just used a
spreadsheet but wanted something more collaborative, so Preston
suggested Google Docs. For now, the release checklist will live in SVN.
Switching away from the Cafepress store was also brought up. Cafepress
doesn't produce DVDs, but the releng team wants to encourage LiveDVD use
because they have so much more content. Chris is researching some
alternate stores.
Regarding hardware, most architectures have working, hosted development
machines. The main amd64 dev box, poseidon, could use some faster hard
drives for the automated builds.
Since constant security vulnerabilities forcibly canceled the 2007.1
release, improving how the releng team deals with them was a concern.
The main change will be a closer collaboration between the security team
and the releng team. "Releng is going to be treated just like an arch,
with a security liaison and everything," Chris said, "and we'll be added
to CC just like any other architecture. Before, I just found out about
stuff when either someone told me or when it hit the arch aliases I was
on ... neither of which was very good for planning."
--
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer
--
gentoo-releng@lists.gentoo.org mailing list
reply other threads:[~2008-01-24 22:52 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1201215158.16962.61.camel@workbox.quova.com \
--to=wolf31o2@gentoo.org \
--cc=gentoo-dev-announce@lists.gentoo.org \
--cc=gentoo-releng@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox