On Sat, Sep 19, 2015 at 4:37 PM, Boudhayan Gupta <bgu...@kde.org> wrote: > On 19 September 2015 at 19:34, Vishesh Handa <m...@vhanda.in> wrote: >> Please note that consistency isn't a requirement to be part of KDE. If >> I decide to write an application in Rust, which is only for Windows, >> and uses a completely different build system, that is allowed. > > How are these two things even remotely similar? Of course you're > allowed to write a Windows specific app in Rust. Hell, according to > the manifesto we should be able to write apps for the Commodore64 if > we want to, provided that the software complies with licensing and > community engagement requirements of the KDE community. On a more > realistic note, almost all KDE apps have their own coding style, and > every maintainer has their own standard on how far to stick to these > styles. > > It is important to note that we're talking about infrastructural > consistency here, not code consistency. There is a distinction. <snip> >
My point over here was to illustrate that there are many parts to building a project, the code, development, handling contributions, handling bugs, infrastructure, etc. None of these *have* to be consistent. The manifesto does not actually dictate terms of "infrastructure". Relevant part - "Online services associated with the project are either hosted on KDE infrastructure or have an action plan that ensures continuity which is approved by the KDE system administration team" >>> >>> 3. Regarding point 4, if developers already have personal GitHub >>> clones that they use for their own purposes, nothing is stopping them >>> from continuing to use them. Those clones are not endorsed by KDE, >>> they are under complete control of the individual >>> developers/maintainers, they are entirely the responsibility of the >>> developers/maintainers, and the developers/maintainers are free to do >>> with them as they see fit. >>> >> >> Because maintainers are not responsible for their own projects anyway? >> If I'm taking responsibility for a project, I'm also taking >> responsibility for other parts of it. In this case Github. No one is >> forcing anyone. >> > > Common ownership. There's a difference between any random open source > project on GitHub/SF.net/elsewhere and a KDE project. Maintainers are > responsible for their own projects (that's why they're maintainers). > They're also responsible for playing nice with the rest of the > community and abiding by the requirements of the rest of the > community. And how does also accepting github requests not play nice with the rest of the community? > Also, while the rest of KDE may not have a say in the code > of the project (the maintainer is the maintainer because he/she > understands the code to a higher degree than the rest of the people > here), they do have a say in the project's governance. > "governance" is quite a vague word over here. Release cycles, documentation, QA, online infrastructure? what exactly? >>> Here's what developers and maintainers should really do: forget that >>> github.com/kde exists. >> >> They can do that if they are comfortable with the status-quo. Some >> people are clearly not. Your email disregards the points raised and >> implies that the github readonly mirror is only what is acceptable. >> That result is clearly not shared by everyone. > > This comment disregards the entire e-mail which is about why the > read-only mirror should be acceptable. Again, why it should be > acceptable is because it's as important to the KDE infrastructure as > an anongit server. > I think we're talking about different things. The read-only mirror is done, and shipped. I was talking about projects being able to also use github, and the rest of the community respecting that decision. _______________________________________________ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community