Currently, the criteria are:
- existing tests should run green
- new tests that exercise the feature/fix/etc should be added
Should we include addtions/updates to user documentation as an
additional criterion? Anything else we should add?
-d
Currently, the criteria are:
Should we include addtions/updates to user documentation as an
additional criterion? Anything else we should add?
-d
Story should include core functionality needed to support a set of tasks.
Foreman claims to support ec2 but is unusable for all but the most basic
functionality.
Can not select a VPC, can not assign a specific private IP to a Foreman
built instance, can not select the root volume size, can not assign an EIP
to an instance, can not assign an instance to an ELB.
So for example as a Foreman user I need to be able to build in the dev VPC
a web server with 40GB EBS volume assign it the IP 192.168.1.21, I would
like it to have an external IP address and if the build is successful I
would like it assigned to the webserver ELB.
Jim
Currently, the criteria are:
- existing tests should run green
- new tests that exercise the feature/fix/etc should be added
Should we include addtions/updates to user documentation as an
additional criterion? Anything else we should add?-d
–
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
I'd perhaps separate this into three types of docs:
small updates like a new setting, changed meaning for a setting, can
be addressed at the same time as a PR so should be part of the criteria
developer notes or docs tend to go onto the wiki, so should be part of
the criteria as they can be written and added immediately
new sections for the manual might be tracked as a separate ticket in
the same or next sprint, as it'll take more time to do
–
Dominic Cleal
Red Hat Engineering
Broadly, for a given task, I'd like to see some form of docs (probably on
the wiki, since the manual is generally branched just before release). So
basically what Dominic said
Currently, the criteria are:
- existing tests should run green
- new tests that exercise the feature/fix/etc should be added
Should we include addtions/updates to user documentation as an
additional criterion? Anything else we should add?
When merging stuff I tend to compare the PR to the intentions stated in
the redmine ticket, so this information should be recorded there by
anybody with a vested interest,
Taking this example though, if EC2 were to be proposed in roughly its
current state today, I'd still merge it and then split stuff like ELB
into additional feature tickets in redmine. It might be that it gets
implemented in the same or subsequent sprint, but we do accept patches
in varying states of completeness, so I'd rather see partial
functionality than no functionality at all.
–
Dominic Cleal
Red Hat Engineering
I'll make sure to bring this up during the next retrospective, and we
can start enforcing the documentation rule in the next sprint.
-d