Jean McCormack wrote:
> Attached is what I believe is what we've decided upon.
> I put the signpost after the packages since I believe it will be an item
> that
> is much more likely to be configured. That's slightly different than
> your bug comments though.
>
That's OK, but you seem not to have cut & pasted the comments related to
the package list and the compression into the right places.
While we're on the subject of comments... I find the manifests too
dense visually. It's sort of tolerable when using a syntax-highlighting
interface such as gedit to view them, but in plain text environments,
they're hard to parse. I'd suggest more white space, including
modifying the block comment style from things like:
<!-- Where to build. This can be a zfs dataset or a mountpoint.
The area will be created if it doesn't exist. If the
build_area
is not a zfs dataset or mountpoint, checkpointing will
not
be enabled.
-->
to
<!--
Where to build. This can be a zfs dataset or a
mountpoint.
The area will be created if it doesn't exist. If the
build_area
is not a zfs dataset or mountpoint, checkpointing will
not
be enabled.
-->
To me, this is easier to read and closer to the style we use in other
types of code. And I'd especially apply it to the signpost; a
single-line comment is easy to miss in comparison to a block with
whitespace.
Dave
> Jean
>
> Dave Miner wrote:
>> Jean McCormack wrote:
>>> Bug 5364 Example manifest should be organized for easy customization
>>>
>>> raises the issue that the manifests could be organized better to enable
>>> people to more easily locate the few options that are likely to be
>>> modified.
>>>
>>> Here's my proposal:
>>>
>>> The areas that are hard to locate are in img_params so those are the
>>> ones I'm
>>> looking at moving.
>>>
>>> Current format:
>>> img_params
>>> packages
>>> post_install_remove_packages
>>> generate_ips_search_index
>>> bootroot_contents
>>> live-img_compression_type
>>> build_area
>>> grub_menu_modifications
>>> output_image
>>> finalizer
>>>
>>>
>>> The issue is that bootroot_contents is so long that anything after it
>>> is hard to find.
>>> So what I think I'd like to do is move the small items to the top and
>>> leave packages
>>> and bootroot_contents near the bottom. Since the
>>> output_image/finalizer scripts
>>> are also largish I'll leave those last.
>>>
>>> Here's what I'm thinking
>>>
>>> img_params
>>> build_area
>>> live-img-compression_type
>>> grub_men_modification
>>> generate_ips_search_index
>>> packages
>>> post_install_remove_packages
>>> bootroot_contents
>>> output_image
>>> finalizer
>>>
>>> Does this sound OK to everyone?
>>>
>>
>> I would think that package lists are much more likely to be modified
>> than the compression and search index stuff.
>>
>> I'd move the bootroot compression setting right next to the packages.
>>
>> Also, I still suggest a signpost (as shown in my comments in the bug)
>> to delineate the likely vs. unlikely modifications.
>>
>> Dave
>
