Irc-Unix.net

Главная | Actual Topics | Обратная связь | Guest Book | В избранное | Сделать домашней
Категории
 System & Utilities
 Unix News
 OS Emulator
 Developing
 Learning/Education
 Games
 Humour
Каталог статей
Все статьи

Antispam
Статьи
Биллу Гейтсу тоже предлагают избавиться ...
Вымогательство в борьбе со спамом
Календарь

July, 2018
ПнВтСрЧтПтСбВс
1
2345678
9101112131415
16171819202122
23242526272829
3031
Опросы
Какой из этих ОС Вы отдаете большее предпочтение?

QNX
FreeBSD
Linux(any)
Solaris
Mac OS
Windows XP
Windows 2003
Что такое ОС? :)


Результаты
Другие опросы

Всего голосов: 326
Комментарии: 0
Ссылки

Архив Новостей
 July 2018 (4)
 June 2018 (13)
 May 2018 (10)
 April 2018 (14)
 March 2018 (11)
 February 2018 (13)
 January 2018 (13)
 December 2017 (14)
 November 2017 (15)
 October 2017 (19)
 September 2017 (18)
 August 2017 (13)
 February 2017 (14)
 January 2017 (19)
 December 2016 (16)
 November 2016 (16)
 October 2016 (21)
 September 2016 (18)
 August 2016 (16)
 July 2016 (16)
 June 2016 (20)
 May 2016 (18)
 April 2016 (15)
 March 2016 (22)
 February 2016 (17)
 January 2016 (15)
 December 2015 (15)
 November 2015 (22)
 October 2015 (20)
 September 2015 (17)
 August 2015 (25)
 July 2015 (20)
 June 2015 (23)
 May 2015 (21)
 April 2015 (17)
 March 2015 (19)
 February 2015 (9)
 January 2015 (23)
 December 2014 (9)
 November 2014 (13)
 October 2014 (12)
 September 2014 (18)
 August 2014 (20)
 July 2014 (10)
 June 2014 (12)
 May 2014 (12)
 April 2014 (10)
 March 2014 (22)
 February 2014 (10)
 January 2014 (8)
 December 2013 (26)
 November 2013 (53)
 October 2013 (40)
 September 2013 (48)
 August 2013 (63)
 July 2013 (56)
 June 2013 (52)
 May 2013 (49)
 April 2013 (67)
 March 2013 (74)
 February 2013 (63)
 January 2013 (62)
 December 2012 (62)
 November 2012 (66)
 October 2012 (68)
 September 2012 (48)
 August 2012 (75)
 July 2012 (60)
 June 2012 (71)
 May 2012 (69)
 April 2012 (85)
 March 2012 (86)
 February 2012 (90)
 January 2012 (81)
 December 2011 (103)
 November 2011 (118)
 October 2011 (74)
 September 2011 (2)
 June 2011 (110)
 May 2011 (118)
 April 2011 (111)
 March 2011 (112)
 February 2011 (101)
 January 2011 (119)
 December 2010 (117)
 November 2010 (118)
 October 2010 (131)
 September 2010 (117)
 August 2010 (226)
 July 2010 (351)
 June 2010 (305)
 May 2010 (319)
 April 2010 (343)
 March 2010 (329)
 February 2010 (311)
 January 2010 (312)
 December 2009 (266)
 November 2009 (156)
 July 2009 (101)
 June 2009 (279)
 May 2009 (365)
 April 2009 (348)
 March 2009 (347)
 February 2009 (323)
 January 2009 (318)
 December 2008 (237)
 November 2008 (155)
 October 2008 (334)
 September 2008 (310)
 August 2008 (343)
 July 2008 (362)
 June 2008 (322)
 May 2008 (503)
 April 2008 (1276)
 March 2008 (1658)
 February 2008 (250)
 January 2008 (6)
 November 2007 (1)
 September 2007 (1)
 June 2007 (1)
 May 2007 (1)
 March 2007 (1)
 January 2007 (2)
 December 2006 (1)
 October 2006 (2)
 September 2006 (1)
 August 2006 (2)

Aaron Seigo (aseigo): re: re: ramblings on 6 month cycles and Plasma

System & Utilities Face of Aaron Seigo (aseigo)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.

Ugh.

"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.



  


Разместил: Planet KDE | Дата: 09.05.2008 | Прочитано: 1171 | Раздел: System & Utilities   

Рейтинг статьи

Средняя оценка: 0.00/0Средняя оценка: 0Всего голосов:0

Отлично
Хорошо Нормально Пойдёт Плохо


Смотрите также связанные темы

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.
Нет комментариев. Почему бы Вам не оставить свой?
Вы не можете отправить комментарий анонимно, пожалуйста зарегистрируйтесь.
Google Search
Google

Web irc-unix.net

Топ Новостей
1: Linux distros aren\'t updating WebKit, making web browsers and email clients vulnerable
Hot NEWS!
Просмотров - 4981


2: Akonadi/KMail issues on Tumbleweed?
Просмотров - 627

3: Netrunner Desktop 16.09 "Avalon" Linux OS Is Out with Kernel 4.7, KDE Plasma 5.7
Просмотров - 593

4: KDevelop 5.0.2 released for Windows and Linux
Просмотров - 572

5: HIG about Simple vs. Advanced Settings
Просмотров - 568

6: KDE\'s Kirigami 2.0 Framework for Convergent UIs Enters Beta with New Features
Просмотров - 548

7: Interview with Esfenodon
Просмотров - 547

8: 3.0 Pre-alpha 3 is out!
Просмотров - 509

9: Multi-screen woes in Plasma 5.7
Просмотров - 503

10: Embrace Open Source culture: the 5 common transformations.
Просмотров - 496

11: GSoC Update 1: The Beginning
Просмотров - 482

12: [TORRENT] chakra-2016.02-ian-x86_64.iso
Просмотров - 479

13: Fedora and KDE/spin\'s treatment - Discussion
Просмотров - 478

14: Qt SCXML and State Chart Support in Qt Creator
Просмотров - 459

15: Interview with Neotheta
Просмотров - 451

Google 120X240
Ссылки

Главная | Actual Topics | Статьи | Обратная связь | Guest Book
Генерация: 1.403 сек. и 13 запросов к базе данных за 1.356 сек.
Powered by SLAED CMS © 2005-2007 SLAED. All rights reserved.