Brock Pytlik wrote: > Shawn Walker wrote: >> Michal Pryc wrote: >>> Brock Pytlik wrote: >>>> Michal Pryc wrote: >>>>> Hello, >>>>> I have made some changes to support BE Management: >>>>> http://defect.opensolaris.org/bz/show_bug.cgi?id=3201 >>>>> >>>>> The webrev is at: >>>>> http://cr.opensolaris.org/~migi/10_09_be_management_3201_v1/ >>>> I know the interface to libbe has changed (or changes in 97). Please >>>> take a look at the change Tim Knitter put back (501:9467b61d5b40) >>>> and do >>>> something similar every place you use be.beList. We need this to be >>>> compatible both with the new code and the old code so we can >>>> continue to >>>> back-publish. >>>> >>>> beadm.py line 163 is where be.beList is being used. >>>> >>>> It's also probably worth your time to talk to the people writing libbe >>>> to find what changes they might have planned for their API, or to at >>>> least let them know that you're directly dependent on them. Ethan Quach >>>> is the person who've I've talked with about libbe before. >>>> >>>> beadm.py: You might consider using our misc.py bytes_to_str method >>>> instead of rolling your own in __convert_size_of_be_to_string(self, >>>> be_size). I'm guessing that what we have should be sufficient, or >>>> can be >>>> made to do what you need it to do. >>> Good to know. I didn't wanted to depend on more code from IPS, since >>> this would introduce risk if the misc.py bytes_to_str would be >>> changed or renamed. What do you think? >> If it gets renamed by us, it's our responsibility to fix it. If it >> gets changed, that's on purpose. Either way, using that function will >> be good since it will ensure that the gui and cli represent sizes of >> "things" the same way. >> > > I disagree with this answer, at least in the long term. This is exactly > how we got into this problem in the first, and why we're creating an API > in the first place. Now, if we want to confer onto misc.py special API > status such that every change made in that file has to be vetted against > everything, then I'm fine with that answer. My impression is that misc > is more or less a dumping ground for things we don't have better places > for. Six months or a year from now, are we likely to remember that this > one function of misc.py has been given special status? > > This answer puts us in the position of having to test every change > against the GUI manually (until automatic testing comes along) because > any piece of our code could be used by the GUI or each of us needs to > become familiar with the GUI and track its changes. (The CLI suffers > from this same problem but is easier to deal with because we have > automated testing and we all know the code base letting us have a > reasonable idea of what our impact will be.) > > If we think it's important for the GUI and the CLI to display byte > information in the same pattern, then that becomes part of the > conceptual API/standards. If the GUI makes calls into misc.py, then that > function becomes part of the implementation API. Neither of these imply > that the function has to move into api.py, but it does confer a status > on that function that isn't given, generally, to most of our functions. > > That being said, if this is a short term solution, I don't really care.
So misc vs no_misc is 2:2, I've made two different versions of webrev, both have the following changes, comparing to the first one: - Strings changed as Brock proposed. Also I've changed the strings which were telling "Default BE will be changed" to "The Active BE will be changed" and in two more places Default was instead Active one. - Jenya Gestrin reviewed the dialogs and I've also changed the BE size column to be right aligned with always two number of digits after comma. In the following two webrevs only beadm.py is differ: http://cr.opensolaris.org/~migi/11_09_be_management_3201_no_misc_unified/ This version is using own function, so pkg.misc is not imported. Also I have unified strings with the function from pkg.misc so there is no "bytes", "M" instead we do have "B", "kB", ... http://cr.opensolaris.org/~migi/11_09_be_management_3201_misc/ This version is using pkg.misc I would really like to hear one strong decision which webrev should be comitted :) -- best Michal _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
