Shelve extension

[Bill Barry]

Paul Moore wrote:
> Which, to be honest, sounds like a good, clear distinction which
> justifies having 2 distinct extensions.
>
> That's not to say that merging all 4 wouldn't be a good goal, of course.


Perhaps a single extension will not be reached; at the very least there 
will be very well defined integration between them.

It is way too early to even begin talking about this but, as of right 
now I am envisioning at some point a UI mechanism that hg webhosts would 
implement which would hook into a mailing list and a repository and a CI 
system and provide a good interface for accepting patches and forming 
some sort of community hub around a source tree.

there would be a process which:
1. monitors a mailing list (or even a set of mailing lists?)
2. for each mail thread that contains a single patch, start a thread in 
the web-system and store the patch in the system's attic (and commit it)
3. for each mail thread that contains a set of patches start a queue in 
the attic and a thread
4. every list reply goes to the thread, and every thread post generates 
a reply to the list

the web interface would:
1. allow users in an ACL to delete threads, mark patches as accepted, 
mark patches as denied
2. provide friendly urls to see what is happenning/manage a 
patch/patchset (ex: 
https://bitbucket.org/segv/hg-website/patchwork/fixbug1 could contain a 
patch and accompanying thread)
3. allow some sort of pbranch clone which would let users clone a 
pbranchified repository of the current patch they are looking at so they 
can collaborate (this repo would additionally contain path aliases set 
up to be able to pull in other user's pbranchified modifications to the 
current patch, etc.)

the backing storage would be defined in such a way that it can be merged 
fully automatically and will be stored within a repository of its own. 
The CI system could interact with this by placing testresults and such 
in a specific location indicating how a particular patch tests out. 
Also, once a patch was marked accepted, the system would queue it up for 
inclusion into the mainline and if the CI system signs off on it and it 
applies cleanly against the tip, the patch would get turned into a 
changeset at the tip of the repository graph.

This would also fulfill the needs for a lightweight (distributed) bug 
reporting system (just file a blank patch with the description of the 
bug to the mailing list or directly in the webinterface)