Re: Changes to our Git infrastructure
On Tuesday 06 January 2015 08:19:20 Thiago Macieira wrote: Unfortunately, as long as the tool permits line-by-line commenting, you're going to get nitpicking. My experience is that people are linear and will start reading the patch, calling out what they see when they see it. I made some code experience with automatic checking of style issues and similar things (e.g. with https://houndci.com). If a tool gives immediate feedback about these things, reviewers don't have to do the nitpicking, and there is no risk of reviewees taking it personal. If the CI checks and comments the small issues, the review by the human reviewer naturally focuses on more high-level questions. -- Cornelius Schumacher schumac...@kde.org
Re: Changes to our Git infrastructure
On Saturday 03 January 2015 15:31:26 Ben Cooksley wrote: (...excellent summary of discussion...) Commentary on the above would be appreciated. There are two questions which aren't addressed int he summary, but which I think are important to have good answers for before we can take a decision. The first question is: Who do we want to address? We obviously want to address existing contributors and for that the list represents the needs quite well. But to what degree do we want to address new contributors? Collecting requirements on kde-core-devel won't give us the input we need, if we want to address people who are not already part of our community. The second question is: What are our requirements for hosting? Do we want to host it ourselves, or would we be ok with a third party hosting the infrastructure as well, and under which conditions? Both questions are related to GitHub, which has been mentioned in the discussion quite a bit. It would address a lot of our requirements and it is something especially new contributors are familiar with. I'm not saying we should simply move to GitHub, but as it is brought up so often, we maybe should review our position, and make sure that we know why we are not going with the flow, and why we are paying the price of a higher barrier of entry and the additional effort of hosting our own infrastructure. -- Cornelius Schumacher schumac...@kde.org
Re: Changes to our Git infrastructure
On Sunday 04 January 2015 13:38:09 Jeff Mitchell wrote: GitHub has been mentioned as a comparison point, but I can't credibly believe that we're willing to migrate to GitHub en masse, no matter what the flow of the industry is. I'm not stating my personal preferences on the matter, but the direction and feedback to the sysadmins has always been FOSS-only. If GitHub *is* on the table, then we need to consider other non-FOSS possibilities as well. FOSS-only is a too simple requirement for a hosted service. It might be perfectly possible and fine to use a service which is not running free software as long as it doesn't force you to run non-free software. The issues are elsewhere (recommeded reading is Richard Stallman's text about this problem [1]). That's why I'm asking what exactly are our requirement there, and do the arguments we had last time we took a decision still hold? And yes, while GitHub is the poster child here, that doesn't mean we shouldn't look at other service providers, if we generally consider this to be an option. I do agree that we want the barrier to entry to be as low as possible. As is often the case, I think that may conflict somewhat with what some of the more/very experienced developers might find to be most useful to them personally. Finding the best balance is a difficult task. That's true, and that's exactly the reason why we should consciously decide what our target is. It might be perfectly valid to focus on current contributors and go with something like a gerrit-based solution, but if we want to focus on new people there might be better solutions. [1]: https://www.gnu.org/philosophy/network-services-arent-free-or-nonfree.html -- Cornelius Schumacher schumac...@kde.org
Re: What is the git workflow for kdelibs ?
On Saturday 10 November 2012 Alexander Neundorf wrote: community.kde.org feels to me like a completely unorganized heap of random stuff. That's true to some degree, and it's exactly the reason why we crated community.kde.org, because we don't want to put this unorganized stuff, which is only understandable, if you have inside knowledge, to 3rd parties as documentation. Techbase is supposed this organized documentation understandable by 3rd parties, so only the stuff, which fits this should go there. -- Cornelius Schumacher schumac...@kde.org
Re: What is the git workflow for kdelibs ?
On Wednesday 07 November 2012 12:48:26 Aaron J. Seigo wrote: On Thursday, November 1, 2012 12:05:51 David Faure wrote: (seems I'm still confused about techbase vs community) I am happy to write something about this. In fact I (and others, too) have done so on both blogs and emails ... blogs not everyone reads, emails are ephemeral, so - where can I put this information where you (and others) are going to find it and can reference it? As soon as that is defined, I'll make sure the information is there asap. We actually have http://wiki.kde.org/, which is meant to serve this information. Maybe we need to just improve this or make it more accessible. -- Cornelius Schumacher schumac...@kde.org
Re: Proposed adjustments to our release cycles
On Sunday 17 June 2012 Inge Wallin wrote: The reasoning behind the move towards shorter release cycles is exactly the opposite of how large organizations reason when they select software. Remember the outcry when Firefox went to its current way of releasing. When Brazil rolls out KDE to 24 million users, they don't want to have to update that every 2-4 months. That's the challenge of our industry. Web apps are on release cycles of hours or even minutes. Browsers are following suit and are on much shorter cycles than they used to be, the Linux kernel is also making it a point to be on a very fast release cycle. They all do it, because there are obvious benefits in getting new features and bug fixes out to users earlier. But users still want to have stability, and the classical approach, especially for enterprises, is to minimize change. This obviously creates a conflict. But there are ways to address this. I think shorter release cycles are doable, if we make sure that we have automated test infrastructure in place, which minimizes regressions, and the channels how our software gets to the end user are set up to handle a release process of increased agility. The first we have in our hands, the second is something where we need to team up with distributions. -- Cornelius Schumacher schumac...@kde.org
Re: Proposed adjustments to our release cycles
On Friday 15 June 2012 Sebastian Kügler wrote: Opinions? The predictability and synchronicity of our current six month release cycle has a lot of benefits. It allows all contributors as well as consumers of our releases to plan ahead and minimizes release overhead. On the other hand it would be great to be able to release in a more agile way, if a sub-project is set up to handle this and is willing to put in the extra effort, so that users get new features and bug fixes quicker. Allowing certain sub-projects to do their own schedule might be a good thing, and we already have seen that some components skipped releases, but I think it's still important that we have some common rhythm, which offers structure to our releases and community (some would call it cadence). So I would really like to keep our release days as common integration and synchronization points, the six-monthly major release day, and the monthly minor release day. That doesn't mean that all sub-projects have to release on this day. But it would continue to be an offer and default option for all those who want to benefit from a common and synchronized effort in terms of release management, translations, packaging, beta testing and all the other things which need to happen around a release. -- Cornelius Schumacher schumac...@kde.org
Re: Formal complaint concerning the use of the name System Settings by GNOME
On Sunday 24 July 2011 Ben Cooksley wrote: Dropping GNOME out of this, as it seems quite clear they aren't interested in co-operating at all. Which is fairly typical for them, they're insular and only care for themselves. I don't want to let a statement like this stand as it is. There are a lot of people in the GNOME community who do want to cooperate. There certainly are also people who don't. That's the same in our community. Not everybody cares about cross-desktop collaboration, and this creates issues, as we have seen. Still, we should treat each other with respect. I understand that it makes you angry, if things break because of decisions outside your control, which you consider to be wrong. But being angry doesn't solve problems, especially not when communication about a common solution is required. There are a lot of technical things we can do to address this specific problem, taking settings from the platform, making configuration available in context, making KDE applications and frameworks more modular and less interdependent. Not everything can be done easily, but we should look for the right solutions and persue them. Additionally we need to talk about how to do integration across desktops. We should not be content with having insular desktops, neither on the GNOME side, nor on our side, nor anywhere else. This only limits us, how we are perceived, and what users think what they can do with KDE software. We aren't the monolithic desktop, which only runs KDE software, and which is required by all KDE applications. That's exactly the misconception we are trying to get rid of. So let's have a constructive conversation with GNOME and others how to share settings, how to integrate applications running on different workspaces independent of the toolkit they are implemented with. The desktop summit provides a great opportunity for that. But again, please act with respect for your own and other communities. Being aggressive doesn't help in finding good solutions for users, and it's really not the atmosphere, I'd like to see in KDE. -- Cornelius Schumacher schumac...@kde.org
Re: KDE git workflow
On Thursday 09 June 2011 Maksim Orlovich wrote: Will we have a single person review every single commit to master, too? We don't have formal rules about who reviews commits. That will be done by the developers and maintainers who care, just like it is done now. We might have a Aaron's branch of Plasma with the latest Plasma features, or a KDAB branch of KDE PIM, which integrates the latest KDE PIM enterprise features, etc. And what if there are multiple branches on the same module at the same time? Which one of these branches, or master (or release?) is going to get testing coverage? The idea is that, if there are multiple feature branches, the integration branch is used to collect them and get testing coverage and review there. An alternative, of course, is to discourage use of branches if at all possible, and rather prefer a consistently working and stable master (which optionally then becomes the release, without further branching)... or at the very least not to disallow such methodology by fiat. For smaller or less central parts of KDE this actually might be a good procedure. For modules where many developers work, or where we need to make extra sure that they are work, like the libraries, we need more review. And discouraging branches at all is not a good policy, as at least there should be local branches for development of everything, which is non-trivial to integrate, otherwise a consistently working and stable master is impossible to achieve. The same for releasing. We need branches for that, so that master can continue to get feature development, while a branch is hardened for release. -- Cornelius Schumacher schumac...@kde.org
Re: KDE git workflow
On Thursday 09 June 2011 Torgny Nyblom wrote: This part I fully agree with, however later in the example section it seems like rebasing should be done prior to review. Is the examples correct? The examples need some reality check, ideally with detailed actual git commands. In general it's a good idea to rebase local branches, before you show them to others. How this will actually look like in terms of actual commands we still have to determine, especially also with regards to the review tool we'll use. For the current ReviewBoard based process we can probably do that now. Any takers for augmenting the examples with step-by-step instructions from the real world? -- Cornelius Schumacher schumac...@kde.org
Re: KDE git workflow
On Thursday 09 June 2011 David Jarvie wrote: In order to get good testing coverage, there should normally only be one integration branch per git module. Otherwise, testing coverage will be split between the competing integration branches. Right. -- Cornelius Schumacher schumac...@kde.org
Re: KDE git workflow
On Thursday 09 June 2011 John Layt wrote: Besides the inconsistency that Torgey also found, the one part of the command flow I'm wondering about is whether for the simple workflow we tell them to push or merge their commits into master? If it's a local branch, rebase the branch, merge it to master, and then push it. This will give linear history. It should be equivalent to working in master, rebasing on pull and just pushing, but it's cleaner and safer to do the development in a branch. If it's a remote branch, just merge it and push it. In general it's a good idea to do a git pull --rebase, when pulling as this doesn't create merge commits with local changes, which can clutter up the history. -- Cornelius Schumacher schumac...@kde.org
KDE git workflow
As you already know, we have discussed the git workflow for KDE at the Platform 11 sprint, and have come up with a recommendation. Please find the full text here: http://community.kde.org/KDE_Core/Platform_11/Git_Workflow The core ideas are that: * master is always kept in a stable state that is ready to be used for starting a release * development is happening in feature branches * for larger projects integration branches will be used for further stabilization and wider testing * changes going into master are going through a review process * releases are coming from release branches Please read the full text before commenting to get all details. This workflow will be adopted by some core modules, and is recommended for all KDE modules. It's flexible enough to be used by modules of different sizes and different requirements in terms of stability, so we hope it to be a reasonable fit for as many people as possible. Obviously we'll have to see how well it works and adapt it, if necessary, but it should be a good start. -- Cornelius Schumacher schumac...@kde.org
Re: Git Worflow, branch creation.
On Thursday 19 May 2011 Aaron J. Seigo wrote: http://techbase.kde.org/Development/Tutorials/Git/Feature_Development_Workf low Wow. This is a pretty complex workflow, and it's breaking with quite some practices KDE used to use for a very long time. We have to make sure that we don't leave developers behind with such a drastic change. The approach of having one central repository and all committers being equal has served us well. Maybe it's time to move forward to a different model, but I think this should be done with care, and without changing more than needed. A lot of this is about semantics and how to name things, not necessarily about technical processes. For example, if master is the stable branch or a release branch doesn't make a big difference technically, but it might affect our development culture quite a bit. This needs to be discussed. I'm looking forward to the upcoming face-to-face meetings, but we should also have a wider discussion, as this is affecting many more people than those who will have the opportunity to be at these meetings. -- Cornelius Schumacher schumac...@kde.org
Re: why kdelibs?
On Sunday 31 October 2010 Juan Carlos Torres wrote: So basically, what would convince 3rd party developers (Qt developers, Windows developers, iOS/Android developers) to write KDE apps? Better yet, what would now constitute being a KDE app? Platform integration and consistency? Only on desktops/netbooks perhaps. On mobile, we'd have to follow *their* (Maemo, MeeGo, WM) platform. Why not just call the app a Qt app then? Again, this is from an interested 3rd party developer POV. Established KDE SC apps would most probably keep the same brand. Specific KDE apps would be those who are written by the KDE community. That's where KDE has been moving anyway. The brand is more about the community and less about libraries. True that KDE is much more than the libraries. But aren't those libraries also an important part of what makes KDE? I mean, if developers decided to make KDE apps, isn't it sometimes because KDE libraries rock? Exactly. So if these rocking libraries are part of Qt and so available to every single Qt developer, they can easily become part of KDE as well. Something which is quite a barrier today. -- Cornelius Schumacher schumac...@kde.org
