Re: [Beaker-devel] Alternative to disable custom columns.
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: "beaker-devel" <beaker-devel(a)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.
> >
> >
> > 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.
> - Remove the "Disable Custom Result Columns" checkbox
>
> Assuming we can get the above correct then we could just have one code
> path for the grid.
Easily done.
> It would also allow a user to set their preferred columns in prefs.
>
Sounds good
> btw - while testing I received a 500 ISE when selecting
> System/PowerType. I think this blows up because of the nested
> Power->Type relation. Might need to move PowerType to a Power search
>
My code base never had the System/PowerType as that was on another branch to my ticket51 branch. If master now has
System/PowerType in it, I'll merge that in and do some testing/debugging/code adjusting.
> object which has Type in it. thoughts?
>
> Thanks!
Cheers
14 years, 4 months
Alternative to disable custom columns.
by Raymond Mancy
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
14 years, 4 months
Re: [Beaker-devel] updated spec file
by Raymond Mancy
----- "Bill Peck" <bpeck(a)redhat.com> wrote:
> From: "Bill Peck" <bpeck(a)redhat.com>
> To: beaker-devel(a)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(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>
> >> 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
^^^^
This is how I'm creating my branches
> > *edit stuff*
> > *git add and commit*
> > make snaparchive
> > make rpm
> >
> > What follows is a bunch of expected out put as well as this
> >
> > error: Could not open
> /home/raymond/dev/Beaker/arch_bug/rpm-build/noarch/beaker-0.4.72-0.1262654333.refs/heads/bz537414.noarch.rpm:
> No such file or directory
> >
> > I tried creating a different branch and I got the same results. It's
> quite possible I'm just doing something wrong.
> >
>
> Can you paste the results of the following command here?
>
> git log --pretty=format:" %at.%d" -1
>
> Both from master and from a couple of your branches.
>
> Thanks!
>
This is the output from one branch that was playing up.
[root@localhost arch_bug]# git log --pretty=format:" %at.%d" -1
1262655692. (refs/heads/test_branch)
This was from master
[root@localhost arch_bug]# git log --pretty=format:" %at.%d " -1
1262640544. (refs/remotes/origin/master, refs/remotes/origin/HEAD, refs/heads/master, refs/heads/bz552451)
I actually fixed the problem. I created patches of my changes, recreated the
branches from fresh and applied the patches onto the newly branches. Everything then worked
as it should've. So it would appear it was something I had done wrong initially,
what it was though I don't know.
Cheers
> >
> >> 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 works for me just fine.
> >
> >
> >> 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.
> >> _______________________________________________
> >> Beaker-devel mailing list
> >> Beaker-devel(a)lists.fedorahosted.org
> >> https://fedorahosted.org/mailman/listinfo/beaker-devel
> >>
> > _______________________________________________
> > Beaker-devel mailing list
> > Beaker-devel(a)lists.fedorahosted.org
> > https://fedorahosted.org/mailman/listinfo/beaker-devel
> >
>
> _______________________________________________
> Beaker-devel mailing list
> Beaker-devel(a)lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/beaker-devel
14 years, 4 months
Re: [Beaker-devel] updated spec file
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>
> 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
What follows is a bunch of expected out put as well as this
error: Could not open /home/raymond/dev/Beaker/arch_bug/rpm-build/noarch/beaker-0.4.72-0.1262654333.refs/heads/bz537414.noarch.rpm: No such file or directory
I tried creating a different branch and I got the same results. It's quite possible I'm just doing something wrong.
> 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 works for me just fine.
> 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.
> _______________________________________________
> Beaker-devel mailing list
> Beaker-devel(a)lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/beaker-devel
14 years, 4 months
updated spec file
by Bill Peck
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.
14 years, 4 months