Второй вопрос: ты не против, если я перетащу сборку sane с тарболов на гит?

ping. Надо проверить на 1.0.25.

(Ответ для Michael Shigorin на комментарий #0)
> Возможно, стоит втянуть в наш 1.0.24 эти патчи:
> 
> http://anonscm.debian.org/cgit/sane/sane-backends.git/log/
> ?qt=grep&q=USB3&showmsg=1
Возможно, но поезд ушёл.
...

(Ответ для Michael Shigorin на комментарий #1)
> Второй вопрос: ты не против, если я перетащу сборку sane с тарболов на гит?
Против, а какой смысл?

> (Ответ для Michael Shigorin на комментарий #1)
> > Второй вопрос: ты не против, если я перетащу сборку sane с тарболов на гит?
> Против, а какой смысл?

Я тоже голосую за гит, если решение не окончательно-бесповоротное, т.к., к примеру:

git blame sane-backends/backend/gt68xx.c

выдает нижеприведенное и нужны дополнительные телодвижения, чтобы определить кто, когда и зачем вносил правки...

[...]
^6bed34fa1 (Vitaly Lipatov 2003-09-26 09:01:18 +0000  146) 
^6bed34fa1 (Vitaly Lipatov 2003-09-26 09:01:18 +0000  147) static SANE_String_Const source_list[] = {
^6bed34fa1 (Vitaly Lipatov 2003-09-26 09:01:18 +0000  148)   SANE_I18N ("Flatbed"),
^6bed34fa1 (Vitaly Lipatov 2003-09-26 09:01:18 +0000  149)   SANE_I18N ("Transparency Adapter"),
^6bed34fa1 (Vitaly Lipatov 2003-09-26 09:01:18 +0000  150)   0
^6bed34fa1 (Vitaly Lipatov 2003-09-26 09:01:18 +0000  151) };
^6bed34fa1 (Vitaly Lipatov 2003-09-26 09:01:18 +0000  152) 
^6bed34fa1 (Vitaly Lipatov 2003-09-26 09:01:18 +0000  153) static SANE_Range x_range = {
86b8fb19c5 (Vitaly Lipatov 2009-06-19 22:28:07 +0000  154)   SANE_FIX (0.0),               /* minimum */
86b8fb19c5 (Vitaly Lipatov 2009-06-19 22:28:07 +0000  155)   SANE_FIX (216.0),             /* maximum */
86b8fb19c5 (Vitaly Lipatov 2009-06-19 22:28:07 +0000  156)   SANE_FIX (0.0)                /* quantization */
^6bed34fa1 (Vitaly Lipatov 2003-09-26 09:01:18 +0000  157) };
^6bed34fa1 (Vitaly Lipatov 2003-09-26 09:01:18 +0000  158) 
^6bed34fa1 (Vitaly Lipatov 2003-09-26 09:01:18 +0000  159) static SANE_Range y_range = {
[...]

(Ответ для nickel@altlinux.org на комментарий #4)
> > (Ответ для Michael Shigorin на комментарий #1)
> > > Второй вопрос: ты не против, если я перетащу сборку sane с тарболов на гит?
> > Против, а какой смысл?
> 
> Я тоже голосую за гит, если решение не окончательно-бесповоротное, т.к., к
> примеру:
> 
> git blame sane-backends/backend/gt68xx.c
> 
> выдает нижеприведенное и нужны дополнительные телодвижения, чтобы определить
> кто, когда и зачем вносил правки...

Не нужно превращать сборку пакета в разработку. Если хотите разрабатывать — есть апстрим. Если нужно просто собрать — надо держаться подальше от всех подробностей, а то можно дойти до крайностей и вычитывать все коммиты каждого релиза.
В нормальном проекте есть свои CI, тестирование, принятие решения о релизе. И надо пользоваться релизами, а не повторять чужую работу, тратя время.

ну конечно же нужно сборку пакета превращать в разработку. Иначе нормального сопровождения пакета невозможно добиться.

Апстрим, к сожалению, в своих CI системах чаще всего ничего не знает про Альт. А разобраться в чём именно причина проблем с пакетом намного удобнее имея историю изменения исходного кода.

(Ответ для Anton Farygin на комментарий #6)
> ну конечно же нужно сборку пакета превращать в разработку. Иначе нормального
> сопровождения пакета невозможно добиться.
> 
> Апстрим, к сожалению, в своих CI системах чаще всего ничего не знает про
> Альт. А разобраться в чём именно причина проблем с пакетом намного удобнее
> имея историю изменения исходного кода.
Чтобы устранить проблему, нужно отправить патч в апстрим. Для этого нужно
а) иметь репозиторий апстрима
б) собирать проект так, как это делает апстрим
и репозиторий альта тут ни при чём.
Нет, ну если кому-то нравится в невидимой ветке синхронизировать апстримный репозиторий, тут дело вкуса.

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

Просто у нас разные подходы. Я считаю, что работа мантейнеров не нужна и бессмысленна. А вы хотите в этом найти разработку.

(Ответ для Vitaly Lipatov на комментарий #7)

> Нет, ну если кому-то нравится в невидимой ветке синхронизировать апстримный
> репозиторий, тут дело вкуса.

А почему в невидимой-то?
Как раз слияние апстримной и ALT'овой веток даёт в исходном дереве пакета увидеть, а не влияют ли наши изменения на отвалившуюся часть функционала без необходимости скакать между ветками и грепать то там, то тут...