Bill Peck | 4 Jan 22:36 2010
Picon

updated spec file


Hello Everyone,

I've updated the beaker spec file to do some magic with regard to git.  
If you have a branch checked out and do a make snaparchive and then a 
make srpm or rpm it will have the timestamp and branch name in the release.

for example:

/home/bpeck/Sandbox/Beaker/rpm-build/beaker-0.4.71-0.1262640463.ticket51.el5.src.rpm

But if you do the same from master it will just be:

/home/bpeck/Sandbox/Beaker/rpm-build/beaker-0.4.71-0.el5.src.rpm

This allows for really easy testing of branches without needing to 
update the spec file and check that into git.  Which is always a pain 
because it will no doubt conflict with master when you try and merge it 
later.

I also created a subpackage called beaker which only contains 
beaker/__init__.py with __version__ = '0.4.71' in it.  The idea is to 
update the web templates to display this version on the web page and 
possibly pre-populate a bugzilla url with the right version.

Let me know if you have any questions or see any problems.

Raymond Mancy | 5 Jan 03:02 2010
Picon

Re: updated spec file


----- "Bill Peck" <bpeck <at> redhat.com> wrote:

> From: "Bill Peck" <bpeck <at> redhat.com>
> To: "List for the development of the Beaker project" <beaker-devel <at> lists.fedorahosted.org>
> Sent: Tuesday, January 5, 2010 7:36:47 AM GMT +10:00 Brisbane
> Subject: [Beaker-devel] updated spec file
>
> Hello Everyone,
> 
> I've updated the beaker spec file to do some magic with regard to git.
>  
> If you have a branch checked out and do a make snaparchive and then a
> 
> make srpm or rpm it will have the timestamp and branch name in the
> release.
> 
> for example:
> 
> /home/bpeck/Sandbox/Beaker/rpm-build/beaker-0.4.71-0.1262640463.ticket51.el5.src.rpm
>

I seem to be having a problem with this. From the master branch I do the following

git branch bz537414
git checkout bz537414
*edit stuff*
*git add and commit*
make snaparchive
make rpm
(Continue reading)

Bill Peck | 5 Jan 15:11 2010
Picon

Re: updated spec file

On 01/04/2010 09:02 PM, Raymond Mancy wrote:
> ----- "Bill Peck"<bpeck <at> redhat.com>  wrote:
>
>    
>> From: "Bill Peck"<bpeck <at> redhat.com>
>> To: "List for the development of the Beaker project"<beaker-devel <at> lists.fedorahosted.org>
>> Sent: Tuesday, January 5, 2010 7:36:47 AM GMT +10:00 Brisbane
>> Subject: [Beaker-devel] updated spec file
>>
>> Hello Everyone,
>>
>> I've updated the beaker spec file to do some magic with regard to git.
>>
>> If you have a branch checked out and do a make snaparchive and then a
>>
>> make srpm or rpm it will have the timestamp and branch name in the
>> release.
>>
>> for example:
>>
>> /home/bpeck/Sandbox/Beaker/rpm-build/beaker-0.4.71-0.1262640463.ticket51.el5.src.rpm
>>
>>      
> I seem to be having a problem with this. From the master branch I do the following
>
> git branch bz537414
> git checkout bz537414
> *edit stuff*
> *git add and commit*
> make snaparchive
(Continue reading)

Bill Peck | 5 Jan 15:28 2010
Picon

Re: updated spec file

On 01/05/2010 09:11 AM, Bill Peck wrote:
> On 01/04/2010 09:02 PM, Raymond Mancy wrote:
>    
>> ----- "Bill Peck"<bpeck <at> redhat.com>   wrote:
>>
>>
>>      
>>> From: "Bill Peck"<bpeck <at> redhat.com>
>>> To: "List for the development of the Beaker project"<beaker-devel <at> lists.fedorahosted.org>
>>> Sent: Tuesday, January 5, 2010 7:36:47 AM GMT +10:00 Brisbane
>>> Subject: [Beaker-devel] updated spec file
>>>
>>> Hello Everyone,
>>>
>>> I've updated the beaker spec file to do some magic with regard to git.
>>>
>>> If you have a branch checked out and do a make snaparchive and then a
>>>
>>> make srpm or rpm it will have the timestamp and branch name in the
>>> release.
>>>
>>> for example:
>>>
>>> /home/bpeck/Sandbox/Beaker/rpm-build/beaker-0.4.71-0.1262640463.ticket51.el5.src.rpm
>>>
>>>
>>>        
>> I seem to be having a problem with this. From the master branch I do the following
>>
>> git branch bz537414
(Continue reading)

Raymond Mancy | 5 Jan 23:47 2010
Picon

Re: updated spec file


----- "Bill Peck" <bpeck <at> redhat.com> wrote:

> From: "Bill Peck" <bpeck <at> redhat.com>
> To: beaker-devel <at> lists.fedorahosted.org
> Sent: Wednesday, January 6, 2010 12:11:51 AM GMT +10:00 Brisbane
> Subject: Re: [Beaker-devel] updated spec file
>
> On 01/04/2010 09:02 PM, Raymond Mancy wrote:
> > ----- "Bill Peck"<bpeck <at> redhat.com>  wrote:
> >
> >    
> >> From: "Bill Peck"<bpeck <at> redhat.com>
> >> To: "List for the development of the Beaker
> project"<beaker-devel <at> lists.fedorahosted.org>
> >> Sent: Tuesday, January 5, 2010 7:36:47 AM GMT +10:00 Brisbane
> >> Subject: [Beaker-devel] updated spec file
> >>
> >> Hello Everyone,
> >>
> >> I've updated the beaker spec file to do some magic with regard to
> git.
> >>
> >> If you have a branch checked out and do a make snaparchive and then
> a
> >>
> >> make srpm or rpm it will have the timestamp and branch name in the
> >> release.
> >>
> >> for example:
(Continue reading)

Bill Peck | 5 Jan 23:52 2010
Picon

Re: updated spec file

On 01/05/2010 05:47 PM, Raymond Mancy wrote:
> ----- "Bill Peck"<bpeck <at> redhat.com>  wrote:
>
>    
>> From: "Bill Peck"<bpeck <at> redhat.com>
>> To: beaker-devel <at> lists.fedorahosted.org
>> Sent: Wednesday, January 6, 2010 12:11:51 AM GMT +10:00 Brisbane
>> Subject: Re: [Beaker-devel] updated spec file
>>
>> On 01/04/2010 09:02 PM, Raymond Mancy wrote:
>>      
>>> ----- "Bill Peck"<bpeck <at> redhat.com>   wrote:
>>>
>>>
>>>        
>>>> From: "Bill Peck"<bpeck <at> redhat.com>
>>>> To: "List for the development of the Beaker
>>>>          
>> project"<beaker-devel <at> lists.fedorahosted.org>
>>      
>>>> Sent: Tuesday, January 5, 2010 7:36:47 AM GMT +10:00 Brisbane
>>>> Subject: [Beaker-devel] updated spec file
>>>>
>>>> Hello Everyone,
>>>>
>>>> I've updated the beaker spec file to do some magic with regard to
>>>>          
>> git.
>>      
>>>> If you have a branch checked out and do a make snaparchive and then
(Continue reading)

Raymond Mancy | 7 Jan 06:48 2010
Picon

Alternative to disable custom columns.

Hi Bill, Just wanting your thoughts on a good alternative to the disable result column checkbox on ticket51.

The only reasonable alternative I can come up with is the following.

Initially, in the checkbox list of result columns, have our default columns selected (System,Status,Vendor...etc).
Have another link up the top that allows them to populate that checkbox list with only default values (so they
can easily go from a heavily customised result set back to the default).

I'm trying to make it easy for the user to go between a customised search result and a default search result.
If 
they wanted to go between the two quite often it could get fiddley if they had to do it all manually. Maybe I'm 
overstating this feature though.

Raymond

Bill Peck | 7 Jan 19:46 2010
Picon

Re: Alternative to disable custom columns.

On 01/07/2010 12:48 AM, Raymond Mancy wrote:
> Hi Bill, Just wanting your thoughts on a good alternative to the disable result column checkbox on ticket51.
>
> The only reasonable alternative I can come up with is the following.
>
> Initially, in the checkbox list of result columns, have our default columns selected (System,Status,Vendor...etc).
> Have another link up the top that allows them to populate that checkbox list with only default values (so they
> can easily go from a heavily customised result set back to the default).
>
> I'm trying to make it easy for the user to go between a customised search result and a default search result. If
> they wanted to go between the two quite often it could get fiddley if they had to do it all manually. Maybe I'm
> overstating this feature though.
>
>
> Raymond
>
>
>
>    

Hi Raymond,

Here are my thoughts on testing ticket51 so far.

- Default to having all current columns selected. (The ones we normally 
show)
- Have three "shortcut" links, Select All, Select None, and Select Default.
     - move these to under the checkbox div.  I don't think we want to 
see them unless we are actually clicking and unclicking checkboxes.  
Users will be confused otherwise.
(Continue reading)

Raymond Mancy | 7 Jan 23:23 2010
Picon

Re: Alternative to disable custom columns.


----- "Bill Peck" <bpeck <at> redhat.com> wrote:

> From: "Bill Peck" <bpeck <at> redhat.com>
> To: "Raymond Mancy" <rmancy <at> redhat.com>
> Cc: "beaker-devel" <beaker-devel <at> lists.fedorahosted.org>
> Sent: Friday, January 8, 2010 4:46:57 AM GMT +10:00 Brisbane
> Subject: Re: Alternative to disable custom columns.
>
> On 01/07/2010 12:48 AM, Raymond Mancy wrote:
> > Hi Bill, Just wanting your thoughts on a good alternative to the
> disable result column checkbox on ticket51.
> >
> > The only reasonable alternative I can come up with is the
> following.
> >
> > Initially, in the checkbox list of result columns, have our default
> columns selected (System,Status,Vendor...etc).
> > Have another link up the top that allows them to populate that
> checkbox list with only default values (so they
> > can easily go from a heavily customised result set back to the
> default).
> >
> > I'm trying to make it easy for the user to go between a customised
> search result and a default search result. If
> > they wanted to go between the two quite often it could get fiddley
> if they had to do it all manually. Maybe I'm
> > overstating this feature though.
> >
> >
(Continue reading)

Marian Csontos | 8 Jan 22:01 2010
Picon

Re: result_upload_file, handling attachments and other relationships

Hi Bill,

rhts uses "late binding" - it uploads a file and only then would say it 
was resultLog.

I would like to avoid caching files in backends,
and I would like to go on (at least for a while) with original 
rhts-devel-test-env and submit all patches upstream. At least while it 
will be used by the two systems.

Fortunately rhts is under our control and the change is simple enough - 
requires only to change report_log function in rhts-db-submit-result:
+      bkr = beaker()
+      if bkr:
+          resp = session.results.resultLog(log_type, result_id, prettyname)
        rhts.uploadWrapper(session,log_name,recipetestid, prettyname)
-      resp = session.results.resultLog(log_type, result_id, prettyname)
+      if not bkr:
+          resp = session.results.resultLog(log_type, result_id, prettyname)
...and...
+def beaker():
+    return os.environ.get('FROM_BEAH')

Any advice on this particular solution?

However, we might run into situation, where it will not be that easy.
Do you think it would be possible to change server in such case?

I would like to suggest a change on server: I see no need to 
differentiate between {task,recipe,result}_upload_file - it is just a 
(Continue reading)


Gmane