549912, power type testing data ?
by Raymond Mancy
Hi Bill, I've created a ticket for the search by power type, 549912. I've also pushed the change through in on branch bz549912. I added a couple of entries into my power table as I previously had none. Testing on these worked fine. I don't forsee any problems, but it would be ideal to test on a good amount of realworld data, if any exists.
Raymond
14 years, 3 months
Bug on live that I can't replicate
by Raymond Mancy
Hi Bill, I've noticed a pretty glaring on bug on the live beaker UI when doing an advanced search, it constantly returns to the simple search.
I have never seen this behaviour before and cannot replicate it on the master branch. Is the current version 0.4.69 ?
Raymond
14 years, 3 months
To merge into master
by Raymond Mancy
Hi Bill, when you get a chance can you merge ticket543788 into master. There were a lot changes in this branch.
Once this has been merged into master I have some other branches that will be tricky to merge in, so I will first merge a copy of master into them and then put them
up for you to test and put into the master branch.
Cheers
Raymond
14 years, 3 months
Re: [Beaker-devel] git branches and master
by Raymond Mancy
----- "Bill Peck" <bpeck(a)redhat.com> wrote:
> From: "Bill Peck" <bpeck(a)redhat.com>
> To: "Raymond Mancy" <rmancy(a)redhat.com>
> Cc: "List for the development of the Beaker project" <beaker-devel(a)lists.fedorahosted.org>, "Marian Csontos"
> <mcsontos(a)redhat.com>
> Sent: Thursday, December 17, 2009 7:43:15 AM GMT +10:00 Brisbane
> Subject: Re: git branches and master
>
> On 12/15/2009 07:15 AM, Raymond Mancy wrote:
> > ----- "Bill Peck"<bpeck(a)redhat.com> wrote:
> >
> >
> >> From: "Bill Peck"<bpeck(a)redhat.com>
> >> To: "List for the development of the Beaker
> project"<beaker-devel(a)lists.fedorahosted.org>, "Raymond Mancy"
> >> <rmancy(a)redhat.com>, "Marian Csontos"<mcsontos(a)redhat.com>
> >> Sent: Tuesday, December 15, 2009 1:16:48 AM GMT +10:00 Brisbane
> >> Subject: git branches and master
> >>
> >> Hi Raymond,
> >>
> >> I'm thinking its time to bite the bullet and fix the git repo.
> Right
> >>
> >> now we have release-0.4 branch where we have been putting fixes
> and
> >> some
> >> new development that you have been working on like new search.
> Then
> >> we
> >> have master where Marian and I have been working on the scheduler
> >> version. This is painful because we have to commit fixes to both
> >> release-0.4 and to master. Its all my fault for not understanding
> git
> >>
> >> and how branches work in it. (hint - they actually work unlike
> cvs!).
> >>
> >> So I'd like to make master the main branch and move all
> development
> >> into
> >> branches. This way we can always commit bug fixes to master and
> push
> >> a
> >> new release out when needed but continue to develop in branches
> and
> >> when
> >> done merge into master.
> >>
> >
> > Sure. This makes sense. Once you have merged release-0.4 into master
> I'll
> > create all new devel branches to track master.
> >
> >
> >
> >> I'm willing to merge release-0.4 into master, I'll disable all the
> 0.5
> >>
> >> schema changes by commenting them out. Then I'll branch a
> scheduler
> >> version from that which will cleanly merge back in later.
> >>
> >> Does this sound reasonable?
> >>
> > Yep.
> >
> >
> >
> >> Will you be able to bring your new search
> >>
> >> and column view code to master? I'd like them to be a branch off
> of
> >> master so that we can then merge them in when we are done testing.
> >>
> >>
> > They're currently sitting in their own branch, so once the testing
> is done it should
> > be able to be merged easily enough with master.
> >
> >
> >> If we get this straightened out then it will be much easier to
> develop
> >>
> >> and fix bugs.
> >>
> >
> > Raymond
> >
>
> Ok.. I've merged release-0.4 into master. I need to sort out the
> table
> changes. I'll hopefully post a script Tomorrow to put your local
> sqllite db back in order.
>
> Next step is to "turn off" the scheduler stuff and branch that.
Great. I've merged master into ticket543788, so it should be trivial to put it back into master after testing.
14 years, 3 months
Re: [Beaker-devel] git branches and master
by Raymond Mancy
----- "Bill Peck" <bpeck(a)redhat.com> wrote:
> From: "Bill Peck" <bpeck(a)redhat.com>
> To: "List for the development of the Beaker project" <beaker-devel(a)lists.fedorahosted.org>, "Raymond Mancy"
> <rmancy(a)redhat.com>, "Marian Csontos" <mcsontos(a)redhat.com>
> Sent: Tuesday, December 15, 2009 1:16:48 AM GMT +10:00 Brisbane
> Subject: git branches and master
>
> Hi Raymond,
>
> I'm thinking its time to bite the bullet and fix the git repo. Right
>
> now we have release-0.4 branch where we have been putting fixes and
> some
> new development that you have been working on like new search. Then
> we
> have master where Marian and I have been working on the scheduler
> version. This is painful because we have to commit fixes to both
> release-0.4 and to master. Its all my fault for not understanding git
>
> and how branches work in it. (hint - they actually work unlike cvs!).
>
> So I'd like to make master the main branch and move all development
> into
> branches. This way we can always commit bug fixes to master and push
> a
> new release out when needed but continue to develop in branches and
> when
> done merge into master.
Sure. This makes sense. Once you have merged release-0.4 into master I'll
create all new devel branches to track master.
>
> I'm willing to merge release-0.4 into master, I'll disable all the 0.5
>
> schema changes by commenting them out. Then I'll branch a scheduler
> version from that which will cleanly merge back in later.
>
> Does this sound reasonable?
Yep.
> Will you be able to bring your new search
>
> and column view code to master? I'd like them to be a branch off of
> master so that we can then merge them in when we are done testing.
>
They're currently sitting in their own branch, so once the testing is done it should
be able to be merged easily enough with master.
> If we get this straightened out then it will be much easier to develop
>
> and fix bugs.
Raymond
14 years, 3 months
Multihost synchronization: TESTORDER
by Marian Csontos
Hi Bill,
I am expecting optional testorder attribut in task, in which case
TESTORDER is redefined for the task and all subsequent tasks.
Alternatively, param TESTORDER could be passed in task to override
single task only.
As discussed, these two are taken from different "namespaces"
implemented by prefixing the value by "TSK_" when single task is
overriden or by "RCP_" otherwise.
-- Marian
14 years, 3 months
params semantics
by Marian Csontos
Hi Bill,
how to handle params in beaker? I remember a discussion on having
environment local to task.
Though params are under task in XML, thus it would be natural
considering the envrionment changes local (and actually it is what
harness is doing), in RHTS they are considered global IIRC. Now we could
straight it out.
And we should be able to define a global environment as well.
-- Marian
14 years, 3 months
beah and multi-host
by Bill Peck
Hi Marian,
I kicked off a multihost job and its giving the following output on the
console...
12/14/09 13:12:25 testID:408 finish:
12/14/09 13:12:35 JobID:109
Test:/kernel/filesystems/nfs/connectathon-mh Response:1
12/14/09 13:12:35 testID:409 start:
rhts-sync-block Timeout!
rhts-sync-block Timeout!
rhts-sync-block Timeout!
rhts-sync-block Timeout!
rhts-sync-block
Timeout!
rhts-sync-block Timeout!
I'll attach the xml I used to submit the job. feel free to add a
reserve task on the end so you can debug.
14 years, 3 months
git branches and master
by Bill Peck
Hi Raymond,
I'm thinking its time to bite the bullet and fix the git repo. Right
now we have release-0.4 branch where we have been putting fixes and some
new development that you have been working on like new search. Then we
have master where Marian and I have been working on the scheduler
version. This is painful because we have to commit fixes to both
release-0.4 and to master. Its all my fault for not understanding git
and how branches work in it. (hint - they actually work unlike cvs!).
So I'd like to make master the main branch and move all development into
branches. This way we can always commit bug fixes to master and push a
new release out when needed but continue to develop in branches and when
done merge into master.
I'm willing to merge release-0.4 into master, I'll disable all the 0.5
schema changes by commenting them out. Then I'll branch a scheduler
version from that which will cleanly merge back in later.
Does this sound reasonable? Will you be able to bring your new search
and column view code to master? I'd like them to be a branch off of
master so that we can then merge them in when we are done testing.
If we get this straightened out then it will be much easier to develop
and fix bugs.
14 years, 3 months
ReleaseAction SQL schema ?
by Raymond Mancy
Hi Bill,
I've merged the latest release-0.4 branch with my ticket543788 to do some testing to make sure everything works as it should. The ReleaseAction class that you created though
is tripping up my environment here as I don't have the correct SQL system table schema. Do you have the SQL alter commands that were used along with this code change?
Cheers
Raymond
14 years, 3 months