Re: [pkg-discuss] CR for 6516, 5662, 6227, 5866, 6226, partial fix for 6365
Brock Pytlik wrote: jmr wrote: Folks - I'd like to clarify a few things. At the minute we have a per repository view. With large number of packages it is not working well for type ahead search. There are some things we can do to improve the situation, but until we have a scalable solution I'd vote for turning it off (I had added the preferences dialog setting, but given Glynn's comments, am happy to just turn off the feature and leave the gconf key there for those who want to turn it on). In the meantime Michal's web rev is still useful for us to improve overall category browsing and startup performance, when coupled with a cpickle cache for the repo. I'm glad that we're going with turning it off for now. I hope you'll consider the solution I proposed earlier for how to handle type ahead search, at least as long as the search box is only searching package names, in a way that might scale better, or let me know why it's a dumb idea. Ok - we can discuss when we are over. I have no objection at all to a unified cross repository view but this is not something we can achieve with the current implementation. As various folks have suggested we could move over to a search based implementation, where we populate a Tree View on the left hand side with category nodes from all registered repos, then as a user clicks on one of these nodes issue the appropriate search to populate the right hand list view. When we have a search api in place and its performant enough to allow this to happen its something we could do, but not for this release. We can discuss possible designs with xDesign when the support is in place. It should be noted that a search based approach is not the only solution as Ubuntu have demonstrated with their caching implementation that supports cross repository browsing. To be clear, the suggestion I laid out for browsing doesn't line up with anything you've stated above, and had nothing to do with search. Ok - we can discuss when we are over. I guess I don't understand why it's not possible to achieve a unified view with the current implementation, but I'll accept that it's not. If that's the case, then since all that code will need to be rewritten anyway, I guess there's no problem with the putback b/c we're not moving further from a unified view, we're already as far as we can get. Ok - Michal will put back and followup with his cache support changes webrev. As a side note, remote search, which is what I presume you mean when you're talking about it above, is performant now (or likely as performant as it's going to get anytime soon). The interface to remote search will be changing slightly, but not a huge amount. So developing against what's there today will get you 90%+ of the way to what's coming soon, and I can hand you a workspace with the search API changes in it if that's helpful so you can start testing them if you'd like. I'm not sure why having the API is a prerequisite for discussing a design with xDesign, but the API is basically settled pending feedback from consumers. I'm happy to put out a preliminary webrev and keep it reasonably updated as well if that'd help. It would be great to have a preliminary Search API webrev so we can work on this next week, before we come over. Thanks, JR ___ pkg-discuss mailing list pkg-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
Re: [pkg-discuss] CR for 6516, 5662, 6227, 5866, 6226, partial fix for 6365
jmr wrote: Folks - I'd like to clarify a few things. At the minute we have a per repository view. With large number of packages it is not working well for type ahead search. There are some things we can do to improve the situation, but until we have a scalable solution I'd vote for turning it off (I had added the preferences dialog setting, but given Glynn's comments, am happy to just turn off the feature and leave the gconf key there for those who want to turn it on). In the meantime Michal's web rev is still useful for us to improve overall category browsing and startup performance, when coupled with a cpickle cache for the repo. I'm glad that we're going with turning it off for now. I hope you'll consider the solution I proposed earlier for how to handle type ahead search, at least as long as the search box is only searching package names, in a way that might scale better, or let me know why it's a dumb idea. I have no objection at all to a unified cross repository view but this is not something we can achieve with the current implementation. As various folks have suggested we could move over to a search based implementation, where we populate a Tree View on the left hand side with category nodes from all registered repos, then as a user clicks on one of these nodes issue the appropriate search to populate the right hand list view. When we have a search api in place and its performant enough to allow this to happen its something we could do, but not for this release. We can discuss possible designs with xDesign when the support is in place. It should be noted that a search based approach is not the only solution as Ubuntu have demonstrated with their caching implementation that supports cross repository browsing. To be clear, the suggestion I laid out for browsing doesn't line up with anything you've stated above, and had nothing to do with search. I guess I don't understand why it's not possible to achieve a unified view with the current implementation, but I'll accept that it's not. If that's the case, then since all that code will need to be rewritten anyway, I guess there's no problem with the putback b/c we're not moving further from a unified view, we're already as far as we can get. As a side note, remote search, which is what I presume you mean when you're talking about it above, is performant now (or likely as performant as it's going to get anytime soon). The interface to remote search will be changing slightly, but not a huge amount. So developing against what's there today will get you 90%+ of the way to what's coming soon, and I can hand you a workspace with the search API changes in it if that's helpful so you can start testing them if you'd like. I'm not sure why having the API is a prerequisite for discussing a design with xDesign, but the API is basically settled pending feedback from consumers. I'm happy to put out a preliminary webrev and keep it reasonably updated as well if that'd help. Brock What we have planned to do for this release is to introduce a cross repository search option (from a search combo drop down) which will allow a user to search across all repos. The results listed will show the repository of origin instead of the description. Clicking on a result row will fetch the description data. This will go some way to addressing users concerns about supporting cross repository actions. JR johan...@sun.com wrote: On Tue, Feb 10, 2009 at 05:13:59PM -0800, Brock Pytlik wrote: From a user's perspective, I think I rarely care which repo a package comes from. Sure, I want that information available if I ask for it, but I don't want that to interfere with me finding a package or installing it. I bring this up now b/c I think this changeset takes us farther away from that perspective. If I've understood this set correctly, it's further separating the repo information which may make it harder to implement a unified view in the future. I have to agree with Brock. It's going to make it difficult for users to find packages if they have to flip through every authority when they go looking for a particular package. We ought to be able to have a unified view of the package namespace. The CLI handles this problem by retrieving from the preferred authority if multiple packages have the same name and the requested FMRI was ambiguous. Otherwise the user must specify. However, the GUI doesn't need to be this anal. In the case where two packages have the same name, prefer the preferred authority. Otherwise prompt the user to choose. Eventually, we may have a system of ranked preference. However, splitting the packages up by repo is simply going to make it harder for the user to find what he or she is looking for. I have to add my assent to Brock and j's; there have been numerous reviews of OpenSolaris that have complained about the non-unified view that the packagemanager provides by default. I suspect most
Re: [pkg-discuss] CR for 6516, 5662, 6227, 5866, 6226, partial fix for 6365
Folks - I'd like to clarify a few things. At the minute we have a per repository view. With large number of packages it is not working well for type ahead search. There are some things we can do to improve the situation, but until we have a scalable solution I'd vote for turning it off (I had added the preferences dialog setting, but given Glynn's comments, am happy to just turn off the feature and leave the gconf key there for those who want to turn it on). In the meantime Michal's web rev is still useful for us to improve overall category browsing and startup performance, when coupled with a cpickle cache for the repo. I have no objection at all to a unified cross repository view but this is not something we can achieve with the current implementation. As various folks have suggested we could move over to a search based implementation, where we populate a Tree View on the left hand side with category nodes from all registered repos, then as a user clicks on one of these nodes issue the appropriate search to populate the right hand list view. When we have a search api in place and its performant enough to allow this to happen its something we could do, but not for this release. We can discuss possible designs with xDesign when the support is in place. It should be noted that a search based approach is not the only solution as Ubuntu have demonstrated with their caching implementation that supports cross repository browsing. What we have planned to do for this release is to introduce a cross repository search option (from a search combo drop down) which will allow a user to search across all repos. The results listed will show the repository of origin instead of the description. Clicking on a result row will fetch the description data. This will go some way to addressing users concerns about supporting cross repository actions. JR johan...@sun.com wrote: On Tue, Feb 10, 2009 at 05:13:59PM -0800, Brock Pytlik wrote: From a user's perspective, I think I rarely care which repo a package comes from. Sure, I want that information available if I ask for it, but I don't want that to interfere with me finding a package or installing it. I bring this up now b/c I think this changeset takes us farther away from that perspective. If I've understood this set correctly, it's further separating the repo information which may make it harder to implement a unified view in the future. I have to agree with Brock. It's going to make it difficult for users to find packages if they have to flip through every authority when they go looking for a particular package. We ought to be able to have a unified view of the package namespace. The CLI handles this problem by retrieving from the preferred authority if multiple packages have the same name and the requested FMRI was ambiguous. Otherwise the user must specify. However, the GUI doesn't need to be this anal. In the case where two packages have the same name, prefer the preferred authority. Otherwise prompt the user to choose. Eventually, we may have a system of ranked preference. However, splitting the packages up by repo is simply going to make it harder for the user to find what he or she is looking for. I have to add my assent to Brock and j's; there have been numerous reviews of OpenSolaris that have complained about the non-unified view that the packagemanager provides by default. I suspect most users are looking for a piece of software and they don't care where it comes from if they're using the gui; nor should they have to. It's fine to have the ability to view packages from a single repository, but a unified view should also be possible, and the default in my opinion. ___ pkg-discuss mailing list pkg-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
Re: [pkg-discuss] CR for 6516, 5662, 6227, 5866, 6226, partial fix for 6365
On 12/02/2009, at 1:26 PM, Brock Pytlik wrote: It is not a solution for bug 6365, but the split of the repositories will for sure improve performance, that is why I've wrote "partial fix" and for sure I will not close the bug, just update with all relevant information. John is also introducing webrev with preference dialog which allow to change type-in search to after-enter-pressed search, which will address some of the problems described in 6365. I'm glad John's going to be doing that. Given that, I'm not sure why the refactoring of the data (in this way) is needed. Ugh, please no. We don't need preference dialogs cluttered with options that most people won't care about. Hide it in GConf if you will, but please don't put it in a dialog [1] Glynn [1] Better yet, fix the underlying problem, rather than giving the pig lipstick ___ pkg-discuss mailing list pkg-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
Re: [pkg-discuss] CR for 6516, 5662, 6227, 5866, 6226, partial fix for 6365
Michal Pryc wrote:
Brock,
My comments inline.
I've made new webrev after pylinting the code and also clearing the
list of selected packages after the preferred repository was changed:
http://cr.opensolaris.org/~migi/lists_split_11_02_2009
Packagemanager.py:
Lines 1314-1320: don't these lines mean that if I have chosen a repo
other then my default repo, select some packages from that repo which
are also present in my default repo, then click install, I'll do the
install from my default repo anyway? Since only the pkg stem is being
passed in, I'm not sure how the authority info could be passed along.
Does this also mean I can't select 3 pkgs from contrib and 2 from dev
and have them all installed in one shot?
The webrev introduces control model containing all selections which
user did for any of the repositories. The packages from the control
model are passed to the api, so the user is able to select many
packages from many repositories and hit proper action button to
proceed with all selected packages not only from the given (preferred)
repository. As discussed with xDesign if the user mouse over the
install/update or remove button, tooltip will appear with information
how many packages and from which repository were selected (counted
separately for install/update and remove buttons).
The model is a dictionary:
self.selected_pkgs = {}
The structure of this dictionary is as follows:
{
"auth_1_name" : [
{package_stem:package_status_enum},
{package_stem2:package_status_enum},
...
],
"auth_2_name" : [
{package_stem:package_status_enum},
{package_stem2:package_status_enum},
...
]
...
}
Two private functions are modifying this model:
__add_pkg_stem_to_list(stem, status)
This function is adding package stem to the currently selected in
the combobox authority.
__remove_pkg_stem_from_list(stem)
This function removes stem from any authority, as we want to
remove from not currently visible as well.
So the control model does know from which repository selections were
made and this is used to preserve selections when the user switch to
different repository and switch back.
Those selections are also cleaned if the user changes the preferred
repository as the stem of the package is changed. Also if the user
disables one of the repositories we are removing selections from the
control model for that repository.
Great, this sounds like the right functionality then. Just wanted to
make sure.
I don't totally grok all the other changes, but those were the things
that jumped out at me.
Also, from bug 6365, it sounds like this is going to be a temporary fix
to get find-as-you-type working till something else which scales is
found? (If that's the case, I'm not sure that saying this fixes 6365 and
closing it makes a lot of sense unless you're planning to open another
to track the future scaling issues.) I also have some ideas on how we
might pull a feature like this out of the search API, if you're
interested let me know soon as that wad's starting to come together, and
if that's going to be something we need, I want to make sure the design
I have in mind at least allows for it going forward.
It is not a solution for bug 6365, but the split of the repositories
will for sure improve performance, that is why I've wrote "partial
fix" and for sure I will not close the bug, just update with all
relevant information. John is also introducing webrev with preference
dialog which allow to change type-in search to after-enter-pressed
search, which will address some of the problems described in 6365.
I'm glad John's going to be doing that. Given that, I'm not sure why the
refactoring of the data (in this way) is needed.
Other than 6365, I don't get why 6516 is needed, or even desired. Could
you please fill out that bug with more explanation? Is it to fix 6227?
If so, I don't think I understand how that helps.
It is not a solution for bug 6365, but the split of the repositories
will for sure improve performance, that is why I've wrote "partial
fix" and for sure I will not close the bug, just update with all
relevant information. John is also introducing webrev with preference
dialog which allow to change type-in search to after-enter-pressed
search, which will address some of the problems described in 6365.
6227 was caused by refiltering the data model too many times while the
repository was changed. The fix for this was to use self.in_setup
variable in proper places, so the refiltering is done only when needed.
Ok, stopping the multiple refiltering seems good :)
Also, in the bug reports, I'm seeing a lot of reference to caching, but
I don't really understand/know what that means in this context. I
apologize if I'v
Re: [pkg-discuss] CR for 6516, 5662, 6227, 5866, 6226, partial fix for 6365
johan...@sun.com wrote: On Tue, Feb 10, 2009 at 05:13:59PM -0800, Brock Pytlik wrote: From a user's perspective, I think I rarely care which repo a package comes from. Sure, I want that information available if I ask for it, but I don't want that to interfere with me finding a package or installing it. I bring this up now b/c I think this changeset takes us farther away from that perspective. If I've understood this set correctly, it's further separating the repo information which may make it harder to implement a unified view in the future. I have to agree with Brock. It's going to make it difficult for users to find packages if they have to flip through every authority when they go looking for a particular package. We ought to be able to have a unified view of the package namespace. The CLI handles this problem by retrieving from the preferred authority if multiple packages have the same name and the requested FMRI was ambiguous. Otherwise the user must specify. However, the GUI doesn't need to be this anal. In the case where two packages have the same name, prefer the preferred authority. Otherwise prompt the user to choose. Eventually, we may have a system of ranked preference. However, splitting the packages up by repo is simply going to make it harder for the user to find what he or she is looking for. I have to add my assent to Brock and j's; there have been numerous reviews of OpenSolaris that have complained about the non-unified view that the packagemanager provides by default. I suspect most users are looking for a piece of software and they don't care where it comes from if they're using the gui; nor should they have to. It's fine to have the ability to view packages from a single repository, but a unified view should also be possible, and the default in my opinion. -- Shawn Walker ___ pkg-discuss mailing list pkg-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
Re: [pkg-discuss] CR for 6516, 5662, 6227, 5866, 6226, partial fix for 6365
On Tue, Feb 10, 2009 at 05:13:59PM -0800, Brock Pytlik wrote: > From a user's perspective, I think I rarely care which repo a package comes > from. Sure, I want that information available if I ask for it, but I don't > want that to interfere with me finding a package or installing it. I bring > this up now b/c I think this changeset takes us farther away from that > perspective. If I've understood this set correctly, it's further separating > the repo information which may make it harder to implement a unified view > in the future. I have to agree with Brock. It's going to make it difficult for users to find packages if they have to flip through every authority when they go looking for a particular package. We ought to be able to have a unified view of the package namespace. The CLI handles this problem by retrieving from the preferred authority if multiple packages have the same name and the requested FMRI was ambiguous. Otherwise the user must specify. However, the GUI doesn't need to be this anal. In the case where two packages have the same name, prefer the preferred authority. Otherwise prompt the user to choose. Eventually, we may have a system of ranked preference. However, splitting the packages up by repo is simply going to make it harder for the user to find what he or she is looking for. -j ___ pkg-discuss mailing list pkg-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
Re: [pkg-discuss] CR for 6516, 5662, 6227, 5866, 6226, partial fix for 6365
Michal Pryc wrote:
Brock,
My comments inline.
I've made new webrev after pylinting the code and also clearing the list
of selected packages after the preferred repository was changed:
http://cr.opensolaris.org/~migi/lists_split_11_02_2009
Packagemanager.py:
Lines 1314-1320: don't these lines mean that if I have chosen a repo
other then my default repo, select some packages from that repo which
are also present in my default repo, then click install, I'll do the
install from my default repo anyway? Since only the pkg stem is being
passed in, I'm not sure how the authority info could be passed along.
Does this also mean I can't select 3 pkgs from contrib and 2 from dev
and have them all installed in one shot?
I think I didn't fully answer this question. So if the user selects
exactly the same package, which is present in many repositories the GUI
will behave like CLI - the last given to the command line / the last
selected will be installed.
best
Michal
The webrev introduces control model containing all selections which user
did for any of the repositories. The packages from the control model are
passed to the api, so the user is able to select many packages from many
repositories and hit proper action button to proceed with all selected
packages not only from the given (preferred) repository. As discussed
with xDesign if the user mouse over the install/update or remove button,
tooltip will appear with information how many packages and from which
repository were selected (counted separately for install/update and
remove buttons).
The model is a dictionary:
self.selected_pkgs = {}
The structure of this dictionary is as follows:
{
"auth_1_name" : [
{package_stem:package_status_enum},
{package_stem2:package_status_enum},
...
],
"auth_2_name" : [
{package_stem:package_status_enum},
{package_stem2:package_status_enum},
...
]
...
}
Two private functions are modifying this model:
__add_pkg_stem_to_list(stem, status)
This function is adding package stem to the currently selected in the
combobox authority.
__remove_pkg_stem_from_list(stem)
This function removes stem from any authority, as we want to remove from
not currently visible as well.
So the control model does know from which repository selections were
made and this is used to preserve selections when the user switch to
different repository and switch back.
Those selections are also cleaned if the user changes the preferred
repository as the stem of the package is changed. Also if the user
disables one of the repositories we are removing selections from the
control model for that repository.
I don't totally grok all the other changes, but those were the things
that jumped out at me.
Also, from bug 6365, it sounds like this is going to be a temporary fix
to get find-as-you-type working till something else which scales is
found? (If that's the case, I'm not sure that saying this fixes 6365 and
closing it makes a lot of sense unless you're planning to open another
to track the future scaling issues.) I also have some ideas on how we
might pull a feature like this out of the search API, if you're
interested let me know soon as that wad's starting to come together, and
if that's going to be something we need, I want to make sure the design
I have in mind at least allows for it going forward.
It is not a solution for bug 6365, but the split of the repositories
will for sure improve performance, that is why I've wrote "partial fix"
and for sure I will not close the bug, just update with all relevant
information. John is also introducing webrev with preference dialog
which allow to change type-in search to after-enter-pressed search,
which will address some of the problems described in 6365.
Other than 6365, I don't get why 6516 is needed, or even desired. Could
you please fill out that bug with more explanation? Is it to fix 6227?
If so, I don't think I understand how that helps.
It is not a solution for bug 6365, but the split of the repositories
will for sure improve performance, that is why I've wrote "partial fix"
and for sure I will not close the bug, just update with all relevant
information. John is also introducing webrev with preference dialog
which allow to change type-in search to after-enter-pressed search,
which will address some of the problems described in 6365.
6227 was caused by refiltering the data model too many times while the
repository was changed. The fix for this was to use self.in_setup
variable in proper places, so the refiltering is done only when needed.
Also, in the bug reports, I'm seeing a lot of reference to caching, but
I don't really understand/know what that means in this context. I
apologize if I've missed or forgotten the relevant discussions, but
could you give an outline of what caching you have in mind? It might
help me put these other changes in context.
6516 is needed as a part of more changes coming - caching. The caching
will use cpickle to dump gtk.ListStore and read it back for the given
Re: [pkg-discuss] CR for 6516, 5662, 6227, 5866, 6226, partial fix for 6365
Brock,
My comments inline.
I've made new webrev after pylinting the code and also clearing the list
of selected packages after the preferred repository was changed:
http://cr.opensolaris.org/~migi/lists_split_11_02_2009
Packagemanager.py:
Lines 1314-1320: don't these lines mean that if I have chosen a repo
other then my default repo, select some packages from that repo which
are also present in my default repo, then click install, I'll do the
install from my default repo anyway? Since only the pkg stem is being
passed in, I'm not sure how the authority info could be passed along.
Does this also mean I can't select 3 pkgs from contrib and 2 from dev
and have them all installed in one shot?
The webrev introduces control model containing all selections which user
did for any of the repositories. The packages from the control model are
passed to the api, so the user is able to select many packages from many
repositories and hit proper action button to proceed with all selected
packages not only from the given (preferred) repository. As discussed
with xDesign if the user mouse over the install/update or remove button,
tooltip will appear with information how many packages and from which
repository were selected (counted separately for install/update and
remove buttons).
The model is a dictionary:
self.selected_pkgs = {}
The structure of this dictionary is as follows:
{
"auth_1_name" : [
{package_stem:package_status_enum},
{package_stem2:package_status_enum},
...
],
"auth_2_name" : [
{package_stem:package_status_enum},
{package_stem2:package_status_enum},
...
]
...
}
Two private functions are modifying this model:
__add_pkg_stem_to_list(stem, status)
This function is adding package stem to the currently selected in
the combobox authority.
__remove_pkg_stem_from_list(stem)
This function removes stem from any authority, as we want to
remove from not currently visible as well.
So the control model does know from which repository selections were
made and this is used to preserve selections when the user switch to
different repository and switch back.
Those selections are also cleaned if the user changes the preferred
repository as the stem of the package is changed. Also if the user
disables one of the repositories we are removing selections from the
control model for that repository.
I don't totally grok all the other changes, but those were the things
that jumped out at me.
Also, from bug 6365, it sounds like this is going to be a temporary fix
to get find-as-you-type working till something else which scales is
found? (If that's the case, I'm not sure that saying this fixes 6365 and
closing it makes a lot of sense unless you're planning to open another
to track the future scaling issues.) I also have some ideas on how we
might pull a feature like this out of the search API, if you're
interested let me know soon as that wad's starting to come together, and
if that's going to be something we need, I want to make sure the design
I have in mind at least allows for it going forward.
It is not a solution for bug 6365, but the split of the repositories
will for sure improve performance, that is why I've wrote "partial fix"
and for sure I will not close the bug, just update with all relevant
information. John is also introducing webrev with preference dialog
which allow to change type-in search to after-enter-pressed search,
which will address some of the problems described in 6365.
Other than 6365, I don't get why 6516 is needed, or even desired. Could
you please fill out that bug with more explanation? Is it to fix 6227?
If so, I don't think I understand how that helps.
It is not a solution for bug 6365, but the split of the repositories
will for sure improve performance, that is why I've wrote "partial fix"
and for sure I will not close the bug, just update with all relevant
information. John is also introducing webrev with preference dialog
which allow to change type-in search to after-enter-pressed search,
which will address some of the problems described in 6365.
6227 was caused by refiltering the data model too many times while the
repository was changed. The fix for this was to use self.in_setup
variable in proper places, so the refiltering is done only when needed.
Also, in the bug reports, I'm seeing a lot of reference to caching, but
I don't really understand/know what that means in this context. I
apologize if I've missed or forgotten the relevant discussions, but
could you give an outline of what caching you have in mind? It might
help me put these other changes in context.
6516 is needed as a part of more changes coming - caching. The caching
will use cpickle to dump gtk.ListStore a
Re: [pkg-discuss] CR for 6516, 5662, 6227, 5866, 6226, partial fix for 6365
Ok, more detailed follow up: Packagemanager.py: Lines 1314-1320: don't these lines mean that if I have chosen a repo other then my default repo, select some packages from that repo which are also present in my default repo, then click install, I'll do the install from my default repo anyway? Since only the pkg stem is being passed in, I'm not sure how the authority info could be passed along. Does this also mean I can't select 3 pkgs from contrib and 2 from dev and have them all installed in one shot? I don't totally grok all the other changes, but those were the things that jumped out at me. Also, from bug 6365, it sounds like this is going to be a temporary fix to get find-as-you-type working till something else which scales is found? (If that's the case, I'm not sure that saying this fixes 6365 and closing it makes a lot of sense unless you're planning to open another to track the future scaling issues.) I also have some ideas on how we might pull a feature like this out of the search API, if you're interested let me know soon as that wad's starting to come together, and if that's going to be something we need, I want to make sure the design I have in mind at least allows for it going forward. Other than 6365, I don't get why 6516 is needed, or even desired. Could you please fill out that bug with more explanation? Is it to fix 6227? If so, I don't think I understand how that helps. Also, in the bug reports, I'm seeing a lot of reference to caching, but I don't really understand/know what that means in this context. I apologize if I've missed or forgotten the relevant discussions, but could you give an outline of what caching you have in mind? It might help me put these other changes in context. Thanks, Brock Michal Pryc wrote: Hello, The webrev is: http://cr.opensolaris.org/~migi/lists_split_10_02_2009_v1 This change makes the per repository underlying data model allowing selecting packages in many of them at the same time. Before the change, the main data model contaied all packages and it's selections. Current implementation splits that, so the selections are stored in dictionaries and data model is per repository only stored in the gtk.ListStore. This improves performance of many functions, as we are working on smaller data sets and we are not iterating through all packages to get selections. Switching repositories may take now more time, but this will be improved a lot once caching will go in, but I didn't wanted to introduce to many changes in one webrev. This fixes bugs: [Split the repository data models]: http://defect.opensolaris.org/bz/show_bug.cgi?id=6516 [Package manager should elide categories which are empty] http://defect.opensolaris.org/bz/show_bug.cgi?id=5662 [packagemanager chews CPU when changing repository] http://defect.opensolaris.org/bz/show_bug.cgi?id=6227 [Unnecessary processing during PackageManager startup] http://defect.opensolaris.org/bz/show_bug.cgi?id=5866 [Two entries appear in packagemanager for installed package] From the bug description I think I was not able to reproduce, but I didn't understand this bug description in 100%. http://defect.opensolaris.org/bz/show_bug.cgi?id=6226 ["find as you type" performance doesn't scale] This is just an improvement for this bug. Having per repository data model refilter function will reduce time to perform it, but only in some cases. Please read more in the bug description. http://defect.opensolaris.org/bz/show_bug.cgi?id=6365 ___ pkg-discuss mailing list pkg-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
Re: [pkg-discuss] CR for 6516, 5662, 6227, 5866, 6226, partial fix for 6365
I haven't had a chance to look at all the changes in detail, but I'll try to get to it tomorrow. From a high level perspective though, I have a concern (and I apologize if this is rehashing old discussions or beating a dead horse). From a user's perspective, I think I rarely care which repo a package comes from. Sure, I want that information available if I ask for it, but I don't want that to interfere with me finding a package or installing it. I bring this up now b/c I think this changeset takes us farther away from that perspective. If I've understood this set correctly, it's further separating the repo information which may make it harder to implement a unified view in the future. Maybe that ship has sailed, but I'm hoping it hasn't. Brock Michal Pryc wrote: Hello, The webrev is: http://cr.opensolaris.org/~migi/lists_split_10_02_2009_v1 This change makes the per repository underlying data model allowing selecting packages in many of them at the same time. Before the change, the main data model contaied all packages and it's selections. Current implementation splits that, so the selections are stored in dictionaries and data model is per repository only stored in the gtk.ListStore. This improves performance of many functions, as we are working on smaller data sets and we are not iterating through all packages to get selections. Switching repositories may take now more time, but this will be improved a lot once caching will go in, but I didn't wanted to introduce to many changes in one webrev. This fixes bugs: [Split the repository data models]: http://defect.opensolaris.org/bz/show_bug.cgi?id=6516 [Package manager should elide categories which are empty] http://defect.opensolaris.org/bz/show_bug.cgi?id=5662 [packagemanager chews CPU when changing repository] http://defect.opensolaris.org/bz/show_bug.cgi?id=6227 [Unnecessary processing during PackageManager startup] http://defect.opensolaris.org/bz/show_bug.cgi?id=5866 [Two entries appear in packagemanager for installed package] From the bug description I think I was not able to reproduce, but I didn't understand this bug description in 100%. http://defect.opensolaris.org/bz/show_bug.cgi?id=6226 ["find as you type" performance doesn't scale] This is just an improvement for this bug. Having per repository data model refilter function will reduce time to perform it, but only in some cases. Please read more in the bug description. http://defect.opensolaris.org/bz/show_bug.cgi?id=6365 * ___ pkg-discuss mailing list pkg-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
