Politika slanja na CVS...
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Pošto se spremam da preliminarno stablo prebacim na CVS server, pripremio sam
dokument koji određuje politiku slanja izmena na server. Ovaj dokument je
preuzet sa sa KDE-ovog sajta i prilagođen je našim potrebama.
Nepoštovanje ovog dokumenta povlači oduzimanje CVS naloga, stoga vas sve
molim da dobro proučite šta u njemu piše kako ne bih dolazio u neprijatnu
situaciju da nekome moram da ukinem nalog.
Gvozdene, priloženi fajl bi mogao da prebaciš na weblog, a ja ću videti da se
nađe i na CVS-u.
- --
Pozdrav,
Tanasković Toplica
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFAU0cMtKJqksC6c0sRAgr/AJ9X8CSnvjCTKBHQvFUD5SyrLD9T+ACgkxik
B5itiCLCgwZ40v8oOR2KBKU=
=TOK8
-----END PGP SIGNATURE-----
Политика слања на CVS сервер
----------------------------
Сажетак:
--------
1. Размислите двапут пре слања.
2. Никада не шаљите код који не може да се компајлира.
3. Тестирајте своје промене пре слања.
4. ДОБРО проверите шта шаљете.
5. Увек додајте описне поруке за дневник.
6. Код који шаљете мора да поштује политике КДЕ-овог кодирања.
7. Поштујте посебне политике слања које поставља план издавања.
8. Поштујте политике одржавалаца програма и библиотека, и увек се консултујте са њима пре него што учините велике измене.
9. Када планирате да направите измене које утичу на пуно другог кода у CVS-у, најавите их на време у дописној листи.
10. Не шаљите измене јавних API-ја библиотека пре него што се консултујете са осталим програмерима.
11. Преузмите одговорност за своја слања.
12. Не шаљите код који не разумете.
13. Немојте злоупотребљавати ваш CVS налог да прогурате измене са којима се остали програмери не слажу.
14. Ако шаљете исправке грешака-багова, размислите о портовању тих исправки на остале гране.
15. Ако исправите грешку пријављену на систему за праћење грешака, додајте број грешке у поруци за дневник.
16. Избегавајте губитак CVS историје, преименовањем или премештањем фајлова.
17. Званичне ознаке издања или грана користе само велика слова. Користите мала слова за све остале ознаке и гране.
18. Немојте додавати генерисане фајлове у складиште.
19. Немојте користити кључне речи CVS-а као што су Id или Log у фајловима изворног кода.
20. Радите „елементарна“ слања.
21. Не мешајте измене у форматирању са изменама у коду.
22. Ако ваше слање прави видљиве измене у GUI-ју, додајте кључну реч GUI у поруку за дневник.
Детаљи:
-------
1. Размислите двапут пре слања.
Слаље нечега на CVS има озбиљне последице. Сви програмери ће добити ваше измене оног тренутка када се нађу у
CVS-у, и ако нешто „скрше“, скршиће свима. Сва слања биће јавно доступна у CVS складишту заувек.
Са друге стране CVS дозвољава да се измене врате, тако да је могуће оппоравити се од грешака. Ово је релативно
једноставно за слања за појединачне фајлове, али исто тако може бити огроман посао за веће измене.
Поента је: Будите свесни последица ваших слања. Одвојите времена да размислите о њима пре слања.
2. Никада не шаљите код који не може да се компајлира.
Компајлирајте код и исправите све грешке пре слања. Уверите се да су новопридодати фајлови послати. Ако недостају
ваше компајлирање у локалу ће радити како треба, али сви остали неће моћи да компајлирају код.
Обавезно се уверите да се код компајлира код вас у локалу. Такође размотрите које ће последице имати ваша слања за
компајлирање са изворишним директоријумом који је различит од директоријума изградње. Било би лепо да може да се
компајлира и са опцијом --enable-final, али то неће бити експлицитно подржано.
Будите посебно опрезни ако мењате систем изградње, нпр. Makefile фајлови.
3. Тестирајте своје промене пре слања.
Покрените програм на којег утичу ваше измене и уверите се да се измењени код понаша онако како сте хтели.
Покрените регресивне тестове ако постоје („make check“).
4. ДОБРО проверите шта шаљете.
Урадите „cvs update“ и „cvs diff“ пре слања. Озбиљно схватите поруке од CVS-а које се тичу конфликата, непознатих
фајлова, и др. „cvs diff“ ће вам тачно рећи шта ћете да пошаљете. Проверите да ли то оно што сте стварно хтели да
пошаљете.
5. Увек додајте описне поруке за дневник.
Поруке за дневник би требало да буду разумљиве за неког ко види само дневник. Оне неби требало да зависе од информација
изван контекста слања. Покушајте да остављате поруке само за оне фајлове на које утичу промене описане у поруци.
Све у свему дајте све важне информације које се не могу видети из diff-а у поруци дневника.
6. Код који шаљете мора да поштује политике КДЕ-овог кодирања.
Ово укључује безбедност (цитати шкољке, препуне прихватника-бафера, рањивости низа-стринга форматирања), бинарну
компатибилност (dpointers), i18n, употребљивост, водич стила сучеља-интерфејса, (API) документацију, документацију и
дефиницију управљања меморијом и политике власништва, именовање метода, услове за уључивање у kdelibs, проблеме
портабилности и напомене о лиценцирању.
Ове политике су дефинисане посебно. Ако вам нешто није јасно питајте у дописној листи.
7. Поштујте посебне политике слања које поставља план издавања.
8. Поштујте политике одржавалаца програма и библиотека, и увек се консултујте са њима пре него што учините велике измене.
Системи за контролу изворног кода нису замена за комуникацију међу програмерима.
9. Када планирате да направите измене које утичу на пуно другог кода у CVS-у, најавите их на време у дописној листи.
Промене које утичу на много кода у CVS-у, као што је рецимо коришћење нових могућности билиотека, могу да „скрше“
остатак кода чак иако изгледају тривијално, нпр. зато што програм мора да се компајлира под старијом верзијом библиотека
из неких разлога. Најављивањем измена унапред, програмери су припремљени, и могу да изразе забринутост пре него се
нешто „скрши“.
10. Не шаљите измене јавних API-ја библиотека пре него што се консултујете са осталим програмерима.
Постоје извесни посебни захтеви за јавни API библиотека, нпр. бинарна и компатибилност изборног кода. Промене јавног
API-ја утичу на многе прогрере, тако да је захтев за разматрање тих измена обавезан да неби корисници API-ја имали
проблема, а и да би се унапредио API.
11. Преузмите одговорност за своја слања.
Ако ваше слање „скрши“ нешто или има споредне ефекте на остатак кода, преузмите одговорност за поправку или помозите
у решавању насталих проблема.
12. Не шаљите код који не разумете.
Избегавајете ствари као „Не знам зашто пада, али кад урадим ово, онда више не пада“ или „Нисам потпуно сигуран да је
ово исправно, али бар код мене ради како треба“.
Ако не пронађете решење проблема, поразговарајте са осталим програмерима.
13. Немојте злоупотребљавати ваш CVS налог да прогурате измене са којима се остали програмери не слажу.
Ако постоје неслагања око измена кода, њих би требало расправити дискусијом на листи или приватно, а не присиљавањем
осталих простим слањем измена на CVS.
14. Ако шаљете исправке грешака-багова, размислите о портовању тих исправки на остале гране.
Користите исти коментар и за оригиналну исправку и за остале гране. На овај начин лако се види које су исправке већ
урађене у осталим гранама.
15. Ако исправите грешку пријављену на систему за праћење грешака, додајте број грешке у поруци за дневник.
Да би систем за праћење грешака био синхронизован са CVS-ом, требало би да референцирате извештај о грешци у вашим
слањима, и да затворите извештај о грешци у систему за праћење грешака.
Ово не значи да вам нису потребне разумљиве поруке у дневнику. Из поруке мора бити јасно шта је промењено без гледања
у извештај о грешци.
16. Избегавајте губитак CVS историје, преименовањем или премештањем фајлова.
Алтернатива преименовању или премештању фајлова коришћењем CVS наредби је њихово премештање на серверу. Питајте
администратора система да то уради ако морате да преименујете или преместите фајлове у CVS складишту.
17. Званичне ознаке издања или грана користе само велика слова. Користите мала слова за све остале ознаке и гране.
Ово правило захтевају скрипте на CVS серверу.
18. Немојте додавати генерисане фајлове у складиште.
Фајлови направљени током изградње неби требало да буду у складишто зато што сто су то редундантне информације и
могу да изазову конфликте. Само би прави изворни код требало да се налази у CVS-у. Изузетак за ово су фајлови
направљени алатима који би били неуобичајен услов за изградњу.
Стандардни алати укључују autoconf/automake, gcc, bash, perl, moc, uic и алате који су део KDE-а, нпр. dcopidl.
Алати који не би требало да буду услов за изградњу пројекта укључују lex/flex, yacc/bison, python, ruby итд.
19. Немојте користити кључне речи CVS-а као што су Id или Log у фајловима изворног кода.
Ове ознаке изазивају непотребне конфликте приликом стапања грана и не садрже никакве информације које нису ионако
већ доступне у CVS складишту.
20. Радите „елементарна“ слања.
CVS има могућност слања више од једног фајла одједном. Због тога, све повезане измене у различитим фајловима, чак
иако се простиру у различитм директоријума истовремене, шаљите у истом слању. На овај начин, осигуравате да CVS остаје
у стању које може да се компајлира и пре и после слања.
21. Не мешајте измене у форматирању са изменама у коду.
Промена форматирања кода, као што је увлачење или празнине, издрнда diff, тако да је тешко пронаћи измене у коду, ако
су оне помешане са слањима у вези форматирања или слично, приликом каснијег гледања у дневник или diff.
Одвојено слање измена у форматирању решава проблем.
22. Ако ваше слање прави видљиве измене у GUI-ју, додајте кључну реч GUI у поруку за дневник.
Додавање кључне речи „GUI“ у поруку дневника осигурава да ће писци документације бити обавештени о вашим изменама.
Hash: SHA1
Pošto se spremam da preliminarno stablo prebacim na CVS server, pripremio sam
dokument koji određuje politiku slanja izmena na server. Ovaj dokument je
preuzet sa sa KDE-ovog sajta i prilagođen je našim potrebama.
Nepoštovanje ovog dokumenta povlači oduzimanje CVS naloga, stoga vas sve
molim da dobro proučite šta u njemu piše kako ne bih dolazio u neprijatnu
situaciju da nekome moram da ukinem nalog.
Gvozdene, priloženi fajl bi mogao da prebaciš na weblog, a ja ću videti da se
nađe i na CVS-u.
- --
Pozdrav,
Tanasković Toplica
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFAU0cMtKJqksC6c0sRAgr/AJ9X8CSnvjCTKBHQvFUD5SyrLD9T+ACgkxik
B5itiCLCgwZ40v8oOR2KBKU=
=TOK8
-----END PGP SIGNATURE-----
Политика слања на CVS сервер
----------------------------
Сажетак:
--------
1. Размислите двапут пре слања.
2. Никада не шаљите код који не може да се компајлира.
3. Тестирајте своје промене пре слања.
4. ДОБРО проверите шта шаљете.
5. Увек додајте описне поруке за дневник.
6. Код који шаљете мора да поштује политике КДЕ-овог кодирања.
7. Поштујте посебне политике слања које поставља план издавања.
8. Поштујте политике одржавалаца програма и библиотека, и увек се консултујте са њима пре него што учините велике измене.
9. Када планирате да направите измене које утичу на пуно другог кода у CVS-у, најавите их на време у дописној листи.
10. Не шаљите измене јавних API-ја библиотека пре него што се консултујете са осталим програмерима.
11. Преузмите одговорност за своја слања.
12. Не шаљите код који не разумете.
13. Немојте злоупотребљавати ваш CVS налог да прогурате измене са којима се остали програмери не слажу.
14. Ако шаљете исправке грешака-багова, размислите о портовању тих исправки на остале гране.
15. Ако исправите грешку пријављену на систему за праћење грешака, додајте број грешке у поруци за дневник.
16. Избегавајте губитак CVS историје, преименовањем или премештањем фајлова.
17. Званичне ознаке издања или грана користе само велика слова. Користите мала слова за све остале ознаке и гране.
18. Немојте додавати генерисане фајлове у складиште.
19. Немојте користити кључне речи CVS-а као што су Id или Log у фајловима изворног кода.
20. Радите „елементарна“ слања.
21. Не мешајте измене у форматирању са изменама у коду.
22. Ако ваше слање прави видљиве измене у GUI-ју, додајте кључну реч GUI у поруку за дневник.
Детаљи:
-------
1. Размислите двапут пре слања.
Слаље нечега на CVS има озбиљне последице. Сви програмери ће добити ваше измене оног тренутка када се нађу у
CVS-у, и ако нешто „скрше“, скршиће свима. Сва слања биће јавно доступна у CVS складишту заувек.
Са друге стране CVS дозвољава да се измене врате, тако да је могуће оппоравити се од грешака. Ово је релативно
једноставно за слања за појединачне фајлове, али исто тако може бити огроман посао за веће измене.
Поента је: Будите свесни последица ваших слања. Одвојите времена да размислите о њима пре слања.
2. Никада не шаљите код који не може да се компајлира.
Компајлирајте код и исправите све грешке пре слања. Уверите се да су новопридодати фајлови послати. Ако недостају
ваше компајлирање у локалу ће радити како треба, али сви остали неће моћи да компајлирају код.
Обавезно се уверите да се код компајлира код вас у локалу. Такође размотрите које ће последице имати ваша слања за
компајлирање са изворишним директоријумом који је различит од директоријума изградње. Било би лепо да може да се
компајлира и са опцијом --enable-final, али то неће бити експлицитно подржано.
Будите посебно опрезни ако мењате систем изградње, нпр. Makefile фајлови.
3. Тестирајте своје промене пре слања.
Покрените програм на којег утичу ваше измене и уверите се да се измењени код понаша онако како сте хтели.
Покрените регресивне тестове ако постоје („make check“).
4. ДОБРО проверите шта шаљете.
Урадите „cvs update“ и „cvs diff“ пре слања. Озбиљно схватите поруке од CVS-а које се тичу конфликата, непознатих
фајлова, и др. „cvs diff“ ће вам тачно рећи шта ћете да пошаљете. Проверите да ли то оно што сте стварно хтели да
пошаљете.
5. Увек додајте описне поруке за дневник.
Поруке за дневник би требало да буду разумљиве за неког ко види само дневник. Оне неби требало да зависе од информација
изван контекста слања. Покушајте да остављате поруке само за оне фајлове на које утичу промене описане у поруци.
Све у свему дајте све важне информације које се не могу видети из diff-а у поруци дневника.
6. Код који шаљете мора да поштује политике КДЕ-овог кодирања.
Ово укључује безбедност (цитати шкољке, препуне прихватника-бафера, рањивости низа-стринга форматирања), бинарну
компатибилност (dpointers), i18n, употребљивост, водич стила сучеља-интерфејса, (API) документацију, документацију и
дефиницију управљања меморијом и политике власништва, именовање метода, услове за уључивање у kdelibs, проблеме
портабилности и напомене о лиценцирању.
Ове политике су дефинисане посебно. Ако вам нешто није јасно питајте у дописној листи.
7. Поштујте посебне политике слања које поставља план издавања.
8. Поштујте политике одржавалаца програма и библиотека, и увек се консултујте са њима пре него што учините велике измене.
Системи за контролу изворног кода нису замена за комуникацију међу програмерима.
9. Када планирате да направите измене које утичу на пуно другог кода у CVS-у, најавите их на време у дописној листи.
Промене које утичу на много кода у CVS-у, као што је рецимо коришћење нових могућности билиотека, могу да „скрше“
остатак кода чак иако изгледају тривијално, нпр. зато што програм мора да се компајлира под старијом верзијом библиотека
из неких разлога. Најављивањем измена унапред, програмери су припремљени, и могу да изразе забринутост пре него се
нешто „скрши“.
10. Не шаљите измене јавних API-ја библиотека пре него што се консултујете са осталим програмерима.
Постоје извесни посебни захтеви за јавни API библиотека, нпр. бинарна и компатибилност изборног кода. Промене јавног
API-ја утичу на многе прогрере, тако да је захтев за разматрање тих измена обавезан да неби корисници API-ја имали
проблема, а и да би се унапредио API.
11. Преузмите одговорност за своја слања.
Ако ваше слање „скрши“ нешто или има споредне ефекте на остатак кода, преузмите одговорност за поправку или помозите
у решавању насталих проблема.
12. Не шаљите код који не разумете.
Избегавајете ствари као „Не знам зашто пада, али кад урадим ово, онда више не пада“ или „Нисам потпуно сигуран да је
ово исправно, али бар код мене ради како треба“.
Ако не пронађете решење проблема, поразговарајте са осталим програмерима.
13. Немојте злоупотребљавати ваш CVS налог да прогурате измене са којима се остали програмери не слажу.
Ако постоје неслагања око измена кода, њих би требало расправити дискусијом на листи или приватно, а не присиљавањем
осталих простим слањем измена на CVS.
14. Ако шаљете исправке грешака-багова, размислите о портовању тих исправки на остале гране.
Користите исти коментар и за оригиналну исправку и за остале гране. На овај начин лако се види које су исправке већ
урађене у осталим гранама.
15. Ако исправите грешку пријављену на систему за праћење грешака, додајте број грешке у поруци за дневник.
Да би систем за праћење грешака био синхронизован са CVS-ом, требало би да референцирате извештај о грешци у вашим
слањима, и да затворите извештај о грешци у систему за праћење грешака.
Ово не значи да вам нису потребне разумљиве поруке у дневнику. Из поруке мора бити јасно шта је промењено без гледања
у извештај о грешци.
16. Избегавајте губитак CVS историје, преименовањем или премештањем фајлова.
Алтернатива преименовању или премештању фајлова коришћењем CVS наредби је њихово премештање на серверу. Питајте
администратора система да то уради ако морате да преименујете или преместите фајлове у CVS складишту.
17. Званичне ознаке издања или грана користе само велика слова. Користите мала слова за све остале ознаке и гране.
Ово правило захтевају скрипте на CVS серверу.
18. Немојте додавати генерисане фајлове у складиште.
Фајлови направљени током изградње неби требало да буду у складишто зато што сто су то редундантне информације и
могу да изазову конфликте. Само би прави изворни код требало да се налази у CVS-у. Изузетак за ово су фајлови
направљени алатима који би били неуобичајен услов за изградњу.
Стандардни алати укључују autoconf/automake, gcc, bash, perl, moc, uic и алате који су део KDE-а, нпр. dcopidl.
Алати који не би требало да буду услов за изградњу пројекта укључују lex/flex, yacc/bison, python, ruby итд.
19. Немојте користити кључне речи CVS-а као што су Id или Log у фајловима изворног кода.
Ове ознаке изазивају непотребне конфликте приликом стапања грана и не садрже никакве информације које нису ионако
већ доступне у CVS складишту.
20. Радите „елементарна“ слања.
CVS има могућност слања више од једног фајла одједном. Због тога, све повезане измене у различитим фајловима, чак
иако се простиру у различитм директоријума истовремене, шаљите у истом слању. На овај начин, осигуравате да CVS остаје
у стању које може да се компајлира и пре и после слања.
21. Не мешајте измене у форматирању са изменама у коду.
Промена форматирања кода, као што је увлачење или празнине, издрнда diff, тако да је тешко пронаћи измене у коду, ако
су оне помешане са слањима у вези форматирања или слично, приликом каснијег гледања у дневник или diff.
Одвојено слање измена у форматирању решава проблем.
22. Ако ваше слање прави видљиве измене у GUI-ју, додајте кључну реч GUI у поруку за дневник.
Додавање кључне речи „GUI“ у поруку дневника осигурава да ће писци документације бити обавештени о вашим изменама.
- Follow-Ups:
- Re: Politika slanja na CVS...
- From: Toplica Tanaskovic <toptan@kde.org.yu>
- Re: Politika slanja na CVS...
Previous by date: Timovi...
Next by date: Re: Politika slanja na CVS...
Previous by thread: Politika slanja na CVS... Next by thread: Re: Politika slanja na CVS...
Previous by thread: Politika slanja na CVS... Next by thread: Re: Politika slanja na CVS...