MPlayer 1.0-rc4?

MPlayer

Ember nincs, aki érti vagy követni tudja, hogy mikor, miért hányas verziónál tart az MPlayer fejlesztése. Valószínűleg köszönhető ez a fejlesztői csapat kifinomult (értsd: gyakorlatilag nem létező) kommunikációjának is. Mindenesetre - bejelentés és levelezési lista nyomok hiányában - úgy tippelem, hogy megérkezett az MPlayer 1.0 negyedik kiadásra jelölt verziója. Vagy valami, ami ilyen néven napok óta elérhető a projekt FTP szerverén. Az MPlayer 1.0-rc4 letölthető innen.

( nanto | 2011. 01. 30., v – 13:44 )

Mar az elozot (RC3) sem veletlen hivtak "Godot has arrived"-nak. Amig mukodik a vdpau-val/vaapival es a gites snapshotot csomagoljak a disztributorok, addig nincs is ezzel baj.

En igy szeretem az mplayert, ahogy van: rendes verzioszamozas nelkul (ennel csak a Chrome/chromium fejlesztesi projektmenedzsmentjevel ertek jobban egyet)

nem is az a lenyeg, hanem hogy 3 szalat fejlesztenek parhuzamosan:
-whole new feature csak a dev-channelbe (stable+2)
-nagyobb lepteku bugfix, funkcio javiotas a beta channelbe is (stable+1)
-biztonsagi hibak javitasa, kisebb bugfixek pedig a stable-be is

Es a stable valtozo erteket emelik 6 hetente, igy nincs az, mint pl. a KDE-nel, hogy kitalaltal valamit, de a 4.6 trunkja mar be van fagyasztva uj feature-okhoz, de a 4.7-é meg meg nincs megnyitva (tudom mostmar megvan)

Mplayernel meg megint mas van: (fixme) ellenorzik a git kommitokat 1-2 napig amennyire en tudom, es a "release"-ben (legutobb rc3) pedig kiteszteltetik a snapshotban egyebkent instabilitas miatt kikapcsolt funkciokat, a userekkel (bug report, esetleg patchkuldes). Mondhatjuk, hogy ott tulajdonkeppen a release az unstable/testing. Hatranya, hogy ez valahol a kevesbe figyelmes userek atvagasa, elonye, hogy itt is barmikor tudsz uj feature-t commitolni (ami ha rakas szar, kilovik, hogy stabil maradjon a snapshot)

( arpi_esp v | 2011. 01. 30., v – 15:14 )

nekem ez a kedvencem a changelog-bol:
- Changes towards removing the GUI
- The GUI will no longer display any error or warning messages.

:)

A'rpi

( arpi_esp v | 2011. 01. 30., v – 15:21 )

> Ember nincs, aki érti vagy követni tudja, hogy mikor, miért hányas verziónál tart az MPlayer fejlesztése.

dehogynincs.
mikor: amikor eszebe jut valakinek. mivel fejlesztes (az mplayer kodjaban) gyakorlatilag nincs, igy vegulis tok mind1 mikor adnak ki rls-t...
miert hanyas: en anno azt irtam/mondtam, hogy akkor lesz v1.0 ha kesz lesz. na marmost kesz nincs, tehat 1.0 nem lehet, viszont volt mar 1.0rc1 igy a 2 koze kellett beloniuk valamit :)

> Valószínűleg köszönhető ez a fejlesztői csapat kifinomult (értsd: gyakorlatilag nem létező) kommunikációjának is.

van kommunikacio, csak miota diego & co atvette a hatalmat, semmi sem publikus, mert a vegen meg kiderulne hogy 1. mennyire nem ertenek hozza 2. meg valaki ertelmes hozzaszolna
mostanaba az #evil_overlord @ irc.freenode a torzshelyuk itt szovogetik "forradalmi" terveiket...
be lehet lepni, de aki nem a szuk barati tarsasaguk tagja azt ugyis egybol bannoljak...

A'rpi

man mplayer egy Linuxos/BSD-s gepen midnent elarul. Csupan a parancssori kapcsolokkal es az ott leirt hotkeyekkel tonnanyi olyan funkcio elohozhato, amirol VLC-t hasznalva almodni sem mernek.

pl. 2cd-s filmreleasehez 1cd-s feliratom volt, a megoldast 20 sec alatt megtalaltam (man mplayer):
mplayer -subdelay [CD1 hossza (ezt kezzel neztem ki O betu, mint OSD-rol)] film-cd2.avi
(es nyilvan az srt-t is atnevezetem, hogy a cd1-hez meg cd2-hoz is az nyiljon meg)

Vagy mkv-n meg DVD-n altgr+X (#) gombbal hangot valtok, v-vel eltuntetem a feliratot, azok is hasznosak.

Egyszoval: nagyon sajnalom, hogy ez lett a sorsa a vilag legjobb lejatszojanak

Mintha vlc-ben nem lehetne feliratot késleltetni, akár hotkeyekkel. Ugyanígy van hotkey hangsáv váltásra és feliratsáv váltásra (beleértve ezek letiltását).

Biztos vagyok benne, hogy az mplayer okosabb, de talán olyan funkciókat kellene előbb találni amit a vlc tényleg nem tud. :)

--
Don't be an Ubuntard!

mplayer -subdelay <num> <-> vlc --sub-delay=<num>

Hotkeyek:
felirat késleltetés csökkentése: g, növelése: h
hangsáv váltása: b
feliratsáv váltása: v

Guiban:
felirat késleltetés: Eszközök -> Sávszinkronizálás ablakban
hangsáv váltása: Hang -> Hangsáv
feliratsáv váltása: Videó -> Feliratsáv

--
Don't be an Ubuntard!

szep, hogy van ilyen, de ezt miert nem talalom se a --helpben, se a manpageben? (plane 20 sec alatt)

[nanto@myhost ~]$ man vlc | grep sub
[nanto@myhost ~]$ vlc --help | grep sub
VLC media player 1.1.6 The Luggage (revision exported)
--sub-file Use subtitle file
--sub-autodetect-file, --no-sub-autodetect-file
Autodetect subtitle files (default enabled)
--sub-filter Subpictures filter module
--sub-language Subtitle language
--key-subtitle-track
Cycle subtitle track
--global-key-subtitle-track
Cycle subtitle track
[nanto@myhost ~]$

Ez ugyan teljesen off, de miért is nem azt a logikusabb megoldást választottad, hogy "avimerge -o 1cds.avi -i 2cds.1.avi 2cds.2.avi"
De ha ilyen jól megy neked a feliratkezelés, arra mi a megoldás, ha én szeretnék egy 2cd-s hangsávból a fenti avimerge-hez hasonlót csinálni, de a feliratsávból?

valoban logikusabb, csak gyorsabb beutni a man mplayer-t es egy /-t, mint egy avitabot, mert avimerge-t eddig nem is tudtam, hopgy van a gepemen :D (ja meg lehet filmnezes kozben seedelni, mert nem modositom a file-t)

"én szeretnék egy 2cd-s hangsávból a fenti avimerge-hez hasonlót csinálni, de a feliratsávból?"

Lehet, hogy en vagyok az olvasatlan bunko, de ezt nem sikerult ertelmeznem. En kulonallo srt-ket hasznalok tobbnyire, es ha jol ertelmezem, akkor egy kulon programot keresel, ami "merge-eli es csusztatja" a feliratot, biztos leteznie kell vmi ilyennek

A kérdés az lett volna, hogy van cd1.avi, cd1.srt, cd2.avi és cd2.srt. Az avikat össze tudom ragasztani a fent említett avimerge paranccsal egybe, de hogyan kell ugyanezt az összefűzést megcsinálni a hozzájuk tartozó feliratfájlokkal. Azt reméltem, hogy ezt valahogy meg lehet oldani mplayer-rel/mencoder-rel, és te ezt fejből tudod. (Sokadszorra nem sikerült rájöjjek a man alapján arra, hogy ezt lehet-e egyáltalán, és hogyan.)

A többiek által adott válaszokat köszönöm, velük egyetlen bajom van: szeretem a parancssoros eszközöket :-) De persze lassan megvilágosodtam, és sikerült (ha nem is elsőre) a megfelelő kulcszavakat megtalálnom, így eljutottam erre az oldalra. Már csak azt tartott sokáig megtalálnom, hogy az itt emlegetett srttool parancs már nem része a transcode csomagnak (contrib-ként sem), ellenben FreeBSD-n a subtitleripper nevű önálló, parancssoros eszközöket adó csomagban található.

Speciel en atalakitanam MPSub formatumba (Gabu tervezese :) de tenyleg a leglogikusabb felirat-formatum).
- dumpmpsub
Aztan itt mar lehet varialgatni, cat 1.srt 2.srt > film.srt
A vegen meg vissza az eredeti formatumba (ha mondjuk asztali cuccon nezed, mert persze az mpsub-ot mplayeren kivul mas nem ismeri)
http://web.njit.edu/all_topics/Prog_Lang_Docs/html/mplayer/Hungarian/do…

--
http://www.micros~1

Jo, en kertem az egyikbe :) a T. fw-fejlesztotol (New Age), de nem kerult bele es azota sem talalkoztam olyannal, ami ismeri. Ami rosszabb, hoyg altalaban a UNIX-sorvege jelet sem ismerik :(
Ezek voltak:
Yamada 6700
Arita (mar nem tudom, milyen)
Ferguson D780HX
Most a ferguson D990 lesz, ha valaha megjelenik magyar nyelvteruleten. Es vegre ertem, mitol szaguld a lengyel GDP: ezek az orultek evente kijonnek egy-egy kurvajo playerrel.

Ja, amugy infok innen:
http://forum.mpeg4-players.info/

--
http://www.micros~1

Pl. gnome-subtitle tud ilyet:
Megnyitod az egyiket, aztán „Edit → Insert Subtitle”, és eldöntöd, hogy utána vagy elé szeretnéd-e.

B verzió, hogy a filmet vágod ketté ;) 

int getRandomNumber() { // ←ez itt már az aláírásom
	return 4;//szabályos kockadobással választva.
}		//garantáltan véletlenszerű. xkcd

egy "license compliance engineer" :)
(az kb olyan, mint mint a common room cleaning manager)

egy seggfej amugy aki mindenkit probal iranyitani dirigalni befolyasolni de amugy koze nincs a programozashoz, de mint kiderult a joghoz se
commitjai altalaban szokozok beszurasabol vagy kitorlesebol allnak, code cosmetics neven. tovabbi hires commitjei meg evente az ossszes file fejleceben a copyright datum modositasai...

o all a masfel hete tortent ffmpeg "forradalom" mogott is... egyenkent beetette a fejlesztoket hogy jajj de jo lesz nekik ha csatlakoznak. hat mostmar latjuk milyen jo lett...

A'rpi

pont diego-ek flameltek ki a projectbol, A'rpi meg nyomott egy ragequit-et.
azota erdemes kicsit perspektivabol nezni, amiket ir az mplayer/ffmpeg fejleszteserol, mert ugyan mar nem koveti napi szinten, de ugy ir rola, valamint megragad minden alkalmat, hogy az ellenlabasokat rossz szinben tuntesse fel.
ami egyebkent azert rossz, mert tenyleg ot(A'rpit) igazolta az elet, csak nem kellene ennyire hangsulyozni ezt.

Tyrael

De! Arpi azert letett az mplayerrel valamit az asztalra, es semmi olyat nem csinalt, ami indokolta volna, hogy ne o fejlessze tovabb, es meg az elet is ot igazolta. Miert ne fikazza Diegoekat, foleg ha triplan igaza van? (jo, lehet en is unnam, ha minden nap ez lenne a tema, de ebben a topikban (meg par masik mplayeresben) boven elfer)

1, amit el lehetett mondani a regi uggyel kapcsolatban, azt mar szerintem hallottuk, tul lehetne lepni rajta, mar unalmas egy kicsit.
2, ha mar nem vesz reszt a fejlesztesben, akkor ne ragadjon meg minden alkalmat hogy fikazza az ottmaradtakat, es ne csinaljon ugy, mintha meg mindig insider lenne.

http://article.gmane.org/gmane.comp.video.ffmpeg.devel/125201

sokkal nagyobb fricska lenne szerintem, ha kijonne a G2-vel, mint hogy "egeti" magat.
szerintem

Tyrael

Igazabol bizonyos esetekben jo, ha egy projveznek csak ilyen committokat kell tenni, mert egyebkent profi kodoloi vannak, aki nem sok csinalnivalot hagy neki, csak az ilyen CQ fixeket. Persze, jelen esetben nem ez a helyzet.

PS: Most neztem, diego hibazott, van egy sor, ahonnet csunyan lemaradt a sor vegi enter, konkretan az elso sor, amit kiir a mplayer. :-)
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Esetleg azt össze tudnád röviden foglalni, hogy miért ennyire rögös az útja az ffmpeg/mplayer projectnek, miért van az, hogy szétflame-elik a csapatokat és hogy a fenébe éri el ez a Diego, hogy őt követik? Ha igaz, hogy tönkretette az mplayer fejlesztését, akkor miért követik most az ffmpeg fejlesztők is? (Bizonyára ismerik az mplayer-es szerepét.)

Az az érdekes, hogy szerintem még mindig az mplayer a linuxos lejátszók királya (smplayer frontendel), de hogy lehet ez, ha már évek óta nincs haladás? (Ha jól tudom elsők közt -vagy elsőként- támogatta az Nvidia VDPAU-t is.)

Anno még patch-t is küldtem neked véleményezni, asszem a multithread dekódolást és a már dekódolt képkockák bufferingjét tudta, de kijelentetted, hogy az mplayer nem multithread és pont. Pedig csodát tett a 2x400MHz dual Celeron gépemen az a patch! ;) Ma már bizonyára epic facepalm lenne ha látnám azt a kódot, de jó, hogy nem maradt fenn. :) /Nosztalgia
UPDATE: a picsába, fennmaradt, 2001. :) Nagypontosságú időzítés RTC-vel, AV-sync finomítás, külső triggerrel működő vblank időzítés, mennyi baromság! Imádtam játszani az mplayerrel. Nélküle szerintem nem váltok Linuxra és talán a C-t se tanulom meg..

> össze tudnád röviden foglalni
roviden nem

> hogy a fenébe éri el ez a Diego, hogy őt követik
hat ez jo kerdes

> miért követik most az ffmpeg fejlesztők
nem kovetik szerencsere, csak paran. a tobbseg foleg az oreg motorosok akik azert atlatnak a szitan es emlekeznek erre-arra, Michaelt tamogatjak

A'rpi

Lenne egy kerdesem, mert nem igazan vagyok jaratos az opensource fejlesztesek napi meneteben. En alapbol ugy kepzeltem, hogy az ilyen hatbaszurasok ott nehezen mennek, mert ha van alternativa fenntartva, akkor a kozosseg inkabb azt koveti, ahol van erdemi fejlodes felmutatva.

Konkretan azt ertem ezalatt, hogyha a lenyegi fejlesztok jo resze atlat valamennyire a szitan, fogja magat es csinal egy diego-mentes forkot, akkor a csavo hoppon marad, mivel erdemi fejlesztesek nelkul az o valtozata, csak zaj lesz az interneten.

Ez miert nem tortent meg annak idejen? Amennyire en erzekeltem, a core fejlesztok egyszeruen felalltak es angolosan tavoztak a projektbol, ami egy teljesen jogos reakcio, de folytatni azert lehetett volna. Mar nem volt bennetek sem motivacio, vagy a G2 fejlesztes lett volna a valasz?

1. az MPlayer nev jol be van jaratva, ismeri mindenki, a hattertortenet meg a gyakorlatban a kutyat sem erdekli par embert leszamitva. Ennek a farvizein nyereszkedik a fazon, abbol el lassan 5-6 eve.

2. Ido. A megelhetes, a boldogulas es/vagy a csalad mar lassan fontosabb tenyezove valik, mint egy ilyen project. Rengeteg idot felemeszt mar csak a karbantartasa is, nemhogy a fejlesztese.

---
pontscho / fresh!mindworkz

szerintem pont arra celzott, hogy ebbol egyaltalan nem lehet megelni, ez hobbi projekt. ugyanakkor penzt is kell keresni ezert marad egyre kevesebb ideje erre.

volt par megkeresesunk cegektol kisebb mplayer modositasokra, fejlesztesre de azok bizonytalanok, es nem sok penz.
(pl. a Pixar is megkeresett egy eleg huzos feature requesttel (framenkenti leptetes elore-hatra), es meg fizetni se akartak erte, el is hajtottuk oket)

ennek ellenere en azt mondom, megerte, mert hozott olyan ismertseget, amibol maig profitalok (kapcsolati toke ugyebar), kaptam sok allasajanlatot, nehanyat nagyon komoly cegektol (ezeket nem fogadtam el), a megszerzett tudasrol es tapasztalatokrol nem is beszelve...

A'rpi

ennek ellenere en azt mondom, megerte, mert hozott olyan ismertseget, amibol maig profitalok (kapcsolati toke ugyebar), kaptam sok allasajanlatot, nehanyat nagyon komoly cegektol (ezeket nem fogadtam el), a megszerzett tudasrol es tapasztalatokrol nem is beszelve...

Igy lehet megelni belole. Hazudnek ha azt mondanam, h nem volt ilyen hozadeka nalam is a dolgoknak. :) De Diegotol eddig csak bullshitet lattam, meg elcseszett lehetoseget tomkeleget. Igaz, h Gabunak volt egy fajta stilusa, de kiverte anno a KISS-bol is a kompenzaciot amit a neuteam szarakodasa szepen el is cseszett. Azota rohog rajtuk pl. a KiSS ugyvedi irodaja is. A tobbi hasonlo esetrol nem is beszelve. (Az ffmpeg foundationtol kapott 2k euroval elszamolt mar?)

---
pontscho / fresh!mindworkz

altalaban 2 okra vezetheto vissza:
1, a hatbaszurt fejlesztonek altalaban mindig voltak surlodasai a tobbi fejlesztovel, ezert fordulhat elo, hogy a hata mogott egy jo kommunikacios es szugesszios kepesseggel rendelkezo, de szakmailag kissebb fejleszto meg tud szervezni egy ilyen hatalomatvetelt.
2, az mplayer es az ffmpeg kapcsan is felmerult, hogy a kiutalt/megsertodott vezeto tovabbvigye a projectet, de A'rpi meg nem allt azota elo a G2-vel, Michael is azt mondta, hogy folytatja egy ideig a sajat repojaban a munkat, de o is azt mondta, hogyha egyedul marad a sajat projectje, akkor ertelmetlen folytatni (ugyhogy inkabb visszament kuzdeni a vezetoi pozicioert)

Tyrael

pontosan errol (1.) van szo az ffmpeg eseteben. Michael (a korabbi maintainer/leader akit most hatbaszurtak) nagyon szigoru volt, a gany/broken patcheket rejectelgette, a cosmetics patcheket se dijjazta (diego mestermuveit) igy sokan nem rajongtak erte. ehhez hozza jott, hogy o nagyon jo coder, a legjobb akit ismerek, es ezt a sizntet elvarta masoktol is: ha kuldtek egy patchet ami megvalositott valami featuret, de o tudta hogy ezt jobban/szebben is meg lehetne csinalni, akkor nem fogadta a patchet mondvan irjak meg jobban (adott ugyan utmutatasokat, de valoszinu kevesen vannak akik meg is tudnak csinalni). neha megcsinalta o, de altalaban nem volt hozza ideje/kedve.

diegoek erre epitettek most, az ilyen rejected patchek szerzoit allitottak maguk melle, es most ezeket commitoljak agyba-fobe, rovid uton lerontva a kod minoseget.

a 2. ponttal is teljesen igazad van, en pontosan azert alltam le a g2-vel, mert egyedul nem gyoztem es nem is akartam megcsinalni az egeszet, abban biztam anno, hogy tobben segitenek, de meg csak tesztelni se akarta senki. Michael jobb helyzetben van, mert azert sok fejleszto mellette all es az o git-jebe dolgoznak, illetve a vlc is azt hasznalja, es azert mostanaban ok a fo huzoero... kerdes inkabb az, hogy ez meddig marad igy, illetve meddig lehet annyira szinkronban tartani a 2 repo-t hogy ne legyenek mergelesi es api/abi kompatibilitasi problemak?

A'rpi

kerdes inkabb az, hogy ez meddig marad igy, illetve meddig lehet annyira szinkronban tartani a 2 repo-t hogy ne legyenek mergelesi es api/abi kompatibilitasi problemak?

ennek a megvalaszolasahoz szerintem elobb tisztazodnia kell a 2 csoport koruli "jogi" helyzetnek.

http://ffmpeg.org/download.html

git://git.ffmpeg.org/ffmpeg.git http://git.ffmpeg.org/?p=ffmpeg.git FFmpeg team Main development
git://git.videolan.org/ffmpeg.git http://git.videolan.org/?p=ffmpeg.git Michael Niedermayer Direct commits by various developers

gyakorlatilag diego-ek ugy forkoltak a projectet, hogy a nevhez fuzodo minden jogot igyekszenek megtartani, es szerintem vissza is elnek vele, hogy az ffmpeg site az o kezukon van.

tisztazni kellene, hogy most akkor vezetovaltas tortent-e, ha igen, akkor az uj csapatot es a policykat meg kellene szavaznia, el kellene fogadniuk a fejlesztoknek.
ha pedig fork, akkor szeritnem diegoeknak el kellene engedniuk a domaint, illetve uj nevet kellene a projectnek adni, meg akkor is, ha az "eredeti" ffmpeg csapat Michael-re redukalodik is.
illetve ott van meg, hogy az ffmpeg trademark Fabrice Bellard neven van, ot meg meg nem hallottuk megszolalni a kerdesben (amugy sem erheto el mar evek ota)

amig ezek nem tisztazodnak, addig szerintem a mergeles a legkisebb problema, ami a project(ek) elott all.

Tyrael

> gyakorlatilag diego-ek ugy forkoltak a projectet, hogy a nevhez fuzodo minden jogot igyekszenek megtartani, es szerintem vissza is elnek vele, hogy az ffmpeg site az o kezukon van.

pontosan

> tisztazni kellene, hogy most akkor vezetovaltas tortent-e, ha igen, akkor az uj csapatot es a policykat meg kellene szavaznia, el kellene fogadniuk a fejlesztoknek.

igen, pont emiatt megy a balhe. diegoek azzal ervelnek, hogy szerintuk nyilvanvalo a levlistarol, hogy mindenki utalja Michaelt, ezert folosleges a szavazas, meg hogy milyen sokan alairtak a leveluket (hat ahhoz kepest hogy 192 fejlesztot szamoltunk ossze nem sok az a kb 15 ember, plane hogy a 2/3-arol most hallottam eloszor)

valojaban arrol van szo (olvastam a szervezkedes irclogjat) hogy fosnak tole, hogy egy esetleges szavazasnal Michael nyerne, mert megiscsak o irta az ffmpeg felet meg o a legismertebb fejlesztoje, igy akinek nincs szemelyes problemaja vele az ra szavazna...

> illetve ott van meg, hogy az ffmpeg trademark Fabrice Bellard neven van, ot meg meg nem hallottuk megszolalni a kerdesben (amugy sem erheto el mar evek ota)

abban nem vagyok biztos, hogy a tardemark az ove, es nem az ffmpeg foundation-e, de a domain az o neven van, es o is ellenzi amit diegoek csinaltak es tamogatja Michaelt ha ugy dont, hogy eroszakkal visszaveszi a hatalmat

A'rpi

http://www.ffmpeg.org/legal.html ez alapjan a Fabrice-nel van a trademark.
kivancsi leszek, mi lesz a vege, de a szemelyes velemenyem az, hogy barmi lesz is, valakinek mennie kell, nem lehet a jovoben 1 csapatban tartani majd Diegot es Mal-t Michael-lel.
viszont jo lenne, ha ez a bilikiboritassal annyit elernenek, hogy ezek az indulatok, meg evek ota lappango problemak felszinre, illetve megoldasra kerulnek.
pl. nekem szimpatikus volt, ahogy Michael onkritikat gyakorolt, es elismerte, hogy vannak problemak vele, es hogy legjobb igyekezete szerint dolgozott rajta, hogy ezeket csokkentse.

Tyrael

ha kuldtek egy patchet ami megvalositott valami featuret, de o tudta hogy ezt jobban/szebben is meg lehetne csinalni, akkor nem fogadta a patchet mondvan irjak meg jobban (adott ugyan utmutatasokat, de valoszinu kevesen vannak akik meg is tudnak csinalni). neha megcsinalta o, de altalaban nem volt hozza ideje/kedve.

Kellő türelemmel sem lehetséges ez? Szerintem sokan csak feladják, vagy nem bírják elviselni hogy csicskáztatják őket. Sokan úgy kezdenek ezzel az egésszel foglalkozni(pl én), hogy van valami konkrét elképzelésük, és csak arra a részfeladatra figyelnek. Nem tudják hogy globálisan "mi? hány? merre? mennyi?". Nekem a paraméter feldolgozásnál volt ilyen gondom. Mondjuk lehet hogy csak többet kellett volna olvasni, de leírva sincsen minden. Türelem kell hozzá, és az ember belerázódik.

sajat peldambol kiindulva nagyon sok esetben nem feltetlen cel az, hogy bekeruljon az upstream-be a patch.
"he sracok, van egy ilyen bug, szoptam vele fel napot mire rajottem, igy ki lehet javitani, ha tudtok vele kezdeni valamit, akkor egeszsegetekre."
ezek utan, ha olyan valasz jon, hogy csinalj diffet a jelenlegi trunkra, valamint a 2 stabil agra, es ne ne tabot, hanem space-t hasznalj, ott lehetne sporolni egy iteraciot, etc, etc, akkor inkabb hagyja a patch bekuldoje a fenebe az egeszet, amivel mindenki veszit.
ezt jol korulirtak az ffmpeg-es levlistan, es irtak peldakat is, hogy 2-3 eves nagyongaz bugok vannak a rendszerben, mert a patch-et nem fogadtak be, de a szorozok arra sem vettek a faradtsagot, hogy kijavitsak, igy nem lett egyaltalan kijavitva.

Tyrael

Szerintem egyértelmű, hogy amikor az ember patchet ír, akkor alkalmazkodik az adott projekt igényeihez.
- úgy indentálok, ahogy a projekt
- a patchet elsősorban a trunk-ra kell megírni (hiszen az lesz a jövő, a core fejlesztők is arra koncentrálnak) még akkor is ha nekem egy release-re kell a fix (akkor kell még egy patchet írni a branchre)
- dokumentálni, tesztet írni szintén a projektben elvártak szerint (és nem azért mert az embernek erre van ingere)
- nem levlistára tölti az ember a patchet, hanem issue trackerben esetet nyit neki és feltölti oda. Így nem veszik el/felejtődik el és más is fel tudja venni a fonalat akár évekkel később is.

Patch íróként a projekt gazdák fejével is kell gondolkozni. Különösen ha nem egy bug fixről van szó, hanem egy új feature-ről. Te szeretnéd ezt az új funkciót, de a projekt fejlesztőinek is megvannak a saját tervei, nem feltétlen arra várnak, hogy végre valaki igényét lefejleszthessék. Szóval úgy kell tálalni az igényt és a patchet, hogy a fogadó azt a lehető legkisebb megerőltetéssel tudja alkalmazni.

Ez valóban egyértelmű. A gond ott kezdődik, amikor javítani akarsz egy gyakorlati bugot és erre pl jön egy olyan válasz, hogy írd újra az alrendszert is, mert ebbe nem fér bele tisztán a megoldásod. Ha ennek azután az a vége, hogy ottmarad a régi alrendszer és a bug évekig -a felhasználók életét megkeserítve-, akkor szerintem rossz döntést hozott a karbantartó és bizony vannak ilyenek.

fel kell ismerni, hogy nem a maintainer tesz csak szivesseget a patch bekuldojenek azzal, ha beolvasztja a munkajat.
szoval tok jo dolog, hogy felvazoltad az idealis patch irot, de nem mindenki ilyen(sot gyakorlatilag a casual, 1 patches fejlesztok nagyresze).
a kerdes az, hogy mivel jarunk jobban, ha magas bekerulesi kuszobot szabunk meg a fejleszteshez, cserebe viszont jobb minosegu lesz a kod, vagy ha megkonnyitjuk a hozzajarulok dolgat.
szerintem nagyon keves olyan project van, ahol az lenne a problema, hogy tul sok fejleszto tulekedne.
ezert en ugy gondolom, hogy a leheto legjobban meg kell konnyiteni a hozzajarulast, akar csak ugy, hogy elsopeccses embereknek nem visszadobod a munkajat, hanem felhivod a figyelmet, hogy legkozelebb igy es igy csinalja, de most megcsinalod helyette.
meg ugye egy csomo mindent automatizalni is lehet (tab vs space).

Tyrael

Szerintem ez nem tülekedés kérdése. Csak vannak, akik már rájöttek, hogy egyszerűbb úgy kódot karbantartani, bugfixálni vagy továbbfejleszteni, ha mind a kód mind annak története viszonylag jó minőségű. Nem csak az aktuális maintainernek és fejlesztőknek, hanem a leendő elsőpeccseseknek is.

Nem az ideális patch írót akartam felvázolni, hanem azokat akikkel én találkoztam (meg amikhez tartom magam, amikor küldök patchet). Bár tény, hogy azok opensource java és nem c projektek, de azokat használják is nagyvállalati környezetben (is).

Az indentálás meg persze, hogy automatizálva van, a projektek általában version controlban tartják a szabályaikat, amiket az IDE (Eclipse) automatikusan alkalmaz minden mentéskor. Úgyhogy erre sem kell különösebben figyelnie egy patch írónak. Ezért is nem értem miért problémázik valaki azon, hogy kidobják a patchét ha még erre sem ügyel.

Az általam ismert projektekben szokott lenni erre weboldal, ahol le van írva, hogy hogyan kell patchet írni a projekthez, hogy az ember átugorja ezeket a tisztelet köröket. Úgyhogy nem kell minden újdonsült titánt külön külön betanítani, csak olvasni kell.

"fel kell ismerni, hogy nem a maintainer tesz csak szivesseget a patch bekuldojenek azzal, ha beolvasztja a munkajat"
Ez így igaz. Ettől függetlenül, ha a patch író mégis úgy áll hozzá, hogy nem a magas lóról dobja oda a koncot, akkor mindenki jól jár. A programozók többsége eléggé nárcisztikus, erre rá lehet játszani alázattal, ha az ember gyors eredményt akar. ;) Másrészt a maintainerek legtöbbször ugyanúgy a szabadidejüket szánják a projektre, mint a patch írója, ezért is közösségi projekt és ezért sem teheti meg a beküldő, hogy csak "oda... önt" valamit.

"Az indentálás meg persze, hogy automatizálva van, a projektek általában version controlban tartják a szabályaikat, amiket az IDE (Eclipse) automatikusan alkalmaz minden mentéskor."

Ez többnyire kifejezetten rossz ötlet, egy csomó szívás van vele. Nem csak Eclipse van a világon, így más IDE-k vagy editorok használók mit se tudnak azokról a beállításokról, másrészt Eclipse használók esetén is esélyes, hogy valami path nem fog stimmelni, meg kell változtatni a .classpath-ban, emiatt a VCS mindig módosított file-t jelez, stbstb.

Erre valok a tobb VCS-nel is elerheto pre-commit hookok, amik szolnak hogy vazze, rossz az identalasod ABORT. Jol megirt hook megmondja hol talalja az ember a guidelinet, meg hogy kb mi a hiba, es onnantol ki-ki ugy javitja, ahogy epp gondolja.

Emelle szinten VCSbe be lehet tenni a kulonboz editorhoz tartozo beallitasokat, hogy az azt hasznaloknak konnyebb legyen, stb.

Igy a szivas turhetore mersekelheto, es az is megoldott, hogy be van tartatva a szabaly.

--
|8]

+0.5

Legtobb esetben ha patchet irok, igyekszem azert olyan formara hozni, hogy at lehessen venni kulonosebb faragas nelkul. De ha elkezdenek szivatni, hogy apro-csepro dolgokat alakitsak at rajta, nem fog erdekelni. Hasznalom lokalisan, upstream meg csinal amit akar. Reszemrol megtettem, ami tolem elvarhato: viszketett, megvakartam. Ha o maskepp vakarna, az mar nem az en problemam.

Nyilvan nem azt mondom, hogy minden kis patchet at kell venni ugy ahogy van, de a lo tuloldalara se kene atesni, hogy a random felhasznalotol profi, kifogastalan patchet varjon az ember. Hamar megvan a patch, sokkal konnyebb azt egy hozzaertobbnek atalakitani, mint a forrashoz frissen hozzanyulo, es egyebkent a fejlesztesben nem tul erdekelt embernek.

--
|8]

Ez azert erosen fugg attol, hogy mennyi munkaval jar az upstreambe benyomas. Vannak esetek, amikor egy teljesen atlagos hobby-hackernek baromira nem eri meg ezzel szorakozni.

Ha annyirol van szo, hogy coding styleon kell valtoztatni, vagy par aprosagot, az siman belefer. De ha at kene irni az egeszet, vagy atdesignolni valami grandiozusabb dologga, na, az mar nagyon nem fogja megerni.

--
|8]

Értem én csak szomorú, hogy az ember keres egy feature-t, és a google a levlistát dobja ki, egy patch-ről, ami ráadásul még csak nem is a legfrissebb változat. Mikor megtalálja kiderül, hogy a project ott akadt el, hogy egy függvénynek nem szépen vannak átadva a paraméterek, a command-line paraméterek feldolgozása nem felel meg a legújabb szabványnak, amit még nem is alkalmaztak a forráskódban egyébként, csak az új kódok bekerülésénél követelik meg. Ja és persze van benne egy tab is.

Persze nem azt mondom hogy ezt be kéne commit-olni úgy ahogy van, de egy fejlesztőnek aki képben van ezeket 10 perc lenne megcsinálni(max 30).

ezek mind elhangzottak a levlistan, a fejlesztok tobbsege ezen a velemenyen van, Michael is beismerte, hogy ez problema, es hogy o is probalt valtoztatni ezen a szorozos hozzaallasan (sot azt is vicces volt olvasni, hogy o pl. azert nem commitolt mostanaban semmit, mert a szorozeseert cserebe az o commitjait betunkent szetcincaltak egyesek)

Tyrael

igen ezt nagyon jol megfogalmaztad.

az a baj, hogy mind a maintainerek, mind a contributorok/patch kuldok "for fun" azaz hobbibol szorakozasbol csinaljak. egyiknek sincs semmi kedve a kevesbe erdekes dolgokhoz, mint cosmetics, backportolas etc.

a contributor orul, hogy osszeganyolta valahogy mukodore az uj featuret vagy talalt valami bugot es valahogy fixelte (nem feltetlen a legjobb modon, pl. nem a hiba forrasat szuntette meg, hanem elfedte a tuneteit). a maintainer meg nem orul mert tudja hogy ez igy szar, de se kedve se ideje sozpni vele hogy kijavitsa. leirja par sorban (ebbe is belekotnek mindig paran hogy nem elegge udvariasan, szep kerek irodalmi mondatokban irja) mik a problemak vele, a contributor meg ugy van vele hogy "buzik!" meg hogy o leszarja az upstream-et, neki mukodik igy is, es az a lenyeg.

na most ebbol jonnek a konfliktusok, az userek sirnak hogy ott a bugfix/featurepatch, miert nem applied, a mainteinerek sirnak hogy szart nem raknak be, a contributor meg sir hogy a buzik miert rejecteltek...

en anno mplayer maintainerkent viszonylag megengedo voltam, nagyon keves patch lett rejectelve, ha kellett en javitgattam ki amit tudtam. kerult is be jo sok szemet igy a kodba, a vegen mar annyi hogy inkabb abbahagytam mondvan ezt igy nem erdemes folytatni.

Michael meg a masik veglet, o amig nem volt 100%-ban tokeletes valami addig nem engedte commitelni. kesobb lazitott de nem elegge. es meg mindig azt mondom, o csinalta jobban, de sajnos boritekolhato volt hogy ha eleg sok patchet rejectel, a "nep" felhaborodik.

A'rpi

> csak zaj lesz az interneten.

hat csak az a baj, hogy diegoek kezeben van az mplayerhq.hu es ffmpeg.org domaineket kiszolgalo infrastruktura (hivatalos svn/git repo, weboldalak, levlistak) igy megfelelo kommunikacioval elhitethetik a nagyvilaggal hogy minden rendben, es eltuntetik meg a nyomat is a forkoknak (ahogy ez tortent most is, Michael beleirta a weboldalba hogy van nala is egy fork, ezt rogton toroltek, ekkor kezdtek elfajulni a dolgok).

Ez ellen 2 dolgot lehet tenni (utolag):
1. eroszakkal visszaszerezni a domaint es elkoltoztetni a projektet masik szerverre (erre technikaliag adott a lehetoseg, a domain tulajdonosa mellettunk all)

2. kitalalni egy uj nevet, es kello marketinggel elarasztva a netet kihirdetni hogy uj neven folytatodik a project es mostantol ez a jo. na most ez vagy sikerul, vagy nem, foleg ha kozben a regi domainen megy az ellenkampany es a tagadas ezerrel.
(ugye kiben bizik az egyszeri user? a hivatalos domainen levo infokban!)

A korrekt az lett volna diego-ek reszerol, hogy ha ennyire elegedetlenek a mostani helyzettel, akkor forkoljanak ok, aztan meglatjuk hogy a fejlesztok tobbsege tenyleg oket tamogatja-e?
De nem ezt tettek, hanem egyszeruen toroltek mindenkit aki nekik nem tetszett, majd irtak egy szep mezes-mazos levelet amiben megmagyaraztak miert veszik at a projektet (nagyreszt hazugsag/tulzas), es nagynehezen (tenyleg nehezen, 3 honapig gyozkodtek a nepet) osszevakartak par embert aki tamogatta/alairta.

A'rpi

elsosorban etikai oka van, semmivel se lennenk kulonbek diegoeknal ha ugyanugy eroszakkal vennenk at/vissza a hatalmat. jo nem teljesen igaz, mert egyrestz ok kezdtek, masreszt jogtalanul tettek, de akkor is, egyelore megy az egyezkedes, hatha sikerul bekes megoldast talalni. de vegso esetre ott van ez a lehetoseg is.

masreszt ennek az mplayerhez semmi koze sincs, az mplayerhq.hu nem tudom kinek a kezeben van most, talan al3x? es hogy o mit gondol errol az is jo kerdes.

A'rpi

Nem csak Diegorol van szo, a puccs tamogatoi kozott van tobb kituno fejleszto is (pl. Dark Shikari, Kostya, Loren, hogy csak parat emlitsek). A hatbatamadas szerintem is hiba volt, de ezen tul a "puccsistaknak" is van amiben igazuk van (ahogy en latom pl. ha egy patch javit az ffmpegen es semmin se ront, nem kene szenne szivatni a contributort, tovabba talan volt nemi atgondolatlansag/kovetkezetlenseg abban a tekintetben, hogy ki kaphat commit jogot illetve akar hogy a comitterek patcheire milyen minosegi szabalyok ervenyesek (kevesbe szigoruak mint a hetvegi koderekeire?)).

Jo lenne ha sikerulne valamilyen kompromisszumot kotni, mert mindket oldalon vannak jo es elismert szakemberek, es nyilvan kar lenne ha barmelyikuket elveszitene a project.

szerk: persze az ffmpeg ugyre reagaltam, mert szerintem itt arrol volt szo, az mplayer project emlkeim szerint teljesen mas utat jart be amiota Arpi visszavonult (nem volt puccs)

- Use the Source Luke ! -

"persze az ffmpeg ugyre reagaltam, mert szerintem itt arrol volt szo, az mplayer project emlkeim szerint teljesen mas utat jart be amiota Arpi visszavonult (nem volt puccs)"

http://hup.hu/cikkek/20110130/mplayer_1.0_rc_4_feltehetoen#comment-1213…

ps: amugy furcsa hogy A'rpi-nak valaszolva elso szam harmadik szemelyben irsz rola. :)

Tyrael

( Zaneck | 2011. 01. 30., v – 18:29 )

Engem nem érdekel mi van az MPlayer-rel (eddig egyébként is rolling release volt, ennek az -rc4-nek semmi értelme, de valamit a fejlesztőknek is tenniük kell, ha már fejleszteni nem akarnak), ha már nagyon használhatatlan lesz / feature kell akkor akár forkolni is lehet, de megírni egy másik FFmpeg frontendet sem elképzelhetetlen (mondjuk én ha megírnám nem releaselném, hogy aztán supportálhassam).

Az FFmpeg karbantartásának és fejlesztésének jelenlegi helyzete annál inkább érdeklődésre tarthat számot.