Thanks for the feedback! Some follow-up below...
On Thu, 2011-06-23 at 09:12 -0700, Adam Williamson wrote:
On Thu, 2011-06-23 at 10:46 -0400, James Laska wrote:
> Greetings testers,
>
> I've been playing with some ideas on how to allow secondary
> architectures to leverage the primary release criteria. I have some
> ideas/challenges that I'll send to the list for feedback later.
> However, in preparation for those ideas/concerns, I'd like to propose
> several changes to the release criteria.
>
> The proposed changes are intended to make the existing criteria slightly
> more generic, without losing their meaning. Additionally, I've made a
> few other minor changes and added a few questions. Please take a few
> minutes to review the proposed changes (highlighted in red at the links
> below). If nothing alarming surfaces during review, I'll proceed with
> operation genericize [1] early next week.
>
>
https://fedoraproject.org/wiki/User:Jlaska/Draft_Alpha_criteria_revision
I'm unclear on the addition of the word 'package' to 2: what does this
clarify? What is the other type of install if not a 'package install'?
Deleting CD, sure.
Yeah, deleting the CD's for one. It's technically not needed, but we
have a lot of users that boot a DVD, and install from the online
repositories. I was trying to articulate that this only applies to
packages from the media. But perhaps that's redundant after saying
"media-based install"?
On the deletion of the 'primary architectures' mention from
4: we should
probably replace this with something in the preamble, similar to what's
there for 'release-blocking desktops'.
I was hoping to avoid too much preamble, since for me, the eye really
draws to the bullet list, and not the preamble. The deletion was going
to be accompanied with my other ideas for secondary architecture
handling. But I decided to break that up into two parts, so for now
I'll back out that change.
Are we at the point where we need to create a section called
'Assumptions', which would include release-blocking desktops and primary
architectures?
On 7: Not sure about this - I think booting from boot.iso and then
using
the DVD as a package source is explicitly supported, isn't it? Was this
criterion meant to ensure that works?
Good discussion. I was trying to bring the criteria closer to what we
actually test (fedora-qa) and maintain (anaconda-devel). Booting the
boot.iso with askmethod, then installing from the DVD is a use case that
we don't explicitly test and I wasn't intended with the original
criteria, and we'd be hard-pressed to get fixes for.
I discussed this use case in #anaconda ... while we don't explicitly
prevent a user from doing this, there is no logical use case to do this.
They requested rephrasing the criteria to explicitly mention booting,
and installing from, the DVD.
Per request, I'll hold off on filing a bug/patch to restrict CD/DVD
askmethod install source selection until the UI redesign settles down.
10 seems to kind of fall between two stools, as it's still not
very
generic but now it looks a bit like we're supporting very obscure
storage protocols on primary arches. I may be able to come up with
something better here...how about:
"The installer must be able to complete an installation using any
storage interface which is reasonably prevalent in general use" ? That
was kind of the intention of the PATA, SATA, SCSI set for Intel.
I like that! Updated draft wiki, however refer to the Final criteria
comments below.
>
https://fedoraproject.org/wiki/User:Jlaska/Draft_Beta_criteria_revision
Dropping 3: yup, it's not needed any more, good catch. Ditto 7.
>
https://fedoraproject.org/wiki/User:Jlaska/Draft_Final_criteria_revision
So for 4 we have the same problem as for Alpha, and it's a bit harder to
re-write generically :/ So, we add iSCSI to the list for Intel, and zFCP
(whatever that is) for another arch; is there anything in particular
about these interfaces that we support? Is it just 'all interfaces for
which anaconda actually has code' at this point?
Yeah, you nailed it. I was trying to make it generic, while still
specific ... and failed. Without specific examples, I was having a hard
time pinpointing the range of devices.
Originally we added this criteria to have a place to hang iSCSI support.
I'd include zFCP (s390x fibre channel storage) in the same boat as
iSCSI... important, but only critical for the final release.
What if we distinguish between the two Alpha and Final storage device
criteria by differentiating between physically attached (Alpha), vs
network (iSCSI) or SAN/fibre attached storage (zFCP/qLogic etc...)?
So alpha would be rewritten to cover (PATA, SATA, SCSI, eSATA) ...
"The installer must be able to complete an installation using
any locally connected storage interface (e.g. PATA, SATA, SCSI
etc...)"
And final would add in the network component ...
"The installer must be able to complete an installation using
any networked storage devices (e.g. iSCSI, FCoE, Fibre Channel)"
How's that sound?
15 and 17: not entirely sure what the question is here. The Alpha
criterion specifically limits itself to the media, and the generic-*
packages are not included on the media. It is acceptable for packages in
the repository but not on the media to conflict.
That's what I was hoping to get clarification on. Is it generally
accepted that the phrasing "release repository" means the online
+mirrored repos, not the media-based repos?
Thanks,
James