Re: [PATCH] Updates for No Frozen Rawhide (NFR), which include: * Enabling dist-f13 and dist-f14-updates-candidate in post-koji-build * Update repoinfo.conf with f13 urls * Update parent tag info in koji_utils.py
by Kamil Paral
----- "James Laska" <jlaska(a)redhat.com> wrote:
> ---
> hooks/post-koji-build/watch-koji-builds.py | 2 ++
> lib/python/koji_utils.py | 2 ++
> repoinfo.conf | 17 ++++++++++++++++-
> 3 files changed, 20 insertions(+), 1 deletions(-)
>
> diff --git a/hooks/post-koji-build/watch-koji-builds.py
> b/hooks/post-koji-build/watch-koji-builds.py
> index d1b1707..2dcfc6d 100755
> --- a/hooks/post-koji-build/watch-koji-builds.py
> +++ b/hooks/post-koji-build/watch-koji-builds.py
> @@ -35,6 +35,8 @@ kojiserver =
> 'http://koji.fedoraproject.org/kojihub'
> taglist = set(('dist-f10-updates-candidate',
> 'dist-f11-updates-candidate',
> 'dist-f12-updates-candidate',
> + 'dist-f13-updates-candidate',
> + 'dist-f14-updates-candidate',
Why do we want to have dist-f14 specified now? It will be equal to
rawhide for next 6 months and no builds should be tagged like
that (rawhide does not use updates repo). Even if somebody tags it
like that, we don't want to test it, right?
> ))
> archlist = ('i686', 'x86_64', 'noarch')
>
> diff --git a/lib/python/koji_utils.py b/lib/python/koji_utils.py
> index e7c3d26..c9fad5d 100644
> --- a/lib/python/koji_utils.py
> +++ b/lib/python/koji_utils.py
> @@ -25,6 +25,8 @@ from repoinfo import repoinfo
> import rpmUtils.miscutils
>
> parents_for_tag = {
> + 'dist-f14-updates-candidate':
> ('f14','f14-updates','f14-updates-testing'),
The same question as above.
> + 'dist-f13-updates-candidate':
> ('f13','f13-updates','f13-updates-testing'),
> 'dist-f12-updates-candidate':
> ('f12','f12-updates','f12-updates-testing'),
> 'dist-f11-updates-candidate':
> ('f11','f11-updates','f11-updates-testing'),
> 'dist-f10-updates-candidate':
> ('f10','f10-updates','f10-updates-testing'),
> diff --git a/repoinfo.conf b/repoinfo.conf
> index f358dc5..0b66c1c 100644
> --- a/repoinfo.conf
> +++ b/repoinfo.conf
> @@ -3,7 +3,7 @@ parents =
> arches = i386, x86_64, ppc
> # tag defaults to dist-[section_name]
> tag = dist-%(__name__)s
> -baseurl = http://gromit.redhat.com/pub/fedora/linux
> +baseurl = http://download.fedoraproject.org/pub/fedora/linux
> goldurl = %(baseurl)s/releases/%(path)s/Everything/%(arch)s/os
I would love if anyone could tell me what the Everything path
is good for. The only difference I found for F12 is that it
contains also ppc64 architecture.
This is not really related to the patch, just something I've
found I don't understand.
> updatesurl = %(baseurl)s/updates/%(path)s/%(arch)s
> rawhideurl = %(baseurl)s/%(path)s/%(arch)s/os
> @@ -13,6 +13,21 @@ arches = i386, x86_64
> path = development
This should be also changed, to 'development/rawhide' I believe.
(It's the [rawhide] section, but the top line is cut off).
> url = %(rawhideurl)s
>
> +[f13]
> +# path will change when Fedora 13 is released
> +path = development/13
> +url = %(rawhideurl)s
> +
> +[f13-updates]
> +path = 13
> +url = %(updatesurl)s
> +parents = f13
> +
> +[f13-updates-testing]
> +path = testing/13
> +url = %(updatesurl)s
> +parents = f13-updates, f13
> +
> [f12]
> path = 12
> url = %(goldurl)s
> --
> 1.6.6
>
Otherwise it looks good from my point of view.
14 years, 1 month
[AutoQA] #122: beakerlib_initscripts: Install packages from Koji
by fedora-badges
#122: beakerlib_initscripts: Install packages from Koji
-----------------------------------+----------------------------------------
Reporter: kparal | Owner: jskladan
Type: defect | Status: new
Priority: major | Milestone:
Component: tests | Version: 1.0
Keywords: beakerlib_initscripts |
-----------------------------------+----------------------------------------
Currently we download packages from stable repos to test them with
initscripts tests. But we want to download the packages from Koji. Let's
have a look at the rpmlint test and let's download the required package
(including subpackages) similarly and install them.
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/122>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
14 years, 1 month
2010-02-26 - AutoQA resultdb design discussion (part#2)
by James Laska
# AutoQA ResultsDB Discussion
# Date: 2010-02-26
# Time: 15:00 UTC (10:00 EST, 16:00 CET)
# Participants - wwoods, jlaska, kparal, jskladan
= Review definition/goals =
https://fedorahosted.org/pipermail/autoqa-devel/2010-February/000201.html
Goals
* One central database to store test results (audience QA)
* Multiple front-ends to present stored results (audience QA/developers)
= Recap of research =
* Overview - https://fedoraproject.org/wiki/AutoQA_resultsdb_approaches
Spikesource schema -
http://dev.spikesource.com/wiki/index.php/Trpi-schema_view
* No concept of WAIVE results
RHTS/Beaker - http://beaker.fedorahosted.org/
* stores log files directly
* presents most important data on main results page (e.g. stdout)
* Hiearchy - Job contains RecipeSet(s), which contains Recipe(s), which
contains test(s), which contain phase(s)
Beakerlib
* Allows specification of test phases
* Provides common test writing format in bash
* beakerlib xml journal
http://jskladan.fedorapeople.org/beakerlib_format.xml
** test which produced the output:
http://git.fedorahosted.org/git/?p=autoqa.git;a=blob;f=tests/beakerlib_in...
RATS
* Test results linked by a unique key (timestamp of tree being tested)
* install.py test also uses concept of "phases" -
http://git.fedorahosted.org/git/?p=autoqa.git;a=blob;f=tests/rats_install...
* Multiple tests (2), each with multiple phases - Viewed from single
location - http://jlaska.fedorapeople.org/rats.png
= Ideate =
* Define an output standard for each test type for easier inspection of
results (similar to beakerlib)
* TCMS - something we're gonna forget about for now (db scheme review in
'open topics')
= Terminology =
* test case - one unit with a single result (but may contain several
phases)
* test phase - parts of a test case, their results are not stored
separately in the results db, but define pass/fail result of the test
case itself (internally for the test)
* test plan - contains several test cases, provides meta data around
test cases (responsibility, workflow, high-level criteria etc...)
* mapping to the beakerlib_format.xml - depends on particular test, for
initscripts checking: <log> ~ test case, <phase> ~ test phase
= Open topics =
* How to handle policy (waive) in tools?
** https://fedoraproject.org/wiki/AutoQA_resultsdb_approaches#DB_schema
- rpmdiff solution
* Is defining a common test writing and output format the same as
providing a results front-end/workflow?
* Examine nitrate/testopia resultsdb format?
* Test case results vs autotest job results (unhandled exception, etc)
= Tasks =
* [wwoods] - Examine beakerlib output format if it is sufficient for our
purposes
* [jlaska] - Examine nitrate/testopia DB schema
* [kparal + jskladan] - Define personas and write use cases
Example:
https://fedoraproject.org/wiki/No_frozen_rawhide_announce_plan#Use_Cases
Wiki page: https://fedoraproject.org/wiki/AutoQA_resultsdb_use_cases
* [kparal + jskladan] - Propose some initial DB schema
= Next Meeting =
* 2010-03-05 - mailing list checkin (conference call if needed)
14 years, 1 month
Increase the default guest RAM size and add command-line tunable
by James Laska
Greetings,
>From bug#559290, it's looking more like 512M for an x86_64 install is not sufficient. While that discovery process is underway, I'd like to increase the default guest RAM size from 512 to 768. Additionally, I found that being able to change this value from the command-line was very helpful. The following patch add a command-line argument to install.py to support changing the RAM size of the guest.
Comments/concerns appreciated.
Thanks,
James
14 years, 1 month
Re: autoqa development info/policy
by Kamil Paral
----- "James Laska" <jlaska(a)redhat.com> wrote:
> On Tue, 2010-02-23 at 12:27 -0500, Will Woods wrote:
> > Hi folks,
> >
> > So I've been thinking about how we should be managing the autoqa
> > sources, and patch review, and things like that. Here's some
> guidelines
> > that I've come up with. Probably this will go in a wiki page on the
> > autoqa trac instance, but I wanted to send it here for review
> first.
> >
> > The short version is this:
> >
> > * we use git, and the 'master' branch is the production code (for
> now)
> > * send git-formatted patches to the autoqa-devel list
> > * if changes are too big for patches, ask for a personal branch
> > * wwoods is responsible for applying patches / merging changes, but
> > he'll also get jlaska & kparal to help
>
> I'd defer to you and Kamil first. But I'm happy to merge changes
> whenever desired.
>
> > The longer version:
> >
> > * autoqa is hosted in git, and the autoqa-devel mailing list is the
> best
> > place to discuss new ideas for autoqa tests, features, and such.
>
> Definitely. Keep the thread coming! :)
To discuss, certainly. I'm just a little worried about patch
management. It is really easy to forget about a waiting patch in the
mailing list. Unless we have a Review Board [1], maybe we can
create tickets for patches in our Trac, just not to forget about
them?
[1] https://fedorahosted.org/fedora-infrastructure/ticket/1196
>
> > * The autoqa git repo has a 'master' branch - this should be
> considered
> > the production code, at least for now. We encourage developers to
> clone
> > the repo and create their own private branches.
>
> With guidance from Will, I updated the AutoQA_PatchProcess page to
> provide some guidance on creating a named branch to work on changes.
>
> https://fedoraproject.org/wiki/AutoQA_PatchProcess#Named_Branch
I think there should not be "git push --all" in the examples, just
the name of the new branch. Recently I was quite surprised when
I noticed some branches available that I deleted from our git repo
a long time ago. This may be the explanation :)
>
> > * If you have a bugfix or a proposed patch, please send it to the
> list
> > for review or discussion. It's best if you use 'git format-patch'
> and
> > 'git send-email' to format and send your patch(es). Anyone on the
> list
> > should feel free to comment on incoming patches.
>
> Same here. I reordered some wiki content regarding patch submission.
> Thoughts/concerns welcome -
> https://fedoraproject.org/wiki/AutoQA_PatchProcess#Patch_submission
>
> > * If you have some changes that are more complex than a simple patch
> or
> > patch set, feel free to ask for commit access to the repo so you
> can
> > have your own branch in the public repo.
Git is decentralized, so why grant people commit access to our repo?
I would just instruct them to push their branch to their own location
(like on fedorapeople.org). Simple http server is enough. And then
they just send us the link to their branch.
> (This will make it easier
> to
> > cherrypick changes and/or merge large patch sets without
> overwhelming
> > the list.)
> >
> > * It's helpful if people who have personal branches put their
> > username/IRC nick in the branch name, so everyone knows who owns
> which
> > branch.
>
> In hindsight, having my local changes in a branch would have made
> merging a bit easier.
>
> > * wwoods is the maintainer/patch monkey for the 'master' branch, but
> he
> > sometimes delegates authority to jlaska and kparal to do updates to
> > master. (Especially when he's off in the clouds and there's bugs
> that
> > need fixin'.)
So unless you say otherwise, all the patches goes through you (even
patches from our team), is that right?
> >
> >
> > Does this clear up the current development process any?
>
> This does for me. I don't have tons of development project
> experience,
> but what I appreciate here is trying to be specific about who is
> responsible for what. So if this helps identify who is doing what,
> when ... great!
>
> Thanks,
> James
>
> _______________________________________________
> autoqa-devel mailing list
> autoqa-devel(a)lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/autoqa-devel
14 years, 2 months
resultsdb meeting - Friday, Feb. 26
by Will Woods
Hi guys,
If possible, I'd like to have a (hopefully quick) meeting tomorrow, in
#fedora-meeting, to review the resultsdb goals and the research we've
done.
All are welcome, of course - see the previous mail thread[1] for info on
what we've been talking about so far:
https://fedorahosted.org/pipermail/autoqa-devel/2010-February/000201.html
Kamil, James, how's 1500 UTC (10am US Eastern, 4pm Brno) sound?
-w
[1] Is there a wiki page for this stuff yet? I don't see one in my
browser history but I'm not looking real hard..
14 years, 2 months
autoqa development info/policy
by Will Woods
Hi folks,
So I've been thinking about how we should be managing the autoqa
sources, and patch review, and things like that. Here's some guidelines
that I've come up with. Probably this will go in a wiki page on the
autoqa trac instance, but I wanted to send it here for review first.
The short version is this:
* we use git, and the 'master' branch is the production code (for now)
* send git-formatted patches to the autoqa-devel list
* if changes are too big for patches, ask for a personal branch
* wwoods is responsible for applying patches / merging changes, but
he'll also get jlaska & kparal to help
The longer version:
* autoqa is hosted in git, and the autoqa-devel mailing list is the best
place to discuss new ideas for autoqa tests, features, and such.
* The autoqa git repo has a 'master' branch - this should be considered
the production code, at least for now. We encourage developers to clone
the repo and create their own private branches.
* If you have a bugfix or a proposed patch, please send it to the list
for review or discussion. It's best if you use 'git format-patch' and
'git send-email' to format and send your patch(es). Anyone on the list
should feel free to comment on incoming patches.
* If you have some changes that are more complex than a simple patch or
patch set, feel free to ask for commit access to the repo so you can
have your own branch in the public repo. (This will make it easier to
cherrypick changes and/or merge large patch sets without overwhelming
the list.)
* It's helpful if people who have personal branches put their
username/IRC nick in the branch name, so everyone knows who owns which
branch.
* wwoods is the maintainer/patch monkey for the 'master' branch, but he
sometimes delegates authority to jlaska and kparal to do updates to
master. (Especially when he's off in the clouds and there's bugs that
need fixin'.)
Does this clear up the current development process any?
-w
14 years, 2 months
