ALT Linux Team development discussions
 help / color / mirror / Atom feed
From: Andrey Orlov <cray@neural.ru>
To: devel@altlinux.ru
Subject: Re: [devel] Re: [sisyphus] Питоньи модуля
Date: Sun, 11 Jan 2004 13:45:20 +0300
Message-ID: <200401111345.20731.cray@neural.ru> (raw)
In-Reply-To: <20040111032820.GG12307@localhost.localdomain>

On Sunday 11 January 2004 06:28, Alexey Morozov wrote:
> Грустно. Почему - ниже.
> > Старые версии питона, типа python22 остаются
> > исключительно для целей разработки и тестирования, соответственно,
> > предполагается что те, кому они нужны - в состоянии пересобрать все
> Не понятно, зачем тогда держать такой пакет, если пользоваться им все равно
> нельзя.

Я уже объяснил. Для разработчиков. Сплит на две альтернативы произошел до моего
появления в AltLinuxTeam и я точно не знаю чем он был вызван. Предположительно -
тем, что Zope не работал с python22. С моим появлением ситуацию с Zope мы разрулили
и по большому счету pythob21 стал не нужен. Но, как у мантейнера Zope, у меня
иной раз возникала в нем необходимость. Просто чбы убедится в том, что некая бага
не привнесена переносом Zope на python22, а воспроизводится на python21.

С официальным переходом Zope на python223 пакет python21 стал не нужен. Сейчас
ситуация повторяется с python22 / 23. 

> Тогда логичнее было бы делать так:
>
> python-<the last and shining version>
> python-compat<any previous version>

Оно сделано так как сделано. Считайте, что это осталоь так по историческим причинам.

> > так и пишут "required". Таким образом, пересобрать новую версию пакета
> > под оба питона  сразу - в общем случе, нереально.
>
> %define _with_python<bad version> --without-python<bad version>
> прямо в спеке?

Тогда вы получите тоже самое что сейчас, только с другой стороны - у вас отвалятся
MySQLdb, psycopg etc. Таким образом, вы опять не будете иметь полного набора
пакетов для обеих версий питона. Я все это уже видел на 21 vs 22. 

Вы все-таки киньте мне на мыло посмотреть ваши макросы и т.п. Если бы я был 100% 
уверен в том, что это невозможно и ненужно - я бы даже обсуждать это не стал ;).

> То есть, Вы утверждаете, что обратная совместимость есть всегда, и
> ситуация, когда я при апгрейде питона и всех модулей получаю
> неработоспособное приложения, невозможна, или, во всяком случае, _крайне_
> мало вероятна?

Я утверждаю прямо противопложенное - в общем случае нет ни обратной, ни
прямой совместимости. Но все продукты переносятся их разработчиками на новые
версии и это вполне естественный процесс. Который нужно поддерживать и форсировать.

> > Как тогда это соотносится с:
> > положу 2.6.3 в сиз (завтра, наверно) кто им пользуется - будьте

Вышеупомянутым образом. Разработчики Z портировали его на py23, причем заявлено
что ближайшие версии Z будут несвместимы с py22 в любых проявлениях. 

> > Тут проблема очень простая, на самом деле. По своему предыдущему
> (непитоньему) опыту я знаю, что у каждого продукта, если это не наколенный
> скрипт для внутреннего потребления, есть maintaince cycle. То есть, грубо
> говоря, период, когда мы _вынуждены_ поддерживать ту версию программы,

Да. Я с этим согласен. Но, как я уже сказал - для перехода на python23 был 1 (один) год.
Времени достаточно. Для дальнейшей поддержки заказчиков есть дистрибутив
master 22 который можно им ставить. В ALM3, вполне возможно, python22 не будет.
Во всяком случае  - мой голос "ЗА".

> которую установили заказчику. Причем, поддерживать именно в том виде, в
> котором установили - максимум, мелкие патчи, которые не меняют приложение
> кардинально.

Любой апдейт из Сизифа - это уже кардинальное изменение положения. В то же
время, по опыту патчей к Zope, за редчайшим исключением, переход py21 - py22 и
py22 - py23 не есть кардинальное изменение положения. 

> У меня сейчас, возможно, образуется ситуация, когда я буду просто не в
> состоянии говорить: "а мы с разработчиками тут переехали на новый [питон],
> он рулит, но со старым [питоном] совместимости больше нет, и давайте мы вам
> за _ваш_ счет произведём апгрейд". За свой, понятное дело, тоже не очень
> хочется :-)). Вот и подпрыгиваю :-).

Я вас очень хорошо понимаю. Я прохожу через это каждое лето. В тех случаях, когда
оплата перехода оказывается невозможной - я не апдейчу клиентские сервера до
нового мастера, а ограничиваюсь паккетами из updates. Соответственно, новый софт
клиент не получает и это логично: за новые версии надо платить.

Но всю разработку мы ведем только на последних версиях, соотв. если наш старый
клиент хочет новые фичи, которых не было в старых версиях софта - ему приходится
ставить новую версию и нашего софта, и его окружения. И, по факту, я не в силах
поддерживать в  новых версиях продуктов ни совместимость с python21 / 22, ни 
совместимость с Zope251, ни совместимость с omniORB3: просто не было в них тех
возможностей, которые используют новые версии наших продуктов. И это вполне
естественно. Так что, мое мнение:

 1. Сизифус - для разработчиков, для которых актуален немедленный переход на новые версии
     софта;

 2. Поддержка старых инсталляций осуществляется исключительно за счет updates старых
      дистрибутивов, а не за счет апдейта из сизифа;

 3. Обновление старых инсталляций в связи с переходом на новые версии софта требует
     перехода на послендий оффициальный релиз дистрибутива.

По-моему это логично и в подавляющем большинстве случаев можно объяснить клиенту, 
который выбирает для себя вариант подходящий по деньгам и функционалу.

ЗЫ: Когда я закончил институт и делал свой первый проект, я не придерживался первого
пункта и наступил на очень большие грабли: к моменту сдачи проекта весь софт, на
котором он был построен безнадежно устарел.  С его сдачей возникли проблемы... Теперь
для меня разработка на последних релизах, а лучше даже на альфа- и бета- версиях - непреложное
правило от которого я стараюсь не отходить и другим советую тоже самое.

-- 
WthBstRgrds -- Андрей Орлов --  
 --- http: www.neural.ru, mail: cray@neural.ru, jid: cray@altlinux.org ---
----------------------------------------



  reply	other threads:[~2004-01-11 10:45 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-10 11:58 ` Andrey Orlov
2004-01-11  3:28   ` Alexey Morozov
2004-01-11 10:45     ` Andrey Orlov [this message]
2004-01-11 19:23       ` [devel] Re: [sisyphus] ðÉÔÏÎØÉ ÍÏÄÕÌÑ Alex Ott
2004-01-11 21:07         ` [devel] Re: [sisyphus] Питоньи модуля Andrey Orlov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200401111345.20731.cray@neural.ru \
    --to=cray@neural.ru \
    --cc=devel@altlinux.ru \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

ALT Linux Team development discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \
		devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru
	public-inbox-index devel

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://lore.altlinux.org/org.altlinux.lists.devel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git