<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Sep 19, 2015 at 8:07 PM, Boudhayan Gupta <span dir="ltr"><<a href="mailto:bgupta@kde.org" target="_blank">bgupta@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">On 19 September 2015 at 19:34, Vishesh Handa <<a href="mailto:me@vhanda.in">me@vhanda.in</a>> wrote:<br>
> Please note that consistency isn't a requirement to be part of KDE. If<br>
> I decide to write an application in Rust, which is only for Windows,<br>
> and uses a completely different build system, that is allowed.<br>
<br>
</span>How are these two things even remotely similar? Of course you're<br>
allowed to write a Windows specific app in Rust. Hell, according to<br>
the manifesto we should be able to write apps for the Commodore64 if<br>
we want to, provided that the software complies with licensing and<br>
community engagement requirements of the KDE community. On a more<br>
realistic note, almost all KDE apps have their own coding style, and<br>
every maintainer has their own standard on how far to stick to these<br>
styles.<br>
<br>
It is important to note that we're talking about infrastructural<br>
consistency here, not code consistency. There is a distinction. What<br>
you're suggesting is akin to GitHub deciding to have a HTML5 text<br>
console for half their repository pages, and their standard web<br>
interface for the other half, with glitzy christmas decorations and<br>
falling snow effects put on a few pages for good measure.<br>
<span class=""><br></span></blockquote><div><br></div><div>Adding to this, its not even about just the infrastructure, its about workflow consistency. Why do we wish to confuse newcomers by giving them two methods of code contributions when we can live with just one?<br><br></div><div>(oh and btw, and though its not really relevant to this discussion, consistency was one of *the* founding principles of KDE, go read the 2nd sentence at <a href="https://www.kde.org/announcements/announcement.php">https://www.kde.org/announcements/announcement.php</a> )<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">
>><br>
>> 3. Regarding point 4, if developers already have personal GitHub<br>
>> clones that they use for their own purposes, nothing is stopping them<br>
>> from continuing to use them. Those clones are not endorsed by KDE,<br>
>> they are under complete control of the individual<br>
>> developers/maintainers, they are entirely the responsibility of the<br>
>> developers/maintainers, and the developers/maintainers are free to do<br>
>> with them as they see fit.<br>
>><br>
><br>
> Because maintainers are not responsible for their own projects anyway?<br>
> If I'm taking responsibility for a project, I'm also taking<br>
> responsibility for other parts of it. In this case Github. No one is<br>
> forcing anyone.<br>
><br>
<br>
</span>Common ownership. There's a difference between any random open source<br>
project on GitHub/SF.net/elsewhere and a KDE project. Maintainers are<br>
responsible for their own projects (that's why they're maintainers).<br>
They're also responsible for playing nice with the rest of the<br>
community and abiding by the requirements of the rest of the<br>
community. Also, while the rest of KDE may not have a say in the code<br>
of the project (the maintainer is the maintainer because he/she<br>
understands the code to a higher degree than the rest of the people<br>
here), they do have a say in the project's governance.<br>
<span class=""><br>
>> Here's what developers and maintainers should really do: forget that<br>
>> <a href="http://github.com/kde" rel="noreferrer" target="_blank">github.com/kde</a> exists.<br>
><br>
> They can do that if they are comfortable with the status-quo. Some<br>
> people are clearly not. Your email disregards the points raised and<br>
> implies that the github readonly mirror is only what is acceptable.<br>
> That result is clearly not shared by everyone.<br>
<br>
</span>This comment disregards the entire e-mail which is about why the<br>
read-only mirror should be acceptable. Again, why it should be<br>
acceptable is because it's as important to the KDE infrastructure as<br>
an anongit server.<br>
<span class=""><br>
>> For all practical purposes, it does not exist.<br>
>> It isn't there. It should never be a part of your workflow. You should<br>
>> never ever look at it. It is simply an additional clone source, just<br>
>> like KDE's anongit servers. That's it.<br>
><br>
> This is the part of your email I really like. Though this is not what<br>
> you meant: If projectX choose to also use Github, it is not affecting<br>
> your project in anyway. Just ignore it and move on.<br>
<br>
</span>I re-iterate. <a href="http://github.com/kde" rel="noreferrer" target="_blank">github.com/kde</a> is a place where people outside the KDE<br>
ecosystem can come and see the code in all its glory. To a KDE<br>
developer, it does not exist.<br>
<br>
Cheers,<br>
Boudhayan Gupta<br>
<div class=""><div class="h5">_______________________________________________<br>
kde-community mailing list<br>
<a href="mailto:kde-community@kde.org">kde-community@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/kde-community" rel="noreferrer" target="_blank">https://mail.kde.org/mailman/listinfo/kde-community</a></div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr"><div>Shantanu Tushar    (UTC +0530)<br><a href="http://shantanu.io" target="_blank">shantanu.io</a></div></div></div>
</div></div>