Re: [Openstack] RFC: Thoughts on improving OpenStack GIT commit practice/history
Hi, As a recent contributor to OpenStack, but with experience in other projects, I think moving in the directions you document would be good. And as you wrote, it's common practice in many many projects, which is another argument for this :-) However, one comment: Le mercredi 27 juin 2012, à 11:52 +0100, Daniel P. Berrange a écrit : It might be mentioned that Gerrit's handling of patch series is not entirely perfect. This is a not a valid reason to avoid creating patch series. It'd be really great if we could first improve Gerrit to handle the patch series workflow in a better way. Without such a change, pushing patch series to Gerrit is really no fun for anyone :/ I've no idea if this is currently being worked on (at least, I don't really se an issue reported in Gerrit's issue tracker). Maybe we should sit down and at least document how we'd like to improve this specific workflow? Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Nova] How to improve our bug triaging ?
Hi, Le jeudi 21 juin 2012, à 16:29 +0200, Thierry Carrez a écrit : * Run BugTriage days more often ? We could have regular (monthly?) Nova Bugtriage days to get rid of what accumulated in the mean time. But I fear that urgent bugs might not get the attention they deserve, and that over time less and less people participate to those exciting events... [...] * Should we just encourage more people to do BugTriaging ? Sounds like the obvious solution. However to do good triaging, you need bug supervisors rights, and when I proposed to open that team (the nova-bugs team) to anyone, there was resistance. Maybe it makes sense for Nova though... or maybe someone should actively manage that team and grant rights to any known triager that needs them. To me, those two points are related: we likely want to have more bug triage days, but in order to make this work in the long term, we need to encourage more people to join the effort. Else, there'll be burnout. We can then have several ways to make those days more exciting; this has been done in many other projects already (setting goals, friendly competition between participants, and even just creating a friendly atmosphere on irc during the day). Even just seeing the impressive stats in your last blog post is a good motivation for the next triage day... Oh, and I don't think we should be afraid of opening up the bug supervisors rights to more people. In other projects, the upsides have largely outweighed the potential downsides. Of course, it requires some expertise, but people will try hard to avoid doing mistakes, and mistakes can be reverted anyway :-) It's more important to have a sane bug database and happy bug reporters, than no mistakes at all. Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] [devstack] Easing maintenance of list of distro packages to install
Hi, In devstack, we currently have two separate lists of packages to install: one for Ubuntu (in files/apts/) and one for Fedora (in files/rpms/). This has two issues: - this leads to incomplete updates for dependencies. It happens that someone updates the apts files but not the rpms ones. (shameless plug: https://review.openstack.org/#/c/8475/ needs some review love) - this just doesn't scale when adding support for another distro, especially as rpm-based distros don't all share the same package names (hence files/rpms/ cannot really be shared). I'd like us to move to a new scheme where we have one list of packages (say the Ubuntu one, for instance) and instead of adding another one Fedora, openSUSE, etc., we have translation tables to map package names from Ubuntu to other distros. Supporting a new distro is then a matter of adding a translation table (+ hacking the code to change the right config files, obviously), and we can easily add tests to make sure the translation tables contain a mapping for each package (and therefore fix the first issue). I already have some working code for that, but I want to check if people are fine with the idea before submitting it for review. Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [devstack] Easing maintenance of list of distro packages to install
Hi, Le mercredi 20 juin 2012, à 11:24 +0100, Daniel P. Berrange a écrit : On Wed, Jun 20, 2012 at 12:06:46PM +0200, Vincent Untz wrote: I'd like us to move to a new scheme where we have one list of packages (say the Ubuntu one, for instance) and instead of adding another one Fedora, openSUSE, etc., we have translation tables to map package names from Ubuntu to other distros. Supporting a new distro is then a matter of adding a translation table (+ hacking the code to change the right config files, obviously), and we can easily add tests to make sure the translation tables contain a mapping for each package (and therefore fix the first issue). I already have some working code for that, but I want to check if people are fine with the idea before submitting it for review. I've nothing against your proposal certainly the motivation is good, but thought I'd throw out an alternative idea just in case Instead of having one sub-dir per package/distro, just have a single (CSV/JSON/XML/whatever) file listing all distros in the same place [...] The core idea is to have all the data, both the master list and distro mappings in one clear place. It's indeed nice to have everything in one unique place, but it's more cumbersome to parse from shell, while still allowing some specific overrides for different versions of distros. But I'm happy to go that way if it's the preferred one. Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [devstack] Easing maintenance of list of distro packages to install
Le mercredi 20 juin 2012, à 08:17 -0500, Dean Troyer a écrit : On Wed, Jun 20, 2012 at 5:06 AM, Vincent Untz vu...@suse.com wrote: - this leads to incomplete updates for dependencies. It happens that someone updates the apts files but not the rpms ones. (shameless This is going to always be a problem, independent of the mechanism used to manage package lists. Unless we have tests checking that all distros have a mapping for each package :-) The simple fact is that we really only develop DevStack on Ubuntu, anything else is a second-class citizen by definition. I do test Fedora periodically, but as of this point those are the only two distros we have committed to support, and Fedora still lags (try running stack.sh on f17 sometime). Well, I'd say it's up to the people running that distro to ensure that DevStack works fine there, really. But we can make their life easier, and make second-class feel much closer to first-class :-) - this just doesn't scale when adding support for another distro, especially as rpm-based distros don't all share the same package names (hence files/rpms/ cannot really be shared). The directory names could easily be anything else, it was originally meant to distinguish packages (apts) vs pips. Sure. I already have some working code for that, but I want to check if people are fine with the idea before submitting it for review. We have had other package dependency schemes proposed in the past, in the end the issue isn't the mechanism but the support. As it is the Fedora lists still often lag unless I can catch a review and prompt the author to add the required entry in the rpms directory Support aside, anything that we might adopt will necessarily be kept simple, such as changing the packaging names (apts/rpms) to packager names (ubuntu,fedora,etc). Is the following simple-enough: - adding a package: add the Debian package name in files/apts/, and add one line for the mapping in each other distro. Lazy approach is a line telling it's the same name, and users of the other distro will fix it when they update their devstack. - renaming a package: a simple sed in files/apts/ and in the translation tables - removing a package: simply removing the lines in files/apts/ and in the translation tables Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
