[RFH/MERGE 3/3] Towards XML log output: An implementation of XmlLogFormatter

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John Arbash Meinel wrote:
> Aaron Bentley wrote:
>>> For anyone wondering, Bundle Buggy didn't treat this as a merge request
>>> because the subject didn't start with '(re: )?\[(merge|patch)'.  Which
>>> appears to be correct, as James don't consider this ready to be merged.
> 
> I wonder if we would want to look at [BUG] and *maybe* [RFC].

I would definitely not want to treat RFCs as merge requests.  Maybe they
deserve tracking, but they're not merge requests.  I specifically use
[RFC] for things I don't want to be merged as-is.

> Alternatively, I think anything with a bundle could go into the queue.

I would really not like that.  Both from a policy POV and from an
efficiency one.  Patches and bundles are not necessarily merge requests,
and may not even refer to the bzr.dev codebase.  RFCs in particular are
not merge requests, and some patches that are posted are examples of bzr
behavior, not merge requests.

> But it doesn't really matter. I know I have a bundle I sent in under BUG.

Many BUGs don't provide a solution.  So if we did anything, I'd want to
only do it for BUGs that provide bundles/patches.  But often the patches
for a BUG are not intended to be ready for merging.  They're just quick
fixes that need test cases added and more polish.

If people think a more inclusive policy is better, I can change it.  I
just think that requiring explicit merge requests makes Bundle Buggy a
better tool for all us.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFTnOZ0F+nu1YWqI0RAkl3AJ9XcH1bngibdjUppAkFCx2NAQY2kQCeNB/3
Ct8SrMJlnz6FItm71acKgnk=
=7OZ8
-----END PGP SIGNATURE-----