Irc-Unix.net

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

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

November, 2018
ПнВтСрЧтПтСбВс
1234
567891011
12131415161718
19202122232425
2627282930
Опросы
Какой из этих ОС Вы отдаете большее предпочтение?

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


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

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

Архив Новостей
 November 2018 (3)
 October 2018 (13)
 September 2018 (8)
 August 2018 (8)
 July 2018 (11)
 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 (464)
 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)

Adriaan de Groot (adridg): Spring, Summer, Winter and Fall

System & Utilities [[ Yes, it's Violent Femmes Reference Time again! ]] I've gone and set up some Mercurial repositories and clones and whatnot now, some of which are publicly accessible, some which are local to my workstation, and somewhat to my surprise I can see the season's cycle [[ XTC reference time! ]] that Aaron, Dirk and Sebas talked about show up in a fairly natural fashion. And I've come up with another mixed metaphor, that development life is a highway [[ Tom Petty? ]] and you can ride it all night long, but there must be some way to get out .. nah. I'll just explain later.

DVCS Diagram

The top three repositories are publicly accessible. Master is the gold standard, the released stuff, the this-is-totally-stable-and-usable repository. Staging pulls from Master and is the beta-and-release-candidate repository, where things end up that are probably releasable; this is stable for enthusiast users to follow and is where the developers coordinate and polish before things get into master. Then there's Devel, which pulls from Staging and which is where alpha-development happens. Here, things may -- but shouldn't, unless you want to score a dozen turds or more -- break and things can change or be backed out or reconsidered. Developers should be watching this.

In my setup, Devel is publicly anonymously world-writable. I made that choice consciously because I want to make it possible for anyone to contrbute patches in a straightforward way. Consider Devel a playground, if you will. It's possible that Devel gets abused and that the clone is thrown away and re-cloned from Staging; it depends on how things turn out in practice. Right now I'm still in "do not assume the worst" mode. Staging, on the other hand, is writable for a few and then Master is writable for a select few. I suppose I could have labeled this "Linus", "Lieutenants", "Development Communities" to get the same across for those aware of how Linux kernel development works.

Down on the bottom row, there are the local repositories, not public, not accessible from outside my local workstation. Let's go from right to left: Local Devel is a whole forest of repositories for feature development, bugfixing, documentation and what have you. I need to remember that cloning is cheap and you should clone for each line (coherent thought expressed as a sequence of patches or changes) of development instead of trying to juggle multiple lines of effort in one repo. That's probably the biggest change for my personal style of working and one that already suggests itself as highly convenient in the long run. But change is an effort.

Right, so we have Local Devel where stuff happens; this is where commits might be the most frequent and there might be multiple concurrent lines of development going on. Local Devel tries to stay in sync with Devel (the public one) and may publish results to Devel as well for review by other developers. Changes move from Local Devel via Devel to Local Staging for quality checking by me (since this is local to my machine). If I think it's OK, then I dare to push it out to the public Staging; similarly changes propagate from Local Staging through public scrutiny to Local Master for a final check before being pushed to the global Master.

Looking at the diagram in another dimension, we have the rightmost column which is most active and where most of the development and experimentation occurs; the center column where stabilization occurs and the leftmost column where, basically, release happens.

This ties in with our seasons metaphor; Local Devel is spring, where a thousand features bloom in a thousand repositories. They grow and mature in the summer, where they bask in the warmth of the sun and the glare of curious and critical eyes -- that's the public Devel. Then they reach fruition at the end of summer and the beginning of autumn; growth slows and the fruits of our labor become available to all. Finally, winter sets in and preserves and freezes what once was a tender tendril of code but is now a full grown feature.

Hm. I'm not sure that the "winter" metaphor works all that well; things are completed but not unchanging or hibernating.

And anyway, we need to remember that if it's summer here it's August in Greece (and nothing every gets done in August in Greece, it's far too hot) so we have the different seasons happening at the same time. I've never been to the southern hemisphere so I don't really know what that's like. It also strikes me that the metaphor, agricultural as it is, needs a little work to handle cultural contexts like Calgary where the growing season is just a tad under 180 days -- that's less than half the year and the rest is hard-frozen winter stillness. Really Aaron, you should be used to freezes taking up half your time.

So at this point it looks like a four seasons [[ Vivaldi reference! I knew you were waiting for that one. ]] metaphor makes a fair amount of sense in that it reflects naturally a division of public (stuff you feel is less-or-more done) and private (spring, where you sow your wild oats) as well as changes in maturity of the codebase.

Part of the process of working with a DVCS is merging and pushing between repositories; the interesting merges in this little diagram are the diagonal ones, where a decision needs to be made about moving a feature or group of patches from one season to the next. It's like growing up from the Farm Leagues, and there need to be scouts watching what's happening and tryouts and testing and then thumbs up to the move. Gatekeepers or a release team play a big role in doing exactly these diagonal pulls and there ought to be a succinct question that needs to be answered positively in order to move from Devel to Staging and from Staging to Master. Something like "can I rely on this as a developer for the next three months?" and "can I rely on this as a user in a binary compatible fashion for the next two years?" comes to mind, but that is kind of library-and-infrastructure oriented.

If pulling stuff between repos and maturing chunks of code like fine cheese is easier with a DVCS, it introduces a new kind of discipline that is needed to work successfully in getting code to Master and it requires new processes and people to watch over those processes. Someone has to make the call that some bit of code is good; is it done? Is it ripe? And if it is ripe, is it a Limburger cheese, or a fine Cheddar?

There is another way of looking at this development model -- here focussing on a single repo, which is a single coherent unit of software (I don't think a single repo like we use now for all of KDE is feasible at all) -- is as a highway. Code hits the off-ramp and goes out into the wide world. It's done with the highway. It is released. It only does that when it's done, though, when it's good and ready. The rightmost lane is for code looking for an exit. There's a center lane for passing and doing the speed limit, and then there's a left lane where Muttley gets to drive like a maniac. On this highway, all the on ramps enter on the left -- road safety isn't all that important to Dirk Dastardly, after all. Moving to the right [[ yes, Paul Adams, I am roundly discriminating against your ridiculous driving habits ]] means slowing down, driving more calmly, cooperating with other drivers more. You can't be a maniac and on an off ramp at the same time. You have to trade in your sports car for a station wagon.

I think that if you plot that repositories diagram over time with each repo as a lane of traffic and each coherent chunk of code as a vehicle, you'll find that it does look like the traffic situation. Merge right, slow down (the rate of change).

What's missing in all of these views of the development process is a metaphor for understanding how dependencies across repositories work. When developing your application KFrobnitz you depend on other applications for DBus interfaces and on libraries and frameworks elsewhere. For you as a developer, KFrobnitz is in spring, in the fast lane. But for the things you depend on like the KDE workspace or KDE runtime (those are product names) or kdelibs (currently an SVN module) should you be looking for them in spring, summer, winter or fall? Spring doesn't make much sense -- even if it is publicly available. Too wild, too woolly. I think a rule of thumb would be:
  • If your app pushes the limits of what it depends on and might drive development there, use summer / the center lane.
  • If your app is intended for use on the next release of what it depends on, use fall / the right lane.
  • If your app continues to develop features for the released version of your dependency, use winter / what's gone down the off-ramp.
You can ask that question for each of your dependencies and thus pick the right set of things to build on. Now, if you're working somewhere lower in the stack like on libraries you might be concerned about breaking applications higher in the stack. So there you pick winter or fall versions of applications you care about or which are representative and build those against your spring as a check that you're not breaking stuff.

I think the message is that in any one software development environment (by which I mean the whole stack that you are building) you should avoid having spring in more than one place. No Wacky Races between repositories; only one should be going fast while the rest chug along. That way software productivity (not just DVCS based) lies.





  


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

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

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

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


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

05.03.2008 The road to GSoC 2008
This is that time of year again. The wonderful folks at Google have announced (http://code.google.com/soc/2008/) that they were running their Summer of Code program again. We at the Scribus Team are quite excited about it in part as one of the two newest additions to our group Hermann Kraus has made his way in through [...]
18.03.2008 Scribus Team accepted into Google Summer of Code 2008
Well folks the game is on. It is with great pleasure that I announce that we have been accepted into the wonderful Google Summer of Code program for thesecond time. My thanks go to all the people from the team and the larger Scribus Community who were involved in preparation of our application and especiallyto [...]
28.03.2008 KDE and OpenUsability Offer Summer Stipends for Students
Saturday, March 22 2008 @ 12:58 CST Contributed by: Linegod From KDE News : Our friends over at OpenUsability have just started a call for students of usability, user-interface design, and interaction design or ...
28.03.2008 15 наиболее влиятельных людей в мире открытого ПО по версии eWeek
Издание eweek.com определило 15 наиболее влиятельных людей в бизнесе, связанном с открытым программным обеспечением: Linus Torvalds - создатель Linux ядра Mitchell Baker - председатель совета директоров Mozilla Corporation и лидер Mozilla Foundation Mike Milinkovich - директор Eclipse Foundation Tim Golden - вице-президент Банка Америки, пропагандист внедрения открытого ПО в корпоративном секторе Jim Zemlin - исполнительный директор Linux Foundation Peter Fenton - способствовал привлечению инвестиций в проекты JBoss, XenSource и Zimbra Larry Augustin - основатель компании VA Linux, создавшей ...
31.03.2008 digiKam : Google summer of code - call for students
As KDE is a mentoring organization for the Google Summer of Code 2008 (see Advanced image resize for image editor==> KDE3 and KDE42/ read more
31.03.2008 digiKam : Google summer of code - call for students
As KDE is a mentoring organization for the Google Summer of Code 2008 (see Advanced image resize for image editor==> KDE3 and KDE42/ read more
11.04.2008 Вышел Linux-дистрибутив Mandriva 2008 Spring
Французская компания Mandriva объявила о выпуске новой версии своего дистрибутива -- Mandriva Linux 2008.1 (2008 Spring)...
28.04.2008 Netbeans 6.1
Сегодня, 28 апреля, вышла новая версия Netbeans IDE. Из нововведений: Поддержка JavaScript. Увеличение производительности (запуск на 40% быстрее). Поддержка Spring Framework. Улучшена поддержка JavaBeans, Ruby, JRuby.
27.04.2008 Tutorial explains Mandriva 2008 configuration
A step-by-step tutorial on setting up Mandriva One 2008 Spring desktop has been published on HowtoForge.com . Written by Oliver Meyer, the six-page tutorial, called "The Perfect Desktop," covers basic ...
28.05.2008 VMware podcasts: quick listens on many topics
I've got podcasts on the brain this week, which reminded me that VMware is producing a few nice podcast series as well. They are nicely produced and are a nice length (often 10 or 15 minutes). They don't fall into...
Нет комментариев. Почему бы Вам не оставить свой?
Вы не можете отправить комментарий анонимно, пожалуйста зарегистрируйтесь.
Google Search
Google

Web irc-unix.net

Топ Новостей
1: Fedora and KDE/spin\'s treatment - Discussion
Hot NEWS!
Просмотров - 2984


2: Offline Vaults for an extra layer of protection
Просмотров - 758

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

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

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

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

7: Debugging issues booting a PC in 2018
Просмотров - 636

8: plib3.gui 0.9.9
Просмотров - 602

9: Konstruct
Просмотров - 596

10: Best Desktop Environment
Просмотров - 580

11: KDE Connect – State of the union
Просмотров - 572

12: KDE Connect Sprint
Просмотров - 571

13: Multi-screen woes in Plasma 5.7
Просмотров - 571

14: Come dine with the KDE e.V. board in Berlin in October
Просмотров - 569

15: Help Canonical Test GNOME Patches, Android Apps Illegally Tracking Kids, MySQL 8.0 Released and More
Просмотров - 559

Google 120X240
Ссылки

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