Re: [Openstack] Stable branch reviews
Hi James, On Fri, 2011-11-11 at 07:03 +, Mark McLoughlin wrote: On Thu, 2011-11-10 at 08:02 -0800, James E. Blair wrote: Mark McLoughlin mar...@redhat.com writes: Only folks that understand the stable branch policy[1] should be allowed to +2 on the stable branch. Basically, a stable branch reviewer should only +2 if: - It fixes a significant issue, seen, or potentially seen, by someone during real life use - The fix, or equivalent, must be in master already - The fix was either a fairly trivial cherry-pick that looks equally correct for the stable branch, or that the fix has sufficient technical review (e.g. a +1 from another stable reviewer if it's fairly straightforward, or one or more +1s from folks on core it it's really gnarly) - If this reviewer proposed the patch originally, another stable branch reviewer should have +1ed it All we need is an understanding of the policy and reasonable judgement, it's not rocket science. I'd encourage folks to apply to the team for membership after reviewing a few patches. It sounds like the best way to implement this policy is to give openstack-stable-maint exclusive approval authority on stable branches, and then make sure people understand those rules when adding them to that team. If that's the consensus, I can make the change. Yes, that's what Thierry initially suggested and I'm persuaded now too :) Could you go ahead and make this change? Thanks much, Mark. ___ 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] Stable branch reviews
Since we're clear about how changes should be included in stable branches, are there any expectations on how often packages (e.g. Ubuntu ones) should be updated? Kind regards, Yuriy. On Fri, Nov 18, 2011 at 10:42, Mark McLoughlin mar...@redhat.com wrote: Hi James, On Fri, 2011-11-11 at 07:03 +, Mark McLoughlin wrote: On Thu, 2011-11-10 at 08:02 -0800, James E. Blair wrote: Mark McLoughlin mar...@redhat.com writes: Only folks that understand the stable branch policy[1] should be allowed to +2 on the stable branch. Basically, a stable branch reviewer should only +2 if: - It fixes a significant issue, seen, or potentially seen, by someone during real life use - The fix, or equivalent, must be in master already - The fix was either a fairly trivial cherry-pick that looks equally correct for the stable branch, or that the fix has sufficient technical review (e.g. a +1 from another stable reviewer if it's fairly straightforward, or one or more +1s from folks on core it it's really gnarly) - If this reviewer proposed the patch originally, another stable branch reviewer should have +1ed it All we need is an understanding of the policy and reasonable judgement, it's not rocket science. I'd encourage folks to apply to the team for membership after reviewing a few patches. It sounds like the best way to implement this policy is to give openstack-stable-maint exclusive approval authority on stable branches, and then make sure people understand those rules when adding them to that team. If that's the consensus, I can make the change. Yes, that's what Thierry initially suggested and I'm persuaded now too :) Could you go ahead and make this change? Thanks much, Mark. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ 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] Stable branch reviews
Hi Yuriy, On Fri, 2011-11-18 at 11:38 +0400, Yuriy Taraday wrote: Since we're clear about how changes should be included in stable branches, are there any expectations on how often packages (e.g. Ubuntu ones) should be updated? I've pushed out a Fedora 16 update with the latest stable branch and I think Chuck is doing the same for Ubuntu. We're also hoping to do a 2011.3.1 release from the branch in the not too distant future. Cheers, Mark. ___ 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] Stable branch reviews
On Fri, 2011-11-11 at 08:57 -0800, James E. Blair wrote: Mark McLoughlin mar...@redhat.com writes: On Fri, 2011-11-11 at 12:11 +0400, Yuriy Taraday wrote: I wonder if we should keep Change ID consistent in stable and master branches so that if one merged something into master, reviewers and archaeologists can easily find both related changes in master and all backports of specific change. The simple scenario is: push change into master, then cherry-pick it on top of stable branch(es). Change-Id will be the same, Gerrit will allow one to find all such backports by clicking on Change-Id. If gerrit can handle it, that would be great. But I'm not sure it does It does work as Yuriy described, and seems to be in keeping with gerrit philosophy. Maybe we should update the wiki to incorporate that. Here's an example: https://review-dev.openstack.org/#q,I1729eb6fb7027808650bae9a87b2d95cc5c5a0f7,n,z Cool, I'll update the wiki. In the mean time, we make sure that all commits to the stable branch include cherry picked from X in the commit message to help tracking. Also, I'm experimenting with using git-notes to keep track of e.g. why patches on master weren't cherry-picked into stable: http://wiki.openstack.org/StableBranch#Keeping_Notes Why not (also) leave review comments to that effect in gerrit? If you started them out with something like Reviewed for stable inclusion, they'd be easy to spot when scanning the collapsed comments. Well, what I want to do is occasionally go over all the commits that have been made on master since the last time I reviewed them. And I don't really want to have to go to gerrit for every single commit on master to add comments. Cheers, Mark. ___ 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] Stable branch reviews
I wonder if we should keep Change ID consistent in stable and master branches so that if one merged something into master, reviewers and archaeologists can easily find both related changes in master and all backports of specific change. The simple scenario is: push change into master, then cherry-pick it on top of stable branch(es). Change-Id will be the same, Gerrit will allow one to find all such backports by clicking on Change-Id. Kind regards, Yuriy. On Wed, Nov 9, 2011 at 19:50, Thierry Carrez thie...@openstack.org wrote: Hi everyone, Since there seems to be some confusion around master vs. stable/diablo vs. core reviewers, I think it warrants a small thread. When at the Design Summit we discussed setting up stable branches, I warned about the risks that setting them up brings for trunk development: 1) Reduce resources affected to trunk development 2) Reduce quality of trunk To mitigate that, we decided that the group doing stable branch maintenance would be a separate group (i.e. *not* core developers), and we decided that whatever ends up in the stable branch must first land in the master branch. So a change goes like this: * Change is proposed to trunk * Change is reviewed by core (is it appropriate, well-written, etc) * Change lands in trunk * Change is proposed to stable/diablo * Change is reviewed by stable team (is it relevant for a stable update, did it land in trunk first) * Change lands in stable/diablo This avoids the aforementioned risks, avoids duplicating review efforts (the two reviews actually check for different things), and keep the teams separate (so trunk reviews are not slowed down by stable reviews). Note that this does not prevent core developers that have an interest in stable/diablo from being in the two teams. Apparently people in core can easily mistake master for stable/diablo, and can also +2 stable/diablo changes. In order to avoid mistakes, I think +2 powers on stable/diablo should be limited to members of the stable maintenance team (who know their stable review policy). That should help avoid mistakes (like landing a fix in stable/diablo that never made it to master), while not preventing individual core devs from helping in stable reviews. Regards, -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ 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] Stable branch reviews
On Fri, 2011-11-11 at 12:11 +0400, Yuriy Taraday wrote: I wonder if we should keep Change ID consistent in stable and master branches so that if one merged something into master, reviewers and archaeologists can easily find both related changes in master and all backports of specific change. The simple scenario is: push change into master, then cherry-pick it on top of stable branch(es). Change-Id will be the same, Gerrit will allow one to find all such backports by clicking on Change-Id. If gerrit can handle it, that would be great. But I'm not sure it does In the mean time, we make sure that all commits to the stable branch include cherry picked from X in the commit message to help tracking. Also, I'm experimenting with using git-notes to keep track of e.g. why patches on master weren't cherry-picked into stable: http://wiki.openstack.org/StableBranch#Keeping_Notes Cheers, Mark. ___ 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] Stable branch reviews
Mark McLoughlin mar...@redhat.com writes: On Fri, 2011-11-11 at 12:11 +0400, Yuriy Taraday wrote: I wonder if we should keep Change ID consistent in stable and master branches so that if one merged something into master, reviewers and archaeologists can easily find both related changes in master and all backports of specific change. The simple scenario is: push change into master, then cherry-pick it on top of stable branch(es). Change-Id will be the same, Gerrit will allow one to find all such backports by clicking on Change-Id. If gerrit can handle it, that would be great. But I'm not sure it does It does work as Yuriy described, and seems to be in keeping with gerrit philosophy. Maybe we should update the wiki to incorporate that. Here's an example: https://review-dev.openstack.org/#q,I1729eb6fb7027808650bae9a87b2d95cc5c5a0f7,n,z In the mean time, we make sure that all commits to the stable branch include cherry picked from X in the commit message to help tracking. Also, I'm experimenting with using git-notes to keep track of e.g. why patches on master weren't cherry-picked into stable: http://wiki.openstack.org/StableBranch#Keeping_Notes Why not (also) leave review comments to that effect in gerrit? If you started them out with something like Reviewed for stable inclusion, they'd be easy to spot when scanning the collapsed comments. -Jim ___ 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] Stable branch reviews
Hey, On Wed, 2011-11-09 at 16:50 +0100, Thierry Carrez wrote: Hi everyone, Since there seems to be some confusion around master vs. stable/diablo vs. core reviewers, I think it warrants a small thread. When at the Design Summit we discussed setting up stable branches, I warned about the risks that setting them up brings for trunk development: 1) Reduce resources affected to trunk development 2) Reduce quality of trunk The it must be in trunk first policy is the best way to mitigate against that. To mitigate that, we decided that the group doing stable branch maintenance would be a separate group (i.e. *not* core developers), and we decided that whatever ends up in the stable branch must first land in the master branch. Well, I recall it a little differently - that both the stable branch maint group and the core team members would have +2 privileges on the stable branch. Maybe I just misread James here: https://lists.launchpad.net/openstack/msg04751.html only members of the maintainers team or core devs can +/-2 I also seem to have imagined the core teams being members of the stable branch maint team: https://launchpad.net/~openstack-stable-maint/+members But, whatever :) We have a separate team with me, Chuck and Dave on it. Only one of us can +2. But wait! Vish +2ed a stable branch patch yesterday: https://review.openstack.org/328 James, help a poor confused soul out here, would you? :) So a change goes like this: * Change is proposed to trunk * Change is reviewed by core (is it appropriate, well-written, etc) * Change lands in trunk * Change is proposed to stable/diablo * Change is reviewed by stable team (is it relevant for a stable update, did it land in trunk first) * Change lands in stable/diablo This avoids the aforementioned risks, avoids duplicating review efforts (the two reviews actually check for different things), and keep the teams separate (so trunk reviews are not slowed down by stable reviews). Note that this does not prevent core developers that have an interest in stable/diablo from being in the two teams. Apparently people in core can easily mistake master for stable/diablo, and can also +2 stable/diablo changes. In order to avoid mistakes, I think +2 powers on stable/diablo should be limited to members of the stable maintenance team (who know their stable review policy). That should help avoid mistakes (like landing a fix in stable/diablo that never made it to master), while not preventing individual core devs from helping in stable reviews. Right, that makes sense. Only folks that understand the stable branch policy[1] should be allowed to +2 on the stable branch. Basically, a stable branch reviewer should only +2 if: - It fixes a significant issue, seen, or potentially seen, by someone during real life use - The fix, or equivalent, must be in master already - The fix was either a fairly trivial cherry-pick that looks equally correct for the stable branch, or that the fix has sufficient technical review (e.g. a +1 from another stable reviewer if it's fairly straightforward, or one or more +1s from folks on core it it's really gnarly) - If this reviewer proposed the patch originally, another stable branch reviewer should have +1ed it All we need is an understanding of the policy and reasonable judgement, it's not rocket science. I'd encourage folks to apply to the team for membership after reviewing a few patches. Cheers, Mark. [1] - http://wiki.openstack.org/StableBranch ___ 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] Stable branch reviews
Mark McLoughlin mar...@redhat.com writes: To mitigate that, we decided that the group doing stable branch maintenance would be a separate group (i.e. *not* core developers), and we decided that whatever ends up in the stable branch must first land in the master branch. Well, I recall it a little differently - that both the stable branch maint group and the core team members would have +2 privileges on the stable branch. If we discussed that explicitly, I'm afraid it didn't make it into my notes from the summit. It wouldn't surprise me if we left the answer to that question in the bike shed. Maybe I just misread James here: https://lists.launchpad.net/openstack/msg04751.html only members of the maintainers team or core devs can +/-2 You read correctly; I took your proposal, translated it into slightly more formal gerrit terms, and implemented that. So currently gerrit is configured so that _either_ core devs or the maintainers team can approve changes to stable/ branches. That can be changed, and maintainers can be given exclusive approval authority over the stable/ branches. I also seem to have imagined the core teams being members of the stable branch maint team: https://launchpad.net/~openstack-stable-maint/+members Right now it doesn't matter because in gerrit core devs have the same authority as maintainers. However, if we make maintainers exclusive approvers, it might be better for individuals with interests in both to be individually members of both since the stable branch has extra behavioral rules. But wait! Vish +2ed a stable branch patch yesterday: https://review.openstack.org/328 James, help a poor confused soul out here, would you? :) Right, that makes sense. Only folks that understand the stable branch policy[1] should be allowed to +2 on the stable branch. Basically, a stable branch reviewer should only +2 if: - It fixes a significant issue, seen, or potentially seen, by someone during real life use - The fix, or equivalent, must be in master already - The fix was either a fairly trivial cherry-pick that looks equally correct for the stable branch, or that the fix has sufficient technical review (e.g. a +1 from another stable reviewer if it's fairly straightforward, or one or more +1s from folks on core it it's really gnarly) - If this reviewer proposed the patch originally, another stable branch reviewer should have +1ed it All we need is an understanding of the policy and reasonable judgement, it's not rocket science. I'd encourage folks to apply to the team for membership after reviewing a few patches. It sounds like the best way to implement this policy is to give openstack-stable-maint exclusive approval authority on stable branches, and then make sure people understand those rules when adding them to that team. If that's the consensus, I can make the change. -Jim ___ 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] Stable branch reviews
On Nov 10, 2011, at 6:22 AM, Mark McLoughlin wrote: But wait! Vish +2ed a stable branch patch yesterday: https://review.openstack.org/328 I don't mind losing my powers over stable/diablo. On a related note, is there a way we can change the color scheme in gerrit (to red??) for stable branches? I think there are a number of cases with core members reviewing stable/diablo patches thinking they were for trunk. Vish ___ 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] Stable branch reviews
On Thu, Nov 10, 2011 at 08:02:23AM -0800, James E. Blair wrote: SNIP But wait! Vish +2ed a stable branch patch yesterday: https://review.openstack.org/328 James, help a poor confused soul out here, would you? :) Right, that makes sense. Only folks that understand the stable branch policy[1] should be allowed to +2 on the stable branch. Basically, a stable branch reviewer should only +2 if: - It fixes a significant issue, seen, or potentially seen, by someone during real life use - The fix, or equivalent, must be in master already - The fix was either a fairly trivial cherry-pick that looks equally correct for the stable branch, or that the fix has sufficient technical review (e.g. a +1 from another stable reviewer if it's fairly straightforward, or one or more +1s from folks on core it it's really gnarly) - If this reviewer proposed the patch originally, another stable branch reviewer should have +1ed it All we need is an understanding of the policy and reasonable judgement, it's not rocket science. I'd encourage folks to apply to the team for membership after reviewing a few patches. It sounds like the best way to implement this policy is to give openstack-stable-maint exclusive approval authority on stable branches, and then make sure people understand those rules when adding them to that team. If that's the consensus, I can make the change. Hi, Thanks for helping to add clarification to this. From our perspective, I have confidence that ~*-core members know the difference between trunk and stable policy. Therefore for the short term, it makes sense to have more eyes - especially those which are likely to have good knowledge of the internals. Therefore, I am happy for ~*-core to still have +2 access; especially if it helps seed the maint team. Going forward, it probably will make sense to have a distinction, but I feel it might be quite early for that to be a requirement. Thanks. Kind Regards, Dave Walker signature.asc Description: Digital signature ___ 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] Stable branch reviews
On Thu, 2011-11-10 at 09:02 -0800, Vishvananda Ishaya wrote: On Nov 10, 2011, at 6:22 AM, Mark McLoughlin wrote: But wait! Vish +2ed a stable branch patch yesterday: https://review.openstack.org/328 I don't mind losing my powers over stable/diablo. On a related note, is there a way we can change the color scheme in gerrit (to red??) for stable branches? I think there are a number of cases with core members reviewing stable/diablo patches thinking they were for trunk. No doubt gerrit could be improved, but what works for me is to just look at reviews for the master branch with e.g. https://review.openstack.org/#q,status:open+project:openstack/nova+branch:master,n,z Gerrit's query syntax is actually quite useful, e.g. https://review.openstack.org/#q,status:open+project:openstack/nova+branch:master+owner:vish,n,z Docs on it here: http://review.coreboot.org/Documentation/user-search.html Cheers, Mark. ___ 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] Stable branch reviews
On Thu, 2011-11-10 at 08:02 -0800, James E. Blair wrote: Mark McLoughlin mar...@redhat.com writes: Only folks that understand the stable branch policy[1] should be allowed to +2 on the stable branch. Basically, a stable branch reviewer should only +2 if: - It fixes a significant issue, seen, or potentially seen, by someone during real life use - The fix, or equivalent, must be in master already - The fix was either a fairly trivial cherry-pick that looks equally correct for the stable branch, or that the fix has sufficient technical review (e.g. a +1 from another stable reviewer if it's fairly straightforward, or one or more +1s from folks on core it it's really gnarly) - If this reviewer proposed the patch originally, another stable branch reviewer should have +1ed it All we need is an understanding of the policy and reasonable judgement, it's not rocket science. I'd encourage folks to apply to the team for membership after reviewing a few patches. It sounds like the best way to implement this policy is to give openstack-stable-maint exclusive approval authority on stable branches, and then make sure people understand those rules when adding them to that team. If that's the consensus, I can make the change. Yes, that's what Thierry initially suggested and I'm persuaded now too :) Cheers, Mark. ___ 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] Stable branch reviews
Hi Dave, On Thu, 2011-11-10 at 17:33 +, Dave Walker wrote: On Thu, Nov 10, 2011 at 08:02:23AM -0800, James E. Blair wrote: SNIP But wait! Vish +2ed a stable branch patch yesterday: https://review.openstack.org/328 James, help a poor confused soul out here, would you? :) Right, that makes sense. Only folks that understand the stable branch policy[1] should be allowed to +2 on the stable branch. Basically, a stable branch reviewer should only +2 if: - It fixes a significant issue, seen, or potentially seen, by someone during real life use - The fix, or equivalent, must be in master already - The fix was either a fairly trivial cherry-pick that looks equally correct for the stable branch, or that the fix has sufficient technical review (e.g. a +1 from another stable reviewer if it's fairly straightforward, or one or more +1s from folks on core it it's really gnarly) - If this reviewer proposed the patch originally, another stable branch reviewer should have +1ed it All we need is an understanding of the policy and reasonable judgement, it's not rocket science. I'd encourage folks to apply to the team for membership after reviewing a few patches. It sounds like the best way to implement this policy is to give openstack-stable-maint exclusive approval authority on stable branches, and then make sure people understand those rules when adding them to that team. If that's the consensus, I can make the change. Hi, Thanks for helping to add clarification to this. From our perspective, I have confidence that ~*-core members know the difference between trunk and stable policy. Therefore for the short term, it makes sense to have more eyes - especially those which are likely to have good knowledge of the internals. Therefore, I am happy for ~*-core to still have +2 access; especially if it helps seed the maint team. Going forward, it probably will make sense to have a distinction, but I feel it might be quite early for that to be a requirement. I basically said the same thing initially to Thierry on irc, but he turned me around. I'm not actually sure all folks on core do grok (or even want to grok) the subtleties of the stable branch policy and the tradeoffs you need to make when deciding whether to +2 some on the stable branch. Thierry has had some similar experience with the milestone-proposed branch, I guess. Also, I'm not even sure all folks on core always notice that a patch is being submitted against stable, not master :) But, of course, if anyone in core wanted to help with +2ing on the stable branch, we'd add them to stable-maint in a flash. Cheers, Mark. ___ 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] Stable branch reviews
++ On Wed, Nov 9, 2011 at 10:50 AM, Thierry Carrez thie...@openstack.org wrote: Hi everyone, Since there seems to be some confusion around master vs. stable/diablo vs. core reviewers, I think it warrants a small thread. When at the Design Summit we discussed setting up stable branches, I warned about the risks that setting them up brings for trunk development: 1) Reduce resources affected to trunk development 2) Reduce quality of trunk To mitigate that, we decided that the group doing stable branch maintenance would be a separate group (i.e. *not* core developers), and we decided that whatever ends up in the stable branch must first land in the master branch. So a change goes like this: * Change is proposed to trunk * Change is reviewed by core (is it appropriate, well-written, etc) * Change lands in trunk * Change is proposed to stable/diablo * Change is reviewed by stable team (is it relevant for a stable update, did it land in trunk first) * Change lands in stable/diablo This avoids the aforementioned risks, avoids duplicating review efforts (the two reviews actually check for different things), and keep the teams separate (so trunk reviews are not slowed down by stable reviews). Note that this does not prevent core developers that have an interest in stable/diablo from being in the two teams. Apparently people in core can easily mistake master for stable/diablo, and can also +2 stable/diablo changes. In order to avoid mistakes, I think +2 powers on stable/diablo should be limited to members of the stable maintenance team (who know their stable review policy). That should help avoid mistakes (like landing a fix in stable/diablo that never made it to master), while not preventing individual core devs from helping in stable reviews. Regards, -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
