On Thu, 2010-06-03 at 12:10 -0700, Adam Williamson wrote:
On Thu, 2010-06-03 at 15:00 -0400, James Laska wrote:
> We've also been accumulating group membership requests. Are we ready to
> start processing these requests?
>
>
https://fedorahosted.org/fedora-qa/query?status=new&status=assigned&a...
I guess one thing we should agree on first is what we will be 'teaching'
our applicants. =)
I think so far we've informally wound up working on this logic:
1. We're expected to review 'critical path' updates
2. The 'critical path' definition is about being able to boot the
system, start a graphical desktop, and do updates
I believe so. From [1], "The critical path is defined as the set of
packages required to perform the most fundamental actions on a Fedora
system."
The detailed list of actions in the original critpath definition [2]
include:
* graphical network install
* post-install booting
* decrypt encrypted filesystems
* graphics
* login
* networking
* get updates
* minimal buildroot
* compose new trees
* compose live
[1]
http://fedoraproject.org/wiki/Critical_Path_Packages
[2]
https://fedoraproject.org/wiki/Critical_Path_Packages_Proposal#What_is_th...
3. Therefore we ought to be looking at whether the packages contain
regressions which break these: we should look at updates from the
perspective of whether they prevent us from carrying out critical path
tasks
is that roughly accurate, for a first cut?
Definitely!
Alternatively, we could use the release criteria, and check that
updates
don't introduce regressions which would infringe the release criteria.
This is effectively a superset of the first option, as part of what the
release criteria enforce is the critical path functionality.
This seems like a good long-term goal to help us determine how to
grow/extend the current process. I imagine we want to use the same
process/tools to encourage non-critpath updates testing as well.
(Boy, the grammar in this post is horrible!)
Heh, wait until you read this :)
Thanks,
James