Aaron Seigo (aseigo): re: re: ramblings on 6 month cycles and Plasma
Toma took the time to reply to my blog entry on the six month cycle. He raised some ambiguities that I could probably clarify on a bit.
"First point is the very complex reasoning of the available time to do new features with a six months release cycle, which according to Aarons calculation means that half of the year we are in non-feature development. I don't understand that. "
As Toma calculates, 4 out of 6 months are spend in feature development. At least that's what the schedule says. A common pitfall in management (of any sort) is to keep your eyes on what is written on paper (the theory) and not glance up to examine what's really going on in reality. Reality is that right after a release I spend time doing the following three things:
Catching my breath a bit (let's call that a day or three, so not significant)
Responding to bug and wishlist reports; these tend to pick up right after a release and I like to spend the start of each cycle working on the x.1 release that is going to come out soon after the x.0 release. This is usually a significant time sink in the first couple weeks.
Surveying the landscape, revisiting the feature plan and figuring out exactly what will be done in this next cycle. This is impacted by the results of the last cycle as well as the ever evolving needs and desires for the product. This too takes time and prevents immediately diving in to new feature development
It is not unusual, in my experience, for working on bugs, wishlists and drafting the next cycle's hit list (which hopefully is based partly on an already laid out set of goals, but must also include what got punted as well as shifted priorities) to take a few weeks of time. Therefore, I don't expect a ton of new feature development in the first month of a cycle. This is born out by what happened this first cycle around, and matches with my experience from past projects as well.
That means that effectively we have 3 months of feature development. Sure, what's written down in the theory (the schedule) says 4 months ... but I live in reality, and therefore management of my resources should too.
"I hear you scream that svn branches suck."
No arguments from me there ;)
"moving it to git repositories will give you a lot more overhead and merging that all back at intervals to KDE's svn will frustrate you as well."
Not if we don't do any development in KDE's svn and simply use it as a release dump. There are decent scripts out there to replay git commits into, e.g. svn. This would be a lot easier if KDE were using git as well, but really .. I don't want to start the vcs discussion here. This is about release schedules, the tools that we use making that harder or easier to cope with is another discussion altogether.
"With git you usually merge a completed feature, making the diff too large for people to check on the mailinglists. At least I prefer ten smaller commits to review than one big one."
We use review board for this and it works just fine, actually, especially for larger patches. We can always replay the git commits one by one if we wish, but really that too is a detail. With development happening in a separate repository, we can do all our small commits in usual chunks there and then merge back to the release branch however we see fit.
This is where I get really uncomfortable, though: to solve the issue with an inappropriately sized cycle, I end up moving the development away from the KDE infrastructure which is totally counter productive from the perspective of shared development. This particularly hits us when it comes to internationalization (i18n), but more on that in a minute.
That alone makes me hesitate. I feel like I'm between a rock and a hard place on this one. The rock is a poor choice of release cycle for my work in plasma, and the hard place is our current vcs tool being too poor at merging branches to even consider using it as a solution to the release cycle problem.
"After the period merge back, people using KDE's svn will make build fixes, etc. That will need to sync back to the git repository."
The number of such commits would be trivial and easily tracked even manually. Still not wonderful, but I'd rather optimize for mainline development speed than occasional build and bug fixes.
Note that I already read every commit to the plasma codebases (libplasma, plasma, krunner, extragear, ..) so this is already factored into my work life.
It actually isn't the build fixes, however, that will be a paint. It's the translations: those are scripted to work against our shared svn repository and those would need to get sync'd back and forth regularly. Supporting i18n scares me in this scenario.
"I'm sorry, but if you want more hacking time, this is not the way to go in my opinion."
Merging from a mainline devel git repository to an virtual read-only release branch in one big go is 15 minutes work. Watching for code commits from svn and syncing those back isn't a big issue either, and also mostly able to be automated.
So I think you're vastly overstating the overhead this would incur on my part. Unfortunately, it would really hinder i18n and raise the bar for new people to get involved (another repo you have to know about and another vcs that you have to know how to use).
It's really interesting how this choice in cycles results in degrading one or more of the following: existing development efforts, new comer involvement and i18n. Yes, I know it all looks good in theory ... but history is littered with failures due to deciding based on theory instead of what the theory actually means in practice.
I also disagree with the general remark that a 'six month cycle' does not work for you in this project. How on earth is it possible to judge that, when the very first cycle is not even completed.
Well, this isn't exactly the first project I've ever worked on. =) As for plasma itself, I've seen what this cycle has done and have already spent some time mapping out the next one; I fully expect the next cycle to be a repeat in many ways of this one. So, lots of good development, but lots of punting combined with sprinting to get features in under the wire. This is really the funny thing about the choice of "6 months": it's short enough that timing matters a lot, but not short enough to be suited for fast iterations in development.
It's a lot like trying to avoid stepping on the cracks in a sidewalk where the slabs aren't quite a multiple of your natural stride: you can do it but you end up losing your rhythm and looking like a bit of a goofball in the process.
"I always learned from my mother (hi mam!) that I need to give it a try for a couple of times before deciding it does not work."
That's good advice from your mother. I'm sure she'd also tell you to learn from the mistakes and successes of others, to not repeat errors you've made in the past and to repeat your successes whenever possible. It's not like creation cycles are a new science.
It may be the first time KDE's tried to stick consistently to such a short cycle period, but it's not my first time around.
"The schedule is not set in stone and if you have reasons to change things, mail the release-team."
If I had an idea of what would both work globally and also wouldn't result in me sinking days of my time into a discussion and decisions process I would. Right now, I'm not sure what the best solution is for all of KDE. I honestly haven't gotten to that point in thinking about it. I just know that for the project I'm most deeply involved in, it sucks. That doesn't mean it isn't perfect for other aspects of the project; as I said in my original blog this is a "one size does not fit all" sort of issue, and I suspect 6 months might work just fine for kdelibs.
If you're wondering why previous release cycles didn't cause such angst, it's because if a cycle is longer than you need or short enough to match natural short-term iterations it's not a big deal. KDE always tended to have longer-than-strictly-needed cycles which made them fit really well a broad cross section of the project and, I would argue, thereby actually increasing the development pace.
It's really hard to argue with the pace of KDE3 development.
So, I've no concrete solutions for the problems mentioned in Aarons blog,
Damn! And here I was hoping someone smarter than me would come up with the brilliant and obvious solution ;)
I can understand that a new project requires a lot of setup for the infratructure, but when that's done things will get easier.
This is the "it will eventually be done" theory. That theory works really well for projects which have a fairly limited scope (so a limited amount of internal pressure) that gets applied in an environment that is mostly static (so little to no external pressure). Unfortunately, Plasma has both huge ambitions (so lots of internal pressure to keep moving) and competes in what is right now one of the more competitive and evolving areas (primary user interfaces and the bling that makes them sing) which means lots of external pressure to keep moving.
I'd be very surprised if core Plasma development settles down within two years time. While we may not be mucking with existing code (source and binary compat being what it is), there is a lot left to be added.
Anyways, thanks, Toma, for taking the time for a well reasoned reply. Hopefully the above gives you a bit clearer idea of what thoughts are rattling around my wee little head.
07.09.2008 Seigo on Plasma, Context and Nepomuk KDE's Aaron Seigo has published a blog post in which he details how Nepomuk and the semantic desktop can be beneficial to users.15.10.2010 E-mail In his lengthy and interesting blog post covering the future of Plasma, KDE's Aaron Seigo proposes Qt Quick and QML as replacement of the Graphics View architecture currently used by Plasma.29.01.2012 New Spark Tablet To Come Loaded With KDE's Active Plasma Interface According to Aaron J. Seigo, 'It's the first tablet computer that comes with Plasma Active pre-installed.' The Spark, with its 7" screen, is built around a Cortex A9 with a Mali-400-gpu, 512MB RAM and an SD-card slot.12.04.2011 KDE запускает проект Plasma Active для различных устройств Вчера Арон Сейго (Aaron Seigo), разработчик из проекта рабочей среды KDE, объявил о запуске череды блоговых публикаций, посвященных новой инициативе, — Plasma Active.Идея Plasma Active — создать пользовательский интерфейс для современных мобильных устройств вроде планшетных компьютеров, мультимедийных центров и смартфонов. В основу ее дизайна заложен декларативный язык разметки Plasma Quick, позволяющий создавать интерфейс с помощью QML из Qt Quick.Plasma Active станет объединением ряда более узконаправленных проектов, таких как анонсированный Contour. Contour призван привнести «новую и захват...02.02.2012 Анонсирован Spark — планшет с Mer (MeeGo) и KDE Plasma за 200 евро Известный разработчик из проекта KDE Арон Сейго (Aaron Seigo) анонсировал первый в мире планшет с предварительно установленным графическим окружением KDE Plasma Active — Spark.В качестве управляющей операционной системы в Spark используются наработки проекта Mer — форка свободной мобильной платформы MeeGo. Известные на данный момент технические характеристики планшета Spark таковы: 7-дюймовый емкостной multitouch-дисплей, процессор ARM от AMLogic с тактовой частотой 1 ГГц, Mali-400 GPU, 512 мегабайт оперативной памяти, 4 Гб для хранения данных и слот для SD-карт, поддержка Wi-Fi. Стоимость нов...12.05.2008 Plasma question for Aaron Linked by Thom Holwerda on Sat 14th Jul 2007 20:06 UTC, submitted by AdamW "PC users have volumes of information saved on their computers, most of it disconnected and disparate save for a basic directory ... 04.03.2008 OpenGTL and QtCTL 0.9.1 A new release of JIT thanks to the use of the Aaron's feeling xvidcap hangs on debian, and I couldn't find out to make recordmydesktop records only a small part of a screen, and just the thought of post-editing scares me, yeah I am easily scared, but if you blink fast and can synchronize your blinking with the scrolling, you can see a short animation below !). 28.06.2008 'Aaron, we owe you' or 'Why I am happy that Nepomuk is not as popular as Plasma' Submitted by trueg on Thu, 06/26/2008 - 09:50. After more than two weeks of vacation I read up on my email and of course am also sickened by some of the stuff I have to read there.28.01.2009 Torvalds, KDE 4, and the Media Circus "Torvalds' comment produced a flood of response across the web, including an apologia from leading KDE developer Aaron Seigo.15.01.2011 Opinion: Why KDE is People, Not Software "As the first of several opinion pieces exploring current issues in KDE, we offer you a video of Aaron Seigo explaining how KDE's success as a community producing all kinds of software led to outgrowing our old name, the "K Desktop Environment", what KDE means now and why it matters.