While a little disorganized, I think that our phone meeting earlier today was useful. Hopefully everyone else is of the same mind even though it was a little longer than initially planned :)
Rather than regurgitating all of the information covered in the discussion, I have started documenting our planning in Trac [1]. It's not done but I will finish the initial pages later today or tomorrow and start creating more tickets to reflect our discussion today.
Feedback on formatting and/or usefullness would be appreciated. The raw etherpad document produced is also available [2].
Tim
Discussed: - What is the important feedback information for maintainers? - What could the test logs look like? - What are our design goals for test log output? - When should we be sending email notifications to maintainers? - What are our next steps?
General Agreed: 1. Evaluate release ready-ness on a regular basis (every 2 weeks to start) 2. Write code for email defaults with an eye towards configurability - Only as far as this makes sense to do - Per-user email configuration will not be a part of 0.5.x 3. For log formatting, plaintext logs are a must-have. HTML logs would be nice to have, but will likely not be a part of 0.5.x
General Todo: 1. Create mockups for plaintext logs (specifically the "pretty" logs) 2. Determine timebox for mockups, planning
Action Items: 1. tflink to reach out to lmacken, infra on deployment timeline for Bodhi enhancements for email notification control 2. jlaska to reach out to dmalcolm and esantiago for thoughts on maintainer result notification frequency
[1] https://fedorahosted.org/autoqa/wiki/Planning050series [2] http://tflink.fedorapeople.org/autoqa/planning/05x/2011-05-04_meeting_openEt...
On Wed, May 04, 2011 at 11:02:39AM -0600, Tim Flink wrote:
Action Items:
- tflink to reach out to lmacken, infra on deployment timeline for Bodhi enhancements for email notification control
python-fedora-0.3.23, which is on its way to updates-testing, has a BodhiClient.comment() method that can take an 'email' boolean argument that will let you toggle whether or not you want the comment to trigger email notifications.
The server-side bodhi currently does not support this, but I'm in the process of wrapping up some other features/fixes and I am hoping to get a new release into production this week. I'll be sure to ping you guys when it's good to go.
luke
On 05/04/2011 11:11 AM, Luke Macken wrote:
On Wed, May 04, 2011 at 11:02:39AM -0600, Tim Flink wrote:
Action Items:
- tflink to reach out to lmacken, infra on deployment timeline for Bodhi enhancements for email notification control
python-fedora-0.3.23, which is on its way to updates-testing, has a BodhiClient.comment() method that can take an 'email' boolean argument that will let you toggle whether or not you want the comment to trigger email notifications.
The server-side bodhi currently does not support this, but I'm in the process of wrapping up some other features/fixes and I am hoping to get a new release into production this week. I'll be sure to ping you guys when it's good to go.
luke
Thanks for the update, one less email that I have to write :)
We were just wanting to make sure that everything would be in place if we started working on our end now. Figured that if we didn't ask, we would end up with code that didn't quite work :)
Thanks,
Tim
While a little disorganized, I think that our phone meeting earlier today was useful. Hopefully everyone else is of the same mind even though it was a little longer than initially planned :)
The structure always falls apart :), but nevertheless it was positive, agreed.
Rather than regurgitating all of the information covered in the discussion, I have started documenting our planning in Trac [1].
Very appreciated, thanks for the work!
It's not done but I will finish the initial pages later today or tomorrow and start creating more tickets to reflect our discussion today.
Feedback on formatting and/or usefullness would be appreciated.
I would probably do it as a subsection of https://fedoraproject.org/wiki/AutoQA_Roadmap because we can all subscribe to those pages' changes, as opposed trac wiki pages. Just an idea.
Also, I wouldn't duplicate the list of tickets under Progress section, because it is bound to be outdated all the time. The always current list is available as: https://fedorahosted.org/autoqa/milestone/0.5.0 (and clicking on Closed and Active tickets links)
The raw etherpad document produced is also available [2].
Tim
https://fedorahosted.org/autoqa/wiki/Planning050logFormatting
"Pretty" log - the output linked to from bodhi, designed for maintainers Will contain highlights and the first 1000 or so lines of log output
My idea was to attach only link to the full log, not the first 1000 lines. We can also do that, but I think it would fail the objective to have the pretty log short and concise.
On 05/05/2011 12:51 AM, Kamil Paral wrote:
It's not done but I will finish the initial pages later today or tomorrow and start creating more tickets to reflect our discussion today.
Feedback on formatting and/or usefullness would be appreciated.
I would probably do it as a subsection of https://fedoraproject.org/wiki/AutoQA_Roadmap because we can all subscribe to those pages' changes, as opposed trac wiki pages. Just an idea.
I figured that the trac wiki was a better place for it since it's AutoQA development specific and unlikely to be of much interest to other people. My feeling is that more fedorahosted projects (ie [1], [2]) put development information in their Trac wiki instead of mediawiki but I could be wrong here.
I don't feel strongly enough about putting it in trac to fight the group about it, though. If we want this in mw, I can move it.
[1] https://fedorahosted.org/bodhi/ [2] https://fedorahosted.org/fas/
Also, I wouldn't duplicate the list of tickets under Progress section, because it is bound to be outdated all the time. The always current list is available as: https://fedorahosted.org/autoqa/milestone/0.5.0 (and clicking on Closed and Active tickets links)
Actually, that is a Trac wiki macro that lists the tickets instead of a list of tickets typed out by hand. It's functionally the same as looking at the milestone and updated without any extra work on our part.
Newer versions of Trac allow for more formatting on the ticket queries
https://fedorahosted.org/autoqa/wiki/Planning050logFormatting
"Pretty" log - the output linked to from bodhi, designed for maintainers Will contain highlights and the first 1000 or so lines of log output
My idea was to attach only link to the full log, not the first 1000 lines. We can also do that, but I think it would fail the objective to have the pretty log short and concise.
OK, I misunderstood. Will fix if you haven't already.
Tim
I would probably do it as a subsection of https://fedoraproject.org/wiki/AutoQA_Roadmap because we can all subscribe to those pages' changes, as opposed trac wiki pages. Just an idea.
I figured that the trac wiki was a better place for it since it's AutoQA development specific and unlikely to be of much interest to other people. My feeling is that more fedorahosted projects (ie [1], [2]) put development information in their Trac wiki instead of mediawiki but I could be wrong here.
Your point of view is completely valid. We just can't subscribe for changes. But let's keep it there, I don't think it's too much important. (And not everyone is probably such subscriber freak as I am:)).
Also, I wouldn't duplicate the list of tickets under Progress section, because it is bound to be outdated all the time. The always current list is available as: https://fedorahosted.org/autoqa/milestone/0.5.0 (and clicking on Closed and Active tickets links)
Actually, that is a Trac wiki macro that lists the tickets instead of a list of tickets typed out by hand. It's functionally the same as looking at the milestone and updated without any extra work on our part.
Gosh, that's good! /me should have looked at the page source. Nice.
On 05/05/2011 07:31 AM, Kamil Paral wrote:
Your point of view is completely valid. We just can't subscribe for changes. But let's keep it there, I don't think it's too much important. (And not everyone is probably such subscriber freak as I am:)).
It's not quite the same, but you can get an rss feed from the timeline of trac [1] that shows wiki/ticket modifications and git pushes.
[1] https://fedorahosted.org/autoqa/timeline?ticket=on&changeset=on&mile...
Also, I wouldn't duplicate the list of tickets under Progress section, because it is bound to be outdated all the time. The always current list is available as: https://fedorahosted.org/autoqa/milestone/0.5.0 (and clicking on Closed and Active tickets links)
Actually, that is a Trac wiki macro that lists the tickets instead of a list of tickets typed out by hand. It's functionally the same as looking at the milestone and updated without any extra work on our part.
Gosh, that's good! /me should have looked at the page source. Nice.
There is all sorts of cool stuff that you can do with trac like macros to display selected source code (revision, file, line range) in any wiki-ish section (ticket descriptions, comments etc.) or writing pages in rST instead of the normal moin-ish trac wiki syntax.
Tim
autoqa-devel@lists.fedorahosted.org