我是 Launchpad 和 Bazaar，我正在尝试找出提交错误修复的最佳方法。我正在使用一些托管在 Launchpad 上的相当流行的开源软件，但它不是很稳定。我创建了自己的项目分支来稳定它，并仅应用我们需要的错误修复，而无需添加正在进行的开发中的其他更改。
当我提交错误并找出如何自己修复它们时，我会将修复推送到我们的稳定分支。我应该如何将修复发布回主项目？我可以创建一个补丁文件并将其附加到错误中，或者我可以建议对我们的稳定分支进行合并。
如果我修复了多个错误，我可以为每个错误制定单独的合并建议，还是可以累积？
I'm new to Launchpad and Bazaar, and I'm trying to figure out what the best way is to submit bug fixes. I'm using some reasonably popular open-source software that's hosted on Launchpad, but it's not very stable. I've created my own branch of the project to stabilize it and apply just the bug fixes we need without adding other changes from ongoing development.
When I file bugs and then figure out how to fix them myself, I push the fix to our stable branch. How should I publish the fix back to the main project? I could create a patch file and attach it to the bug, or I could propose a merge for our stable branch.
If I fix multiple bugs, can I make a separate merge proposal for each one, or are they cumulative?
发布评论
评论（2）
更新：看起来OpenERP项目的官方文档现在有提出合并建议的指南。我也会在这里留下我的版本，因为它有一些不同的细节。
在使用 Bazaar 和 Launchpad 几天并提交了一些补丁和合并提案之后，我想我应该写一个我的发现的摘要。 Launchpad 和 Bazaar 提供了一些强大的工具，特别是对于社区驱动的项目，但我认为新用户不太可能掉入成功的深渊还没。有多种方法可以使该过程变得缓慢且令人沮丧，因此我希望本演练可以帮助一些人避免一些错误。
以下是我学到的用于修复错误并向团队提交合并提案（针对 Launchpad 上托管的项目）的工作流程。我正在 GNU/Linux 工作站上工作，但我认为 Bazaar 命令在其他平台上是等效的。在此示例中，我正在处理 OpenObject 项目组中名为 OpenObject Addons 的项目之一。维护者的用户名是openerp。我将把我的工作区放在
~/workspace文件夹中。如果您想了解有关此处任何命令的更多信息，请使用
bzr help加上命令名称。创建共享存储库
因为我要为每个想要回馈项目的功能创建一个分支，所以我不想为每个分支拥有项目整个历史记录的单独副本。为了避免这种情况，我创建了一个共享存储库，然后在其中创建每个分支。需要注意的一件事是，您的存储库格式必须与官方分支的格式相匹配，以使后续的一些步骤起作用。
检查官方分支上的存储库格式：
获取代码
现在创建一个工作区文件夹，该文件夹将保存您计算机上的任何本地分支 - 我只是以项目命名它。然后使用您在官方分支上找到的格式在其中创建一个共享存储库。
下一步是从官方分支查看源代码。它通常称为主干，但您可能更喜欢使用仅用于错误修复的稳定版本分支。在此示例中，我将在 5.0 发行版分支上工作。
对于大型项目来说，该步骤可能是整个过程中最慢的，因为您要将整个项目的所有代码以及所有历史记录复制到硬盘上。请注意，我以我要处理的功能来命名该分支。
创建分支
此时，您可以尝试在本地工作站上构建和运行代码。您可以对代码进行更改，但您还没有任何地方可以提交它们，因为您可能不允许直接提交到官方分支。要发布代码更改，您需要创建一个公共分支。如果您是 Launchpad 新手，则需要创建帐户并注册公钥 首先。
设置帐户后，您可以将自己的分支发布为官方分支的副本，并开始使用它。
lp-login命令告诉 bazaar 在启动板站点上使用什么帐户名，whoami命令告诉 bazaar 在您提交的每个修订上使用什么名称。您在whoami中使用的电子邮件地址应与您为 Launchpad 帐户配置的电子邮件地址之一匹配。您切换到新分支，以便提交将记录在您的本地历史记录和公共分支中。您可能想了解结帐和分支之间的区别。使其成为堆叠分支意味着创建速度非常快，因为它只包含官方分支中没有的历史记录。 这篇博文让它听起来像分支公共项目应该默认为堆叠，但这对我不起作用。请注意，我以我想要添加的某些功能来命名该分支。正如 bialix 建议的，我为每个功能创建一个单独的分支，最终建议将其合并回官方分支。
提交并提出合并建议
现在您已经有了一个分支，您可以进行代码更改并提交它们。
您可以从分支结构中的任何位置提交，并且默认情况下会提交整个分支。运行
bzr help commit了解详细信息。您可能还会发现bzr status和bzr diff很有用。一旦您对更改感到满意并将所有内容提交到功能分支，您就可以访问 Launchpad 网站并创建合并提案。这是一个方便的快捷方式，您可以运行它来启动分支的网页：
创建合并提案后，Launchpad 将为其生成一个差异。非常值得回顾一下这个差异。有时我选择了错误的分支作为目标，我只是注意到差异的变化比我预期的要多。还有一个用于合并提案的
bzr send命令，但我没有使用它。有一个电子邮件界面用于引导您的提案完成整个过程，或者您也可以使用网站。
将分支附加到错误也很有用，以便其他人可以像在自己的系统上使用补丁一样使用它。
正在进行的更改
如果您正在开发多个功能，并且维护者审核您的提案的速度不是很快，那么可能值得建立自己的主线分支。该分支将您的所有功能收集在一起，并保存您将在服务器上运行的代码。如果官方分支不是很稳定并且您想要稳定生产环境的分支，那么它也很有用。然后，您可以决定何时升级到最新版本，以及何时针对损害用户的错误采取特定补丁。
第一步是创建另一个堆叠在官方分支上的分支：
现在您需要合并两个更改源。首先，从功能或错误修复分支合并：
当然，如果您仍然有功能分支的本地副本，则进行本地合并会更快：
其次，您偶尔会想要合并来自的最新和最好的分支官方分支：
从官方分支合并时使用
--remember后，您可以单独使用bzr merge来从官方分支合并。如果项目使用标签来标记发布点，您可以查看标签列表并从标签进行合并。Update: It looks like the OpenERP project's official documentation now has guidelines for making merge proposals. I'll also leave my version here because it has some different details.
After playing with Bazaar and Launchpad for a few days and submitting a few patches and merge proposals, I thought I'd write a summary of what I found. Launchpad and Bazaar provide some powerful tools, particularly for community-driven projects, but I don't think new users are likely to fall into the pit of success yet. There are several ways to make the process slow and frustrating, so I hope this walk through helps some people avoid a few mistakes.
Here's the work flow I've learned for working on bug fixes and submitting merge proposals back to the team for a project that's hosted on Launchpad. I'm working on a GNU/Linux workstation, but I assume the Bazaar commands would be equivalent on other platforms. In this example, I'm working on one of the projects in the OpenObject project group called OpenObject Addons. The maintainer's user name is openerp. I'll put my workspace in the
~/workspacefolder.If you want to learn more about any of the commands here, use
bzr helpplus the command name.Create a shared repository
Because I'm going to be creating a branch for each feature I want to contribute back to the project, I don't want to have a separate copy of the project's entire history for each branch. To avoid that, I create a shared repository and then create each branch within that. One thing to be careful of is that your repository format has to match the official branch's format to make some of the later steps work.
Check the repository format on the official branch:
Get the code
Now create a workspace folder that will hold any local branches on your machine - I just name it after the project. Then create a shared repository in it using the format you found on the official branch.
The next step is to check out the source code from the official branch. It's usually called trunk, but you might prefer to work with a stable release branch that is just being used for bug fixes. In this example, I'm going to work on the 5.0 release branch.
That step is probably the slowest in the whole process for a large project, because you're copying all the code plus all the history for the entire project onto your hard drive. Note that I name the branch after the feature I'm going to work on.
Create a branch
At this point you can experiment with building and running the code on your local workstation. You can make changes to the code, but you don't have anywhere to commit them yet, because you're probably not allowed to commit directly into the official branch. To publish your code changes you need to create a public branch. If you're new to Launchpad, you'll need to create an account and register a public key first.
Once you've set up your account, you can publish your own branch as a copy of the official branch, and start working with it. The
lp-logincommand tells bazaar what account name to use on the launchpad site, and thewhoamicommand tells bazaar what name to use on each revision you commit. The e-mail address you use inwhoamishould match one of the e-mail addresses you configured for your Launchpad account.You switch to the new branch so that commits will be recorded in your local history and in your public branch. You might want to learn about the difference between a checkout and a branch. Making this a stacked branch means that it's very fast to create because it only contains the history that's not in the official branch. This blog post makes it sound like branches of public projects should default to stacked, but that hasn't worked for me. Notice that I named the branch after some feature I want to add. As bialix suggested, I create a separate branch for each feature that I will eventually propose merging back into the official branch.
Commit and make a merge proposal
Now that you have a branch, you can make code changes and commit them.
You can commit from anywhere within the branch structure, and it commits the entire branch by default. Run
bzr help commitfor details. You might also findbzr statusandbzr diffuseful.Once you're happy with the changes and you've committed everything to your feature branch, you can go to the Launchpad web site and create a merge proposal. Here's a handy shortcut that you can run to launch the branch's web page:
Once you create the merge proposal, Launchpad will generate a diff for it. It's well worth reviewing that diff. Sometimes I've selected the wrong branch as a target, and I only noticed because the diff had way more changes than I expected. There's also a
bzr sendcommand for merge proposals, but I haven't used it.There's an e-mail interface for shepherding your proposal through the process, or you can just use the web site.
It's also useful to attach the branch to the bug so that other people can use it like a patch on their own systems.
Ongoing changes
If you work on several features and the maintainer isn't very speedy at reviewing your proposals, it's probably worth setting up your own mainline branch. This branch collects all your features together and it holds the code that you would run on your servers. It's also useful if the official branch isn't very stable and you want to stabilize a branch for your production environment. Then you can decide when to upgrade to the latest, and when to take specific patches for bugs that are hurting your users.
The first step is to create another branch that is stacked on the official branch:
Now there are two sources of changes you'll need to merge from. First, merging from a feature or bug fix branch:
Of course, if you still have a local copy of the feature branch, it will be faster to do a local merge:
Second, you'll occassionally want to merge the latest and greatest from the official branch:
After using
--rememberwhen you merge from the official branch, you can just usebzr mergeon its own to merge from the official branch. If the project uses tags to mark release points, you can view a list of tags and merge from a tag.此类策略（使用合并提案或补丁）应由项目本身的核心开发人员或维护人员定义。但作为一般规则，为每个修复使用单独的分支比仅使用普通补丁更好。
将所有修复保留在一个分支中不利于在合并提案中使用它。但它本身对于测试所有修复或将其用作稳定分支（例如用于测试）很有用。因此，我建议为每个单独的修复使用单独的（功能）分支，为它们提交单独的合并建议，并将这些分支合并到您的稳定分支中，就像您今天所做的那样。通过这种方式，您可以完全自由地对每个修复应用额外的更改，然后将其再次合并到稳定分支。
如果您需要将现有的稳定分支拆分为几个单独的分支，您可以使用 John Meinel 在他的博客中描述的配方：http://jam-bazaar.blogspot.com/2009/10/refactoring-work-for-review-and-keep.html
Such policy (using merge proposals or patches) should be defined by core developers or maintainers of the project itself. But as general rule using separate branches for each fix is preferable way over just plain patches.
Keep all fixes in one branch is not good for using it in merge proposal. But it's useful per se for testing all your fixes or using it as stable branch (e.g. for dogfooding). So I'd suggest to use separate (feature) branches for each separate fix, file for them separate merge proposals, and merge these branches into your stable branch as you doing today. This way you can get full freedom over applying additional changes to each your fix and then merge it again to your stable branch.
If you need to split your existing stable branch to several separate branches you can use the recipe from John Meinel described in his blog: http://jam-bazaar.blogspot.com/2009/10/refactoring-work-for-review-and-keep.html