[RFC] Community driven branch extensions

[Martin Pool]

2009/11/12 Jelmer Vernooij <jelmer at samba.org>:
> Hi Ian,
>
> On Tue, 2009-11-10 at 13:50 +1000, Ian Clatworthy wrote:
>> Apologies up front for the length of this email. I hope the topic is
>> important enough to warrant it ...
>
> [...]
>
>> Don't that make sense? Am I smoking crazy stuff and ought to be locked
>> up? Are there better ways of achieving the same outcome? If not, would
>> this empower you and what would you use it for?
> Yes, I think this would make a lot of sense. It seems like we already
> have such a small set of features (subtrees, rich-roots) required for a
> repository at the moment, except that set is implied by the format
> rather than stored explicitly.

I think this would be good too, for use (as you mention) either for
local policy or for extensions.

Format bumps have been a sense of unnecessary pain so the more we can
do to enable future features to happen without format bumps, the
better.  If you look back at our format history then quite a few bumps
haven't been because of major changes of representation but just
because there's been something new that needs to be taken into account
- content filtering, stacking, etc.  We could potentially have done
them with requirements, though in that case you'd have to be careful
they're really enforced, and think about whether the requirements get
set automatically.

You might want these either in the tree (in say .bzrmeta/requirements)
or in the branch or repo.

There also seems to be a gap that the _kind of implementation_ that's
acceptable in bzr itself is different to what works in plugins.  It's
reasonable that we require core code to be eg more stable or tested or
documented, but seems questionable that it needs inherently different
code or formats.  So I don't see this so much as something to help
non-core developers only.

-- 
Martin <http://launchpad.net/~mbp/>