abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
dnes 13:22 | Nová verze

Alan Griffiths z Canonicalu oznámil vydání verze 1.0.0 display serveru Mir (GitHub, Wikipedie). Mir byl představen v březnu 2013 jako náhrada X serveru a alternativa k Waylandu. Dnes Mir běží nad Waylandem a cílen je na internet věcí (IoT).

Ladislav Hagara | Komentářů: 0
včera 22:00 | Nasazení Linuxu
Stabilní aktualizace Chrome OS 69 (resp. Chromium OS), konkrétně 69.0.3497.95, přináší mj. podporu linuxových aplikací. Implementována je pomocí virtualizace, a proto je tato funkce také omezena na zařízení s dostatkem paměti a podporou hardwarové akcelerace, tudíž nejsou podporovány chromebooky s 32bitovými architekturami ARM, či Intel Bay Trail (tzn. bez Intel VT-x).
Fluttershy, yay! | Komentářů: 3
včera 21:32 | Zajímavý projekt
Došlo k uvolnění linuxové distribuce CLIP OS, vyvíjené francouzským úřadem pro kybernetickou bezpečnost ANSSI, jako open source. Vznikla za účelem nasazení v úřadech, kde je potřeba omezit přístup k důvěrným datům. Je založená na Gentoo.
Fluttershy, yay! | Komentářů: 0
včera 16:00 | Komerce

Zjistěte více o bezpečné a flexibilní architektuře v cloudu! IBM Cloud poskytuje bezpečné úložiště pro Vaše obchodní data s možností škálovatelnosti a flexibilitou ukládání dat. Zároveň nabízí prostředky pro jejich analýzu, vizualizaci, reporting a podporu rozhodování.

… více »
Fluttershy, yay! | Komentářů: 12
včera 12:22 | Nová verze

V dubnu letošního roku Mozilla představila webový prohlížeč pro rozšířenou a virtuální realitu Firefox Reality (GitHub). V úterý oznámila vydání verze 1.0. Ukázka na YouTube. Firefox Reality je k dispozici pro Viveport, Oculus a Daydream.

Ladislav Hagara | Komentářů: 2
včera 12:00 | Komunita

V srpnu loňského roku společnost Oracle oznámila, že Java EE (Enterprise Edition) bude uvolněna jako open source. O měsíc později bylo rozhodnuto, že tato open source Java EE bude přejmenována a předána Eclipse Foundation. Nové jméno bylo oznámeno v únoru letošního roku. Z Java EE se stala Jakarta EE. Eclipse Foundation včera oznámila dosažení dalšího milníku. Zdrojové kódy aplikačního serveru GlassFish jsou již k dispozici v git repozitářích Eclipse Foundation (GitHub).

Ladislav Hagara | Komentářů: 0
19.9. 23:55 | Komunita

LTS (Long Term Support) podpora Ubuntu 12.04 LTS (Precise Pangolin) skončila po 5 letech od jeho vydání, tj. v dubnu 2017. V březnu 2017 ale Canonical představil placenou ESM (Extended Security Maintenance) podporu, díky které je Ubuntu 12.04 podporováno do dubna 2020. Dnes Canonical potvrdil ESM podporu také pro Ubuntu 14.04 LTS (Trusty Tahr), jehož LTS podpora skončí v dubnu 2019.

Ladislav Hagara | Komentářů: 0
19.9. 15:00 | Nová verze

Byla vydána verze 3.0.0 frameworku pro vývoj multiplatformních desktopových aplikací pomocí HTML, CSS a JavaScriptu Electron (YouTube, GitHub). Electron byl původně vyvíjen pro editor Atom pod názvem Atom Shell. Dnes je na Electronu postavena celá řada dalších aplikací.

Ladislav Hagara | Komentářů: 0
19.9. 14:44 | Nová verze

Po půl roce vývoje od vydání verze 6.0.0 byla vydána verze 7.0.0 překladačové infrastruktury LLVM (Wikipedie). Přehled novinek v poznámkách k vydání: LLVM, Clang, clang-tools-extra a LLD.

Ladislav Hagara | Komentářů: 0
19.9. 13:44 | Nová verze

Byla vydána verze 3.0.0 knihovny pro vykreslování grafů v programovacím jazyce Python Matplotlib (Wikipedie, GitHub). Přehled novinek a galerie grafů na stránkách projektu. Zrušena byla podpora Pythonu 2.

Ladislav Hagara | Komentářů: 0
Na optické médium (CD, DVD, BD aj.) jsem naposledy vypaloval(a) data před méně než
 (13%)
 (14%)
 (20%)
 (23%)
 (25%)
 (4%)
 (1%)
Celkem 382 hlasů
 Komentářů: 33, poslední 16.9. 11:55
Rozcestník
Štítky: není přiřazen žádný štítek

Vložit další komentář
xkucf03 avatar 11.3. 16:31 xkucf03 | skóre: 46 | blog: xkucf03
Rozbalit Rozbalit vše Re: git - popis vývojové větve
Jenže jak stáhnout aktuální změny v hlavní vývojové větvi, když se na ni bez uložených změn nemohu přepnout?

K tomu slouží git stash – je to něco jako kdyby sis udělal git diff výsledek pojmenoval a někam uložil pro budoucí použití a změny v pracovním adresáři zahodil. Udělat klasický git commit (--amend), je taky cesta, ale tam hrozí, že člověk na rozdělanou práci zapomene a omylem udělá git push.

Popis může být i víceřádkový. Součástí řetězce v souboru .git/config pak bude i sekvence pro zalomení řádku.

Ty popisy jsou ale jen lokální, ostatní je nevidí, ne? Při týmové práci bych spíš větev pojmenoval podle čísla úkolu ze systému na správu chyb/požadavků (Bugzilla atd.) a podrobný popis měl tam.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
12.3. 10:19 Aleš Kapica | skóre: 47 | blog: kenyho_stesky | Ostrava
Rozbalit Rozbalit vše Re: git - popis vývojové větve
Ty popisy jsou ale jen lokální, ostatní je nevidí, ne?
Ano. Ale to je přesně to, co jsem od toho očekával. Ty popisy jsou určeny především pro mne, abych si po čase snáz vzpoměl proč jsem onu branch buď já, nebo autor aplikace vlastně založil. Někdy samozřejmě stačí pouhé pojmenování větve, ale v některých případech ne.

Navíc nemám ambice, ani čas na to, abych participoval na vývoji kdejaké aplikace. Pokud potřebuji vyřešit nějaký problém, založím si branch, pro sebe problém vyřeším a pokud to má valný smysl i pro někoho jiného, pošlu autorovi patch a nechám zcela na jeho libovůli jak s ním naloží.
Josef Kufner avatar 11.3. 16:50 Josef Kufner | skóre: 68
Rozbalit Rozbalit vše Re: git - popis vývojové větve
Řešení je jednoduché: Nepoužívej k vývoji hlavní vývojovou větev (master).

Než něco začneš dělat, tak si udělej feature branch, typicky vytvořenou z nějakého issue (Gitlab na to má dokonce čudlík). Pak něco chvilku děláš na té feature branch a když je ta jedna věc hotova, tak se to mergne do masteru. WIP commit s poznámkama na konci takové větve nevadí. Mezitím můžeš v klidu přepínat na funkční master a přidávat malé opravy na relativně stabilní kód.

Když dělá na projektu více lidí, tak si každý hraje ve své feature větvi a lidi si navzájem nepřekážejí. Hezky to také funguje s merge requesty a code review.
Hello world ! Segmentation fault (core dumped)
11.3. 18:48 Doli
Rozbalit Rozbalit vše Re: git - popis vývojové větve
Jenže jak stáhnout aktuální změny v hlavní vývojové větvi, když se na ni bez uložených změn nemohu přepnout?
git fetch stáhne změny z remote, aniž by cokoliv měnil v lokálním repu.
11.3. 21:35 KS | skóre: 10 | blog: blg | Horní polní u západní dolní
Rozbalit Rozbalit vše Re: git - popis vývojové větve
Nebo přepnout pomocí git worktree.
Pochybnost, nejistota - základ poznání
xkucf03 avatar 11.3. 19:37 xkucf03 | skóre: 46 | blog: xkucf03
Rozbalit Rozbalit vše stažení všech větví

BTW: jak řešíte situaci, kdy si chcete zazálohovat vzdálený git? A tím myslím kompletně – všechny větve.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
Josef Kufner avatar 11.3. 20:02 Josef Kufner | skóre: 68
Rozbalit Rozbalit vše Re: stažení všech větví
Prostě to naklonuješ:
       --mirror
           Set up a mirror of the source repository. This implies --bare. Compared to
           --bare, --mirror not only maps local branches of the source to local branches
           of the target, it maps all refs (including remote-tracking branches, notes
           etc.) and sets up a refspec configuration such that all these refs are
           overwritten by a git remote update in the target repository.
Hello world ! Segmentation fault (core dumped)
xkucf03 avatar 11.3. 20:12 xkucf03 | skóre: 46 | blog: xkucf03
Rozbalit Rozbalit vše Re: stažení všech větví

A následný pull/fetch přes všechny větve?

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
11.3. 20:33 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: stažení všech větví

Stačí fetch, pull je jen zkratka pro fetch + merge a ten merge už můžete udělat lokálně. Takhle to třeba řeším na notebooku, kde je dobré mít fetchnutý co nejvíc akutální stav, ale není nutné mít aktuální i lokální tracking branche, protože to už můžu v případě potřeby udělat i offline. Takže když jsem online, pustím něco jako

  for d in ~/work/git/*; do git -C "$d" fetch --all; done

a update lokálních větví nechám až na moment, kdy je opravdu chci použít.

xkucf03 avatar 11.3. 20:49 xkucf03 | skóre: 46 | blog: xkucf03
Rozbalit Rozbalit vše Re: stažení všech větví

Mně právě někdy přišlo, že git nepostahuje všechno, ani když dám fetch --all. Ale teď jsem to zkoušel a vypadá to OK.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
11.3. 22:37 dementni.lojzik | skóre: 19 | blog: ze zivota na vsi
Rozbalit Rozbalit vše Re: stažení všech větví
pokud chces, aby se ti to stahovalo pokazde jen pres git fetch, tak by melo stacit do .git/config dat neco jako
[remote "upstream"]
        url = $REPO
        fetch = +refs/heads/*:refs/remotes/upstream/*
Takhle jsou automaticky napr. z githubu stahovat i pull requesty do prislusne vetve
[remote "upstream"]
        url = $REPO
        fetch = +refs/heads/*:refs/remotes/upstream/*
        fetch = +refs/pull/*/head:refs/remotes/upstream/pr/*
vencour avatar 11.3. 21:10 vencour | skóre: 55 | blog: Tady je Vencourovo | Praha+západní Čechy
Rozbalit Rozbalit vše Re: git - popis vývojové větve
Přidal jsem do výběru.
Ty nejhlubší objevy nečekají nutně za příští hvězdou. Jsou uvnitř nás utkány do vláken, která nás spojují, nás všechny.
Bedňa avatar 12.3. 00:41 Bedňa | skóre: 34 | blog: Žumpa | Horňany
Rozbalit Rozbalit vše Re: git - popis vývojové větve
Git spravuje verzie, to že nedokončuješ svoju prácu je tvoj problém. Na to je dobré nasadiť Git + niečo. Napr. taký GitHub má Issues, kde si aj sám môžeš napísať, čo tam treba dorobiť.

Vlastne by stačilo urobiť niečo na spôsob GitHub issues, kde si budeš písať poznámky k branchom kde si skončil a čo to malo pôvodne robiť.

Git robí svoju prácu dobre, na tebe záleží ako si spravíš svoje nástroje nad tým postavené.
KERNEL ULTRAS video channel >>>
12.3. 10:39 Aleš Kapica | skóre: 47 | blog: kenyho_stesky | Ostrava
Rozbalit Rozbalit vše Re: git - popis vývojové větve
Nechápu smysl tvého sdělení. Samozřejmě že git dělá svoji práci dobře. Jinak bych ho už víc jak deset let nepoužíval.

Jinak jak jsi správně podotknul, můj pracovní workflow je také čistě můj problém. Do vývoje aplikací zasahuji z dobré vůle, ne proto že by mě za to někdo platil, nebo že bych z toho něco měl. Nejsem typ multitaskingového člověka, který je schopen se plynule přepínat mezi úlohami a pokaždé bez problémů navázat. Potřebuji na věc plně soustředit.

To je ostatně důvod, proč na abclinuxu také aktivně přispívám do diskuze. Někomu stačí k odreagování si sem tam něco přečíst. Ovšem bez toho, že bych čs od času v diskuzi nezareagoval by se mi v kupř. v hlavě honilo: "Panebože ten XY je snad úplný kretén?" nebo "Proč to nezkusí vyřešit taky takhle?". Takže si během pár sekund vyčistím hlavu. Někoho moje reakce pobaví či navede správným směrem, jiného nasere, ale já se můžu soustředit na práci.
Bedňa avatar 12.3. 23:28 Bedňa | skóre: 34 | blog: Žumpa | Horňany
Rozbalit Rozbalit vše Re: git - popis vývojové větve
Jako OK kámo, nič v zlom, len som písal, že pre tvoje potreeby by bolo lepšie postaviť nad Gitom niečo, kde si sám budeš písať ciele a poznámky. GitHub to má priamo v sebe.
KERNEL ULTRAS video channel >>>
xkucf03 avatar 13.3. 00:10 xkucf03 | skóre: 46 | blog: xkucf03
Rozbalit Rozbalit vše git, github, gitlab, kallithea, fossil, správa chyb/požadavků, wiki

GitHub je proprietární služba. Když už tak něco jako GitLab, Kallithea atd. A nebo pak třeba Fossil, což je verzovací systém, který má vestavěnou wiki i správu chyb/požadavků.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
Bedňa avatar 13.3. 00:19 Bedňa | skóre: 34 | blog: Žumpa | Horňany
Rozbalit Rozbalit vše Re: git, github, gitlab, kallithea, fossil, správa chyb/požadavků, wiki
Rovnako uprednostňujem slobodný softvér, mno zrovna to čo si vymenoval nieje úplne adekvátna náhrada, to skôr Gitea. Hoci Fossil nepoznám, ale mrknem na to.
KERNEL ULTRAS video channel >>>
13.3. 07:54 oryctolagus | skóre: 29 | blog: Untitled
Rozbalit Rozbalit vše Re: git, github, gitlab, kallithea, fossil, správa chyb/požadavků, wiki
GitHub je proprietární služba.
To je sice pravda, ale na GitHubu ani tak nejde o tu službu, jako spíš o tu komunitu a viditelnost. Pro vlastní účely si člověk určitě může nahodit GitLab nebo cokoli jinýho, ale imho veřejný foss projekt potřebuje dnes alespoň mirror na GitHubu. Může se nám to nelíbit, ale je to tak ...
Josef Kufner avatar 13.3. 12:15 Josef Kufner | skóre: 68
Rozbalit Rozbalit vše Re: git, github, gitlab, kallithea, fossil, správa chyb/požadavků, wiki
Mirror na GitHubu je v pohodě, ale primární repozitář s issues je lepší mít více pod kontrolou. Pro malé projekty to je asi jedno, ale pro něco většího a dlouhodobějšího už to má smysl řešit.
Hello world ! Segmentation fault (core dumped)
xkucf03 avatar 13.3. 20:18 xkucf03 | skóre: 46 | blog: xkucf03
Rozbalit Rozbalit vše Re: git, github, gitlab, kallithea, fossil, správa chyb/požadavků, wiki

Aby moje předchozí tvrzení neznělo tak radikálně: zrovna u distribuovaných verzovacích systémů není proprietární služba resp. hosting až taková tragédie, protože úložiště se dá kdykoli naklonovat, vystavit jinde a uživatelé si jen změní URL. Taky nehrozí ztráta dat, protože autoři mají všechno i u sebe. A integritu lze zajistit elektronickým podpisem jednotlivých verzí.

Nicméně i přesto mi to trochu vadí a považuji to za problém (i když jsou mnohem horší věci). Např. jde o to, že s GitHubem musíš uzavřít smlouvu, vzdát se různých práv a k jiným věcem se zase zavázat. Prostě typické právnické sračky jako u jiného proprietárního softwaru. Taky to běží v USA a podléhá jejich právu (patenty, jejich výklad copyrightu…).

veřejný foss projekt potřebuje dnes alespoň mirror na GitHubu

A to je právě špatně. Je to trochu taková davová psychóza, připomíná mi to časy ICQ… Jsi tam, protože tam jsou všichni a oni tam jsou, protože tam jsi ty a ostatní… A zrovna u distribuovaného verzovacího systému je to vážně hloupé a zbytečné – jeho zásadní vlastností je právě ta distribuovanost/decentralizace. A nutnost mít účet u jednoho konkrétního poskytovatele gitového hostingu jde přímo proti této myšlence.

Mělo by být jedno, kde je ten repozitář uložený – technologie to podporuje. A pokud jsou potřeba nějaké dodatečné funkce (úkoly, pull requesty, wiki, statistiky atd.), měl by je pokrývat svobodný software – ne proprietární služba.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
xkucf03 avatar 13.3. 20:32 xkucf03 | skóre: 46 | blog: xkucf03
Rozbalit Rozbalit vše Re: git, github, gitlab, kallithea, fossil, správa chyb/požadavků, wiki
s GitHubem musíš uzavřít smlouvu

Jde to řešit tak, že si vytvoříš falešnou identitu, nějakého svého virtuálního kolegu, který s GitHubem tu smlouvu uzavře, a bude dělat pravidelně git pushgit pull a synchronizovat tak úložiště. Primární ale musí být u tebe a vždy musíš být připraven na to, že hosting na GitHubu může kdykoli skončit. Ten kolega bude ve skutečnosti robot a to, že uzavřeli smlouvu s robotem je jejich problém nikoli tvůj.

Na tyhle proprietární služby bych se nespoléhal, je to stejný případ jako třeba YouTube nebo Facebook – jsou lidé, kteří si tam vybudovali síť přátel/kontaktů a pak o ni jednoho dne přišli, protože se provozovateli nelíbil nějaký jejich obsah nebo se třeba jen nějaký jejich pracovník spletl. Komunikace s takovou korporací a snaha o nápravu je jen ztráta času. Viděl jsem např. lidi doporučující si budovat i paralelní síť přátel na VK.com. Ale to je trochu z bláta do louže (záleží taky na politických postojích a možných konfliktech zájmů).

Tak jako tak si člověk musí udržovat záložní komunikační kanál pro případ problémů. Jenže když už člověk tu záložní infrastrukturu má, tak proč ji nepoužít rovnou jako primární místo té proprietární služby? Kvůli šířce pásma a lepšímu pingu do různých částí světa? Kolik dat vlastně potřebujete hostovat a jakou latenci vyžadujete, aby tento argument byl vůbec relevantní?

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
13.3. 21:15 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: git, github, gitlab, kallithea, fossil, správa chyb/požadavků, wiki
Čas od času mne přepadnou pochybnosti, jestli to s tou nekonformností a paranoiou už trochu nepřeháním. Pak zajdu na ABCLinuxu a to mne spolehlivě uklidní… :-)
13.3. 23:15 oryctolagus | skóre: 29 | blog: Untitled
Rozbalit Rozbalit vše Re: git, github, gitlab, kallithea, fossil, správa chyb/požadavků, wiki
Asi tak ;-)
13.3. 21:05 oryctolagus | skóre: 29 | blog: Untitled
Rozbalit Rozbalit vše Re: git, github, gitlab, kallithea, fossil, správa chyb/požadavků, wiki
A to je právě špatně. Je to trochu taková davová psychóza, připomíná mi to časy ICQ… Jsi tam, protože tam jsou všichni a oni tam jsou, protože tam jsi ty a ostatní…
Ano, tak to funguje. Viz network effect / bandwagon effect.

Přijde mi, že diskuse, jestli to je nebo není špatně je tak trochu bezpředmětná. Já taky mam samozřejmě radší svobodné služby oproti proprietárním. Terms & conditions, NDA a podobně se mi taky nelíbí. Na úrovni teorie souhlasim s těmi ideály o svobodných decentralizovaných slulžbách, nicméně reálně to jde celé do kopru ve chvíli, když si spočteš, že pravděpodobnost, že ti někdo reportuje bug je na Githubu násobně vyšší než na nějakém self-hosted řešení. (Inb4 elitistické racionalizace á la "Uživatel, který nechce reportovat do našeho systému nám nestojí za to a stejně nejspíš píše blbý bugerporty.")

Časy ICQ ti to přípomíná správně, ty časy se nijak nezměnily. ICQ nebylo nahrazeno Jabberem, nýbrž Facebookem. A jestli něco nahradí Facebook, nejspíš to zase bude nějaká proprietární centralizovaná služba spíš než nějaká Diaspora nebo podobné softwary, které jsou sice docela hezké, ale bohužel šanci na reálné využití mají mizivou (a to i přesto, že existují lokální extrémy).

Nejsem nijak proti svobodným alternativám populárních služeb, občas je zkoušim, ale v jejich úspěch moc nevěřim. Spíš si myslim, že to časem dospěje k tomu, že přibudou "socialistické" zákony na regulaci digitální infrastruktury, včetně všelijakých služeb (podobně jako "socialistické" zákony, které regulující volnný trh), ale myslim si, že bude ještě nějakou chvíli trvat, než k tomu společnost dospěje...
xkucf03 avatar 13.3. 22:25 xkucf03 | skóre: 46 | blog: xkucf03
Rozbalit Rozbalit vše Svoboda internetu, decentralizace vs. státní regulace
Spíš si myslim, že to časem dospěje k tomu, že přibudou "socialistické" zákony na regulaci digitální infrastruktury, včetně všelijakých služeb (podobně jako "socialistické" zákony, které regulující volnný trh), ale myslim si, že bude ještě nějakou chvíli trvat, než k tomu společnost dospěje...

Zrovna vedle na Rootu: Londýnský starosta na SXSW 2018: technologické firmy nejsou nad zákonem:

Sítě jako Facebook, Twitter či YouTube podle něj nedělají dostatečnou prevenci před šířením fake news, hate speech, harašení a propagandě na svých platformách. … Pokud sítě jako Facebook, Twitter či YouTube a další nevezmou existující problémy vážně, může je potkat regulace ze strany vlád. V tomto kontextu připomněl nedávné úpravy zákonů v Německu, které umožňují pokutovat provozovatele sítí až 50 milióny eur, pokud neodstraní hanlivý příspěvek do 24 hodin. Khan by nerad viděl, aby to (regulace) zašlo tak daleko, neb tyto formy regulace nejsou v souladu se svobodou projevu.

Decentralizovaná sítě jsou prostě nutnost, jinak nám zase stát bude nařizovat, co smíme říkat, co si smíme myslet… Rovněž je důležitá anonymita/pseudonymita, protože pokud stát neví, která fyzická osoba to je, nemůže ji za nepohodlné názory potrestat.

Nebo: Vlády přesměrovávají uživatele na software doplněný o malware:

Avast, CCleaner, VLC, Opera, 7-Zip a další populární aplikace. Pokud se je pokusíte stáhnout v Turecku, dostanete k nim zvláštní dárek – malware. … Turecko se svým poskytovatelem Türk Telekom však není jedinou zemí, kde byla tato praktika objevena. Stejné zařízení pro zkoumání provozu bylo objeveno také v Egyptě u společnosti Telekom Egypt.

Německo, Turecko, Británie, Egypt a další země… tyhle nezdravé myšlenky popírající svobodu se šíří všude možně, takže si nemyslím, že jde o nějakou přehnanou paranoiu.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
13.3. 22:57 oryctolagus | skóre: 29 | blog: Untitled
Rozbalit Rozbalit vše Re: Svoboda internetu, decentralizace vs. státní regulace
Decentralizované sítě jsou prostě nutnost, jinak nám zase stát bude nařizovat, co smíme říkat, co si smíme myslet…
V čem je výhoda sítě, která je decentralizovaná, liberální a necenzurovaná, ale na které nikdo není? Je to sice totálně cynické, ale i cenzurovaný Facebooku má stále větší užitnou hodnotu než třeba ta Diaspora, protože tam prostě nikdo není*. Je sice hrozně hezké, že si tam můžu napsat co chci, ale k čemu mi to je, když to nikdo neuvidí?

Čimž určitě nechci schvalovat cenzuru sociálních sítí ze strany státu, jenom mi není jasný, v čem je praktická hodnota toho tvého tvrzení. IMHO pravděpodobně má mnohem větší šanci na úspěch snaha o nastavení smysluplnějších pravidel pro Facebook než snaha o protlačení Diaspory apod.

*) Tímto se omlouvám davkolovi, který byl tuším můj jediný kontakt na Diaspoře, když jsem ji zkoušel používat.
Nebo: Vlády přesměrovávají uživatele na software doplněný o malware
V čem je pointa? Repozitář mého distra je v zásadě centralizovaný, stejně jako repozitáře ostatních dister. Ten odkaz je prostě akorát o tom, že Turecko není právní stát a stojí to tam za *****.
xkucf03 avatar 13.3. 23:20 xkucf03 | skóre: 46 | blog: xkucf03
Rozbalit Rozbalit vše Sociální sítě, reklama, komerce, spam, propaganda
Je to sice totálně cynické, ale i cenzurovaný Facebooku má stále větší užitnou hodnotu než třeba ta Diaspora, protože tam prostě nikdo není*. Je sice hrozně hezké, že si tam můžu napsat co chci, ale k čemu mi to je, když to nikdo neuvidí?

S tím souhlasím – pokud potřebuješ získat davy příznivců nebo rozšířit nějakou informaci průměrnému obyvatelstvu, tak jsou sociální sítě jako Facebook nebo YouTube velice dobrá volba. Tzn. využít je v některých případech dává smysl. Na druhou stranu ale není důvod tyto sítě a obecně tento způsob myšlení podporovat tím, že bys tam publikoval něco užitečného nebo to používal pro normální kontakt se svými přáteli. Publikovat tam nějaký užitečný obsah (tzn. poskytnout provozovateli práva, licenci, svoje data…) dává smysl leda za účelem získání těch příznivců. Takže tyhle sítě jsou dobré leda tak pro různé kremloboty/euroboty/sorošboty/aláhoboty a podobné. A do toho tam pumpují explicitní nebo častěji skrytou/neoznačenou reklamu různé firmy a dotují různé tragédy a klauny, smyslem jejichž existence je získat „popularitu“ a příznivce a pak šířit reklamu pro toho, kdo zrovna platí.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
13.3. 23:31 oryctolagus | skóre: 29 | blog: Untitled
Rozbalit Rozbalit vše Re: Sociální sítě, reklama, komerce, spam, propaganda
S tím souhlasím – pokud potřebuješ získat davy příznivců nebo rozšířit nějakou informaci průměrnému obyvatelstvu, tak jsou sociální sítě jako Facebook nebo YouTube velice dobrá volba. Tzn. využít je v některých případech dává smysl. Na druhou stranu ale není důvod tyto sítě a obecně tento způsob myšlení podporovat tím, že bys tam publikoval něco užitečného nebo to používal pro normální kontakt se svými přáteli.
Ok, kterou sociální síť doporučuješ na kontakt s přáteli?
xkucf03 avatar 13.3. 23:49 xkucf03 | skóre: 46 | blog: xkucf03
Rozbalit Rozbalit vše Re: Sociální sítě, reklama, komerce, spam, propaganda

Pro 1:1 klasicky e-mail a Jabber (pokud možno šifrovat). A pro m:n komunikaci opět klasické blogy, RSS/Atom a servery typu Ábíčko nebo různé komunitní weby.

Webové videokonference fungují pěkně na meet.jit.si. (zatím jsem nezkoumal, jak je to tam s odposlechem, ale neříkal jsem tam nic důvěrného, co bych neříkal na veřejném místě, jako je třeba hospoda nebo tramvajová zastávka)

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
13.3. 23:56 oryctolagus | skóre: 29 | blog: Untitled
Rozbalit Rozbalit vše Re: Sociální sítě, reklama, komerce, spam, propaganda
Ani jedno z toho není sociální síť. Nejblíž k tomu má Ábíčko, na kterém ale nejsou moji přátelé (resp. nějací jo, ale jen hodně malá část a ubývá to). Jabber používá málo lidí dokonce i z těch technicky zaměřených.
14.3. 00:23 oryctolagus | skóre: 29 | blog: Untitled
Rozbalit Rozbalit vše Re: Sociální sítě, reklama, komerce, spam, propaganda
Abych to upřesnil, u těhle služeb / poskytovatelů / atd., kde jde z velké části nebo primárně o komunikaci, je hodně důležitý ten network effect - ten tam dělá velkou část nebo i většinu té hodnoty. IMHO ho nejde jen tak ignorovat a řešit jen technické vlastnosti, protože sebelepší technické vlastnosti ti bez network efektu k ničemu moc nejsou dobrý. Viz tohle xkcd.
xkucf03 avatar 14.3. 07:53 xkucf03 | skóre: 46 | blog: xkucf03
Rozbalit Rozbalit vše Web a e-mail jako sociální síť

To záleží, jak definuješ sociální sítě. Ze společenského pohledu jsou to okruhy tvých přátel a známých1. Z pohledu IT je to pak nějaká technologie/platforma, která ti umožňuje s těmito lidmi komunikovat a to buď 1:1 nebo 1:N.

Proč by tou platformou nemohl být web a e-mail? Webový prohlížeč a e-mailovou schránku mají všichni (minimálně všichni ti, které bys mohl potkat na proprietární sociální síti typu Facebook).

[1] rodina, sousedi, spolužáci z různých škol, kolegové z různých prací, kamarádi z různých sportů a kroužků, náhodní lidé, které jsi potkal atd.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
14.3. 08:49 oryctolagus | skóre: 29 | blog: Untitled
Rozbalit Rozbalit vše Re: Web a e-mail jako sociální síť
Proč by tou platformou nemohl být web a e-mail? Webový prohlížeč a e-mailovou schránku mají všichni (minimálně všichni ti, které bys mohl potkat na proprietární sociální síti typu Facebook).
Webový prohlížeč mají všichni ale svůj vlastní web nemají a nebudou ho mít. Dále ani web ani e-mail nemají to UI, které by se vyrovnalo té sociální síti. E-mail pokrývá pouze relativně malou podmnožinu té funkcionality.
Heron avatar 14.3. 13:03 Heron | skóre: 51 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Sociální sítě, reklama, komerce, spam, propaganda
Kdysi jsem napsal článek o tom, že sociální sítě jsou jen taková lepší RSS čtečka. To totiž záleží na tom, jak je používáš. Já a celá moje bublina to používá způsobem pro sdělení one to many, většinou dávají odkaz na nějaký web a k tomu napíší svůj názor. (Takže je to vlastně odkaz na článek s komentářem od kámoše.)

Někdy se pod tím odkazem vytvoří více či méně hodnotná diskuse, která je určitě přínosem. Jen je škoda, že se většinou vede diskuse na sociální síti a nikoliv pod článkem samotným.

Ano, i já považuji za nejlepší způsob 1:1 komunikace email a taky se mi to daří provozovat, s určitými lidmi si píšeme mnohostránkové emaily, což je něco, co se na sociální sítě docela blbě umisťuje. Jistě bych byl raději, kdyby to psali někam na veřejný blog, ale ne každý je této povahy.
14.3. 14:24 oryctolagus | skóre: 29 | blog: Untitled
Rozbalit Rozbalit vše Re: Sociální sítě, reklama, komerce, spam, propaganda
Kdysi jsem napsal článek o tom, že sociální sítě jsou jen taková lepší RSS čtečka.
Třeba Facebook v tomhle režimu používám z relativně malé části. Usecase "RSS čtečka" je vhodná na veřejný obsah. (Navíc popravdě RSS čtečky mi nikdy k srdci moc nepřirostly a jsou orientované na technicky zaměřené lidi.)

Pro mě přínos FB je asi v těhle věcech:
  • Sdělení 1:N, které ale nemá být úplně veřejné. ("Čau, nechystáte se někdo jet tam a tam nebo udělat to a to? Měl bych zájem o tohle a tohle ..." atd. atp.)
  • Události, a to hlavně opět neveřejné, ale pro nějakou skupinu. Na organizování nějaké společné akce s kámošema je to dost bezkonkurenční.
  • Zájmové skupiny, opět třeba ne úplně veřejné (měli jsme skupinu školního kruhu, kolejní skupinu, atd.)
  • Celkem dobrý IM
  • Výše zmíněné featury jsou spolu integrované. V tom vidím podobný přínos jako třeba použití IDE nebo příkazové řádky slušného OS, kde ty věci jsou na sebe navzájem navázané.
Samozřejmě většina těch věcí výše by se dala nějakým způsobem nahradit, alespoň s technického hlediska, ale zase: o tom to tak úplně není.

Co se týče e-mailu, taky ho používám i na komunikaci s kamarády / rodinou. Teďka mam dokonce čerstvou zkušenost, kdy jsem jednu akci pro kamarády organizoval přes e-mail a jednu na FB. Obojí má svoje pro a proti. Na tom FB mi to ale přijde snazší a je to přehlednější - problém s e-mailem je, že je v zásadě bezstavový.
Heron avatar 14.3. 15:08 Heron | skóre: 51 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Sociální sítě, reklama, komerce, spam, propaganda
veřejný obsah
No já FB používám výhradně jen na veřejný obsah. Jsou sice lidé, kteří mi píší na FB IM ale i tam se snažím mít na paměti (což se teda ne vždy povede...), že to fakt není soukromá komunikace a že to může kdykoliv kdokoliv číst. Ale jinak žádný obsah se sníženou viditelností netvořím, vše veřejné. Jsem i členem několika uzavřených skupin, ale i tam je tolik lidí, že je to taky v podstatě veřejné (a asi to je teda i veřejně vidět, jen to nečlenové nemohou komentovat).

Co se týče toho organizování akcí, no já jsem dost paranoidní na to, abych dopředu "veřejně" oznámil kdy a na jak dlouho patrně nebudu doma. A s lidmi, kteří mají takový nápad to roztroubit do světa "učastním se akce a budou tak i tito další" jsem na FB udělal krátký proces. Akce se mají domlouvat pouze mezi účastníky a případné zveřejnění provést až po ukončení.
14.3. 15:20 oryctolagus | skóre: 29 | blog: Untitled
Rozbalit Rozbalit vše Re: Sociální sítě, reklama, komerce, spam, propaganda
A s lidmi, kteří mají takový nápad to roztroubit do světa "učastním se akce a budou tak i tito další" jsem na FB udělal krátký proces. Akce se mají domlouvat pouze mezi účastníky a případné zveřejnění provést až po ukončení.
Soukromou událost na FB vidí pouze ti pozvaní (což třeba v mém aktuálním případě dělá ~10 lidí) a nikdo jiný vůbec nevidí ani tu událost ani jestli se ji někdo účastní nebo ne ani nemají možnost ji "sdílet" nebo whatever, prostě se k tomu fakt dostanou jen ti pozvaní.
16.3. 12:43 snajpa | skóre: 20 | blog: snajpuv_blocek | Brno
Rozbalit Rozbalit vše Re: Sociální sítě, reklama, komerce, spam, propaganda
No, kdyz je na tom FB pekne podokumentovana, tak zas tak soukroma neni, ze jo.
--- vpsFree.cz --- Virtuální servery svobodně
16.3. 13:03 oryctolagus | skóre: 29 | blog: Untitled
Rozbalit Rozbalit vše Re: Sociální sítě, reklama, komerce, spam, propaganda
?

Jak se to liší od organizace události po e-mailu? Šance, že někdo z tvých kamarádů má gmail nebo něco podobného je hodně velká. Takže ten rozdíl je reálně akorát v tom, že na tom FB je to dokumentované u FB, zatímco po e-mailu to je dokumentované u Googlu, Seznamu a pár dalších firem.
16.3. 18:41 ehm
Rozbalit Rozbalit vše Re: Sociální sítě, reklama, komerce, spam, propaganda
Co ti brání ty zprávy šifrovat?
16.3. 23:36 oryctolagus | skóre: 29 | blog: Untitled
Rozbalit Rozbalit vše Re: Sociální sítě, reklama, komerce, spam, propaganda
Chci vidět mé ne-technické kamarády, jak šifrují e-mail ...
16.3. 23:45 ehm
Rozbalit Rozbalit vše Re: Sociální sítě, reklama, komerce, spam, propaganda
Nauč je to.
19.3. 14:18 oryctolagus | skóre: 29 | blog: Untitled
Rozbalit Rozbalit vše Re: Sociální sítě, reklama, komerce, spam, propaganda
Lol, tak určitě. Do toho by se nejspíš nechtělo ani těm technicky založeným. O ne-technických povahách nemluvě.
19.3. 17:44 ehm
Rozbalit Rozbalit vše Re: Sociální sítě, reklama, komerce, spam, propaganda
Pak je to možná zbytečně složité. Co řešit, jak to zjednodušit?
19.3. 19:06 snajpa | skóre: 20 | blog: snajpuv_blocek | Brno
Rozbalit Rozbalit vše Re: Sociální sítě, reklama, komerce, spam, propaganda
Slozity je predevsim key & trust management, to neni zvladnute dostatecne BFU-friendly, resp. nevidel jsem uspesny priklad.
--- vpsFree.cz --- Virtuální servery svobodně
13.3. 23:44 trekker.dk | skóre: 71
Rozbalit Rozbalit vše Re: Svoboda internetu, decentralizace vs. státní regulace
Sítě jako Facebook, Twitter či YouTube podle něj nedělají dostatečnou prevenci před šířením fake news, hate speech, harašení a propagandě na svých platformách.
Zajímavé, on existuje nějaký zákon, který by jim něco takového nařizoval? Jestli ono to nebude spíš "tady je něco, na co my politici nemáme takový vliv, jaký bychom chtěli"
Quando omni flunkus moritati
Heron avatar 14.3. 12:50 Heron | skóre: 51 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Svoboda internetu, decentralizace vs. státní regulace
Rovněž je důležitá anonymita/pseudonymita, protože pokud stát neví, která fyzická osoba to je, nemůže ji za nepohodlné názory potrestat.
S tou anonymitou bych to zase tak nepřeháněl, určitě ne hned v začátku. Podle mě je správné* podepsat své názory, stát (strašné slovo) si za tím, dokázat je obhájit slušným způsobem apod. Pokud je to anonymní výkřik, tak nemá zkrátka takovou váhu a navíc nikdy nevíš, zda to někdo neříkal z postranních důvodů.

Podle mě je místo pro anonymizaci skutečně až ve chvíli, kdy za názor hrozí kulka do hlavy. V takových režimech jsou anonymní nástroje jistě přínosem, pokud jsou ovšem používány pro pravdivé informování o stavu v takové společnosti nebo režimu. Ani tady příliš nepomůžou výkřiky, které nejsou pravdivé.

*) Jako jak jinak chceš budovat slušnou občanskou společnost, pokud budou všichni anonymní a Tonda nebude vědět, že stejné názory má i Karel odvedle, se kterým se na anonymních fórech vlastně shoduje? Prostě podle mého přesvědčení je potřeba anonymitu používat skutečně jen ve výjimečných případech a snažit se dostat do stavu, kdy už nebude potřeba.
xkucf03 avatar 14.3. 20:02 xkucf03 | skóre: 46 | blog: xkucf03
Rozbalit Rozbalit vše Anonymita, pseudonymita

Proto jsem psal anonymita/pseudonymita. Na to, abys podpořil nějaký názor autoritou svojí osoby, není potřeba, aby ostatní znali tvoji fyzickou identitu – stačí, aby si dokázali daný výrok/názor spojit s tvými dřívějšími projevy a dát si ho do kontextu. Naopak na tom internetu je mnohem užitečnější znát ten internetový pseudonym než znát občanské jméno a bydliště – např. komentář, který psal uživatel Heron pro mě má větší váhu než komentář, který psal např. Jan Zahradník z Frýdku-Místku registrovaný pod číslem 197611, který se nechal ověřit doporučeným dopisem a SMSkou a který o sobě vyžvanil i jméno babičky za svobodna a přiložil fotokopii vysvědčení ze základky.

Podpis beru jako součást projevu – stejně jako jazyk, styl nebo formu – a je na autorovi, jak a jestli se podepíše, jak moc propojí daný výrok se svojí internetovou nebo dokonce fyzickou identitou. A právo ostatních zase je, číst, co jim vyhovuje a přisuzovat tomu váhu i podle toho jak a kdo to podepsal – např. můžou zcela ignorovat anonymní příspěvky nebo příspěvky od neznámých pseudonymů. Různé druhy podpisu mají svoje výhody a nevýhody a nemyslím si, že by měla existovat nějaká obecná norma, jak se to má dělat.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
13.3. 22:45 ehm
Rozbalit Rozbalit vše Re: git, github, gitlab, kallithea, fossil, správa chyb/požadavků, wiki
pravděpodobnost, že ti někdo reportuje bug je na Githubu násobně vyšší než na nějakém self-hosted řešení
A není to spíš jeho problém? Založit ticket v self-hosted Bugzille nebo poslat bugreport mailem fakt není o moc složitější než založit issue na GitHubu. Pokud mu to nestojí za to, ať si klidně dál používá zabugovaný software, nebo najde nějakou alternativu. FOSS přece člověk píše zpravidla hlavně pro sebe a je jeho dobrou vůlí dávat to zdarma k dispozici ostatním. Ostatně, to elitářství, o kterém se zmiňuješ dál, je zcela na místě: Jak kvalitní bug report lze očekávat od člověka, co si neumí vyhledat/zjistit/přečíst, jak reportovat bugy, a obětovat tomu pár minut?

Osobně mě nejvíc děsí to, jak velká část FOSS světa je závislá na jediné službě. Ono není tak moc pravděpodobné, že by GitHub ze dne na den zmizel ze světa a dokonce by se dalo předpokládat, že projekt hostovaný na GitHubu bude (většinou) dostupný delší dobu než self-hosted projekt. Ale i tak by větší diverzifikace byla záhodná – tohle je prostě moc snadný cíl. Co by se stalo v případě nějakého většího výpadku? Spoustu menších projektů dnes nemá ani vlastní web, jen README hostované na GitHubu, což je obrovský problém. Mirrory mohou existovat, ale neexistuje žádný autoritativní zdroj, nikdo nebude schopen prokázat, že on je tím původním autorem daného projektu a tady ve vývoji pokračuje apod.

Kdyby se GitHub používal opravdu jen jako hosting pro git repozitáře, přičemž přechod na jinou službu by spočíval jen v nahrazení URL repozitáře na webu za jinou, tak bych s tím tak velký problém neměl. Otázkou pak je, proč něco takového dělat, když hostovat repozitář lze i na vlastním serveru, a to naprosto triviálně. Navíc lze vytvořit i soukromý repozitář, aniž by za něj bylo třeba platit (jako na GitHubu). A máš nad tím kompletní kontrolu ty, ne třetí strana, která se snaží tvářit, že je hodná, ale vždy se bude orientovat především na finanční zisk; a i kdyby ji zatím vlastnil nějaký moralistický idealista, vše se může změnit se změnou vlastníka.
xkucf03 avatar 13.3. 23:08 xkucf03 | skóre: 46 | blog: xkucf03
Rozbalit Rozbalit vše Re: git, github, gitlab, kallithea, fossil, správa chyb/požadavků, wiki

+1

Spoustu menších projektů dnes nemá ani vlastní web, jen README hostované na GitHubu, což je obrovský problém.

A teď si to spoj s tím, že státy dělají MITM útoky a podstrkávají uživatelům mallware. Pokud jediný kontakt na autora softwaru, který máš, je URL na GitHubu a nemáš ani otisky jeho GPG veřejných klíčů, tak vládě stačí zatlačit na jednu firmu a může uživatelům okamžitě distribuovat škodlivý software. Neříkám, že napadnout libovolného poskytovatele domén a hostingu nejde – jasně, že to jde, ale těch poskytovatelů jsou spousty, mají různou míru (ne)ochoty spolupracovat a různou míru odvahy dát o tom svinstvu vědět veřejnosti. Kdežto, když je všechno v jednom centru, u jednoho subjektu, tak to má útočník mnohem jednodušší a šance na odhalení se snižuje.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
13.3. 23:22 oryctolagus | skóre: 29 | blog: Untitled
Rozbalit Rozbalit vše Re: git, github, gitlab, kallithea, fossil, správa chyb/požadavků, wiki
Kolik lidí má tvůj GPG klíč a GPG klíče kolika vývojářů máš ty?
xkucf03 avatar 13.3. 23:28 xkucf03 | skóre: 46 | blog: xkucf03
Rozbalit Rozbalit vše Re: git, github, gitlab, kallithea, fossil, správa chyb/požadavků, wiki

Málo. Ale pointa byla v tom, že když je něco centralizované, je to snáze napadnutelné a snáze se dá útok utajit, než když by se útočník měl „dohodnout“ se spoustou malých subjektů – u nich je větší pravděpodobnost, že někdo z nich o útoku alespoň řekne veřejnosti.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
13.3. 23:35 oryctolagus | skóre: 29 | blog: Untitled
Rozbalit Rozbalit vše Re: git, github, gitlab, kallithea, fossil, správa chyb/požadavků, wiki
Pointě nerozumim. Resp. přijde mi zřejmá - to taknějak plyne přímo z definice (de)centralizovanosti.
xkucf03 avatar 13.3. 23:42 xkucf03 | skóre: 46 | blog: xkucf03
Rozbalit Rozbalit vše Re: git, github, gitlab, kallithea, fossil, správa chyb/požadavků, wiki

V té velké korporaci o tom může vědět třeba jen pár lidí – zatímco většina zaměstnanců vůbec nic netuší (pro ně to jsou jen nějaké automatizované procesy, uzly v síti nebo krabice v serverovně, kam nemají přístup – ale na tom není nic divného, protože v korporaci je spousta míst, kam nemají přístup). Kdežto v té malé firmě/organizaci o tom bude vědět taky jen pár lidí, ale tam těch „pár lidí“ = třeba polovina nebo i většina zaměstnanců. A v celkovém součtu je těch lidí spousta, protože malých firem/organizací bys musel napadnout mnohem víc než velkých korporací provozujících centralizované služby, abys dosáhl stejného výsledku.

Další věc je, že korporace má hodně co ztratit (např. se přijde na to, že jejich „daňové optimalizace“ jsou nelegální a je potřeba doplatit spoustu peněz, nebo nedostanou vládní zakázky, nebo se přijme nějaký zákon, který je poškodí…), zatímco malá firma toho tolik nemá (přinejhorším1 zkrachují a nechají se někde zaměstnat a taky se nebudou mít špatně) a naopak tam je šance něco získat – zviditelnit se na odhalení vládních zločinů, získat tím jméno a pak (resp. před tím) třeba prchnout za hranice.

[1] taky by mohlo dojít na fyzickou likvidaci – ale pokud by např. v nějaké zemi začali ve velkém umírat provozovatelé hostingu nebo by např. velké procento z nich „mělo nehodu“ tak by si toho veřejnost všimla

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
13.3. 23:52 oryctolagus | skóre: 29 | blog: Untitled
Rozbalit Rozbalit vše Re: git, github, gitlab, kallithea, fossil, správa chyb/požadavků, wiki
Pokud by mělo i plošný zásah (ne cílený na jeden SW), tak mi to na tom GitHubu nepřijde o nic méně nápadné, pokud by nešlo jen o pasivní sběr dat. Ale to je detail, hlavně ale moc nechápu, co tím chceš říct celkově.

Zkusim to jinak: Jestliže ti GitHub vadí, jaký bys navrhl postup pro docílení přelití té popularity z GitHubu na alternativní službu?
xkucf03 avatar 14.3. 00:04 xkucf03 | skóre: 46 | blog: xkucf03
Rozbalit Rozbalit vše Decentralizovaná vývojářská síť

Ona by to hlavně neměla být alternativní služba. Měla by to být vhodná svobodná implementace (v tomto případě verzovací systém + něco navíc), kterou si vývojářské týmy budou moci běžně provozovat na svých serverech. A k tomu nějaká federace identit (ať už SAML IdP nebo OpenID nebo ta tvoje identita může vycházet z tvého veřejného klíče) a pak nějaký standardizovaný formát, ve kterém bys mohl publikovat svůj profil – např. jsem přemýšlel o XML formátu, ve kterém bys mohl zveřejnit informace o sobě, kontakty, svoje úspěchy (odkazy na tebou nahlášené chyby, implementované funkce, opravy…), reference a hodnocení ostatních (např. oblíbené programy, vývojáři, od kterých ses něco naučil, přínosní uživatelé…). Každý by tenhle soubor zveřejnil na svém serveru nebo na serveru své komunity a celé by se to nějak indexovalo, ideálně P2P vyhledávačem (YaCy?).

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
14.3. 00:25 oryctolagus | skóre: 29 | blog: Untitled
Rozbalit Rozbalit vše Re: Decentralizovaná vývojářská síť
To vůbec neodpovídá na tu moji otázku ...

Krom toho, ty další služby, které zmiňuješ, jsou z hlediska používanosti v podstatě dost faily - Yacy, OpenID - přijde mi, že po nich neštěkne pes. Nerozumim, jak by to mělo pomoct.
13.3. 23:14 oryctolagus | skóre: 29 | blog: Untitled
Rozbalit Rozbalit vše Re: git, github, gitlab, kallithea, fossil, správa chyb/požadavků, wiki
Ostatně, to elitářství, o kterém se zmiňuješ dál, je zcela na místě: Jak kvalitní bug report lze očekávat od člověka, co si neumí vyhledat/zjistit/přečíst, jak reportovat bugy, a obětovat tomu pár minut?
O tomhle to právě vůbec není. Zrovna dnes jsem řešil bug ve foss programu, který tady nejspíš všichni znají. Řešil jsem to během pracovního dne. Mám toho na práci víc než dost a musim řešit spoustu vlastních problémů, takže to, že mají issues na GitHubu mi ohromě usnadňuje práci a šetří čas.

A platí zde něco podobného jako v reakci na tu Frantovu stížnost na cenzuru Facebooku: Stále mi přijde, že má větší užitnou hodnotu, když o nějakém bugu mám nekvalitní bugreport, než když ten bugreport vůbec nemám a o chybě nevím. Nehledě na to, že nikdo s tímto názorem zatím nepředložil důkaz, že bugreporty na self-hosted řešení jsou skutečně kvalitnější.
Osobně mě nejvíc děsí to, jak velká část FOSS světa je závislá na jediné službě. Ono není tak moc pravděpodobné, že by GitHub ze dne na den zmizel ze světa a dokonce by se dalo předpokládat, že projekt hostovaný na GitHubu bude (většinou) dostupný delší dobu než self-hosted projekt. Ale i tak by větší diverzifikace byla záhodná – tohle je prostě moc snadný cíl. Co by se stalo v případě nějakého většího výpadku? Spoustu menších projektů dnes nemá ani vlastní web, jen README hostované na GitHubu, což je obrovský problém. Mirrory mohou existovat, ale neexistuje žádný autoritativní zdroj, nikdo nebude schopen prokázat, že on je tím původním autorem daného projektu a tady ve vývoji pokračuje apod.
Podobný problém má asi tak každý balíčkovací manažer. Bez nějakého realistického nápadu, co s tím dělat, mi tohle připadá jako prázdná úvaha. Nějak nevidim, co z toho. Na teoretické rovině s tebou souhlasim. A co dál? Pravděpodobně nic, nejspíše budeme oba spokojeně nadále GitHub... Nebo snad ne?
14.3. 00:23 ehm
Rozbalit Rozbalit vše Re: git, github, gitlab, kallithea, fossil, správa chyb/požadavků, wiki
to, že mají issues na GitHubu mi ohromě usnadňuje práci a šetří čas
Kolik času ti to ušetřilo oproti self-hosted řešení za předpokladu, že by nebyla vyžadována registrace, samotné založení issue by bylo srovnatelně komfortní a efektivně by jediný rozdíl byl v jiné URL (na kterou by vedl odkaz přímo z hlavní stránky projektu, nebylo by to nikde schované)?
Stále mi přijde, že má větší užitnou hodnotu, když o nějakém bugu mám nekvalitní bugreport, než když ten bugreport vůbec nemám a o chybě nevím.
Nekvalitní bugreport může přidělat hodně práce. Mám s tím z práce bohaté zkušenosti (převážně z reportů od UIčkářů). Nedávno jsem se rozhodl, že už to prostě nebudu řešit, dokud nebude přiložen detailní popis, podle kterého to půjde zduplikovat (nebo nebude výslovně uvedeno, že není známo, jak to zduplikovat, protože se to projevuje jen občas).
Bez nějakého realistického nápadu, co s tím dělat, mi tohle připadá jako prázdná úvaha.
Vždyť je zřejmé, co s tím dělat. Mít vlastní web (stačí pro člověka, nemusí to být nutně pro každý projektík zvlášť) a repozitář si hostovat taky ideálně sám. Na bugreporty u úplně malých one-man-show projektů stačí kontaktní e-mail, u větších projektů mailing list a u ještě větších projektů třeba tu Bugzillu, JIRU nebo jakýkoliv jiný ticketovací systém, pod kterým se dají vést diskuze.
14.3. 00:34 oryctolagus | skóre: 29 | blog: Untitled
Rozbalit Rozbalit vše Re: git, github, gitlab, kallithea, fossil, správa chyb/požadavků, wiki
Kolik času ti to ušetřilo oproti self-hosted řešení za předpokladu, že by nebyla vyžadována registrace, samotné založení issue by bylo srovnatelně komfortní a efektivně by jediný rozdíl byl v jiné URL (na kterou by vedl odkaz přímo z hlavní stránky projektu, nebylo by to nikde schované)?
Ten rozdíl efektivně pouze v URL nikdy nebude např. z toho důvodu, že na GitHubu mi přijdou notifikace o tom, že majitej repa mi odpověděl na můj bugreport (což se o hodinu později stalo). (Vyplnění emailu za účelem notifikace někomu na nějakej server se efektivně rovná registraci a nechce se mi to moc dělat.)
Vždyť je zřejmé, co s tím dělat. Mít vlastní web (stačí pro člověka, nemusí to být nutně pro každý projektík zvlášť) a repozitář si hostovat taky ideálně sám. Na bugreporty u úplně malých one-man-show projektů stačí kontaktní e-mail, u větších projektů mailing list a u ještě větších projektů třeba tu Bugzillu, JIRU nebo jakýkoliv jiný ticketovací systém, pod kterým se dají vést diskuze.
Zcela upřímně, kdyby ten projekt to měl nasazeno takhle nějak, tak jim tam dnes ten bugreport nejspíše nepošlu. Můžeš mě zažalovat nebo se pohoršovat nad tím, jak jsem hroznej a linej a kdesi cosi ... Ale to je tak celý.

Plus navíc ten projekt by musel vynakládat úsilí a finance na udržování toho setupu, a přitom GitHub poskytně lepší hodnotu za mnohem menší námahu a peníze. Opět máš možnost se pohoršovat dosytosti. A opět to na praktické stránce věci nezmění vůbec nic.
xkucf03 avatar 14.3. 00:46 xkucf03 | skóre: 46 | blog: xkucf03
Rozbalit Rozbalit vše Re: git, github, gitlab, kallithea, fossil, správa chyb/požadavků, wiki
Vyplnění emailu za účelem notifikace někomu na nějakej server se efektivně rovná registraci a nechce se mi to moc dělat.

Osobně k tomu používám jednoúčelové e-mailové adresy na vlastní doméně – jedna adresa slouží ke komunikaci jen s jedním subjektem a kdyby došlo např. ke spamování, můžu ji okamžitě zaříznout. Dá se to i automatizovat – e-mailové aliasy se můžou vytvářet dynamicky resp. nemusí být ani nikde uložené – jen popsané algoritmem – např. doménaDruhéStrany + "." + hash(tajnýKód, doménaDruhéStrany) + "@x.moje-doména.example.com". A ten tajnýKód můžeš mít i v nějaké své aplikaci, takže pro přidání resp. vygenerování nového e-mailového aliasu ani nemusíš komunikovat se svým serverem (ten jen na základě algoritmu a sdíleného tajemství ověří, že daný alias je platný). Pokud by náhodou došlo k vyzrazení klíče, uděláš z dosud použitých aliasů (na které přišel nějaký e-mail) klasické uložené aliasy a nové začneš vydávat na základě nového klíče.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
14.3. 08:56 oryctolagus | skóre: 29 | blog: Untitled
Rozbalit Rozbalit vše Re: git, github, gitlab, kallithea, fossil, správa chyb/požadavků, wiki
Ty máš asi ten overengineering opravdu hodně v oblibě :-D Jak už jsem psal, ten projekt používá GitHub, takže nic takového jsem nemusel řešit. Jinak na tohle existuje mailinator (pozor: Hnusně centralizovaná proprietární služba).
xkucf03 avatar 14.3. 19:43 xkucf03 | skóre: 46 | blog: xkucf03
Rozbalit Rozbalit vše Re: git, github, gitlab, kallithea, fossil, správa chyb/požadavků, wiki

Mailinator nebo podobné služby taky občas používám, ale to je jiný případ. To, co jsem popisoval, slouží ke spolehlivému doručování zpráv (třeba i za několik let, kdy už ta anonymní služba nemusí ani existovat), které nemají být veřejné (v rámci možností e-mailu). Cílem je, abych mohl sledovat, jak ostatní nakládají s mými osobními údaji a abych mohl snadno zablokovat případný spam.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
14.3. 00:50 ehm
Rozbalit Rozbalit vše Re: git, github, gitlab, kallithea, fossil, správa chyb/požadavků, wiki
Koukám, že je to s FOSS ještě horší než jsem si myslel. Ostatně, delší dobu si lámu hlavu, proč se vlastně vůbec obtěžovat svoje projekty dávat k dispozici ostatním.
14.3. 08:58 oryctolagus | skóre: 29 | blog: Untitled
Rozbalit Rozbalit vše Re: git, github, gitlab, kallithea, fossil, správa chyb/požadavků, wiki
Hele úplně příšerný to je, totálně hrozný. Dekadence, úpadek, liný lidi používající ten strašný GitHub, atd. Prostě fakt hrůza. Nemá to vůbec cenu, nejlepší se na foss úplně vykašlat.

(Dobrý, tak jsem se pohoršili, teď ještě splnit část 2: nezměnit nic praktického. Myslimže to taky nebude těžký, věřim, že to dáme.)
14.3. 20:57 ehm
Rozbalit Rozbalit vše Re: git, github, gitlab, kallithea, fossil, správa chyb/požadavků, wiki
Mám několik menších projektů, které bych mohl zveřejnit. Je to pro mě extra práce, protože to jsou často bastly dělané na míru pro mě. Ve stávajícím stavu se mi to moc nechce zveřejňovat – cítil bych silné nutkání projít a začistit zdrojový kód (možná to i celé zrefactorovat), doplnit dokumentaci, pořádně to dootestovat a podobně.

Co z toho budu mít? Mohl bych si budovat jméno. Taky bych z toho mohl mít dobrý pocit. Co tam je dál? Teoreticky by mi někdo mohl s tím vývojem pomoci (alespoň třeba tou formou reportování bugů), ale to se u tak malých projektů, o kterých se bavíme, spíš nestane. Navíc ty sám připouštíš, že kdybys měl bug reportovat někam jinam než na GitHub, tak bys to vzdal. To je docela nepříjemné slyšet od člověka, kterého zrovna považuji za docela schopného a od něhož bych právě čekal opak.

Takže to mám v lokálním repozitáři a pokud už to někam pushuji, je to vlastní soukromý repozitář na mém serveru. Na jednu stranu mám chuť se o to podělit, ale na druhou stranu mi to přijde jako práce a zodpovědnost navíc, která není skoro ničím kompenzována. Nějaké částečné řešení se mi v hlavě rýsuje, ale to sem psát nechci.
15.3. 06:46 Want
Rozbalit Rozbalit vše Re: git, github, gitlab, kallithea, fossil, správa chyb/požadavků, wiki
Pokud vím, tak u projektů na kterých má participovat víc lidí využívají pro tento účel Redmine.
15.3. 08:45 oryctolagus | skóre: 29 | blog: Untitled
Rozbalit Rozbalit vše Re: git, github, gitlab, kallithea, fossil, správa chyb/požadavků, wiki
Mám několik menších projektů, které bych mohl zveřejnit. Je to pro mě extra práce, protože to jsou často bastly dělané na míru pro mě. Ve stávajícím stavu se mi to moc nechce zveřejňovat – cítil bych silné nutkání projít a začistit zdrojový kód (možná to i celé zrefactorovat), doplnit dokumentaci, pořádně to dootestovat a podobně.
Taky mám všelijaké takové, spíš většinou šuplíkové napůl nedokončené projekty ... Asi ti k tomu nic moc moudrého neporadim, záleží případ od případu a jak moc se ti chce / nechce to zveřejňovat.

Ale v každém případě bych to nebral moc vážně. Když se podíváš, co jsou dnes lidi schopní zveřejnit za "projekty" - třeba JavaScriptové knihovny, které mají logo, baterii integračních testů a dokumentaci, to všechno jen kvůli třeba 50 řádkám reálného kódu* ... to pak zjistíš, že seš nejspíš úplně v pohodě i s nerefaktorovaným kódem.

*) Něldy ani to ne, viz třeba tady.
Navíc ty sám připouštíš, že kdybys měl bug reportovat někam jinam než na GitHub, tak bys to vzdal.
To zas ne. Tam šlo o ten kontext - byl jsem uprostřed pracovního dne, byl rozbitý build, potřeboval jsem rychle vyřešit problémy... Ve chvílích, kdy je víc klid a mam víc času jsem ochoten reportovat i jinam ;-)
13.3. 08:30 little-drunk-jesus | skóre: 14
Rozbalit Rozbalit vše Re: git, github, gitlab, kallithea, fossil, správa chyb/požadavků, wiki
Mne se na male nasazeni osvedcil gogs. Sice nema tolik features, ale je to snadno nasaditelne i updaty jsou vetsinou bezproblemove, umi bezet i nad SQLite, tzn pro domaci pouziti mi to prijde fajn.
Josef Kufner avatar 13.3. 12:20 Josef Kufner | skóre: 68
Rozbalit Rozbalit vše Re: git, github, gitlab, kallithea, fossil, správa chyb/požadavků, wiki
Je jen škoda, že Gogs nemá integrované CI, jako má Gitlab.
Hello world ! Segmentation fault (core dumped)
12.3. 13:20 Helb
Rozbalit Rozbalit vše Re: git - popis vývojové větve
Větve se mají jmenovat podle čísla issue, cokoliv jiného je anarchistický nesmysl
13.3. 16:19 lzap
Rozbalit Rozbalit vše Re: git - popis vývojové větve
Kdepak, nějaké heslo a až zatím číslo issue/BZ. Mám 400 větví na hlavním projektu, čísla si nezapamatuju, ale např. subnet-workaround-26344 nebo rename-sha1-27645 již ano.

Napsal jsem dokonce tool na čištění větví, ovšem ho nepoužívám :-)

https://github.com/lzap/git-xcleaner
Josef Kufner avatar 13.3. 16:59 Josef Kufner | skóre: 68
Rozbalit Rozbalit vše Re: git - popis vývojové větve
Setkal jsem se spíš s opačným přístupem: 26344-subnet-workaround, 27645-rename-sha1.
Hello world ! Segmentation fault (core dumped)
xkucf03 avatar 13.3. 20:35 xkucf03 | skóre: 46 | blog: xkucf03
Rozbalit Rozbalit vše Re: git - popis vývojové větve

To je takové systematičtější, ale je fakt, že pokud to má psát člověk z hlavy, tak si spíš vzpomene na to slovo a zbytek doplní mu bash completion.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
12.3. 23:14 ehm
Rozbalit Rozbalit vše Re: git - popis vývojové větve
Pokud vytvoříš jeden nic neříkající commit (jak jsi to sám nazval) a pak se nedokážeš v těch změnách vyznat, používáš git špatně. Smysl větve má být patrný z jejího názvu, podstata změn pak z commitů.
Marián Kyral avatar 13.3. 07:28 Marián Kyral | skóre: 29 | blog: Sem_Tam | Frýdek-Místek
Rozbalit Rozbalit vše Re: git - popis vývojové větve
Navíc není problém ty parciální commity před mergem do hlavní větve sloučit do jednoho.
13.3. 07:47 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: git - popis vývojové větve
Ne vždy je to ale žádoucí. Pokud jsou to jen "denní přírůstky", tak to smysl dává, ale pokud commity odrážejí nějaké logické členění, tak je lepší nechat je zvlášť. Často to dělám dokonce opačně: v první fázi vývoje nějaké featury má topic branch jen jeden "WiP" commit, který pak pomoci "git gui" rozdělím na jednotlivé commity (které lze pak ještě dodatečně upravovat pomocí "git rebase -i").
13.3. 08:01 oryctolagus | skóre: 29 | blog: Untitled
Rozbalit Rozbalit vše Re: git - popis vývojové větve
Osobně to mam obvykle tak, že do vývojové větvě dávám WIP commity jeden za druhým a pak to stlačím na zhruba 1/5 ~ 1/4 původního počtu.

Je ale pravda, že větší počet commitů se hůř rebasuje, může se stát, že v jednom commitu člověk řeší konflikty jen proto, aby v následujícím úplně zmizely ...

No nicméně zpětně rozdělovat jeden WIP commit na více dílčích a tím víceméně psát fiktivní historii mi nepřijde úplně smysluplný ...
13.3. 08:31 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: git - popis vývojové větve
Je ale pravda, že větší počet commitů se hůř rebasuje, může se stát, že v jednom commitu člověk řeší konflikty jen proto, aby v následujícím úplně zmizely ...

To se sice stát může, ale až tak časté to není. Osobně radši dělám rebase série s jemnější granularitou, protože když na mne vypadne spousta konfliktů najednou, působí to na mne trochu depresivně a demotivačně. Navíc v rámci malého commitu řešícího jednoduchou izolovanou změnu je pro mne snazší udržet si přehled. Ale asi je to věc vkusu.

zpětně rozdělovat jeden WIP commit na více dílčích a tím víceméně psát fiktivní historii mi nepřijde úplně smysluplný

Nemyslel jsem tím fiktivní historii, ale rozdělení jedno monstercommitu na více logicky oddělených změn. Příklad viz třeba tady série ba3eb1a44b12..9fb1a27800d0 (normálně mívám commit message sdílnější, ale snažil jsem se přizpůsobit zvyklostem projektu). Sice by se to dalo sloučit do jednoho commitu "add IPv6 support", ale jsem přesvědčen, že takhle rozdělené je to mnohem přehlednější.

13.3. 10:27 dementni.lojzik | skóre: 19 | blog: ze zivota na vsi
Rozbalit Rozbalit vše Re: git - popis vývojové větve
Navíc v rámci malého commitu řešícího jednoduchou izolovanou změnu je pro mne snazší udržet si přehled. Ale asi je to věc vkusu.
no nevim, jestli jen vkusu. Me velke commity prijdou dost spatne z toho duvodu, ze delat review pull requestu, kde se meni kod treba ve 200 souborech (a uz jsem videl i horsi) je peklo a sance, ze se neco prehledne je podstatne vetsi, nez kdyz je to cleneno do mensich commitu. A i pokud je ten, kdo dela review je natolik schopny se koncentrovat, ze mu mu zadna chybu neunikne, tak tim urcite stravi o dost vic casu. Dalsi vec je, ze pokud se delaji backporty treba do nejake LTS vetve, tak se obcast stava, ze v ramci vyvoje nove funkcionality je upravena nejaka stavajici, kde se casem ukaze, ze tato jeji uprava je potreba backportovat. Udelat cherry-pick daneho commitu je bezpochyby mnohem jednodussi nez to dolovat z obrovskeho commitu. Takze IMHO clenit commity podle (pokud mozno malych) ucelenych logickych celku je vyhodnejsi jak kvuli mensi nachylnosti k chybam, tak celkove snadnejsi udrzovaletnosti kodu.
13.3. 10:35 SazeVaclav
Rozbalit Rozbalit vše Re: git - popis vývojové větve
kde se meni kod treba ve 200 souborech
a ten, kdo to cele navrhoval, sef projektu a vsichni ti ostatni, co jsou zodpovedni za tu architekturu takoveho software - ti dostanou vypoved na hodinu a nebo smeji zustat celou vypovedni dobu?
13.3. 12:53 dementni.lojzik | skóre: 19 | blog: ze zivota na vsi
Rozbalit Rozbalit vše Re: git - popis vývojové větve
U open source projektu se obvykle nikdo nevyhazuje. Nicmene tito lide obvykle zustavaji mnoho let, nez je preplati nejaka firma, aby sli delat pro ne nebo nez jim prace na nejakem jinem projektu prijde zajimevejsi nez to, na cem poslednich par let delali.
Jinak to, ze se v ramci nejake zmeny meni kod ve 200 souborech neznamena, ze je project spatne navrzeny a stejne tak, i kdyz je (typicky z historickych duvodu) projekt spatne navrzeny, to nijak neimplikuje, ze hlavni vyvojar/architekt je neschopny retard, co by mel byt urychlene nahrazen nekym jinym.
26.3. 15:14 Kit
Rozbalit Rozbalit vše Re: git - popis vývojové větve
Pokud nějaké individuum přejmenuje metodu v rozhraní a nechá v IDE přejmenovat všechny výskyty, tak to skutečně postihne i víc než 200 souborů naráz.
13.3. 10:46 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: git - popis vývojové větve
Výraz "věc vkusu" jsem použil čistě v kontextu toho, co je praktičtější pro rebase lokální pracovní větve, kteřá je ještě "work in progress". Jakmile jde o hotovou verzi, která se má stát součástí historie ve sdíleném repozitáři, tam už podle mne megacommity nemají co dělat (s výjimkou nějakých tree-wide změn generovaných např. coccinelle - ale ani pak nemíchat nesouvisející změny).
13.3. 08:05 oryctolagus | skóre: 29 | blog: Untitled
Rozbalit Rozbalit vše Re: git - popis vývojové větve
Taky to na mě působí jako ne úplně správné použití gitu. Pokud ti tam vzniká větší množství větví s nedokončenou prací, u kterých už si ani podle šítku napamatuješ, co to bylo, tak bude asi něco špatně s workflow / způsobem vývoje té věci...
13.3. 08:45 Aleš Kapica | skóre: 47 | blog: kenyho_stesky | Ostrava
Rozbalit Rozbalit vše Re: git - popis vývojové větve
To je zajímavé kolik z vás tady má křišťálovou kouli.

Já jsem nepsal že mám větší množství větví s nedokončenou prací, ale že mám problém si po nějakém čase rozpomenout, proč jsem vlastně nějakou tu větev vytvořil. Což nesouvisí ani se jménem, ani s počtem větví.

V git adresáři cca 164 git repozitářů a zdaleka ne do všech se to týká. Většinu z nich mám jen k tomu abych se čas od času podíval na aktuální změny.

Pokud se týče správnosti použití gitu - nezdá se vám, že je to tak trošku moje věc, kdy, kde a nač ho nasazuji? Jen tak pro zajímavost - kolik z vás si hlídá jeho prostřednictvím změny konfigurace?
13.3. 10:39 oryctolagus | skóre: 29 | blog: Untitled
Rozbalit Rozbalit vše Re: git - popis vývojové větve
Ok, možná jsem to z toho špatně pochopil.
ale že mám problém si po nějakém čase rozpomenout, proč jsem vlastně nějakou tu větev vytvořil
Jaký je tvůj usecase pro větvě, které nejsou master, ale existují dlouhodobě? Osobně když vytvořim větev, předpokládám u ní pokudmožno krátkou dobu trvání. V podstatě čím kratší, tím lépe. Případně si umím představit něco jako master + dev nebo master + stable nebo něco takového, některé projekty to tak mají.

Náhodné / ad-hoc větve, které ale existují dlouhodobě, mi čistě osobně a subjektivně nepřijdou jako dobrý nápad. Je to jenom moje 0.2$, můžeš samozřejmě neoushlasit a dělat si s gitem co chceš...
Jen tak pro zajímavost - kolik z vás si hlídá jeho prostřednictvím změny konfigurace?
V gitu mývám všechno možné...
13.3. 10:58 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: git - popis vývojové větve

Vždy se najdou výjimky. Já mám třeba v gitu spoustu větví, které přidávají nějaký specifický tracing určený pro konkrétní bug. Ty se hodí zachovat, protože později můžu chtít použít podobný nebo dokonce stejný patch a nemusím ho tak psát znovu.

No a potom existují hodně specifické repozitáře jako např. tehnle, kde se vlastně všechno zajímavé odehrává mimo master branch.

13.3. 13:14 Aleš Kapica | skóre: 47 | blog: kenyho_stesky | Ostrava
Rozbalit Rozbalit vše Re: git - popis vývojové větve
Tak s větvemi pracuji trochu více především u wiki. Je to dané tím, že vycházejí z verzí a jsou na ně navázaná některá z rozšíření. Pro takový případ je třeba mít situaci ošetřenou tak, abych se mohl rychle vrátit k funkčnímu řešení.

Ve většině případů se obejdu i bez těch popisů. Ovšem teď jsem začal dělat na věci, kterou autor sice spravuje v gitu ale moc nepoužívá větve. Navíc se jeho představa o celkové koncepci poněkud liší od té mojí. Takže něco z toho co jsem mu poslal sice využil, ale některé základní komponenty potřebuji napsat úplně jinak než jak je má napsané teď. Mám tak svoji vývojovou větev, jeho hlavní větev. Větev ve které mám sloučené změny. A větev ze které mohu generovat patch, co pak může on aplikovat na svoji větev, aniž by si tím něco rozbil.
Josef Kufner avatar 13.3. 12:27 Josef Kufner | skóre: 68
Rozbalit Rozbalit vše Re: git - popis vývojové větve
Já jsem nepsal že mám větší množství větví s nedokončenou prací, ale že mám problém si po nějakém čase rozpomenout, proč jsem vlastně nějakou tu větev vytvořil. Což nesouvisí ani se jménem, ani s počtem větví.
A co ti brání takovou větev prostě zahodit? Zjevně už není potřeba. (Leda by na ni vedl odkaz z nějakého úkolovníčku, ale to by začínala číslem issue.)
Hello world ! Segmentation fault (core dumped)
13.3. 17:45 trekker.dk | skóre: 71
Rozbalit Rozbalit vše Re: git - popis vývojové větve
Přesně, pokud si už nepamatuju, k čemu je to dobré, nejspíš už to k ničemu není :-)
Quando omni flunkus moritati
14.3. 17:55 ehm
Rozbalit Rozbalit vše Re: git - popis vývojové větve
Samozřejmě můžeš používat sekyru na zatloukání hřebíků, ale nemůžeš se divit, že pak budeš potřebovat ochrané pouzdro na čepel, aby sis při nápřahu nerozsekl čelo; a stejně to nebude tak dobré jako kladivo.
14.3. 19:21 Aleš Kapica | skóre: 47 | blog: kenyho_stesky | Ostrava
Rozbalit Rozbalit vše Re: git - popis vývojové větve
Kdo se při zatloukání hřebíků sekyrou tne do čela, je podle mě lopata, které nepatří do ruky ani kladivo.
14.3. 19:44 ehm
Rozbalit Rozbalit vše Re: git - popis vývojové větve
A podle mě jsi lopata ty, když se nedokážeš orientovat ve změnách, které máš ve verzovacím systému, a obcházíš to nějakým dodatečným popiskem k větvi. A dobrovolně tou lopatou jsi dál, protože ti ješitnost a arogance nedovolí připustit, že profesionální programátoři, kteří ti tu zkouší poradit, možná mají pravdu.
15.3. 00:39 trekker.dk | skóre: 71
Rozbalit Rozbalit vše Re: git - popis vývojové větve
Nicméně pravda je, že pokud se někdo sekne do čela, když sekerou zatlouká hřebíky a nemá na ní přitom ochranné pouzdro, tak mu to patří.
Quando omni flunkus moritati
15.3. 06:43 Want
Rozbalit Rozbalit vše Re: git - popis vývojové větve
Evidentně jsi nepochopil, že tenhle blogpost není dotaz v poradně, ale omáčka k informaci o tom, za jakých okolností se může hodit dodatečný popis u lokální větve git repozitáře.
15.3. 08:06 ehm
Rozbalit Rozbalit vše Re: git - popis vývojové větve
Ale ten důvod není validní.
15.3. 08:20 Aleš Kapica | skóre: 47 | blog: kenyho_stesky | Ostrava
Rozbalit Rozbalit vše Re: git - popis vývojové větve
Jaký "důvod"?
15.3. 08:41 Aleš Kapica | skóre: 47 | blog: kenyho_stesky | Ostrava
Rozbalit Rozbalit vše Re: git - popis vývojové větve
Považuji za totální úlet řešit validitu, neboli platnost "důvodu", který vyvozuješ na základě popsané skutečnosti (faktu). Jednak těch příčin (důvodů) je celá řada, a druhak ti mohou být zcela ukradené, stejně jako ostatním diskutujícím, protože jsou moje.

Pokud jsi cítil v této diskuzi nutkání někoho poučit, fajn. Někdo si toho možná všimne a třeba mu to bude i ku prospěchu. Ovšem ti co znají své limity nad tím akorát s lehkým úsměvem pokývou hlavou. Protože každý používá nástroje co má k dispozici jak nejlépe umí a ne tak jak si představuje někdo jiný.
15.3. 08:47 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: git - popis vývojové větve
Najdou se ovšem i takoví, kteří jsou ochotni nad radami druhých zamyslet a občas některé třeba i do svého workflow přejmout.
15.3. 09:56 Aleš Kapica | skóre: 47 | blog: kenyho_stesky | Ostrava
Rozbalit Rozbalit vše Re: git - popis vývojové větve
Někdo si toho možná všimne a třeba mu to bude i ku prospěchu.
Ovšem to asi nebude případ těch, co nevšimli ani toho, že jsem se o nich zmínil.

Ruku na srdce - diskuze na abclinuxu jsou sice zdrojem zajímavých podnětů, ale nevěřím tomu, že by měly pozitivní vliv na způsob práce diskutérů. Jeden vedle druhého tady píše jak to dělá on, a jak je to podle něj správné, aniž by vůbec brali v potaz, že jejich specifické workflow těm ostatním vyhovovat nemusí.

Spolupráce na projektu je podmíněna tím, že se v prvé řadě stanoví jak takové workflow bude vypadat, důsledně se pak dodržuje a nově příchozí ho pak buď akceptuje (a k projektu se přidá) nebo si udělá fork a nastaví si vlastní workflow pravidla.

A právě v situaci, kdy chci zkombinovat věci které mají různá workflow do jednoho projektu, se může hodit onen lokální popis.

Jinak ta diskuze je téměř od samého počátku mimo mísu. Relevantní byla tak maximálně poznámka, že k přepnutí větve s rozdělanou prací lze použít příkaz stash. Následující dohady, jestli používat gihub, nebo něco jiného. Nebo jak si pojmenovávat větve. Jsou už na úrovni hospodského dohadování. A tomu také odpovídají i moje reakce v tomto vlákně.
15.3. 13:57 trekker.dk | skóre: 71
Rozbalit Rozbalit vše Re: git - popis vývojové větve
Ruku na srdce - diskuze na abclinuxu jsou sice zdrojem zajímavých podnětů, ale nevěřím tomu, že by měly pozitivní vliv na způsob práce diskutérů. Jeden vedle druhého tady píše jak to dělá on, a jak je to podle něj správné, aniž by vůbec brali v potaz, že jejich specifické workflow těm ostatním vyhovovat nemusí.

Podle sebe soudím tebe...
Quando omni flunkus moritati
15.3. 15:52 Aleš Kapica | skóre: 47 | blog: kenyho_stesky | Ostrava
Rozbalit Rozbalit vše Re: git - popis vývojové větve
V takovém případě mi tedy musíš dát za pravdu.
15.3. 20:40 ehm
Rozbalit Rozbalit vše Re: git - popis vývojové větve
Faktem je, že jsi měl problém, nikoliv, že bylo vhodné ten problém řešit dodatečným popiskem k větvi.
15.3. 23:00 Aleš Kapica | skóre: 47 | blog: kenyho_stesky | Ostrava
Rozbalit Rozbalit vše Re: git - popis vývojové větve
Sorry, ale ta věta je poněkud zmatená. Měl jsem několik větví, vytvořených z různých stádií kódu, který psal někdo jiný, v každé fungovalo něco a tak mě napadlo, že určitě existuje možnost si ty větve popsat podrobněji. A protože mi to přišlo jako docela zajímavá a užitečná funkcionalita o které se moc nemluví, sepsal jsem tenhle blogpost. Takže pokud jsem měl podle vás problém, tak podobných řeším denně tucty, aniž bych měl o tom potřebu psát.
16.3. 00:16 ehm
Rozbalit Rozbalit vše Re: git - popis vývojové větve
Nikdo ti nevyčítá, že jsi napsal blogpost. Zajímavá věc to je, užitečné to může být taky. Jen se to mně a pár dalším lidem nezdá jako nejvhodnější řešení toho problému, který jsi tam naznačil. To je celé. Nemá smysl do každého komentáře cpát slovní vatu jen proto, aby se náhodou někdo nerozhodl nechat se tím urazit („Neznám celý kontext, ale podle toho, jak si to v blogu formuloval, to vypadá, že git nepoužíváš úplně správně (ve smyslu toho, jak byl navržen, a jak je zpravidla používán nejefektivněji). Neber to prosím zle, můžeš jej samozřejmě používat jakkoliv uznáš za vhodné (a sám také, bohužel, dělám spoustu věcí neefektivně), ale možná by bylo lepší zkusit ... blá blá blá“). To je patetické, hloupé, zbytečné a bezpředmětné.

Založit nové vláknoNahoru

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.