Custom 404 for autoqa.fp.o
by Tim Flink
For some reason, this came to mind when I was thinking about the bodhi
link issue but how do we feel about putting a custom 404 on autoqa.fp.o?
Since we don't keep logs forever, anything that links to old results
goes to a generic 404 without more explanation than "could not find the
file you were looking for". Instead, we could do a custom 404 that contains:
- Explanation of log retention policy
- Relevant AutoQA or FedoraQA links
It would involve a small change to the apache config and some static
HTML on the autotest server. Pretty easy finger food :)
Thoughts?
Tim
12 years, 9 months
0.6 Planning
by Tim Flink
Unless there is something that I've missed, I don't think that we have
a whole lot of bugs to fix in the 0.5 release series and I was
wondering what people were thinking about planning for
0.6.
How about proposals for features by Tuesday and do another phone
meeting on Thursday?
Tim
12 years, 9 months
0.6.0 Planning Meeting Time Proposal - 2011-07-14
by Tim Flink
The current idea is to have another phone conference to plan for AutoQA
0.6.0 on Thursday. I assume that Kamil, Josef, Martin, Peter and James
will be attending. If anyone else is interested, please let me know.
My initial thought is to do the same time we did for the 0.5.0 planning
- 13:30 UTC (06:30 PDT, 09:30 EDT, 15:30 CEST). If there are no
objections by sometime tomorrow morning, I'll send out teleconference
info.
If this is a bad time of the day for you and you'd like to attend - let
me know and we can try to work something out. We're not trying to
exclude anyone, just trying to balance disparate time zones.
Tim
12 years, 9 months
Git Release Process
by Kamil Paral
I've searched the web for best practices around software release process with Git. It seems that the practices vary a lot. One of the best articles I have come across is this one (I had to Flattr that post):
http://nvie.com/posts/a-successful-git-branching-model/
The process there is quite complex and sophisticated. I imagine it is required and very beneficial for large-scale projects. In our case (just several developers) I believe we are better off with much simpler process. But it's still a great source of inspiration.
In the release process there are some artifacts we recently talked about and which could be important for us:
== A single stable branch ==
This is the branch containing only stable (production-ready) code. In AutoQA we call in "stable". In the aforementioned article they call it "master". There's a small difference in the process of adding hotfixes. We used the same branch for pushing hotfixes and then tagged a new hotfix release at some point. They have a separate "hotfix" branch for those purposes and merge in once they want to create a hotfix release. But otherwise it's the same.
The benefits of having such a branch:
* People following this branch don't have to track release announcements or periodically list available tags. Simple "git pull" will always give them latest stable code.
The drawbacks of having such a branch:
* It is not trivial to maintain this branch with full commit history. My simple approach for AutoQA 0.5.0 was to create a patch from stable to v0.5.0 and apply it on stable [1]. But that does not keep history. The history is retained if you run "git log v0.5.0", but not if you run "git log stable". Tim tried to fix that problem by merging v0.5.0 and stable [2]. But that has its own drawbacks. You need to solve merge conflicts by hand and even if you do that, it is still possible that stable differs from v0.5.0 (some code changes didn't need to be detected as conflicts). With Tim's approach you still need to diff your branches afterwards and resolve any remaining differences by my diff-n-patch approach. It looks better in the end, but it also requires more work.
Interestingly the guy in that article didn't mention this problem at all (although they must have encountered this problem too).
All in all, stable branch has its uses and its challenges. We don't even need it, there are other approaches (described below). It's just a matter what we desire. Do you think there are people out there following just our stable branch? Do we care if they have to switch tags from time to time?
== Release branches ==
The principle is simple. With each tagged (minor) release we fork off a separate branch out of it. For example for 0.5.0 release we create "0.5-stable" branch. For 0.6.0 release we create "0.6-stable" branch. The rest of the process is the same as we have used till now. All hotfix commits are pushed to the relevant release branch and then tagged in some point of time. It then looks like this:
-o--o--o--o--o--o-- (master)
^\
| o--o--o- (0.5-stable)
| ^
| tag:0.5.1
tag:0.5.0
In this picture we have tagged 0.5.0 on master, then forked off 0.5-stable branch, pushed three more commits into that branch and then tagged 0.5.1 release.
Advantages:
* There are no issues with merging. We can work on more releases at once (not relevant to our project imho).
Disadvantages:
* Having the latest stable code requires checking the tags periodically and switching to the latest one.
Maybe you wonder - will we have lots and lots of these branches, eventually exploding the output of "git branch -r"? No. The nice thing here is that we need to create this release branch only when it's needed (we discover a bug that needs a hotfix). Also we can delete these branches once we are sure we won't work on this branch anymore (i.e. once 0.6.0 is out we can delete 0.5-stable in our case). Because don't forget, both branches and tags are the same in Git -- pointers. Branches are just moving pointers, while tag pointers stay put. Once we know there will be no more development, the tag is all we need to keep, the branch can be removed.
I consider this approach quite nice. In the past I was too concentrated on having a stable branch where you can always "git pull" the latest stable code. But maybe we don't need it after all and release branches would satisfy our needs instead? (We can of course have both stable branch and release branches, but I consider that unnecessarily complicated.)
== Branches used for tagging ==
There was a discussion lately on which branch we should tag our releases. I would like to clarify that. Due to the Git's nature this question does not really apply. In the above text I already described that branches and tags are almost the same -- pointers. The branch determines just the top commit and all other commits are linked through ancestor relationship. So you can't say "this commit is on branch X", you can just say "this commit is accessible from branches X, Y and Z". There is no ownership relationship. That means it doesn't really matter which branch the particular commit used to belong, it only matters if that is the top of the tree we want to archive by tagging. The important questions are then:
* Does it contain the code we want?
* Does it refer the commit tree log we want?
It means that these approaches are equivalent:
(master)$ git tag 0.5.0
and
(master)$ git checkout -b 0.5-stable
(0.5-stable)$ git tag 0.5.0
Both contain the same code and both refer to the same tree.
However, if we do big-patch approach for our stable branch (like I did a few days ago), those approaches are not interchangeable:
tag:0.4.0 tag:0.5.0
v v
--o--o--o--o--o--o--o-- (master)
\ \
o---o----------o--- (stable)
^
tag:0.4.1
If I do "git log 0.5.0", I get a fine-grained list of commit history. Now imagine I would tag a different commit:
tag:0.4.0
v
--o--o--o--o--o--o--o-- (master)
\ \
o---o----------o--- (stable)
^ ^
tag:0.4.1 tag:0.5.0
Now I get the same code for "git checkout 0.5.0", but I get only a fraction of commit history for "git log 0.5.0". Not that it doesn't serve the purpose. But the first approach is just better, because it keeps also the history.
== Conclusion ==
I have described the current approaches. I may have misunderstood something, I'll welcome corrections.
As for our project, I'm open to any suggestions. I think that our current practice serves us well. I'm fine with the big-patch approach for stable branch, because the commit history is retained for master branch and for all the tags. I'm fine with Tim's merging approach too.
OTOH I'm also fine with switching to using release branches. They are pretty. And it may be simpler for understanding that our current approach.
I don't think it would be viable for us to do both, release branches and stable branch. KISS.
Once we decide what we want, I'll document the process on our wiki.
Keep the comments coming :)
Kamil
[1] http://piratepad.net/M9RUj1qAe2
[2] https://fedorahosted.org/pipermail/autoqa-devel/2011-June/002475.html
12 years, 9 months
New Tester Introduction
by Petr Schindler
Hello,
I'm Petr Schindler (my nick is pschindl) and I'm new here. I work in fedoraQA team on AutoQA project. I'm looking forward to learn something new and to get some experiences with opensource development.
Bye,
Petr Schindler
12 years, 9 months
[AutoQA] #340: Integrate depcheck tests into main testsuite
by fedora-badges
#340: Integrate depcheck tests into main testsuite
--------------------+-------------------------------------------------------
Reporter: tflink | Owner:
Type: task | Status: new
Priority: minor | Milestone: Finger Food
Component: core | Keywords:
--------------------+-------------------------------------------------------
While an initial test suite was created for #258, it isn't currently
running any of the tests written for depcheck.
As currently written, these tests are functional tests and should be
integrated as such. Another concern is that they are restricted to 64bit
OS only and the integration would need to reflect this.
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/340>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
12 years, 9 months
AutoQA Downtime Starting 2011-07-11 20:00 UTC
by Tim Flink
AutoQA will be affected by the infrastructure changes announced last
week [1]. During the outage, AutoQA tests will not be run and feedback
will not be posted to Bodhi.
At this point, we are expecting the outage to last at least a day while
the systems are re-racked and we reconfigure AutoQA for these changes.
We will update this thread as we get closer to bringing things back online.
If you have any AutoQA specific questions about the outage, please
contact us on the AutoQA devel list [2].
[1] http://lists.fedoraproject.org/pipermail/devel/2011-July/153947.html
[2] autoqa-devel(a)lists.fedorahosted.org
12 years, 9 months
[AutoQA] #183: Write a script and a daemon to send signals between virt machine and host
by fedora-badges
#183: Write a script and a daemon to send signals between virt machine and host
----------------------------+-----------------------------------------------
Reporter: kparal | Owner:
Type: task | Status: new
Priority: major | Milestone: Virtualization
Component: infrastructure | Version: 1.0
Keywords: |
----------------------------+-----------------------------------------------
We need to exchange some signals between virt machine and a host. For
example "autotest job finished, need to revert to previous state". We need
to write simple script that will send this signal for virt machine and a
daemon that will receive this signal in the host machine and act
accordingly.
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/183>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
12 years, 9 months
Re: Virtualization support
by Scott M Ferguson
> Hello Scott,
>
> I'm not exactly sure I get the idea. The autotest server already
> handles starting the task and collecting results (arrows 2. and 3. in
> the picture I added to
> https://fedorahosted.org/autoqa/ticket/183#comment:description). Ticket
> #183 mainly concerns arrow 4., signaling to the host (of that autotest
> client VM). We can use it for reverting the VM to the previous state
> (I think that's the main reason we need all of this). In the Virtualization
> milestone there are other tickets that cover remaining parts of that
> picture.
>
> So, the problem of ticket #183 is not getting the results (autotest handles
> that for us), but telling the host (of that VM) "do something" right after
> completing the test.
>
> Are we on the same page? Maybe I have missed something. Tell me.
>
> Thanks,
> Kamil
>
Kamil,
We were on a different page and it's completely due to lack-of-sleep
on my end, but that's another story (4-week-old daughter). Thanks for
clarifying. All should be well now :)
Best,
Scott
12 years, 9 months
Updated Makefile and packaging instructions
by James Laska
Greetings gang,
I've been playing with an updated Makefile to facilitate a more
consistent autoqa build+update process. I'm happy with the changes so
far, and thought I'd send them to the list for feedback before pushing
into master. In addition to the updated Makefile, I have created a wiki
page describing the process I use when tagging and updating a new
version of autoqa.
https://fedoraproject.org/wiki/AutoQA_Build_Process
I see this document adjusting over time pending the outcome of the git
release process discussion started by Kamil. The document describes the
current version of our process. As always, comments/feedback welcome.
I'll follow-up with my patch shortly.
Thanks,
James
12 years, 9 months
