> On 5 Jul 2016, at 10:11, Florian Schmaus <f...@geekplace.eu> wrote:
> 
> On 05.07.2016 10:56, Ashley Ward wrote:
>> 
>>> On 5 Jul 2016, at 09:51, Florian Schmaus <f...@geekplace.eu> wrote:
>>> 
>>> On 05.07.2016 10:08, Evgeny Khramtsov wrote:
>>>> Tue, 5 Jul 2016 09:55:53 +0200
>>>> Florian Schmaus <f...@geekplace.eu> wrote:
>>>> 
>>>>> I'd also welcome if XEP development, especially for such an important
>>>>> one like MIX, would be more open.
>>>> 
>>>> For the record, we already have github XSF repo for that. We can keep
>>>> development there and tag stable version.
>>> 
>>> So far, the XSF repo is *only* used for submitted XEPs, everything in
>>> inbox/ is a ProtoXEPs and XEPs with numbers follow the standards track.
>>> Changes are only made by the XSF Editor Team. It is not used for active
>>> development of those XEPs, and I think it should be that way.
>> 
>> For a while it’s been my vision that each XEP should have its own repo. The 
>> authors could then ‘own’ their own XEP repo - push to development branches, 
>> accept updates (to draft XEPs), etc. This would need a much higher level of 
>> automation than we have now though, and I just don’t have the bandwidth to 
>> do anything on it at the moment unfortunately.
> 
> To be frank, I think the one-repo-per-XEP approach is a terrible idea. I
> see not a single major advantage, but it would require and enormous
> maintenance and setup effort. Simply have a few people which review PRs
> against the repo for some simple constraints, e.g. that they don't mess
> with other peoples XEPs, and then merge them (note that this is
> basically the same approach the xsf/xeps repo uses).

This is essentially what we have now - the xeps repo has a bunch of PRs which 
anyone can submit, and the editors are responsible for merging. Delegating the 
responsibility of merging changes for experimental xeps to the authors (who are 
ultimately responsible anyway) seems like it would be a good idea to me.

As I said though, to make this work (and not just a maintenance nightmare) 
would require a lot of automation - automatically creating repos and 
maintaining ownership, publishing updates, etc. If it worked well it would be 
awesome, but if it doesn’t work particularly well then it would be worse than 
what we currently have, so I’ll just drop this obligatory xkcd here to stop 
myself getting too excited... https://xkcd.com/1319/ <https://xkcd.com/1319/>

Cheers,

Ash

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

_______________________________________________
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
_______________________________________________

Reply via email to