Author: uau Date: Sat Apr 12 17:51:08 2008 New Revision: 26411 Log: Reindent demuxer.c Modified: trunk/libmpdemux/demuxer.c Modified: trunk/libmpdemux/demuxer.c ============================================================================== --- trunk/libmpdemux/demuxer.c (original) +++ trunk/libmpdemux/demuxer.c Sat Apr 12 17:51:08 2008 @@ -78,108 +78,110 @@ extern const demuxer_desc_t demuxer_desc * demuxer, add it to libavformat, except for wrappers around external * libraries and demuxers requiring binary support. */ -const demuxer_desc_t* const demuxer_list[] = { - &demuxer_desc_rawaudio, - &demuxer_desc_rawvideo, +const demuxer_desc_t *const demuxer_list[] = { + &demuxer_desc_rawaudio, + &demuxer_desc_rawvideo, #ifdef USE_TV - &demuxer_desc_tv, + &demuxer_desc_tv, #endif - &demuxer_desc_mf, + &demuxer_desc_mf, #ifdef USE_LIBAVFORMAT - &demuxer_desc_lavf_preferred, + &demuxer_desc_lavf_preferred, #endif - &demuxer_desc_avi, - &demuxer_desc_y4m, - &demuxer_desc_asf, - &demuxer_desc_nsv, - &demuxer_desc_nuv, - &demuxer_desc_real, - &demuxer_desc_smjpeg, - &demuxer_desc_matroska, - &demuxer_desc_realaudio, - &demuxer_desc_vqf, - &demuxer_desc_mov, - &demuxer_desc_vivo, - &demuxer_desc_fli, - &demuxer_desc_film, - &demuxer_desc_roq, + &demuxer_desc_avi, + &demuxer_desc_y4m, + &demuxer_desc_asf, + &demuxer_desc_nsv, + &demuxer_desc_nuv, + &demuxer_desc_real, + &demuxer_desc_smjpeg, + &demuxer_desc_matroska, + &demuxer_desc_realaudio, + &demuxer_desc_vqf, + &demuxer_desc_mov, + &demuxer_desc_vivo, + &demuxer_desc_fli, + &demuxer_desc_film, + &demuxer_desc_roq, #ifdef HAVE_GIF - &demuxer_desc_gif, + &demuxer_desc_gif, #endif #ifdef HAVE_OGGVORBIS - &demuxer_desc_ogg, + &demuxer_desc_ogg, #endif #ifdef USE_WIN32DLL - &demuxer_desc_avs, + &demuxer_desc_avs, #endif - &demuxer_desc_pva, - &demuxer_desc_mpeg_ts, - &demuxer_desc_lmlm4, - &demuxer_desc_mpeg_ps, - &demuxer_desc_mpeg_pes, - &demuxer_desc_mpeg_es, - &demuxer_desc_mpeg_gxf, - &demuxer_desc_mpeg4_es, - &demuxer_desc_h264_es, + &demuxer_desc_pva, + &demuxer_desc_mpeg_ts, + &demuxer_desc_lmlm4, + &demuxer_desc_mpeg_ps, + &demuxer_desc_mpeg_pes, + &demuxer_desc_mpeg_es, + &demuxer_desc_mpeg_gxf, + &demuxer_desc_mpeg4_es, + &demuxer_desc_h264_es, #ifdef MUSEPACK - &demuxer_desc_mpc, + &demuxer_desc_mpc, #endif - &demuxer_desc_audio, - &demuxer_desc_mpeg_ty, + &demuxer_desc_audio, + &demuxer_desc_mpeg_ty, #ifdef STREAMING_LIVE555 - &demuxer_desc_rtp, + &demuxer_desc_rtp, #endif #ifdef LIBNEMESI - &demuxer_desc_rtp_nemesi, + &demuxer_desc_rtp_nemesi, #endif #ifdef USE_LIBAVFORMAT - &demuxer_desc_lavf, + &demuxer_desc_lavf, #endif #ifdef HAVE_LIBDV095 - &demuxer_desc_rawdv, + &demuxer_desc_rawdv, #endif - &demuxer_desc_aac, + &demuxer_desc_aac, #ifdef HAVE_LIBNUT - &demuxer_desc_nut, + &demuxer_desc_nut, #endif #ifdef HAVE_XMMS - &demuxer_desc_xmms, + &demuxer_desc_xmms, #endif - /* Please do not add any new demuxers here. If you want to implement a new - * demuxer, add it to libavformat, except for wrappers around external - * libraries and demuxers requiring binary support. */ - NULL + /* Please do not add any new demuxers here. If you want to implement a new + * demuxer, add it to libavformat, except for wrappers around external + * libraries and demuxers requiring binary support. */ + NULL }; -void free_demuxer_stream(demux_stream_t *ds){ +void free_demuxer_stream(demux_stream_t *ds) +{ ds_free_packs(ds); free(ds); } -demux_stream_t* new_demuxer_stream(struct demuxer_st *demuxer,int id){ - demux_stream_t* ds=malloc(sizeof(demux_stream_t)); - ds->buffer_pos=ds->buffer_size=0; - ds->buffer=NULL; - ds->pts=0; - ds->pts_bytes=0; - ds->eof=0; - ds->pos=0; - ds->dpos=0; - ds->pack_no=0; -//--------------- - ds->packs=0; - ds->bytes=0; - ds->first=ds->last=ds->current=NULL; - ds->id=id; - ds->demuxer=demuxer; -//---------------- - ds->asf_seq=-1; - ds->asf_packet=NULL; -//---------------- - ds->ss_mul=ds->ss_div=0; -//---------------- - ds->sh=NULL; - return ds; +demux_stream_t *new_demuxer_stream(struct demuxer_st *demuxer, int id) +{ + demux_stream_t *ds = malloc(sizeof(demux_stream_t)); + ds->buffer_pos = ds->buffer_size = 0; + ds->buffer = NULL; + ds->pts = 0; + ds->pts_bytes = 0; + ds->eof = 0; + ds->pos = 0; + ds->dpos = 0; + ds->pack_no = 0; + + ds->packs = 0; + ds->bytes = 0; + ds->first = ds->last = ds->current = NULL; + ds->id = id; + ds->demuxer = demuxer; + + ds->asf_seq = -1; + ds->asf_packet = NULL; + + ds->ss_mul = ds->ss_div = 0; + + ds->sh = NULL; + return ds; } @@ -189,300 +191,343 @@ demux_stream_t* new_demuxer_stream(struc * @param file_format type of the demuxer * @return structure for the demuxer, NULL if not found */ -static const demuxer_desc_t* get_demuxer_desc_from_type(int file_format) +static const demuxer_desc_t *get_demuxer_desc_from_type(int file_format) { - int i; + int i; - for (i = 0; demuxer_list[i]; i++) - if (file_format == demuxer_list[i]->type) - return demuxer_list[i]; + for (i = 0; demuxer_list[i]; i++) + if (file_format == demuxer_list[i]->type) + return demuxer_list[i]; - return NULL; + return NULL; } -demuxer_t* new_demuxer(stream_t *stream,int type,int a_id,int v_id,int s_id,char *filename){ - demuxer_t *d=malloc(sizeof(demuxer_t)); - memset(d,0,sizeof(demuxer_t)); - d->stream=stream; - d->stream_pts = MP_NOPTS_VALUE; - d->reference_clock = MP_NOPTS_VALUE; - d->movi_start=stream->start_pos; - d->movi_end=stream->end_pos; - d->seekable=1; - d->synced=0; - d->filepos=0; - d->audio=new_demuxer_stream(d,a_id); - d->video=new_demuxer_stream(d,v_id); - d->sub=new_demuxer_stream(d,s_id); - d->type=type; - if(type) - if (!(d->desc = get_demuxer_desc_from_type(type))) - mp_msg(MSGT_DEMUXER,MSGL_ERR,"BUG! Invalid demuxer type in new_demuxer(), big troubles ahead."); - if(filename) // Filename hack for avs_check_file - d->filename=strdup(filename); - stream_reset(stream); - stream_seek(stream,stream->start_pos); - return d; +demuxer_t *new_demuxer(stream_t *stream, int type, int a_id, int v_id, + int s_id, char *filename) +{ + demuxer_t *d = malloc(sizeof(demuxer_t)); + memset(d, 0, sizeof(demuxer_t)); + d->stream = stream; + d->stream_pts = MP_NOPTS_VALUE; + d->reference_clock = MP_NOPTS_VALUE; + d->movi_start = stream->start_pos; + d->movi_end = stream->end_pos; + d->seekable = 1; + d->synced = 0; + d->filepos = 0; + d->audio = new_demuxer_stream(d, a_id); + d->video = new_demuxer_stream(d, v_id); + d->sub = new_demuxer_stream(d, s_id); + d->type = type; + if (type) + if (!(d->desc = get_demuxer_desc_from_type(type))) + mp_msg(MSGT_DEMUXER, MSGL_ERR, + "BUG! Invalid demuxer type in new_demuxer(), " + "big troubles ahead."); + if (filename) // Filename hack for avs_check_file + d->filename = strdup(filename); + stream_reset(stream); + stream_seek(stream, stream->start_pos); + return d; } extern int dvdsub_id; -sh_sub_t *new_sh_sub_sid(demuxer_t *demuxer, int id, int sid) { - if (id > MAX_S_STREAMS - 1 || id < 0) { - mp_msg(MSGT_DEMUXER,MSGL_WARN,"Requested sub stream id overflow (%d > %d)\n", - id, MAX_S_STREAMS); - return NULL; - } - if (demuxer->s_streams[id]) - mp_msg(MSGT_DEMUXER, MSGL_WARN, "Sub stream %i redefined\n", id); - else { - sh_sub_t *sh = calloc(1, sizeof(sh_sub_t)); - demuxer->s_streams[id] = sh; - sh->sid = sid; - mp_msg(MSGT_IDENTIFY, MSGL_INFO, "ID_SUBTITLE_ID=%d\n", sid); - } - return demuxer->s_streams[id]; +sh_sub_t *new_sh_sub_sid(demuxer_t *demuxer, int id, int sid) +{ + if (id > MAX_S_STREAMS - 1 || id < 0) { + mp_msg(MSGT_DEMUXER, MSGL_WARN, + "Requested sub stream id overflow (%d > %d)\n", id, + MAX_S_STREAMS); + return NULL; + } + if (demuxer->s_streams[id]) + mp_msg(MSGT_DEMUXER, MSGL_WARN, "Sub stream %i redefined\n", id); + else { + sh_sub_t *sh = calloc(1, sizeof(sh_sub_t)); + demuxer->s_streams[id] = sh; + sh->sid = sid; + mp_msg(MSGT_IDENTIFY, MSGL_INFO, "ID_SUBTITLE_ID=%d\n", sid); + } + return demuxer->s_streams[id]; } -void free_sh_sub(sh_sub_t *sh) { +void free_sh_sub(sh_sub_t *sh) +{ mp_msg(MSGT_DEMUXER, MSGL_DBG2, "DEMUXER: freeing sh_sub at %p\n", sh); free(sh->extradata); #ifdef USE_ASS - if (sh->ass_track) ass_free_track(sh->ass_track); + if (sh->ass_track) + ass_free_track(sh->ass_track); #endif free(sh->lang); free(sh); } -sh_audio_t* new_sh_audio_aid(demuxer_t *demuxer,int id,int aid){ - if(id > MAX_A_STREAMS-1 || id < 0) - { - mp_msg(MSGT_DEMUXER,MSGL_WARN,"Requested audio stream id overflow (%d > %d)\n", - id, MAX_A_STREAMS); - return NULL; +sh_audio_t *new_sh_audio_aid(demuxer_t *demuxer, int id, int aid) +{ + if (id > MAX_A_STREAMS - 1 || id < 0) { + mp_msg(MSGT_DEMUXER, MSGL_WARN, + "Requested audio stream id overflow (%d > %d)\n", id, + MAX_A_STREAMS); + return NULL; } - if(demuxer->a_streams[id]){ - mp_msg(MSGT_DEMUXER,MSGL_WARN,MSGTR_AudioStreamRedefined,id); + if (demuxer->a_streams[id]) { + mp_msg(MSGT_DEMUXER, MSGL_WARN, MSGTR_AudioStreamRedefined, id); } else { sh_audio_t *sh; - mp_msg(MSGT_DEMUXER,MSGL_V,MSGTR_FoundAudioStream,id); - demuxer->a_streams[id]=calloc(1, sizeof(sh_audio_t)); + mp_msg(MSGT_DEMUXER, MSGL_V, MSGTR_FoundAudioStream, id); + demuxer->a_streams[id] = calloc(1, sizeof(sh_audio_t)); sh = demuxer->a_streams[id]; // set some defaults - sh->samplesize=2; - sh->sample_format=AF_FORMAT_S16_NE; - sh->audio_out_minsize=8192;/* default size, maybe not enough for Win32/ACM*/ - sh->pts=MP_NOPTS_VALUE; - mp_msg(MSGT_IDENTIFY, MSGL_INFO, "ID_AUDIO_ID=%d\n", aid); + sh->samplesize = 2; + sh->sample_format = AF_FORMAT_S16_NE; + sh->audio_out_minsize = 8192; /* default size, maybe not enough for Win32/ACM */ + sh->pts = MP_NOPTS_VALUE; + mp_msg(MSGT_IDENTIFY, MSGL_INFO, "ID_AUDIO_ID=%d\n", aid); } - ((sh_audio_t *)demuxer->a_streams[id])->aid = aid; + ((sh_audio_t *) demuxer->a_streams[id])->aid = aid; return demuxer->a_streams[id]; } -void free_sh_audio(demuxer_t *demuxer, int id) { +void free_sh_audio(demuxer_t *demuxer, int id) +{ sh_audio_t *sh = demuxer->a_streams[id]; demuxer->a_streams[id] = NULL; - mp_msg(MSGT_DEMUXER,MSGL_DBG2,"DEMUXER: freeing sh_audio at %p\n",sh); + mp_msg(MSGT_DEMUXER, MSGL_DBG2, "DEMUXER: freeing sh_audio at %p\n", sh); free(sh->wf); free(sh->codecdata); free(sh->lang); free(sh); } -sh_video_t* new_sh_video_vid(demuxer_t *demuxer,int id,int vid){ - if(id > MAX_V_STREAMS-1 || id < 0) - { - mp_msg(MSGT_DEMUXER,MSGL_WARN,"Requested video stream id overflow (%d > %d)\n", - id, MAX_V_STREAMS); - return NULL; +sh_video_t *new_sh_video_vid(demuxer_t *demuxer, int id, int vid) +{ + if (id > MAX_V_STREAMS - 1 || id < 0) { + mp_msg(MSGT_DEMUXER, MSGL_WARN, + "Requested video stream id overflow (%d > %d)\n", id, + MAX_V_STREAMS); + return NULL; } - if(demuxer->v_streams[id]){ - mp_msg(MSGT_DEMUXER,MSGL_WARN,MSGTR_VideoStreamRedefined,id); - } else { - mp_msg(MSGT_DEMUXER,MSGL_V,MSGTR_FoundVideoStream,id); - demuxer->v_streams[id]=calloc(1, sizeof(sh_video_t)); - mp_msg(MSGT_IDENTIFY, MSGL_INFO, "ID_VIDEO_ID=%d\n", vid); + if (demuxer->v_streams[id]) + mp_msg(MSGT_DEMUXER, MSGL_WARN, MSGTR_VideoStreamRedefined, id); + else { + mp_msg(MSGT_DEMUXER, MSGL_V, MSGTR_FoundVideoStream, id); + demuxer->v_streams[id] = calloc(1, sizeof(sh_video_t)); + mp_msg(MSGT_IDENTIFY, MSGL_INFO, "ID_VIDEO_ID=%d\n", vid); } - ((sh_video_t *)demuxer->v_streams[id])->vid = vid; + ((sh_video_t *) demuxer->v_streams[id])->vid = vid; return demuxer->v_streams[id]; } -void free_sh_video(sh_video_t* sh){ - mp_msg(MSGT_DEMUXER,MSGL_DBG2,"DEMUXER: freeing sh_video at %p\n",sh); +void free_sh_video(sh_video_t *sh) +{ + mp_msg(MSGT_DEMUXER, MSGL_DBG2, "DEMUXER: freeing sh_video at %p\n", sh); free(sh->bih); free(sh); } -void free_demuxer(demuxer_t *demuxer){ +void free_demuxer(demuxer_t *demuxer) +{ int i; - mp_msg(MSGT_DEMUXER,MSGL_DBG2,"DEMUXER: freeing demuxer at %p\n",demuxer); - if(demuxer->desc->close) - demuxer->desc->close(demuxer); + mp_msg(MSGT_DEMUXER, MSGL_DBG2, "DEMUXER: freeing demuxer at %p\n", + demuxer); + if (demuxer->desc->close) + demuxer->desc->close(demuxer); // Very ugly hack to make it behave like old implementation if (demuxer->desc->type == DEMUXER_TYPE_DEMUXERS) - goto skip_streamfree; + goto skip_streamfree; // free streams: - for(i = 0; i < MAX_A_STREAMS; i++) - if(demuxer->a_streams[i]) free_sh_audio(demuxer, i); - for(i = 0; i < MAX_V_STREAMS; i++) - if(demuxer->v_streams[i]) free_sh_video(demuxer->v_streams[i]); - for(i = 0; i < MAX_S_STREAMS; i++) - if(demuxer->s_streams[i]) free_sh_sub(demuxer->s_streams[i]); + for (i = 0; i < MAX_A_STREAMS; i++) + if (demuxer->a_streams[i]) + free_sh_audio(demuxer, i); + for (i = 0; i < MAX_V_STREAMS; i++) + if (demuxer->v_streams[i]) + free_sh_video(demuxer->v_streams[i]); + for (i = 0; i < MAX_S_STREAMS; i++) + if (demuxer->s_streams[i]) + free_sh_sub(demuxer->s_streams[i]); // free demuxers: free_demuxer_stream(demuxer->audio); free_demuxer_stream(demuxer->video); free_demuxer_stream(demuxer->sub); -skip_streamfree: - if(demuxer->info) { - for(i=0;demuxer->info[i] != NULL; i++) - free(demuxer->info[i]); - free(demuxer->info); + skip_streamfree: + if (demuxer->info) { + for (i = 0; demuxer->info[i] != NULL; i++) + free(demuxer->info[i]); + free(demuxer->info); } free(demuxer->filename); if (demuxer->chapters) { - for (i=0; i<demuxer->num_chapters; i++) - free(demuxer->chapters[i].name); - free(demuxer->chapters); + for (i = 0; i < demuxer->num_chapters; i++) + free(demuxer->chapters[i].name); + free(demuxer->chapters); } if (demuxer->attachments) { - for (i=0; i<demuxer->num_attachments; i++) { - free(demuxer->attachments[i].name); - free(demuxer->attachments[i].type); - free(demuxer->attachments[i].data); - } - free(demuxer->attachments); + for (i = 0; i < demuxer->num_attachments; i++) { + free(demuxer->attachments[i].name); + free(demuxer->attachments[i].type); + free(demuxer->attachments[i].data); + } + free(demuxer->attachments); } free(demuxer); } -void ds_add_packet(demux_stream_t *ds,demux_packet_t* dp){ -// demux_packet_t* dp=new_demux_packet(len); -// stream_read(stream,dp->buffer,len); -// dp->pts=pts; //(float)pts/90000.0f; -// dp->pos=pos; +void ds_add_packet(demux_stream_t *ds, demux_packet_t *dp) +{ // append packet to DS stream: ++ds->packs; - ds->bytes+=dp->len; - if(ds->last){ - // next packet in stream - ds->last->next=dp; - ds->last=dp; + ds->bytes += dp->len; + if (ds->last) { + // next packet in stream + ds->last->next = dp; + ds->last = dp; } else { - // first packet in stream - ds->first=ds->last=dp; + // first packet in stream + ds->first = ds->last = dp; } - mp_dbg(MSGT_DEMUXER,MSGL_DBG2,"DEMUX: Append packet to %s, len=%d pts=%5.3f pos=%u [packs: A=%d V=%d]\n", - (ds==ds->demuxer->audio)?"d_audio":"d_video", - dp->len,dp->pts,(unsigned int)dp->pos,ds->demuxer->audio->packs,ds->demuxer->video->packs); + mp_dbg(MSGT_DEMUXER, MSGL_DBG2, + "DEMUX: Append packet to %s, len=%d pts=%5.3f pos=%u [packs: A=%d V=%d]\n", + (ds == ds->demuxer->audio) ? "d_audio" : "d_video", dp->len, + dp->pts, (unsigned int) dp->pos, ds->demuxer->audio->packs, + ds->demuxer->video->packs); } -void ds_read_packet(demux_stream_t *ds, stream_t *stream, int len, double pts, off_t pos, int flags) { - demux_packet_t* dp=new_demux_packet(len); - len = stream_read(stream,dp->buffer,len); +void ds_read_packet(demux_stream_t *ds, stream_t *stream, int len, + double pts, off_t pos, int flags) +{ + demux_packet_t *dp = new_demux_packet(len); + len = stream_read(stream, dp->buffer, len); resize_demux_packet(dp, len); - dp->pts=pts; //(float)pts/90000.0f; - dp->pos=pos; - dp->flags=flags; + dp->pts = pts; + dp->pos = pos; + dp->flags = flags; // append packet to DS stream: - ds_add_packet(ds,dp); + ds_add_packet(ds, dp); } // return value: // 0 = EOF or no stream found or invalid type // 1 = successfully read a packet -int demux_fill_buffer(demuxer_t *demux,demux_stream_t *ds){ - // Note: parameter 'ds' can be NULL! -// printf("demux->type=%d\n",demux->type); - return demux->desc->fill_buffer(demux, ds); +int demux_fill_buffer(demuxer_t *demux, demux_stream_t *ds) +{ + // Note: parameter 'ds' can be NULL! + return demux->desc->fill_buffer(demux, ds); } // return value: // 0 = EOF // 1 = successful #define MAX_ACUMULATED_PACKETS 64 -int ds_fill_buffer(demux_stream_t *ds){ - demuxer_t *demux=ds->demuxer; - if(ds->current) free_demux_packet(ds->current); - ds->current=NULL; - if( mp_msg_test(MSGT_DEMUXER,MSGL_DBG3) ){ - if(ds==demux->audio) mp_dbg(MSGT_DEMUXER,MSGL_DBG3,"ds_fill_buffer(d_audio) called\n");else - if(ds==demux->video) mp_dbg(MSGT_DEMUXER,MSGL_DBG3,"ds_fill_buffer(d_video) called\n");else - if(ds==demux->sub) mp_dbg(MSGT_DEMUXER,MSGL_DBG3,"ds_fill_buffer(d_sub) called\n");else - mp_dbg(MSGT_DEMUXER,MSGL_DBG3,"ds_fill_buffer(unknown 0x%X) called\n",(unsigned int)ds); - } - while(1){ - if(ds->packs){ - demux_packet_t *p=ds->first; +int ds_fill_buffer(demux_stream_t *ds) +{ + demuxer_t *demux = ds->demuxer; + if (ds->current) + free_demux_packet(ds->current); + ds->current = NULL; + if (mp_msg_test(MSGT_DEMUXER, MSGL_DBG3)) { + if (ds == demux->audio) + mp_dbg(MSGT_DEMUXER, MSGL_DBG3, + "ds_fill_buffer(d_audio) called\n"); + else if (ds == demux->video) + mp_dbg(MSGT_DEMUXER, MSGL_DBG3, + "ds_fill_buffer(d_video) called\n"); + else if (ds == demux->sub) + mp_dbg(MSGT_DEMUXER, MSGL_DBG3, "ds_fill_buffer(d_sub) called\n"); + else + mp_dbg(MSGT_DEMUXER, MSGL_DBG3, + "ds_fill_buffer(unknown 0x%X) called\n", (unsigned int) ds); + } + while (1) { + if (ds->packs) { + demux_packet_t *p = ds->first; #if 0 - if(demux->reference_clock != MP_NOPTS_VALUE) { - if((p->pts != MP_NOPTS_VALUE) && (p->pts > demux->reference_clock) - && (ds->packs < MAX_ACUMULATED_PACKETS)) { - if(demux_fill_buffer(demux,ds)) - continue; - } - } + if (demux->reference_clock != MP_NOPTS_VALUE) { + if ((p->pts != MP_NOPTS_VALUE) + && (p->pts > demux->reference_clock) + && (ds->packs < MAX_ACUMULATED_PACKETS)) { + if (demux_fill_buffer(demux, ds)) + continue; + } + } #endif - // copy useful data: - ds->buffer=p->buffer; - ds->buffer_pos=0; - ds->buffer_size=p->len; - ds->pos=p->pos; - ds->dpos+=p->len; // !!! - ++ds->pack_no; - if (p->pts != MP_NOPTS_VALUE) { - ds->pts=p->pts; - ds->pts_bytes=0; - } - ds->pts_bytes+=p->len; // !!! - if(p->stream_pts != MP_NOPTS_VALUE) demux->stream_pts=p->stream_pts; - ds->flags=p->flags; - // unlink packet: - ds->bytes-=p->len; - ds->current=p; - ds->first=p->next; - if(!ds->first) ds->last=NULL; - --ds->packs; - return 1; //ds->buffer_size; - } - if(demux->audio->packs>=MAX_PACKS || demux->audio->bytes>=MAX_PACK_BYTES){ - mp_msg(MSGT_DEMUXER,MSGL_ERR,MSGTR_TooManyAudioInBuffer,demux->audio->packs,demux->audio->bytes); - mp_msg(MSGT_DEMUXER,MSGL_HINT,MSGTR_MaybeNI); - break; - } - if(demux->video->packs>=MAX_PACKS || demux->video->bytes>=MAX_PACK_BYTES){ - mp_msg(MSGT_DEMUXER,MSGL_ERR,MSGTR_TooManyVideoInBuffer,demux->video->packs,demux->video->bytes); - mp_msg(MSGT_DEMUXER,MSGL_HINT,MSGTR_MaybeNI); - break; - } - if(!demux_fill_buffer(demux,ds)){ - mp_dbg(MSGT_DEMUXER,MSGL_DBG2,"ds_fill_buffer()->demux_fill_buffer() failed\n"); - break; // EOF + // copy useful data: + ds->buffer = p->buffer; + ds->buffer_pos = 0; + ds->buffer_size = p->len; + ds->pos = p->pos; + ds->dpos += p->len; // !!! + ++ds->pack_no; + if (p->pts != MP_NOPTS_VALUE) { + ds->pts = p->pts; + ds->pts_bytes = 0; + } + ds->pts_bytes += p->len; // !!! + if (p->stream_pts != MP_NOPTS_VALUE) + demux->stream_pts = p->stream_pts; + ds->flags = p->flags; + // unlink packet: + ds->bytes -= p->len; + ds->current = p; + ds->first = p->next; + if (!ds->first) + ds->last = NULL; + --ds->packs; + return 1; + } + if (demux->audio->packs >= MAX_PACKS + || demux->audio->bytes >= MAX_PACK_BYTES) { + mp_msg(MSGT_DEMUXER, MSGL_ERR, MSGTR_TooManyAudioInBuffer, + demux->audio->packs, demux->audio->bytes); + mp_msg(MSGT_DEMUXER, MSGL_HINT, MSGTR_MaybeNI); + break; + } + if (demux->video->packs >= MAX_PACKS + || demux->video->bytes >= MAX_PACK_BYTES) { + mp_msg(MSGT_DEMUXER, MSGL_ERR, MSGTR_TooManyVideoInBuffer, + demux->video->packs, demux->video->bytes); + mp_msg(MSGT_DEMUXER, MSGL_HINT, MSGTR_MaybeNI); + break; + } + if (!demux_fill_buffer(demux, ds)) { + mp_dbg(MSGT_DEMUXER, MSGL_DBG2, + "ds_fill_buffer()->demux_fill_buffer() failed\n"); + break; // EOF + } } - } - ds->buffer_pos=ds->buffer_size=0; - ds->buffer=NULL; - mp_msg(MSGT_DEMUXER,MSGL_V,"ds_fill_buffer: EOF reached (stream: %s) \n",ds==demux->audio?"audio":"video"); - ds->eof=1; - return 0; + ds->buffer_pos = ds->buffer_size = 0; + ds->buffer = NULL; + mp_msg(MSGT_DEMUXER, MSGL_V, + "ds_fill_buffer: EOF reached (stream: %s) \n", + ds == demux->audio ? "audio" : "video"); + ds->eof = 1; + return 0; } -int demux_read_data(demux_stream_t *ds,unsigned char* mem,int len){ -int x; -int bytes=0; -while(len>0){ - x=ds->buffer_size-ds->buffer_pos; - if(x==0){ - if(!ds_fill_buffer(ds)) return bytes; - } else { - if(x>len) x=len; - if(mem) fast_memcpy(mem+bytes,&ds->buffer[ds->buffer_pos],x); - bytes+=x;len-=x;ds->buffer_pos+=x; - } -} -return bytes; +int demux_read_data(demux_stream_t *ds, unsigned char *mem, int len) +{ + int x; + int bytes = 0; + while (len > 0) { + x = ds->buffer_size - ds->buffer_pos; + if (x == 0) { + if (!ds_fill_buffer(ds)) + return bytes; + } else { + if (x > len) + x = len; + if (mem) + fast_memcpy(mem + bytes, &ds->buffer[ds->buffer_pos], x); + bytes += x; + len -= x; + ds->buffer_pos += x; + } + } + return bytes; } /** @@ -494,143 +539,157 @@ return bytes; * \return whether pattern was found */ int demux_pattern_3(demux_stream_t *ds, unsigned char *mem, int maxlen, - int *read, uint32_t pattern) { - register uint32_t head = 0xffffff00; - register uint32_t pat = pattern & 0xffffff00; - int total_len = 0; - do { - register unsigned char *ds_buf = &ds->buffer[ds->buffer_size]; - int len = ds->buffer_size - ds->buffer_pos; - register long pos = -len; - if (unlikely(pos >= 0)) { // buffer is empty - ds_fill_buffer(ds); - continue; - } + int *read, uint32_t pattern) +{ + register uint32_t head = 0xffffff00; + register uint32_t pat = pattern & 0xffffff00; + int total_len = 0; do { - head |= ds_buf[pos]; - head <<= 8; - } while (++pos && head != pat); - len += pos; - if (total_len + len > maxlen) - len = maxlen - total_len; - len = demux_read_data(ds, mem ? &mem[total_len] : NULL, len); - total_len += len; - } while ((head != pat || total_len < 3) && total_len < maxlen && !ds->eof); - if (read) - *read = total_len; - return total_len >= 3 && head == pat; + register unsigned char *ds_buf = &ds->buffer[ds->buffer_size]; + int len = ds->buffer_size - ds->buffer_pos; + register long pos = -len; + if (unlikely(pos >= 0)) { // buffer is empty + ds_fill_buffer(ds); + continue; + } + do { + head |= ds_buf[pos]; + head <<= 8; + } while (++pos && head != pat); + len += pos; + if (total_len + len > maxlen) + len = maxlen - total_len; + len = demux_read_data(ds, mem ? &mem[total_len] : NULL, len); + total_len += len; + } while ((head != pat || total_len < 3) && total_len < maxlen && !ds->eof); + if (read) + *read = total_len; + return total_len >= 3 && head == pat; } -void ds_free_packs(demux_stream_t *ds){ - demux_packet_t *dp=ds->first; - while(dp){ - demux_packet_t *dn=dp->next; - free_demux_packet(dp); - dp=dn; - } - if(ds->asf_packet){ - // free unfinished .asf fragments: - free(ds->asf_packet->buffer); - free(ds->asf_packet); - ds->asf_packet=NULL; - } - ds->first=ds->last=NULL; - ds->packs=0; // !!!!! - ds->bytes=0; - if(ds->current) free_demux_packet(ds->current); - ds->current=NULL; - ds->buffer=NULL; - ds->buffer_pos=ds->buffer_size; - ds->pts=0; ds->pts_bytes=0; +void ds_free_packs(demux_stream_t *ds) +{ + demux_packet_t *dp = ds->first; + while (dp) { + demux_packet_t *dn = dp->next; + free_demux_packet(dp); + dp = dn; + } + if (ds->asf_packet) { + // free unfinished .asf fragments: + free(ds->asf_packet->buffer); + free(ds->asf_packet); + ds->asf_packet = NULL; + } + ds->first = ds->last = NULL; + ds->packs = 0; // !!!!! + ds->bytes = 0; + if (ds->current) + free_demux_packet(ds->current); + ds->current = NULL; + ds->buffer = NULL; + ds->buffer_pos = ds->buffer_size; + ds->pts = 0; + ds->pts_bytes = 0; } -int ds_get_packet(demux_stream_t *ds,unsigned char **start){ +int ds_get_packet(demux_stream_t *ds, unsigned char **start) +{ int len; - if(ds->buffer_pos>=ds->buffer_size){ - if(!ds_fill_buffer(ds)){ + if (ds->buffer_pos >= ds->buffer_size) { + if (!ds_fill_buffer(ds)) { // EOF *start = NULL; return -1; - } + } } - len=ds->buffer_size-ds->buffer_pos; + len = ds->buffer_size - ds->buffer_pos; *start = &ds->buffer[ds->buffer_pos]; - ds->buffer_pos+=len; + ds->buffer_pos += len; return len; } -int ds_get_packet_pts(demux_stream_t *ds,unsigned char **start, double *pts) +int ds_get_packet_pts(demux_stream_t *ds, unsigned char **start, double *pts) { int len; *pts = MP_NOPTS_VALUE; - if(ds->buffer_pos>=ds->buffer_size){ - if (!ds_fill_buffer(ds)) { + if (ds->buffer_pos >= ds->buffer_size) { + if (!ds_fill_buffer(ds)) { // EOF *start = NULL; return -1; - } + } } // Return pts unless this read starts from the middle of a packet if (!ds->buffer_pos) - *pts = ds->current->pts; - len=ds->buffer_size-ds->buffer_pos; + *pts = ds->current->pts; + len = ds->buffer_size - ds->buffer_pos; *start = &ds->buffer[ds->buffer_pos]; - ds->buffer_pos+=len; + ds->buffer_pos += len; return len; } -int ds_get_packet_sub(demux_stream_t *ds,unsigned char **start){ +int ds_get_packet_sub(demux_stream_t *ds, unsigned char **start) +{ int len; - if(ds->buffer_pos>=ds->buffer_size){ - *start = NULL; - if(!ds->packs) return -1; // no sub - if(!ds_fill_buffer(ds)) return -1; // EOF + if (ds->buffer_pos >= ds->buffer_size) { + *start = NULL; + if (!ds->packs) + return -1; // no sub + if (!ds_fill_buffer(ds)) + return -1; // EOF } - len=ds->buffer_size-ds->buffer_pos; + len = ds->buffer_size - ds->buffer_pos; *start = &ds->buffer[ds->buffer_pos]; - ds->buffer_pos+=len; + ds->buffer_pos += len; return len; } double ds_get_next_pts(demux_stream_t *ds) { - demuxer_t* demux = ds->demuxer; - while(!ds->first) { - if(demux->audio->packs>=MAX_PACKS || demux->audio->bytes>=MAX_PACK_BYTES){ - mp_msg(MSGT_DEMUXER,MSGL_ERR,MSGTR_TooManyAudioInBuffer,demux->audio->packs,demux->audio->bytes); - mp_msg(MSGT_DEMUXER,MSGL_HINT,MSGTR_MaybeNI); - return MP_NOPTS_VALUE; - } - if(demux->video->packs>=MAX_PACKS || demux->video->bytes>=MAX_PACK_BYTES){ - mp_msg(MSGT_DEMUXER,MSGL_ERR,MSGTR_TooManyVideoInBuffer,demux->video->packs,demux->video->bytes); - mp_msg(MSGT_DEMUXER,MSGL_HINT,MSGTR_MaybeNI); - return MP_NOPTS_VALUE; + demuxer_t *demux = ds->demuxer; + while (!ds->first) { + if (demux->audio->packs >= MAX_PACKS + || demux->audio->bytes >= MAX_PACK_BYTES) { + mp_msg(MSGT_DEMUXER, MSGL_ERR, MSGTR_TooManyAudioInBuffer, + demux->audio->packs, demux->audio->bytes); + mp_msg(MSGT_DEMUXER, MSGL_HINT, MSGTR_MaybeNI); + return MP_NOPTS_VALUE; + } + if (demux->video->packs >= MAX_PACKS + || demux->video->bytes >= MAX_PACK_BYTES) { + mp_msg(MSGT_DEMUXER, MSGL_ERR, MSGTR_TooManyVideoInBuffer, + demux->video->packs, demux->video->bytes); + mp_msg(MSGT_DEMUXER, MSGL_HINT, MSGTR_MaybeNI); + return MP_NOPTS_VALUE; + } + if (!demux_fill_buffer(demux, ds)) + return MP_NOPTS_VALUE; } - if(!demux_fill_buffer(demux,ds)) - return MP_NOPTS_VALUE; - } - return ds->first->pts; + return ds->first->pts; } // ==================================================================== void demuxer_help(void) { - int i; + int i; - mp_msg(MSGT_DEMUXER, MSGL_INFO, "Available demuxers:\n"); - mp_msg(MSGT_DEMUXER, MSGL_INFO, " demuxer: type info: (comment)\n"); - mp_msg(MSGT_IDENTIFY, MSGL_INFO, "ID_DEMUXERS\n"); - for (i = 0; demuxer_list[i]; i++) { - if (demuxer_list[i]->type > DEMUXER_TYPE_MAX) // Don't display special demuxers - continue; - if (demuxer_list[i]->comment && strlen(demuxer_list[i]->comment)) - mp_msg(MSGT_DEMUXER, MSGL_INFO, "%10s %2d %s (%s)\n", - demuxer_list[i]->name, demuxer_list[i]->type, demuxer_list[i]->info, demuxer_list[i]->comment); - else - mp_msg(MSGT_DEMUXER, MSGL_INFO, "%10s %2d %s\n", - demuxer_list[i]->name, demuxer_list[i]->type, demuxer_list[i]->info); - } + mp_msg(MSGT_DEMUXER, MSGL_INFO, "Available demuxers:\n"); + mp_msg(MSGT_DEMUXER, MSGL_INFO, " demuxer: type info: (comment)\n"); + mp_msg(MSGT_IDENTIFY, MSGL_INFO, "ID_DEMUXERS\n"); + for (i = 0; demuxer_list[i]; i++) { + if (demuxer_list[i]->type > DEMUXER_TYPE_MAX) // Don't display special demuxers + continue; + if (demuxer_list[i]->comment && strlen(demuxer_list[i]->comment)) + mp_msg(MSGT_DEMUXER, MSGL_INFO, "%10s %2d %s (%s)\n", + demuxer_list[i]->name, demuxer_list[i]->type, + demuxer_list[i]->info, demuxer_list[i]->comment); + else + mp_msg(MSGT_DEMUXER, MSGL_INFO, "%10s %2d %s\n", + demuxer_list[i]->name, demuxer_list[i]->type, + demuxer_list[i]->info); + } } @@ -644,36 +703,37 @@ void demuxer_help(void) */ int get_demuxer_type_from_name(char *demuxer_name, int *force) { - int i; - long type_int; - char *endptr; + int i; + long type_int; + char *endptr; - if (!demuxer_name || !demuxer_name[0]) - return DEMUXER_TYPE_UNKNOWN; - if (force) *force = demuxer_name[0] == '+'; - if (demuxer_name[0] == '+') - demuxer_name = &demuxer_name[1]; - for (i = 0; demuxer_list[i]; i++) { - if (demuxer_list[i]->type > DEMUXER_TYPE_MAX) // Can't select special demuxers from commandline - continue; - if (strcmp(demuxer_name, demuxer_list[i]->name) == 0) - return demuxer_list[i]->type; - } + if (!demuxer_name || !demuxer_name[0]) + return DEMUXER_TYPE_UNKNOWN; + if (force) + *force = demuxer_name[0] == '+'; + if (demuxer_name[0] == '+') + demuxer_name = &demuxer_name[1]; + for (i = 0; demuxer_list[i]; i++) { + if (demuxer_list[i]->type > DEMUXER_TYPE_MAX) // Can't select special demuxers from commandline + continue; + if (strcmp(demuxer_name, demuxer_list[i]->name) == 0) + return demuxer_list[i]->type; + } - // No match found, try to parse name as an integer (demuxer number) - type_int = strtol(demuxer_name, &endptr, 0); - if (*endptr) // Conversion failed - return -1; - if ((type_int > 0) && (type_int <= DEMUXER_TYPE_MAX)) - return (int)type_int; + // No match found, try to parse name as an integer (demuxer number) + type_int = strtol(demuxer_name, &endptr, 0); + if (*endptr) // Conversion failed + return -1; + if ((type_int > 0) && (type_int <= DEMUXER_TYPE_MAX)) + return (int) type_int; - return -1; + return -1; } -int extension_parsing=1; // 0=off 1=mixed (used only for unstable formats) +int extension_parsing = 1; // 0=off 1=mixed (used only for unstable formats) -int correct_pts=0; -int user_correct_pts=-1; +int correct_pts = 0; +int user_correct_pts = -1; /* NOTE : Several demuxers may be opened at the same time so @@ -688,321 +748,365 @@ int user_correct_pts=-1; (ex: tv,mf). */ -static demuxer_t* demux_open_stream(stream_t *stream, int file_format, - int force, int audio_id, int video_id, int dvdsub_id, - char* filename) { - -//int file_format=(*file_format_ptr); - -demuxer_t *demuxer=NULL; - -sh_video_t *sh_video=NULL; +static demuxer_t *demux_open_stream(stream_t *stream, int file_format, + int force, int audio_id, int video_id, + int dvdsub_id, char *filename) +{ + demuxer_t *demuxer = NULL; -const demuxer_desc_t *demuxer_desc; -int fformat = 0; -int i; + sh_video_t *sh_video = NULL; -//printf("demux_open(%p,%d,%d,%d,%d) \n",stream,file_format,audio_id,video_id,dvdsub_id); + const demuxer_desc_t *demuxer_desc; + int fformat = 0; + int i; -// If somebody requested a demuxer check it -if (file_format) { - if ((demuxer_desc = get_demuxer_desc_from_type(file_format))) { - demuxer = new_demuxer(stream,demuxer_desc->type,audio_id,video_id,dvdsub_id,filename); - if (demuxer_desc->check_file) - fformat = demuxer_desc->check_file(demuxer); - if (force || !demuxer_desc->check_file) - fformat = demuxer_desc->type; - if (fformat != 0) { - if (fformat == demuxer_desc->type) { - demuxer_t *demux2 = demuxer; - // Move messages to demuxer detection code? - mp_msg(MSGT_DEMUXER, MSGL_INFO, MSGTR_Detected_XXX_FileFormat, demuxer_desc->shortdesc); - file_format = fformat; - if (!demuxer->desc->open || (demux2 = demuxer->desc->open(demuxer))) { - demuxer = demux2; - goto dmx_open; + // If somebody requested a demuxer check it + if (file_format) { + if ((demuxer_desc = get_demuxer_desc_from_type(file_format))) { + demuxer = + new_demuxer(stream, demuxer_desc->type, audio_id, video_id, + dvdsub_id, filename); + if (demuxer_desc->check_file) + fformat = demuxer_desc->check_file(demuxer); + if (force || !demuxer_desc->check_file) + fformat = demuxer_desc->type; + if (fformat != 0) { + if (fformat == demuxer_desc->type) { + demuxer_t *demux2 = demuxer; + // Move messages to demuxer detection code? + mp_msg(MSGT_DEMUXER, MSGL_INFO, + MSGTR_Detected_XXX_FileFormat, + demuxer_desc->shortdesc); + file_format = fformat; + if (!demuxer->desc->open + || (demux2 = demuxer->desc->open(demuxer))) { + demuxer = demux2; + goto dmx_open; + } + } else { + // Format changed after check, recurse + free_demuxer(demuxer); + return demux_open_stream(stream, fformat, force, audio_id, + video_id, dvdsub_id, filename); + } + } + // Check failed for forced demuxer, quit + free_demuxer(demuxer); + return NULL; } - } else { - // Format changed after check, recurse - free_demuxer(demuxer); - return demux_open_stream(stream, fformat, force, - audio_id, video_id, dvdsub_id, filename); - } } - // Check failed for forced demuxer, quit - free_demuxer(demuxer); - return NULL; - } -} - -// Test demuxers with safe file checks -for (i = 0; (demuxer_desc = demuxer_list[i]); i++) { - if (demuxer_desc->safe_check) { - demuxer = new_demuxer(stream,demuxer_desc->type,audio_id,video_id,dvdsub_id,filename); - if ((fformat = demuxer_desc->check_file(demuxer)) != 0) { - if (fformat == demuxer_desc->type) { - demuxer_t *demux2 = demuxer; - mp_msg(MSGT_DEMUXER, MSGL_INFO, MSGTR_Detected_XXX_FileFormat, demuxer_desc->shortdesc); - file_format = fformat; - if (!demuxer->desc->open || (demux2 = demuxer->desc->open(demuxer))) { - demuxer = demux2; - goto dmx_open; + // Test demuxers with safe file checks + for (i = 0; (demuxer_desc = demuxer_list[i]); i++) { + if (demuxer_desc->safe_check) { + demuxer = + new_demuxer(stream, demuxer_desc->type, audio_id, video_id, + dvdsub_id, filename); + if ((fformat = demuxer_desc->check_file(demuxer)) != 0) { + if (fformat == demuxer_desc->type) { + demuxer_t *demux2 = demuxer; + mp_msg(MSGT_DEMUXER, MSGL_INFO, + MSGTR_Detected_XXX_FileFormat, + demuxer_desc->shortdesc); + file_format = fformat; + if (!demuxer->desc->open + || (demux2 = demuxer->desc->open(demuxer))) { + demuxer = demux2; + goto dmx_open; + } + } else { + if (fformat == DEMUXER_TYPE_PLAYLIST) + return demuxer; // handled in mplayer.c + // Format changed after check, recurse + free_demuxer(demuxer); + demuxer = + demux_open_stream(stream, fformat, force, audio_id, + video_id, dvdsub_id, filename); + if (demuxer) + return demuxer; // done! + file_format = DEMUXER_TYPE_UNKNOWN; + } + } + free_demuxer(demuxer); + demuxer = NULL; } - } else { - if (fformat == DEMUXER_TYPE_PLAYLIST) - return demuxer; // handled in mplayer.c - // Format changed after check, recurse - free_demuxer(demuxer); - demuxer=demux_open_stream(stream, fformat, force, - audio_id, video_id, dvdsub_id, filename); - if(demuxer) return demuxer; // done! - file_format = DEMUXER_TYPE_UNKNOWN; - } } - free_demuxer(demuxer); - demuxer = NULL; - } -} - -// If no forced demuxer perform file extension based detection -// Ok. We're over the stable detectable fileformats, the next ones are a bit -// fuzzy. So by default (extension_parsing==1) try extension-based detection -// first: -if(file_format==DEMUXER_TYPE_UNKNOWN && filename && extension_parsing==1){ - file_format=demuxer_type_by_filename(filename); - if(file_format!=DEMUXER_TYPE_UNKNOWN){ - // we like recursion :) - demuxer=demux_open_stream(stream, file_format, force, - audio_id, video_id, dvdsub_id, filename); - if(demuxer) return demuxer; // done! - file_format=DEMUXER_TYPE_UNKNOWN; // continue fuzzy guessing... - mp_msg(MSGT_DEMUXER,MSGL_V,"demuxer: continue fuzzy content-based format guessing...\n"); - } -} -// Try detection for all other demuxers -for (i = 0; (demuxer_desc = demuxer_list[i]); i++) { - if (!demuxer_desc->safe_check && demuxer_desc->check_file) { - demuxer = new_demuxer(stream,demuxer_desc->type,audio_id,video_id,dvdsub_id,filename); - if ((fformat = demuxer_desc->check_file(demuxer)) != 0) { - if (fformat == demuxer_desc->type) { - demuxer_t *demux2 = demuxer; - mp_msg(MSGT_DEMUXER, MSGL_INFO, MSGTR_Detected_XXX_FileFormat, demuxer_desc->shortdesc); - file_format = fformat; - if (!demuxer->desc->open || (demux2 = demuxer->desc->open(demuxer))) { - demuxer = demux2; - goto dmx_open; + // If no forced demuxer perform file extension based detection + // Ok. We're over the stable detectable fileformats, the next ones are + // a bit fuzzy. So by default (extension_parsing==1) try extension-based + // detection first: + if (file_format == DEMUXER_TYPE_UNKNOWN && filename + && extension_parsing == 1) { + file_format = demuxer_type_by_filename(filename); + if (file_format != DEMUXER_TYPE_UNKNOWN) { + // we like recursion :) + demuxer = demux_open_stream(stream, file_format, force, audio_id, + video_id, dvdsub_id, filename); + if (demuxer) + return demuxer; // done! + file_format = DEMUXER_TYPE_UNKNOWN; // continue fuzzy guessing... + mp_msg(MSGT_DEMUXER, MSGL_V, + "demuxer: continue fuzzy content-based format guessing...\n"); + } + } + // Try detection for all other demuxers + for (i = 0; (demuxer_desc = demuxer_list[i]); i++) { + if (!demuxer_desc->safe_check && demuxer_desc->check_file) { + demuxer = + new_demuxer(stream, demuxer_desc->type, audio_id, video_id, + dvdsub_id, filename); + if ((fformat = demuxer_desc->check_file(demuxer)) != 0) { + if (fformat == demuxer_desc->type) { + demuxer_t *demux2 = demuxer; + mp_msg(MSGT_DEMUXER, MSGL_INFO, + MSGTR_Detected_XXX_FileFormat, + demuxer_desc->shortdesc); + file_format = fformat; + if (!demuxer->desc->open + || (demux2 = demuxer->desc->open(demuxer))) { + demuxer = demux2; + goto dmx_open; + } + } else { + if (fformat == DEMUXER_TYPE_PLAYLIST) + return demuxer; // handled in mplayer.c + // Format changed after check, recurse + free_demuxer(demuxer); + demuxer = + demux_open_stream(stream, fformat, force, audio_id, + video_id, dvdsub_id, filename); + if (demuxer) + return demuxer; // done! + file_format = DEMUXER_TYPE_UNKNOWN; + } + } + free_demuxer(demuxer); + demuxer = NULL; } - } else { - if (fformat == DEMUXER_TYPE_PLAYLIST) - return demuxer; // handled in mplayer.c - // Format changed after check, recurse - free_demuxer(demuxer); - demuxer=demux_open_stream(stream, fformat, force, - audio_id, video_id, dvdsub_id, filename); - if(demuxer) return demuxer; // done! - file_format = DEMUXER_TYPE_UNKNOWN; - } } - free_demuxer(demuxer); - demuxer = NULL; - } -} -return NULL; -//====== File format recognized, set up these for compatibility: ========= -dmx_open: + return NULL; + //====== File format recognized, set up these for compatibility: ========= + dmx_open: -demuxer->file_format=file_format; + demuxer->file_format = file_format; -if ((sh_video=demuxer->video->sh) && sh_video->bih){ -int biComp=le2me_32(sh_video->bih->biCompression); - mp_msg(MSGT_DEMUX,MSGL_INFO,"VIDEO: [%.4s] %dx%d %dbpp %5.3f fps %5.1f kbps (%4.1f kbyte/s)\n", - (char *)&biComp, - sh_video->bih->biWidth, - sh_video->bih->biHeight, - sh_video->bih->biBitCount, - sh_video->fps, - sh_video->i_bps*0.008f, - sh_video->i_bps/1024.0f ); -} + if ((sh_video = demuxer->video->sh) && sh_video->bih) { + int biComp = le2me_32(sh_video->bih->biCompression); + mp_msg(MSGT_DEMUX, MSGL_INFO, + "VIDEO: [%.4s] %dx%d %dbpp %5.3f fps %5.1f kbps (%4.1f kbyte/s)\n", + (char *) &biComp, sh_video->bih->biWidth, + sh_video->bih->biHeight, sh_video->bih->biBitCount, + sh_video->fps, sh_video->i_bps * 0.008f, + sh_video->i_bps / 1024.0f); + } #ifdef USE_ASS - if (ass_enabled && ass_library) { - for (i = 0; i < MAX_S_STREAMS; ++i) { - sh_sub_t* sh = demuxer->s_streams[i]; - if (sh && sh->type == 'a') { - sh->ass_track = ass_new_track(ass_library); - if (sh->ass_track && sh->extradata) - ass_process_codec_private(sh->ass_track, sh->extradata, sh->extradata_len); - } else if (sh && sh->type != 'v') - sh->ass_track = ass_default_track(ass_library); - } - } + if (ass_enabled && ass_library) { + for (i = 0; i < MAX_S_STREAMS; ++i) { + sh_sub_t *sh = demuxer->s_streams[i]; + if (sh && sh->type == 'a') { + sh->ass_track = ass_new_track(ass_library); + if (sh->ass_track && sh->extradata) + ass_process_codec_private(sh->ass_track, sh->extradata, + sh->extradata_len); + } else if (sh && sh->type != 'v') + sh->ass_track = ass_default_track(ass_library); + } + } #endif -return demuxer; + return demuxer; } -char* audio_stream = NULL; -char* sub_stream = NULL; +char *audio_stream = NULL; +char *sub_stream = NULL; int audio_stream_cache = 0; -char *demuxer_name = NULL; // parameter from -demuxer +char *demuxer_name = NULL; // parameter from -demuxer char *audio_demuxer_name = NULL; // parameter from -audio-demuxer -char *sub_demuxer_name = NULL; // parameter from -sub-demuxer +char *sub_demuxer_name = NULL; // parameter from -sub-demuxer extern int hr_mp3_seek; extern float stream_cache_min_percent; extern float stream_cache_seek_min_percent; -demuxer_t* demux_open(stream_t *vs,int file_format,int audio_id,int video_id,int dvdsub_id,char* filename){ - stream_t *as = NULL,*ss = NULL; - demuxer_t *vd,*ad = NULL,*sd = NULL; - demuxer_t *res; - int afmt =DEMUXER_TYPE_UNKNOWN,sfmt = DEMUXER_TYPE_UNKNOWN ; - int demuxer_type; - int audio_demuxer_type = 0, sub_demuxer_type = 0; - int demuxer_force = 0, audio_demuxer_force = 0, - sub_demuxer_force = 0; - - if ((demuxer_type = get_demuxer_type_from_name(demuxer_name, &demuxer_force)) < 0) { - mp_msg(MSGT_DEMUXER,MSGL_ERR,"-demuxer %s does not exist.\n",demuxer_name); - } - if ((audio_demuxer_type = get_demuxer_type_from_name(audio_demuxer_name, &audio_demuxer_force)) < 0) { - mp_msg(MSGT_DEMUXER,MSGL_ERR,"-audio-demuxer %s does not exist.\n",audio_demuxer_name); - } - if ((sub_demuxer_type = get_demuxer_type_from_name(sub_demuxer_name, &sub_demuxer_force)) < 0) { - mp_msg(MSGT_DEMUXER,MSGL_ERR,"-sub-demuxer %s does not exist.\n",sub_demuxer_name); - } +demuxer_t *demux_open(stream_t *vs, int file_format, int audio_id, + int video_id, int dvdsub_id, char *filename) +{ + stream_t *as = NULL, *ss = NULL; + demuxer_t *vd, *ad = NULL, *sd = NULL; + demuxer_t *res; + int afmt = DEMUXER_TYPE_UNKNOWN, sfmt = DEMUXER_TYPE_UNKNOWN; + int demuxer_type; + int audio_demuxer_type = 0, sub_demuxer_type = 0; + int demuxer_force = 0, audio_demuxer_force = 0, sub_demuxer_force = 0; - if(audio_stream) { - as = open_stream(audio_stream,0,&afmt); - if(!as) { - mp_msg(MSGT_DEMUXER,MSGL_ERR,MSGTR_CannotOpenAudioStream,audio_stream); - return NULL; + if ((demuxer_type = + get_demuxer_type_from_name(demuxer_name, &demuxer_force)) < 0) { + mp_msg(MSGT_DEMUXER, MSGL_ERR, "-demuxer %s does not exist.\n", + demuxer_name); } - if(audio_stream_cache) { - if(!stream_enable_cache(as,audio_stream_cache*1024,audio_stream_cache*1024*(stream_cache_min_percent / 100.0), - audio_stream_cache*1024*(stream_cache_seek_min_percent / 100.0))) { - free_stream(as); - mp_msg(MSGT_DEMUXER,MSGL_ERR,"Can't enable audio stream cache\n"); - return NULL; - } + if ((audio_demuxer_type = + get_demuxer_type_from_name(audio_demuxer_name, + &audio_demuxer_force)) < 0) { + mp_msg(MSGT_DEMUXER, MSGL_ERR, "-audio-demuxer %s does not exist.\n", + audio_demuxer_name); } - } - if(sub_stream) { - ss = open_stream(sub_stream,0,&sfmt); - if(!ss) { - mp_msg(MSGT_DEMUXER,MSGL_ERR,MSGTR_CannotOpenSubtitlesStream,sub_stream); - return NULL; + if ((sub_demuxer_type = + get_demuxer_type_from_name(sub_demuxer_name, + &sub_demuxer_force)) < 0) { + mp_msg(MSGT_DEMUXER, MSGL_ERR, "-sub-demuxer %s does not exist.\n", + sub_demuxer_name); } - } - vd = demux_open_stream(vs, demuxer_type ? demuxer_type : file_format, - demuxer_force, audio_stream ? -2 : audio_id, video_id, - sub_stream ? -2 : dvdsub_id, filename); - if(!vd) { - if(as) free_stream(as); - if(ss) free_stream(ss); - return NULL; - } - if(as) { - ad = demux_open_stream(as, audio_demuxer_type ? audio_demuxer_type : afmt, - audio_demuxer_force, audio_id, -2, -2, audio_stream); - if(!ad) { - mp_msg(MSGT_DEMUXER,MSGL_WARN,MSGTR_OpeningAudioDemuxerFailed,audio_stream); - free_stream(as); + if (audio_stream) { + as = open_stream(audio_stream, 0, &afmt); + if (!as) { + mp_msg(MSGT_DEMUXER, MSGL_ERR, MSGTR_CannotOpenAudioStream, + audio_stream); + return NULL; + } + if (audio_stream_cache) { + if (!stream_enable_cache + (as, audio_stream_cache * 1024, + audio_stream_cache * 1024 * (stream_cache_min_percent / + 100.0), + audio_stream_cache * 1024 * (stream_cache_seek_min_percent / + 100.0))) { + free_stream(as); + mp_msg(MSGT_DEMUXER, MSGL_ERR, + "Can't enable audio stream cache\n"); + return NULL; + } + } } - else if(ad->audio->sh && ((sh_audio_t*)ad->audio->sh)->format == 0x55) // MP3 - hr_mp3_seek=1; // Enable high res seeking - } - if(ss) { - sd = demux_open_stream(ss, sub_demuxer_type ? sub_demuxer_type : sfmt, - sub_demuxer_force, -2, -2, dvdsub_id, sub_stream); - if(!sd) { - mp_msg(MSGT_DEMUXER,MSGL_WARN,MSGTR_OpeningSubtitlesDemuxerFailed,sub_stream); - free_stream(ss); + if (sub_stream) { + ss = open_stream(sub_stream, 0, &sfmt); + if (!ss) { + mp_msg(MSGT_DEMUXER, MSGL_ERR, MSGTR_CannotOpenSubtitlesStream, + sub_stream); + return NULL; + } } - } - if(ad && sd) - res = new_demuxers_demuxer(vd,ad,sd); - else if(ad) - res = new_demuxers_demuxer(vd,ad,vd); - else if(sd) - res = new_demuxers_demuxer(vd,vd,sd); - else - res = vd; + vd = demux_open_stream(vs, demuxer_type ? demuxer_type : file_format, + demuxer_force, audio_stream ? -2 : audio_id, + video_id, sub_stream ? -2 : dvdsub_id, filename); + if (!vd) { + if (as) + free_stream(as); + if (ss) + free_stream(ss); + return NULL; + } + if (as) { + ad = demux_open_stream(as, + audio_demuxer_type ? audio_demuxer_type : afmt, + audio_demuxer_force, audio_id, -2, -2, + audio_stream); + if (!ad) { + mp_msg(MSGT_DEMUXER, MSGL_WARN, MSGTR_OpeningAudioDemuxerFailed, + audio_stream); + free_stream(as); + } else if (ad->audio->sh + && ((sh_audio_t *) ad->audio->sh)->format == 0x55) // MP3 + hr_mp3_seek = 1; // Enable high res seeking + } + if (ss) { + sd = demux_open_stream(ss, sub_demuxer_type ? sub_demuxer_type : sfmt, + sub_demuxer_force, -2, -2, dvdsub_id, + sub_stream); + if (!sd) { + mp_msg(MSGT_DEMUXER, MSGL_WARN, + MSGTR_OpeningSubtitlesDemuxerFailed, sub_stream); + free_stream(ss); + } + } - correct_pts = user_correct_pts; - if (correct_pts < 0) - correct_pts = demux_control(res, DEMUXER_CTRL_CORRECT_PTS, NULL) == DEMUXER_CTRL_OK; - return res; + if (ad && sd) + res = new_demuxers_demuxer(vd, ad, sd); + else if (ad) + res = new_demuxers_demuxer(vd, ad, vd); + else if (sd) + res = new_demuxers_demuxer(vd, vd, sd); + else + res = vd; + + correct_pts = user_correct_pts; + if (correct_pts < 0) + correct_pts = + demux_control(res, DEMUXER_CTRL_CORRECT_PTS, + NULL) == DEMUXER_CTRL_OK; + return res; } -int demux_seek(demuxer_t *demuxer,float rel_seek_secs,float audio_delay,int flags){ - demux_stream_t *d_audio=demuxer->audio; - demux_stream_t *d_video=demuxer->video; - sh_audio_t *sh_audio=d_audio->sh; - sh_video_t *sh_video=d_video->sh; +int demux_seek(demuxer_t *demuxer, float rel_seek_secs, float audio_delay, + int flags) +{ + demux_stream_t *d_audio = demuxer->audio; + demux_stream_t *d_video = demuxer->video; + sh_audio_t *sh_audio = d_audio->sh; + sh_video_t *sh_video = d_video->sh; double tmp = 0; double pts; -if(!demuxer->seekable){ - if(demuxer->file_format==DEMUXER_TYPE_AVI) - mp_msg(MSGT_SEEK,MSGL_WARN,MSGTR_CantSeekRawAVI); + if (!demuxer->seekable) { + if (demuxer->file_format == DEMUXER_TYPE_AVI) + mp_msg(MSGT_SEEK, MSGL_WARN, MSGTR_CantSeekRawAVI); #ifdef USE_TV - else if (demuxer->file_format==DEMUXER_TYPE_TV) - mp_msg(MSGT_SEEK,MSGL_WARN,MSGTR_TVInputNotSeekable); + else if (demuxer->file_format == DEMUXER_TYPE_TV) + mp_msg(MSGT_SEEK, MSGL_WARN, MSGTR_TVInputNotSeekable); #endif - else - mp_msg(MSGT_SEEK,MSGL_WARN,MSGTR_CantSeekFile); - return 0; -} - + else + mp_msg(MSGT_SEEK, MSGL_WARN, MSGTR_CantSeekFile); + return 0; + } // clear demux buffers: - if(sh_audio){ ds_free_packs(d_audio);sh_audio->a_buffer_len=0;} + if (sh_audio) { + ds_free_packs(d_audio); + sh_audio->a_buffer_len = 0; + } ds_free_packs(d_video); ds_free_packs(demuxer->sub); - - demuxer->stream->eof=0; // clear eof flag - demuxer->video->eof=0; - demuxer->audio->eof=0; -#if 0 - if(sh_audio) sh_audio->timer=sh_video->timer; -#else - if(sh_video) sh_video->timer=0; // !!!!!! -#endif + demuxer->stream->eof = 0; + demuxer->video->eof = 0; + demuxer->audio->eof = 0; - if(flags & SEEK_ABSOLUTE) - pts = 0.0f; + if (sh_video) + sh_video->timer = 0; // !!!!!! + + if (flags & SEEK_ABSOLUTE) + pts = 0.0f; else { - if(demuxer->stream_pts == MP_NOPTS_VALUE) - goto dmx_seek; - pts = demuxer->stream_pts; + if (demuxer->stream_pts == MP_NOPTS_VALUE) + goto dmx_seek; + pts = demuxer->stream_pts; } - if(flags & SEEK_FACTOR) { - if(stream_control(demuxer->stream, STREAM_CTRL_GET_TIME_LENGTH, &tmp) == STREAM_UNSUPPORTED) - goto dmx_seek; - pts += tmp * rel_seek_secs; + if (flags & SEEK_FACTOR) { + if (stream_control(demuxer->stream, STREAM_CTRL_GET_TIME_LENGTH, &tmp) + == STREAM_UNSUPPORTED) + goto dmx_seek; + pts += tmp * rel_seek_secs; } else - pts += rel_seek_secs; + pts += rel_seek_secs; - if(stream_control(demuxer->stream, STREAM_CTRL_SEEK_TO_TIME, &pts) != STREAM_UNSUPPORTED) { - demux_control(demuxer, DEMUXER_CTRL_RESYNC, NULL); - return 1; + if (stream_control(demuxer->stream, STREAM_CTRL_SEEK_TO_TIME, &pts) != + STREAM_UNSUPPORTED) { + demux_control(demuxer, DEMUXER_CTRL_RESYNC, NULL); + return 1; } -dmx_seek: -if (demuxer->desc->seek) - demuxer->desc->seek(demuxer,rel_seek_secs,audio_delay,flags); + dmx_seek: + if (demuxer->desc->seek) + demuxer->desc->seek(demuxer, rel_seek_secs, audio_delay, flags); - if (sh_audio) resync_audio_stream(sh_audio); + if (sh_audio) + resync_audio_stream(sh_audio); -return 1; + return 1; } int demux_info_add(demuxer_t *demuxer, const char *opt, const char *param) @@ -1011,21 +1115,21 @@ int demux_info_add(demuxer_t *demuxer, c int n = 0; - for(n = 0; info && info[2*n] != NULL; n++) - { - if(!strcasecmp(opt,info[2*n])) - { - mp_msg(MSGT_DEMUX, MSGL_INFO,MSGTR_DemuxerInfoChanged,opt,param); - free(info[2*n+1]); - info[2*n+1] = strdup(param); - return 0; - } - } - - info = demuxer->info = (char**)realloc(info,(2*(n+2))*sizeof(char*)); - info[2*n] = strdup(opt); - info[2*n+1] = strdup(param); - memset(&info[2*(n+1)],0,2*sizeof(char*)); + for (n = 0; info && info[2 * n] != NULL; n++) { + if (!strcasecmp(opt, info[2 * n])) { + mp_msg(MSGT_DEMUX, MSGL_INFO, MSGTR_DemuxerInfoChanged, opt, + param); + free(info[2 * n + 1]); + info[2 * n + 1] = strdup(param); + return 0; + } + } + + info = demuxer->info = + (char **) realloc(info, (2 * (n + 2)) * sizeof(char *)); + info[2 * n] = strdup(opt); + info[2 * n + 1] = strdup(param); + memset(&info[2 * (n + 1)], 0, 2 * sizeof(char *)); return 1; } @@ -1035,57 +1139,70 @@ int demux_info_print(demuxer_t *demuxer) char **info = demuxer->info; int n; - if(!info) - return 0; + if (!info) + return 0; - mp_msg(MSGT_DEMUX, MSGL_INFO,MSGTR_ClipInfo); - for(n = 0; info[2*n] != NULL ; n++) - { - mp_msg(MSGT_DEMUX, MSGL_INFO, " %s: %s\n",info[2*n],info[2*n+1]); - mp_msg(MSGT_IDENTIFY, MSGL_INFO, "ID_CLIP_INFO_NAME%d=%s\n", n, info[2*n]); - mp_msg(MSGT_IDENTIFY, MSGL_INFO, "ID_CLIP_INFO_VALUE%d=%s\n", n, info[2*n+1]); + mp_msg(MSGT_DEMUX, MSGL_INFO, MSGTR_ClipInfo); + for (n = 0; info[2 * n] != NULL; n++) { + mp_msg(MSGT_DEMUX, MSGL_INFO, " %s: %s\n", info[2 * n], + info[2 * n + 1]); + mp_msg(MSGT_IDENTIFY, MSGL_INFO, "ID_CLIP_INFO_NAME%d=%s\n", n, + info[2 * n]); + mp_msg(MSGT_IDENTIFY, MSGL_INFO, "ID_CLIP_INFO_VALUE%d=%s\n", n, + info[2 * n + 1]); } mp_msg(MSGT_IDENTIFY, MSGL_INFO, "ID_CLIP_INFO_N=%d\n", n); return 0; } -char* demux_info_get(demuxer_t *demuxer, const char *opt) { - int i; - char **info = demuxer->info; +char *demux_info_get(demuxer_t *demuxer, const char *opt) +{ + int i; + char **info = demuxer->info; - for(i = 0; info && info[2*i] != NULL; i++) { - if(!strcasecmp(opt,info[2*i])) - return info[2*i+1]; - } + for (i = 0; info && info[2 * i] != NULL; i++) { + if (!strcasecmp(opt, info[2 * i])) + return info[2 * i + 1]; + } - return NULL; + return NULL; } -int demux_control(demuxer_t *demuxer, int cmd, void *arg) { +int demux_control(demuxer_t *demuxer, int cmd, void *arg) +{ if (demuxer->desc->control) - return demuxer->desc->control(demuxer,cmd,arg); + return demuxer->desc->control(demuxer, cmd, arg); return DEMUXER_CTRL_NOTIMPL; } -double demuxer_get_time_length(demuxer_t *demuxer){ +double demuxer_get_time_length(demuxer_t *demuxer) +{ double get_time_ans; sh_video_t *sh_video = demuxer->video->sh; sh_audio_t *sh_audio = demuxer->audio->sh; // <= 0 means DEMUXER_CTRL_NOTIMPL or DEMUXER_CTRL_DONTKNOW - if (demux_control(demuxer, DEMUXER_CTRL_GET_TIME_LENGTH,(void *)&get_time_ans)<=0) { - if (sh_video && sh_video->i_bps && sh_audio && sh_audio->i_bps) - get_time_ans = (double)(demuxer->movi_end-demuxer->movi_start)/(sh_video->i_bps+sh_audio->i_bps); - else if (sh_video && sh_video->i_bps) - get_time_ans = (double)(demuxer->movi_end-demuxer->movi_start)/sh_video->i_bps; - else if (sh_audio && sh_audio->i_bps) - get_time_ans = (double)(demuxer->movi_end-demuxer->movi_start)/sh_audio->i_bps; - else - get_time_ans=0; + if (demux_control + (demuxer, DEMUXER_CTRL_GET_TIME_LENGTH, (void *) &get_time_ans) <= 0) { + if (sh_video && sh_video->i_bps && sh_audio && sh_audio->i_bps) + get_time_ans = + (double) (demuxer->movi_end - + demuxer->movi_start) / (sh_video->i_bps + + sh_audio->i_bps); + else if (sh_video && sh_video->i_bps) + get_time_ans = + (double) (demuxer->movi_end - + demuxer->movi_start) / sh_video->i_bps; + else if (sh_audio && sh_audio->i_bps) + get_time_ans = + (double) (demuxer->movi_end - + demuxer->movi_start) / sh_audio->i_bps; + else + get_time_ans = 0; } return get_time_ans; } @@ -1097,56 +1214,65 @@ double demuxer_get_time_length(demuxer_t * 0 otherwise * \return the current play time */ -int demuxer_get_current_time(demuxer_t *demuxer){ +int demuxer_get_current_time(demuxer_t *demuxer) +{ double get_time_ans = 0; sh_video_t *sh_video = demuxer->video->sh; - if(demuxer->stream_pts != MP_NOPTS_VALUE) + if (demuxer->stream_pts != MP_NOPTS_VALUE) get_time_ans = demuxer->stream_pts; - else if(sh_video) get_time_ans = sh_video->pts; + else if (sh_video) + get_time_ans = sh_video->pts; return (int) get_time_ans; } -int demuxer_get_percent_pos(demuxer_t *demuxer){ +int demuxer_get_percent_pos(demuxer_t *demuxer) +{ int ans = 0; int res = demux_control(demuxer, DEMUXER_CTRL_GET_PERCENT_POS, &ans); int len = (demuxer->movi_end - demuxer->movi_start) / 100; if (res <= 0) { - if (len > 0) - ans = (demuxer->filepos - demuxer->movi_start) / len; - else - ans = 0; + if (len > 0) + ans = (demuxer->filepos - demuxer->movi_start) / len; + else + ans = 0; } - if (ans < 0) ans = 0; - if (ans > 100) ans = 100; + if (ans < 0) + ans = 0; + if (ans > 100) + ans = 100; return ans; } -int demuxer_switch_audio(demuxer_t *demuxer, int index){ +int demuxer_switch_audio(demuxer_t *demuxer, int index) +{ int res = demux_control(demuxer, DEMUXER_CTRL_SWITCH_AUDIO, &index); if (res == DEMUXER_CTRL_NOTIMPL) - index = demuxer->audio->id; + index = demuxer->audio->id; if (demuxer->audio->id >= 0) - demuxer->audio->sh = demuxer->a_streams[demuxer->audio->id]; + demuxer->audio->sh = demuxer->a_streams[demuxer->audio->id]; else - demuxer->audio->sh = NULL; + demuxer->audio->sh = NULL; return index; } -int demuxer_switch_video(demuxer_t *demuxer, int index){ +int demuxer_switch_video(demuxer_t *demuxer, int index) +{ int res = demux_control(demuxer, DEMUXER_CTRL_SWITCH_VIDEO, &index); if (res == DEMUXER_CTRL_NOTIMPL) - index = demuxer->video->id; + index = demuxer->video->id; if (demuxer->video->id >= 0) - demuxer->video->sh = demuxer->v_streams[demuxer->video->id]; + demuxer->video->sh = demuxer->v_streams[demuxer->video->id]; else - demuxer->video->sh = NULL; + demuxer->video->sh = NULL; return index; } -int demuxer_add_attachment(demuxer_t* demuxer, const char* name, - const char* type, const void* data, size_t size) { +int demuxer_add_attachment(demuxer_t *demuxer, const char *name, + const char *type, const void *data, size_t size) +{ if (!(demuxer->num_attachments & 31)) - demuxer->attachments = realloc(demuxer->attachments, (demuxer->num_attachments + 32) * sizeof(demux_attachment_t)); + demuxer->attachments = realloc(demuxer->attachments, + (demuxer->num_attachments + 32) * sizeof(demux_attachment_t)); demuxer->attachments[demuxer->num_attachments].name = strdup(name); demuxer->attachments[demuxer->num_attachments].type = strdup(type); @@ -1154,24 +1280,27 @@ int demuxer_add_attachment(demuxer_t* de memcpy(demuxer->attachments[demuxer->num_attachments].data, data, size); demuxer->attachments[demuxer->num_attachments].data_size = size; - return demuxer->num_attachments ++; + return demuxer->num_attachments++; } -int demuxer_add_chapter(demuxer_t* demuxer, const char* name, uint64_t start, uint64_t end){ +int demuxer_add_chapter(demuxer_t *demuxer, const char *name, uint64_t start, + uint64_t end) +{ if (demuxer->chapters == NULL) - demuxer->chapters = malloc (32*sizeof(*demuxer->chapters)); + demuxer->chapters = malloc(32 * sizeof(*demuxer->chapters)); else if (!(demuxer->num_chapters % 32)) - demuxer->chapters = realloc (demuxer->chapters, (demuxer->num_chapters + 32) * sizeof(*demuxer->chapters)); + demuxer->chapters = realloc(demuxer->chapters, + (demuxer->num_chapters + 32) * sizeof(*demuxer->chapters)); demuxer->chapters[demuxer->num_chapters].start = start; demuxer->chapters[demuxer->num_chapters].end = end; demuxer->chapters[demuxer->num_chapters].name = strdup(name); - return demuxer->num_chapters ++; + return demuxer->num_chapters++; } /** - * \brief demuxer_seek_chapter() seeks to a chapter in two possible ways: + * \brief demuxer_seek_chapter() seeks to a chapter in two possible ways: * either using the demuxer->chapters structure set by the demuxer * or asking help to the stream layer (e.g. dvd) * \param chapter - chapter number wished - 0-based @@ -1182,50 +1311,58 @@ int demuxer_add_chapter(demuxer_t* demux * \return -1 on error, current chapter if successful */ -int demuxer_seek_chapter(demuxer_t *demuxer, int chapter, int mode, float *seek_pts, int *num_chapters, char **chapter_name) { +int demuxer_seek_chapter(demuxer_t *demuxer, int chapter, int mode, + float *seek_pts, int *num_chapters, + char **chapter_name) +{ int ris; int current, total; sh_video_t *sh_video = demuxer->video->sh; sh_audio_t *sh_audio = demuxer->audio->sh; if (!demuxer->num_chapters || !demuxer->chapters) { - if(!mode) { - ris = stream_control(demuxer->stream, STREAM_CTRL_GET_CURRENT_CHAPTER, ¤t); - if(ris == STREAM_UNSUPPORTED) return -1; + if (!mode) { + ris = stream_control(demuxer->stream, + STREAM_CTRL_GET_CURRENT_CHAPTER, ¤t); + if (ris == STREAM_UNSUPPORTED) + return -1; chapter += current; } - if(demuxer->video->sh) + if (demuxer->video->sh) ds_free_packs(demuxer->video); - if(demuxer->audio->sh) + if (demuxer->audio->sh) ds_free_packs(demuxer->audio); - if(demuxer->sub->id >= 0) + if (demuxer->sub->id >= 0) ds_free_packs(demuxer->sub); - ris = stream_control(demuxer->stream, STREAM_CTRL_SEEK_TO_CHAPTER, &chapter); - if(ris != STREAM_UNSUPPORTED) + ris = + stream_control(demuxer->stream, STREAM_CTRL_SEEK_TO_CHAPTER, + &chapter); + if (ris != STREAM_UNSUPPORTED) demux_control(demuxer, DEMUXER_CTRL_RESYNC, NULL); - if(sh_video) { + if (sh_video) { ds_fill_buffer(demuxer->video); resync_video_stream(sh_video); } - if(sh_audio) { + if (sh_audio) { ds_fill_buffer(demuxer->audio); resync_audio_stream(sh_audio); } - - //exit status may be ok, but main() doesn't have to seek itself (because e.g. dvds depend on sectors, not on pts) + //exit status may be ok, but main() doesn't have to seek itself + // (because e.g. dvds depend on sectors, not on pts) *seek_pts = -1.0; - if(num_chapters) { - if(stream_control(demuxer->stream, STREAM_CTRL_GET_NUM_CHAPTERS, num_chapters) == STREAM_UNSUPPORTED) + if (num_chapters) { + if (stream_control(demuxer->stream, STREAM_CTRL_GET_NUM_CHAPTERS, + num_chapters) == STREAM_UNSUPPORTED) *num_chapters = 0; } - if(chapter_name) { + if (chapter_name) { *chapter_name = NULL; if (num_chapters && *num_chapters) { char *tmp = malloc(16); @@ -1236,18 +1373,20 @@ int demuxer_seek_chapter(demuxer_t *demu } } - return (ris != STREAM_UNSUPPORTED ? chapter : -1); - } else { //chapters structure is set in the demuxer + return ris != STREAM_UNSUPPORTED ? chapter : -1; + } else { // chapters structure is set in the demuxer total = demuxer->num_chapters; - if (mode==1) { //absolute seeking + if (mode == 1) //absolute seeking current = chapter; - } else { //relative seeking + else { //relative seeking uint64_t now; - now = (sh_video ? sh_video->pts : (sh_audio ? sh_audio->pts : 0.)) * 1000 + .5; + now = + (sh_video ? sh_video->pts : (sh_audio ? sh_audio->pts : 0.)) * + 1000 + .5; for (current = total - 1; current >= 0; --current) { - demux_chapter_t* chapter = demuxer->chapters + current; + demux_chapter_t *chapter = demuxer->chapters + current; if (chapter->start <= now) break; } @@ -1255,36 +1394,40 @@ int demuxer_seek_chapter(demuxer_t *demu } if (current >= total) - return -1; - if (current < 0) current = 0; + return -1; + if (current < 0) + current = 0; *seek_pts = demuxer->chapters[current].start / 1000.0; - if(num_chapters) + if (num_chapters) *num_chapters = demuxer->num_chapters; - if(chapter_name) { - if(demuxer->chapters[current].name) + if (chapter_name) { + if (demuxer->chapters[current].name) *chapter_name = strdup(demuxer->chapters[current].name); - else *chapter_name = NULL; + else + *chapter_name = NULL; } return current; } } -int demuxer_get_current_chapter(demuxer_t *demuxer) { +int demuxer_get_current_chapter(demuxer_t *demuxer) +{ int chapter = -1; if (!demuxer->num_chapters || !demuxer->chapters) { if (stream_control(demuxer->stream, STREAM_CTRL_GET_CURRENT_CHAPTER, &chapter) == STREAM_UNSUPPORTED) chapter = -1; - } - else { + } else { sh_video_t *sh_video = demuxer->video->sh; sh_audio_t *sh_audio = demuxer->audio->sh; uint64_t now; - now = (sh_video ? sh_video->pts : (sh_audio?sh_audio->pts:0))*1000+0.5; + now = + (sh_video ? sh_video->pts : (sh_audio ? sh_audio->pts : 0)) * + 1000 + 0.5; for (chapter = demuxer->num_chapters - 1; chapter >= 0; --chapter) { if (demuxer->chapters[chapter].start <= now) break; @@ -1293,24 +1436,25 @@ int demuxer_get_current_chapter(demuxer_ return chapter; } -char *demuxer_chapter_name(demuxer_t *demuxer, int chapter) { +char *demuxer_chapter_name(demuxer_t *demuxer, int chapter) +{ if (demuxer->num_chapters && demuxer->chapters) { - if (chapter >=0 && chapter < demuxer->num_chapters && - demuxer->chapters[chapter].name) + if (chapter >= 0 && chapter < demuxer->num_chapters + && demuxer->chapters[chapter].name) return strdup(demuxer->chapters[chapter].name); } return NULL; } -char *demuxer_chapter_display_name(demuxer_t *demuxer, int chapter) { +char *demuxer_chapter_display_name(demuxer_t *demuxer, int chapter) +{ char *chapter_name = demuxer_chapter_name(demuxer, chapter); if (chapter_name) { char *tmp = malloc(strlen(chapter_name) + 14); snprintf(tmp, 63, "(%d) %s", chapter + 1, chapter_name); - free(chapter_name); + free(chapter_name); return tmp; - } - else { + } else { int chapter_num = demuxer_chapter_count(demuxer); char tmp[30]; if (chapter_num <= 0) @@ -1321,9 +1465,10 @@ char *demuxer_chapter_display_name(demux } } -float demuxer_chapter_time(demuxer_t *demuxer, int chapter, float *end) { +float demuxer_chapter_time(demuxer_t *demuxer, int chapter, float *end) +{ if (demuxer->num_chapters && demuxer->chapters && chapter >= 0 - && chapter < demuxer->num_chapters) { + && chapter < demuxer->num_chapters) { if (end) *end = demuxer->chapters[chapter].end / 1000.0; return demuxer->chapters[chapter].start / 1000.0; @@ -1331,61 +1476,68 @@ float demuxer_chapter_time(demuxer_t *de return -1.0; } -int demuxer_chapter_count(demuxer_t *demuxer) { +int demuxer_chapter_count(demuxer_t *demuxer) +{ if (!demuxer->num_chapters || !demuxer->chapters) { int num_chapters = 0; if (stream_control(demuxer->stream, STREAM_CTRL_GET_NUM_CHAPTERS, &num_chapters) == STREAM_UNSUPPORTED) num_chapters = 0; return num_chapters; - } - else + } else return demuxer->num_chapters; } -int demuxer_angles_count(demuxer_t *demuxer) { - int ris, angles=-1; +int demuxer_angles_count(demuxer_t *demuxer) +{ + int ris, angles = -1; ris = stream_control(demuxer->stream, STREAM_CTRL_GET_NUM_ANGLES, &angles); - if(ris == STREAM_UNSUPPORTED) return -1; + if (ris == STREAM_UNSUPPORTED) + return -1; return angles; } -int demuxer_get_current_angle(demuxer_t *demuxer) { - int ris, curr_angle=-1; +int demuxer_get_current_angle(demuxer_t *demuxer) +{ + int ris, curr_angle = -1; ris = stream_control(demuxer->stream, STREAM_CTRL_GET_ANGLE, &curr_angle); - if(ris == STREAM_UNSUPPORTED) return -1; + if (ris == STREAM_UNSUPPORTED) + return -1; return curr_angle; } -int demuxer_set_angle(demuxer_t *demuxer, int angle) { - int ris, angles=-1; +int demuxer_set_angle(demuxer_t *demuxer, int angle) +{ + int ris, angles = -1; sh_video_t *sh_video = demuxer->video->sh; sh_audio_t *sh_audio = demuxer->audio->sh; angles = demuxer_angles_count(demuxer); - if((angles < 1) || (angle > angles)) return -1; + if ((angles < 1) || (angle > angles)) + return -1; - if(demuxer->video->sh) + if (demuxer->video->sh) ds_free_packs(demuxer->video); - if(demuxer->audio->sh) + if (demuxer->audio->sh) ds_free_packs(demuxer->audio); - if(demuxer->sub->id >= 0) + if (demuxer->sub->id >= 0) ds_free_packs(demuxer->sub); ris = stream_control(demuxer->stream, STREAM_CTRL_SET_ANGLE, &angle); - if(ris == STREAM_UNSUPPORTED) return -1; + if (ris == STREAM_UNSUPPORTED) + return -1; demux_control(demuxer, DEMUXER_CTRL_RESYNC, NULL); - if(sh_video) { + if (sh_video) { ds_fill_buffer(demuxer->video); resync_video_stream(sh_video); } - if(sh_audio) { + if (sh_audio) { ds_fill_buffer(demuxer->audio); resync_audio_stream(sh_audio); } @@ -1393,13 +1545,13 @@ int demuxer_set_angle(demuxer_t *demuxer return angle; } -int demuxer_audio_track_by_lang(demuxer_t* d, char* lang) +int demuxer_audio_track_by_lang(demuxer_t *d, char *lang) { int i, len; lang += strspn(lang, ","); - while((len = strcspn(lang, ",")) > 0) { - for (i=0; i < MAX_A_STREAMS; ++i) { - sh_audio_t* sh = d->a_streams[i]; + while ((len = strcspn(lang, ",")) > 0) { + for (i = 0; i < MAX_A_STREAMS; ++i) { + sh_audio_t *sh = d->a_streams[i]; if (sh && sh->lang && strncmp(sh->lang, lang, len) == 0) return sh->aid; } @@ -1409,13 +1561,13 @@ int demuxer_audio_track_by_lang(demuxer_ return -1; } -int demuxer_sub_track_by_lang(demuxer_t* d, char* lang) +int demuxer_sub_track_by_lang(demuxer_t *d, char *lang) { int i, len; lang += strspn(lang, ","); - while((len = strcspn(lang, ",")) > 0) { - for (i=0; i < MAX_S_STREAMS; ++i) { - sh_sub_t* sh = d->s_streams[i]; + while ((len = strcspn(lang, ",")) > 0) { + for (i = 0; i < MAX_S_STREAMS; ++i) { + sh_sub_t *sh = d->s_streams[i]; if (sh && sh->lang && strncmp(sh->lang, lang, len) == 0) return sh->sid; } @@ -1425,30 +1577,29 @@ int demuxer_sub_track_by_lang(demuxer_t* return -1; } -int demuxer_default_audio_track(demuxer_t* d) +int demuxer_default_audio_track(demuxer_t *d) { int i; - for (i=0; i < MAX_A_STREAMS; ++i) { - sh_audio_t* sh = d->a_streams[i]; + for (i = 0; i < MAX_A_STREAMS; ++i) { + sh_audio_t *sh = d->a_streams[i]; if (sh && sh->default_track) return sh->aid; } - for (i=0; i < MAX_A_STREAMS; ++i) { - sh_audio_t* sh = d->a_streams[i]; + for (i = 0; i < MAX_A_STREAMS; ++i) { + sh_audio_t *sh = d->a_streams[i]; if (sh) return sh->aid; } return -1; } -int demuxer_default_sub_track(demuxer_t* d) +int demuxer_default_sub_track(demuxer_t *d) { int i; - for (i=0; i < MAX_S_STREAMS; ++i) { - sh_sub_t* sh = d->s_streams[i]; + for (i = 0; i < MAX_S_STREAMS; ++i) { + sh_sub_t *sh = d->s_streams[i]; if (sh && sh->default_track) return sh->sid; } return -1; } -
On Sat, Apr 12, 2008 at 05:51:08PM +0200, uau wrote:
Author: uau Date: Sat Apr 12 17:51:08 2008 New Revision: 26411
Log: Reindent demuxer.c
This is not only a reindentation, this also does other cosmetic changes, which makes this simply unreviewable, and also you are supposed to ask about cosmetic changes before for code you don't maintain. I have simply had enough, if this is the only way you can behave, I simply can't and don't want to work with you, no matter how good your code may be. I'll maintain my code as long as that is desired, but I simply don't want to actively work in this environment anymore. Greetings, Reimar Döffinger
On Sat, Apr 12, 2008 at 06:23:08PM +0200, Reimar Döffinger wrote:
On Sat, Apr 12, 2008 at 05:51:08PM +0200, uau wrote:
Log: Reindent demuxer.c
This is not only a reindentation, this also does other cosmetic changes, which makes this simply unreviewable,
I had no trouble reviewing the output of svn diff -r 26410:26411 --diff-cmd diff -x -uwbBE But of course, Subversion is not configured to output this form of diff. I have attached it for your convenience.
and also you are supposed to ask about cosmetic changes before for code you don't maintain. I have simply had enough, if this is the only way you can behave, I simply can't and don't want to work with you, no matter how good your code may be. I'll maintain my code as long as that is desired, but I simply don't want to actively work in this environment anymore.
Reimar, you are overreacting. That said, I'm not happy about the log message. It should clearly state that you also remove commented-out code and useless parentheses. Diego
On Sat, Apr 12, 2008 at 06:44:58PM +0200, Diego Biurrun wrote:
On Sat, Apr 12, 2008 at 06:23:08PM +0200, Reimar Döffinger wrote:
On Sat, Apr 12, 2008 at 05:51:08PM +0200, uau wrote:
Log: Reindent demuxer.c
This is not only a reindentation, this also does other cosmetic changes, which makes this simply unreviewable,
I had no trouble reviewing the output of
svn diff -r 26410:26411 --diff-cmd diff -x -uwbBE
But of course, Subversion is not configured to output this form of diff. I have attached it for your convenience.
Of course I forgot to attach it. Anything else would be a surprise :) Diego
On Sat, 2008-04-12 at 18:23 +0200, Reimar Döffinger wrote:
Log: Reindent demuxer.c
This is not only a reindentation, this also does other cosmetic changes, which makes this simply unreviewable, and also you are supposed to ask
By "unreviewable" do you mean double-checking that it doesn't accidentally break code? It is possible to check that with suitable tools, and I did in fact do such a check myself before committing.
about cosmetic changes before for code you don't maintain. I have simply had enough, if this is the only way you can behave, I simply can't and don't want to work with you, no matter how good your code may be. I'll maintain my code as long as that is desired, but I simply don't want to actively work in this environment anymore.
Does this cause some actual problems for your work? If so, what? If you had some patches with conflicts then I'm willing to help resolve those.
On Sat, 12 Apr 2008 19:51:26 +0300, Uoti Urpala wrote:
On Sat, 2008-04-12 at 18:23 +0200, Reimar Döffinger wrote:
Log: Reindent demuxer.c
This is not only a reindentation, this also does other cosmetic changes, which makes this simply unreviewable, and also you are supposed to ask
By "unreviewable" do you mean double-checking that it doesn't
unreviewable means the diff generated by svn was not human readable. aka it wasnt easy to see what was just a reindent and what else was changed.
about cosmetic changes before for code you don't maintain. I have simply had enough, if this is the only way you can behave, I simply can't and don't want to work with you, no matter how good your code may be. I'll maintain my code as long as that is desired, but I simply don't want to actively work in this environment anymore.
Does this cause some actual problems for your work? If so, what? If you had some patches with conflicts then I'm willing to help resolve those.
can we get you to submit patches next time for stuff like this ? or even without patches just like 'i am planning to reindent demuxer.c, are there any objections or comments' this doesnt help the mplayer code, or speed it up, but it does help the remaining mplayer developers keep track of the codebase. if they cant keep track of changes , they will agree to kick out anyone who is implementing changes without review. and i would hate to see that happen to any developer.
On Sat, Apr 12, 2008 at 06:23:08PM +0200, Reimar Döffinger wrote:
On Sat, Apr 12, 2008 at 05:51:08PM +0200, uau wrote:
Log: Reindent demuxer.c
and also you are supposed to ask about cosmetic changes before for code you don't maintain.
Is that so? I have reindented libpostproc in FFmpeg without asking first. Diego
On Sat, 12 Apr 2008 19:24:16 +0200 Diego Biurrun <diego@biurrun.de> wrote:
On Sat, Apr 12, 2008 at 06:23:08PM +0200, Reimar Döffinger wrote:
On Sat, Apr 12, 2008 at 05:51:08PM +0200, uau wrote:
Log: Reindent demuxer.c
and also you are supposed to ask about cosmetic changes before for code you don't maintain.
Is that so? I have reindented libpostproc in FFmpeg without asking first.
FFmpeg is not MPlayer. MPlayer rules state that, unless the change is trivial, one should post a patch. And even more so if one is not the maintainer of the code, or if the change might be controversial. Both clearly apply here. Albeu
On Sat, 2008-04-12 at 20:06 +0200, Alban Bedel wrote:
FFmpeg is not MPlayer. MPlayer rules state that, unless the change
There are no "MPlayer rules". If you really think there are try to list them. If you claim they're what is listed in svn-howto.txt then almost all developers disregard some of them.
On Sat, Apr 12, 2008 at 07:24:16PM +0200, Diego Biurrun wrote:
On Sat, Apr 12, 2008 at 06:23:08PM +0200, Reimar Döffinger wrote:
On Sat, Apr 12, 2008 at 05:51:08PM +0200, uau wrote:
Log: Reindent demuxer.c
and also you are supposed to ask about cosmetic changes before for code you don't maintain.
Is that so? I have reindented libpostproc in FFmpeg without asking first.
Yes, i dont remember exactly, but you know that i am almost always in favor of such cleanups. That is you knew i would say yes ... I do not think you would have reindented demuxer.c and mixed non reindent changes into it and without any approval from the maintainer or the people who work/understand the code. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No snowflake in an avalanche ever feels responsible. -- Voltaire
On Sat, 12 Apr 2008 18:23:08 +0200 Reimar Döffinger <Reimar.Doeffinger@stud.uni-karlsruhe.de> wrote:
On Sat, Apr 12, 2008 at 05:51:08PM +0200, uau wrote:
Author: uau Date: Sat Apr 12 17:51:08 2008 New Revision: 26411
Log: Reindent demuxer.c
This is not only a reindentation, this also does other cosmetic changes, which makes this simply unreviewable, and also you are supposed to ask about cosmetic changes before for code you don't maintain. I have simply had enough, if this is the only way you can behave, I simply can't and don't want to work with you, no matter how good your code may be. I'll maintain my code as long as that is desired, but I simply don't want to actively work in this environment anymore.
I can only second that. uau repeatedly ignore the rule, and repeatedly ignore complains about it. What next, will we just see svn rm gui appearing on the list? IMHO ppl _clearly_ not ready to abide by the rules, as is the case here, don't deserve an svn account. They can still send patch and let ppl who responsibly use their account commit. Albeu
On Sat, 2008-04-12 at 19:30 +0200, Alban Bedel wrote:
I can only second that. uau repeatedly ignore the rule, and repeatedly ignore complains about it. What next, will we just see svn rm gui appearing on the list?
At least try to maintain some believability in your exaggerations. I've explicitly said that I'm not asking for it to be permanently removed if there are people willing to maintain it.
IMHO ppl _clearly_ not ready to abide by the rules, as is the case here, don't deserve an svn account. They can still send patch and let ppl who responsibly use their account commit.
"The rules" being something which is not actually defined. svn-howto.txt (which seems to be what people talking about "rules" think contains them) neither has all the things claimed as "rules" nor contains ONLY them. It has things nobody follows in practice. It's easy to accuse anyone you want if everyone breaks some "rules" and you can pick which to enforce. Talking about "the rules" is nothing but an appeal to authority when you mean "this is different from how I'm used to doing things / like things done".
On Sat, 12 Apr 2008 20:52:31 +0300 Uoti Urpala <uoti.urpala@pp1.inet.fi> wrote:
On Sat, 2008-04-12 at 19:30 +0200, Alban Bedel wrote:
IMHO ppl _clearly_ not ready to abide by the rules, as is the case here, don't deserve an svn account. They can still send patch and let ppl who responsibly use their account commit.
"The rules" being something which is not actually defined. svn-howto.txt (which seems to be what people talking about "rules" think contains them) neither has all the things claimed as "rules"
Yes, there are a few unwritten rules. Patch welcome.
nor contains ONLY them.
And what's the big deal about it? Again patch welcome if you really feel that the POLICY / RULES section deserve a file on its own.
It has things nobody follows in practice.
Like? You are the only one who ignore those rules.
It's easy to accuse anyone you want if everyone breaks some "rules" and you can pick which to enforce.
You might want to read the rules section again. I see nothing in there that is selectively enforced.
Talking about "the rules" is nothing but an appeal to authority when you mean "this is different from how I'm used to doing things / like things done".
No, it's a set of things the team agreed upon. They can be changed any time. If you don't like something just submit a patch and have it discussed on the list. But stop wasting everybody's time by knowingly breaking the existing rules. Albeu
On Sat, 2008-04-12 at 21:12 +0200, Alban Bedel wrote:
On Sat, 12 Apr 2008 20:52:31 +0300 Uoti Urpala <uoti.urpala@pp1.inet.fi> wrote:
"The rules" being something which is not actually defined. svn-howto.txt (which seems to be what people talking about "rules" think contains them) neither has all the things claimed as "rules"
Yes, there are a few unwritten rules. Patch welcome.
nor contains ONLY them.
And what's the big deal about it? Again patch welcome if you really feel that the POLICY / RULES section deserve a file on its own.
No I don't think it deserves a separate file. Trying to make it into a legal document which strictly defines what is right and what isn't would require a lot of effort and the result still wouldn't be good. People just need to understand it is not such a document.
It has things nobody follows in practice.
Like? You are the only one who ignore those rules.
It's easy to accuse anyone you want if everyone breaks some "rules" and you can pick which to enforce.
You might want to read the rules section again. I see nothing in there that is selectively enforced.
The most obvious example is the "NOTE:" part of paragraph 6, which tells to leave files incorrectly indented - the exact opposite of what is wanted in practice. Other things which several people have done differently without complaints are at least 5 (what was the last complaint about a correct warning fix?), 7 and 9 (would likely have more examples if the project had more people who work outside a limited area, or if there was more code that is clearly "actively maintained").
Talking about "the rules" is nothing but an appeal to authority when you mean "this is different from how I'm used to doing things / like things done".
No, it's a set of things the team agreed upon.
Arpi originally enforced horrible development practices, which probably drove away most people who already had real experience about doing things right. The ones who remained either accepted such practices or at least came to regard them as business as usual. Since then the practices (though not so much any written descriptions) have slowly moved towards more normal ones.
They can be changed any time. If you don't like something just submit a patch and have it discussed on the list.
There is no procedure for resolving any disagreements in case people on the list do not agree. And as I said I don't think any set of rules could really capture good practices.
But stop wasting everybody's time by knowingly breaking the existing rules.
So how did I waste anyone's time? It's plausible that someone could have a conflicting patch, but so far no one has mentioned that. That's a common pattern among the cases where someone complains about "breaking the rules": it's not that the commit prevented anyone else from doing development, but it's the flaming about it that wastes time. So far my commits have overall improved MPlayer. The complaints about not following traditional rules have not achieved anything positive.
On Sat, 12 Apr 2008 23:55:03 +0300 Uoti Urpala <uoti.urpala@pp1.inet.fi> wrote:
On Sat, 2008-04-12 at 21:12 +0200, Alban Bedel wrote:
On Sat, 12 Apr 2008 20:52:31 +0300 Uoti Urpala <uoti.urpala@pp1.inet.fi> wrote:
It's easy to accuse anyone you want if everyone breaks some "rules" and you can pick which to enforce.
You might want to read the rules section again. I see nothing in there that is selectively enforced.
The most obvious example is the "NOTE:" part of paragraph 6, which tells to leave files incorrectly indented
Don't be stupid. It's absolutely not what paragraph 6 says ! (notice the: "if they are mixed with functional changes") Anyway, if you really see someone breaking any of these rules, you are free to complain and ask him to revert commit. But that don't give your the right to break the rules yourself.
Talking about "the rules" is nothing but an appeal to authority when you mean "this is different from how I'm used to doing things / like things done".
No, it's a set of things the team agreed upon.
Arpi originally enforced horrible development practices
IIRC, those rules where modified and improved far after Arpi's retirement. And AFAIK, all developpers but you do actually agree with those rules. Could you name a developper who disagree ?
The ones who remained either accepted such practices or at least came to regard them as business as usual.
I accepted them and followed them because I think they make sens. They can probably be improved, but they can't be disregarded.
They can be changed any time. If you don't like something just submit a patch and have it discussed on the list.
There is no procedure for resolving any disagreements in case people on the list do not agree.
Common practice is to try getting a compromise. If this doesn't work, the majority get to decide. But why are you thinking about disagreements ? If your propositions are good, there won't be any disagreement !
And as I said I don't think any set of rules could really capture good practices.
Fine. Then propose a patch removing all rules...
But stop wasting everybody's time by knowingly breaking the existing rules.
So how did I waste anyone's time? [...] it's not that the commit prevented anyone else from doing development, but it's the flaming about it that wastes time.
Any commit breaking rules will generate flames. You know it very well, for having tested it many times.
So far my commits have overall improved MPlayer.
That, most people don't disagree with. But that don't give you any right to break rules.
The complaints about not following traditional rules have not achieved anything positive.
This was supposed to achieve one goal: making you comply to the rules. Unfortunately this wasn't successfull. BTW: you broke rules 6 and 9 in your recent commit to demux_mkv (which I maintain). I was pretty hangry seeing this. But I didn't even bothered to reply because I know there's no hope getting you to cooperate. (Note that you can still show your good will by reverting this commit) What you seem to achieve best is driving developpers away from MPlayer. Yes, even if you actually improve MPlayer, I think that overall, your are harmfull to MPlayer. I would be happy if you would either: a) accept to follow strictly the rules, and revert your commit when someone notice you broke a rule b) voluntarily renounce to your svn account If you don't choose any of them, then I would support any request to drop your svn account. Sorry to be rude, but I think no one can be as rude as your commits. Aurel
On Sun, Apr 13, 2008 at 12:04:16AM +0200, Aurelien Jacobs wrote:
BTW: you broke rules 6 and 9 in your recent commit to demux_mkv (which I maintain). I was pretty hangry seeing this. But I didn't even bothered to reply because I know there's no hope getting you to cooperate. (Note that you can still show your good will by reverting this commit)
Huh? ------------------------------------------------------------------------ r26412 | uau | 2008-04-12 17:51:11 +0200 (Sat, 12 Apr 2008) | 2 lines demux_mkv.c: Mark some static tables const ------------------------------------------------------------------------ Do you want to see patches for such trivialities? Reimar started a constify commit series a long time ago. We also saw one in FFmpeg. I merely see this as an extension. Diego
On Sun, 2008-04-13 at 00:04 +0200, Aurelien Jacobs wrote:
On Sat, 12 Apr 2008 23:55:03 +0300 Uoti Urpala <uoti.urpala@pp1.inet.fi> wrote:
On Sat, 2008-04-12 at 21:12 +0200, Alban Bedel wrote:
On Sat, 12 Apr 2008 20:52:31 +0300 Uoti Urpala <uoti.urpala@pp1.inet.fi> wrote:
It's easy to accuse anyone you want if everyone breaks some "rules" and you can pick which to enforce.
You might want to read the rules section again. I see nothing in there that is selectively enforced.
The most obvious example is the "NOTE:" part of paragraph 6, which tells to leave files incorrectly indented
Don't be stupid. It's absolutely not what paragraph 6 says ! (notice the: "if they are mixed with functional changes")
Don't be stupid yourself. The last sentence is a separate case where it tells not to indent at all, not just in another commit. It clearly says not to fix the indentation. It was added by Arpi in 2002 - do you really think he thought back then that up to 5 line mixed cosmetic changes were OK, and larger ones needed to be separated?
Anyway, if you really see someone breaking any of these rules, you are free to complain and ask him to revert commit.
"free" to do something idiotic. "Breaking rules" is never by itself a reason to revert something unless there is a benefit to development.
But that don't give your the right to break the rules yourself.
"The rules" being what the people used to vocally complaining if things don't go their preferred way try to enforce.
Talking about "the rules" is nothing but an appeal to authority when you mean "this is different from how I'm used to doing things / like things done".
No, it's a set of things the team agreed upon.
Arpi originally enforced horrible development practices
IIRC, those rules where modified and improved far after Arpi's retirement. And AFAIK, all developpers but you do actually agree with those rules. Could you name a developper who disagree ?
You really think everyone else prefers the same "rules" as you? That all other new developers just happen to have the same preferences? Old developers like you are by far the most vocal complaining about things that others do, often quite disproportionately to their current activity. Who's the newest (to MPlayer) developer who complains about "rule breaking"? Most people will not argue back for long if the most vocal developers on the mailing list argue they're doing wrong. They'll either avoid conflict, believe that the flamers really are right (especially inexperienced ones) or just quit. That I disagree with your preferred development practices is not something unusual. What is more unusual is that I haven't quit and stopped improving MPlayer. The reason you don't have more people "like me" is not that my disagreeing with you would be exceptional, but that you've managed to drive most of those other people away.
They can be changed any time. If you don't like something just submit a patch and have it discussed on the list.
There is no procedure for resolving any disagreements in case people on the list do not agree.
Common practice is to try getting a compromise. If this doesn't work, the majority get to decide. But why are you thinking about disagreements ? If your propositions are good, there won't be any disagreement !
If there is no disagreement there is little reason for trying to make any rules binding.
So how did I waste anyone's time? [...] it's not that the commit prevented anyone else from doing development, but it's the flaming about it that wastes time.
Any commit breaking rules will generate flames. You know it very well, for having tested it many times.
And you conveniently blame the commit for that, not the flamers?
So far my commits have overall improved MPlayer.
That, most people don't disagree with. But that don't give you any right to break rules.
What gives you the right to insist on any "rules"?
The complaints about not following traditional rules have not achieved anything positive.
This was supposed to achieve one goal: making you comply to the rules. Unfortunately this wasn't successfull.
BTW: you broke rules 6 and 9 in your recent commit to demux_mkv (which I maintain). I was pretty hangry seeing this. But I didn't even bothered to reply because I know there's no hope getting you to cooperate. (Note that you can still show your good will by reverting this commit)
An obviously correct commit, which should not be controversial to any degree. To a file for which you're listed as the maintainer, but do very little actual maintenance for. And you were "pretty angry" because of this? And want the commit reverted??? Your position is so completely ridiculous that it's hard to take you seriously at all. Can you even try to explain how following your wishes in a case like this would benefit development - in fact, why it would not clearly hinder development?
What you seem to achieve best is driving developpers away from MPlayer. Yes, even if you actually improve MPlayer, I think that overall, your are harmfull to MPlayer.
And you think your insisting on "the rules" does not drive away developers or harm MPlayer?
Sorry to be rude, but I think no one can be as rude as your commits.
So you think not agreeing with your rules is incredibly rude, but insisting that everyone must precisely follow whatever you choose as rules is perfectly fine and not rude at all?
On Sat, 12 Apr 2008 23:55:03 +0300 Uoti Urpala <uoti.urpala@pp1.inet.fi> wrote:
On Sat, 2008-04-12 at 21:12 +0200, Alban Bedel wrote:
On Sat, 12 Apr 2008 20:52:31 +0300 Uoti Urpala <uoti.urpala@pp1.inet.fi> wrote:
"The rules" being something which is not actually defined. svn-howto.txt (which seems to be what people talking about "rules" think contains them) neither has all the things claimed as "rules"
Yes, there are a few unwritten rules. Patch welcome.
nor contains ONLY them.
And what's the big deal about it? Again patch welcome if you really feel that the POLICY / RULES section deserve a file on its own.
No I don't think it deserves a separate file. Trying to make it into a legal document which strictly defines what is right and what isn't would require a lot of effort and the result still wouldn't be good. People just need to understand it is not such a document.
You mean it contain some stuff you don't like, so we should all ignore it?
It has things nobody follows in practice.
Like? You are the only one who ignore those rules.
It's easy to accuse anyone you want if everyone breaks some "rules" and you can pick which to enforce.
You might want to read the rules section again. I see nothing in there that is selectively enforced.
The most obvious example is the "NOTE:" part of paragraph 6, which tells to leave files incorrectly indented - the exact opposite of what is wanted in practice. Other things which several people have done differently without complaints are at least 5 (what was the last complaint about a correct warning fix?), 7 and 9 (would likely have more examples if the project had more people who work outside a limited area, or if there was more code that is clearly "actively maintained").
You might want to read again, and carefully this time. Point 6 is about mixing cosmetic and functional changes. This has never ever been tolerated. Point 5 is about senseless warnings, the compiler is not always right, just accept it. Point 7 (fill commit message) and 9 (ask before touching code you don't maintain) are also respected by everybody else afaict.
Talking about "the rules" is nothing but an appeal to authority when you mean "this is different from how I'm used to doing things / like things done".
No, it's a set of things the team agreed upon.
Arpi originally enforced horrible development practices, which probably drove away most people who already had real experience about doing things right. The ones who remained either accepted such practices or at least came to regard them as business as usual. Since then the practices (though not so much any written descriptions) have slowly moved towards more normal ones.
That's your opinion. Personally I find most of these rules make sense and are in fact one of the reasons why MPlayer was able to involve so fast. I don't deny that some stuff need updating, still it doesn't mean you can just ignore what you don't like.
They can be changed any time. If you don't like something just submit a patch and have it discussed on the list.
There is no procedure for resolving any disagreements in case people on the list do not agree. And as I said I don't think any set of rules could really capture good practices.
As you seems to define good practices as yours or nothing else, sure we'll never reach an agreement.
But stop wasting everybody's time by knowingly breaking the existing rules.
So how did I waste anyone's time? It's plausible that someone could have a conflicting patch, but so far no one has mentioned that. That's a common pattern among the cases where someone complains about "breaking the rules": it's not that the commit prevented anyone else from doing development, but it's the flaming about it that wastes time.
True. But what are we supposed to do when someone refuse to work as was agreed. Would you prefer if your svn account was just terminated without any warning? Hmm ... perhaps we should just have done that earlier.
So far my commits have overall improved MPlayer.
I don't disagree, still it is a subjective opinion and it is not code you are maintaining.
The complaints about not following traditional rules have not achieved anything positive.
You have achieved pissing off other developers, and some responsible for quiet large parts of MPlayer. I'm pretty sure you don't care, it was for the Greater Good after all. Albeu
On Sun, 2008-04-13 at 00:44 +0200, Alban Bedel wrote:
On Sat, 12 Apr 2008 23:55:03 +0300 Uoti Urpala <uoti.urpala@pp1.inet.fi> wrote:
No I don't think it deserves a separate file. Trying to make it into a legal document which strictly defines what is right and what isn't would require a lot of effort and the result still wouldn't be good. People just need to understand it is not such a document.
You mean it contain some stuff you don't like, so we should all ignore it?
I mean what I said.
You might want to read the rules section again. I see nothing in there that is selectively enforced.
The most obvious example is the "NOTE:" part of paragraph 6, which tells to leave files incorrectly indented - the exact opposite of what is wanted in practice. Other things which several people have done differently without complaints are at least 5 (what was the last complaint about a correct warning fix?), 7 and 9 (would likely have more examples if the project had more people who work outside a limited area, or if there was more code that is clearly "actively maintained").
You might want to read again, and carefully this time. Point 6 is about mixing cosmetic and functional changes. This has never ever been tolerated.
You're wrong. Read my response to Aurelien for more details.
Point 5 is about senseless warnings, the compiler is not always right, just accept it.
But people do often fix them without "asking first" which would be required by svn-howto.
Point 7 (fill commit message) and 9 (ask before touching code you don't maintain) are also respected by everybody else afaict.
There are lots of really bad and short commit messages (do you really need examples?) and several fixes without asking.
Arpi originally enforced horrible development practices, which probably drove away most people who already had real experience about doing things right. The ones who remained either accepted such practices or at least came to regard them as business as usual. Since then the practices (though not so much any written descriptions) have slowly moved towards more normal ones.
That's your opinion. Personally I find most of these rules make sense and are in fact one of the reasons why MPlayer was able to involve so fast. I don't deny that some stuff need updating, still it doesn't mean you can just ignore what you don't like.
MPlayer was able to evolve fast because it got most of the media player attention on Linux which gave it raw manpower. Bad development practices then led to much of the code becoming a mess and development slowing down.
So how did I waste anyone's time? It's plausible that someone could have a conflicting patch, but so far no one has mentioned that. That's a common pattern among the cases where someone complains about "breaking the rules": it's not that the commit prevented anyone else from doing development, but it's the flaming about it that wastes time.
True. But what are we supposed to do when someone refuse to work as was agreed. Would you prefer if your svn account was just terminated without any warning? Hmm ... perhaps we should just have done that earlier.
And exactly why would you need to do anything? Whatever is your idea of what "was agreed" why do you need to raise a fuss if someone doesn't do things the way you want when you can show no actual problem for development? You've done little development yourself in the last year, except some commits during the last few days. Why is it such a problem for you if someone does development in a different way than what you were used to?
So far my commits have overall improved MPlayer.
I don't disagree, still it is a subjective opinion and it is not code you are maintaining.
The complaints about not following traditional rules have not achieved anything positive.
You have achieved pissing off other developers, and some responsible for quiet large parts of MPlayer. I'm pretty sure you don't care, it was for the Greater Good after all.
And you think insisting on your "rules", for the sake of following rules, doesn't piss anyone off?
On Sun, 13 Apr 2008 02:48:26 +0300 Uoti Urpala <uoti.urpala@pp1.inet.fi> wrote:
On Sun, 2008-04-13 at 00:44 +0200, Alban Bedel wrote:
On Sat, 12 Apr 2008 23:55:03 +0300 Uoti Urpala <uoti.urpala@pp1.inet.fi> wrote:
So how did I waste anyone's time? It's plausible that someone could have a conflicting patch, but so far no one has mentioned that. That's a common pattern among the cases where someone complains about "breaking the rules": it's not that the commit prevented anyone else from doing development, but it's the flaming about it that wastes time.
True. But what are we supposed to do when someone refuse to work as was agreed. Would you prefer if your svn account was just terminated without any warning? Hmm ... perhaps we should just have done that earlier.
And exactly why would you need to do anything? Whatever is your idea of what "was agreed" why do you need to raise a fuss if someone doesn't do things the way you want when you can show no actual problem for development? You've done little development yourself in the last year, except some commits during the last few days. Why is it such a problem for you if someone does development in a different way than what you were used to?
Because you regularly commits stuff that you very well know is controversial. You could do like everyone else, send a patch, wait a bit, then commit. But you don't, and as I can hardly believe that your understanding is so impaired, it can only be for the shake of trolling. I'm not often very active on MPlayer as I have other projects I work on, still as a maintainer I somewhat follow what is happening here, and your obvious disregard of any rule is well documented. I think we all hoped you would improve your behaviour with time, sadly nothing changed and it's getting worse. As you might have noticed I'm not the only one who think your behaviour is not tolerable anymore. And the problem is not this very commit, but your stubbornness in refusing to even considering changing your behaviour. Up to now in this thread we have had: 1 dev threatening to leave, 1 to fork, and 2 that asked for suspension of your svn account. Now seeing that you just seems to think such trivialities doesn't matter, you can add me to those voting for the suspension of your svn account.
So far my commits have overall improved MPlayer.
I don't disagree, still it is a subjective opinion and it is not code you are maintaining.
The complaints about not following traditional rules have not achieved anything positive.
You have achieved pissing off other developers, and some responsible for quiet large parts of MPlayer. I'm pretty sure you don't care, it was for the Greater Good after all.
And you think insisting on your "rules", for the sake of following rules, doesn't piss anyone off?
Stop trolling and realise that ppl only tolerated your behaviour up to now. If you are too dim to understand that when you constantly push the boundaries of tolerance, you should expect some back fire, I can't help you. Albeu
On Sun, Apr 13, 2008 at 02:23:47PM +0200, Alban Bedel wrote:
On Sun, 13 Apr 2008 02:48:26 +0300 Uoti Urpala <uoti.urpala@pp1.inet.fi> wrote: [...] behaviour. Up to now in this thread we have had: 1 dev threatening to leave, 1 to fork, and 2 that asked for suspension of your svn account. Now seeing that you just seems to think such trivialities doesn't matter, you can add me to those voting for the suspension of your svn account.
I just wanted to say that i also officially ask for uotis svn account to be closed/removed/suspended. In case this wasnt obvious. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Breaking DRM is a little like attempting to break through a door even though the window is wide open and the only thing in the house is a bunch of things you dont want and which you would get tomorrow for free anyway
On Sun, Apr 13, 2008 at 4:09 PM, Michael Niedermayer <michaelni@gmx.at> wrote:
On Sun, Apr 13, 2008 at 02:23:47PM +0200, Alban Bedel wrote:
On Sun, 13 Apr 2008 02:48:26 +0300 Uoti Urpala <uoti.urpala@pp1.inet.fi> wrote: [...]
behaviour. Up to now in this thread we have had: 1 dev threatening to leave, 1 to fork, and 2 that asked for suspension of your svn account. Now seeing that you just seems to think such trivialities doesn't matter, you can add me to those voting for the suspension of your svn account.
I just wanted to say that i also officially ask for Uoti's svn account to be closed/removed/suspended. In case this wasn't obvious.
So do I.
On Mon, Apr 14, 2008 at 02:02:55PM +0300, Ivan Kalvachev wrote:
On Sun, Apr 13, 2008 at 4:09 PM, Michael Niedermayer <michaelni@gmx.at> wrote:
On Sun, Apr 13, 2008 at 02:23:47PM +0200, Alban Bedel wrote:
On Sun, 13 Apr 2008 02:48:26 +0300 Uoti Urpala <uoti.urpala@pp1.inet.fi> wrote: [...]
behaviour. Up to now in this thread we have had: 1 dev threatening to leave, 1 to fork, and 2 that asked for suspension of your svn account. Now seeing that you just seems to think such trivialities doesn't matter, you can add me to those voting for the suspension of your svn account.
I just wanted to say that i also officially ask for Uoti's svn account to be closed/removed/suspended. In case this wasn't obvious.
So do I.
And to make sure this is officially known to root, iam CCing to them. I, roberto, alban, aurel and ivan request uoti urpalas mplayer svn account to be immedeatly suspended/removed/closed. For more details and wording of the requests of the mplayer developers see the thread on the mailinglist with the same subject. This request is unanimous, no single developer has objected. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In a rich man's house there is no place to spit but his face. -- Diogenes of Sinope
On Monday 14 April 2008 19:19:52 Michael Niedermayer wrote:
On Mon, Apr 14, 2008 at 02:02:55PM +0300, Ivan Kalvachev wrote:
On Sun, Apr 13, 2008 at 4:09 PM, Michael Niedermayer <michaelni@gmx.at> wrote:
On Sun, Apr 13, 2008 at 02:23:47PM +0200, Alban Bedel wrote:
On Sun, 13 Apr 2008 02:48:26 +0300 Uoti Urpala <uoti.urpala@pp1.inet.fi> wrote:
[...]
behaviour. Up to now in this thread we have had: 1 dev threatening to
leave, 1 to fork, and 2 that asked for suspension of your svn account. Now seeing that you just seems to think such trivialities doesn't matter, you can add me to those voting for the suspension of your svn account.
I just wanted to say that i also officially ask for Uoti's svn account to be closed/removed/suspended. In case this wasn't obvious.
So do I.
And to make sure this is officially known to root, iam CCing to them.
I, roberto, alban, aurel and ivan request uoti urpalas mplayer svn account to be immedeatly suspended/removed/closed.
For more details and wording of the requests of the mplayer developers see the thread on the mailinglist with the same subject. This request is unanimous, no single developer has objected.
[...]
I object. His changes are obviously improving mplayer code, and a slight bending of rules IMO does not warrant such measures.
On Monday, 14 April 2008 at 18:11, Evgeniy Stepanov wrote:
On Monday 14 April 2008 19:19:52 Michael Niedermayer wrote:
On Mon, Apr 14, 2008 at 02:02:55PM +0300, Ivan Kalvachev wrote:
On Sun, Apr 13, 2008 at 4:09 PM, Michael Niedermayer <michaelni@gmx.at> wrote:
On Sun, Apr 13, 2008 at 02:23:47PM +0200, Alban Bedel wrote:
On Sun, 13 Apr 2008 02:48:26 +0300 Uoti Urpala <uoti.urpala@pp1.inet.fi> wrote:
[...]
behaviour. Up to now in this thread we have had: 1 dev threatening to
leave, 1 to fork, and 2 that asked for suspension of your svn account. Now seeing that you just seems to think such trivialities doesn't matter, you can add me to those voting for the suspension of your svn account.
I just wanted to say that i also officially ask for Uoti's svn account to be closed/removed/suspended. In case this wasn't obvious.
So do I.
And to make sure this is officially known to root, iam CCing to them.
I, roberto, alban, aurel and ivan request uoti urpalas mplayer svn account to be immedeatly suspended/removed/closed.
For more details and wording of the requests of the mplayer developers see the thread on the mailinglist with the same subject. This request is unanimous, no single developer has objected.
[...]
I object. His changes are obviously improving mplayer code, and a slight bending of rules IMO does not warrant such measures.
Then he can send patches like everyone else. This isn't the first time it's been brought up. Regards, R. -- MPlayer developer and RPMs maintainer: http://mplayerhq.hu http://rpm.livna.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan
Evgeniy Stepanov wrote:
On Monday 14 April 2008 19:19:52 Michael Niedermayer wrote:
On Mon, Apr 14, 2008 at 02:02:55PM +0300, Ivan Kalvachev wrote:
On Sun, Apr 13, 2008 at 4:09 PM, Michael Niedermayer <michaelni@gmx.at> wrote:
On Sun, Apr 13, 2008 at 02:23:47PM +0200, Alban Bedel wrote:
On Sun, 13 Apr 2008 02:48:26 +0300 Uoti Urpala <uoti.urpala@pp1.inet.fi> wrote:
[...]
behaviour. Up to now in this thread we have had: 1 dev threatening to
leave, 1 to fork, and 2 that asked for suspension of your svn account. Now seeing that you just seems to think such trivialities doesn't matter, you can add me to those voting for the suspension of your svn account.
I just wanted to say that i also officially ask for Uoti's svn account to be closed/removed/suspended. In case this wasn't obvious. So do I. And to make sure this is officially known to root, iam CCing to them.
I, roberto, alban, aurel and ivan request uoti urpalas mplayer svn account to be immedeatly suspended/removed/closed.
For more details and wording of the requests of the mplayer developers see the thread on the mailinglist with the same subject. This request is unanimous, no single developer has objected.
[...]
I object. His changes are obviously improving mplayer code, and a slight bending of rules IMO does not warrant such measures.
I object as well. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero
On Mon, Apr 14, 2008 at 6:19 PM, Michael Niedermayer <michaelni@gmx.at> wrote:
On Mon, Apr 14, 2008 at 02:02:55PM +0300, Ivan Kalvachev wrote:
On Sun, Apr 13, 2008 at 4:09 PM, Michael Niedermayer <michaelni@gmx.at> wrote:
On Sun, Apr 13, 2008 at 02:23:47PM +0200, Alban Bedel wrote:
On Sun, 13 Apr 2008 02:48:26 +0300 Uoti Urpala <uoti.urpala@pp1.inet.fi> wrote: [...]
behaviour. Up to now in this thread we have had: 1 dev threatening to leave, 1 to fork, and 2 that asked for suspension of your svn account. Now seeing that you just seems to think such trivialities doesn't matter, you can add me to those voting for the suspension of your svn account.
I just wanted to say that i also officially ask for Uoti's svn account to be closed/removed/suspended. In case this wasn't obvious.
So do I.
And to make sure this is officially known to root, iam CCing to them.
I, roberto, alban, aurel and ivan request uoti urpalas mplayer svn account to be immedeatly suspended/removed/closed.
For more details and wording of the requests of the mplayer developers see the thread on the mailinglist with the same subject. This request is unanimous, no single developer has objected.
I wonder if somebody got any kind of reply from any root about this issue?
On Fri, Apr 25, 2008 at 10:42 AM, Ivan Kalvachev <ikalvachev@gmail.com> wrote:
On Mon, Apr 14, 2008 at 6:19 PM, Michael Niedermayer <michaelni@gmx.at> wrote:
On Mon, Apr 14, 2008 at 02:02:55PM +0300, Ivan Kalvachev wrote:
On Sun, Apr 13, 2008 at 4:09 PM, Michael Niedermayer <michaelni@gmx.at> wrote:
On Sun, Apr 13, 2008 at 02:23:47PM +0200, Alban Bedel wrote:
On Sun, 13 Apr 2008 02:48:26 +0300 Uoti Urpala <uoti.urpala@pp1.inet.fi> wrote: [...]
behaviour. Up to now in this thread we have had: 1 dev threatening to leave, 1 to fork, and 2 that asked for suspension of your svn account. Now seeing that you just seems to think such trivialities doesn't matter, you can add me to those voting for the suspension of your svn account.
I just wanted to say that i also officially ask for Uoti's svn account to be closed/removed/suspended. In case this wasn't obvious.
So do I.
And to make sure this is officially known to root, iam CCing to them.
I, roberto, alban, aurel and ivan request uoti urpalas mplayer svn account to be immedeatly suspended/removed/closed.
For more details and wording of the requests of the mplayer developers see the thread on the mailinglist with the same subject. This request is unanimous, no single developer has objected.
I wonder if somebody got any kind of reply from any root about this issue?
Hello? Anybody?
On Tue, May 06, 2008 at 01:51:54AM +0300, Ivan Kalvachev wrote:
On Fri, Apr 25, 2008 at 10:42 AM, Ivan Kalvachev <ikalvachev@gmail.com> wrote:
On Mon, Apr 14, 2008 at 6:19 PM, Michael Niedermayer <michaelni@gmx.at> wrote:
On Mon, Apr 14, 2008 at 02:02:55PM +0300, Ivan Kalvachev wrote:
On Sun, Apr 13, 2008 at 4:09 PM, Michael Niedermayer <michaelni@gmx.at> wrote:
On Sun, Apr 13, 2008 at 02:23:47PM +0200, Alban Bedel wrote:
On Sun, 13 Apr 2008 02:48:26 +0300 Uoti Urpala <uoti.urpala@pp1.inet.fi> wrote: [...]
behaviour. Up to now in this thread we have had: 1 dev threatening to leave, 1 to fork, and 2 that asked for suspension of your svn account. Now seeing that you just seems to think such trivialities doesn't matter, you can add me to those voting for the suspension of your svn account.
I just wanted to say that i also officially ask for Uoti's svn account to be closed/removed/suspended. In case this wasn't obvious.
So do I.
And to make sure this is officially known to root, iam CCing to them.
I, roberto, alban, aurel and ivan request uoti urpalas mplayer svn account to be immedeatly suspended/removed/closed.
For more details and wording of the requests of the mplayer developers see the thread on the mailinglist with the same subject. This request is unanimous, no single developer has objected.
I wonder if somebody got any kind of reply from any root about this issue?
Hello? Anybody?
Silence down there! Be glad the holy emperor diego just ordered your arms and legs cut off and in his endless mercy allowed you to continue to live to feed the royal rats. Its not customary that his highness is so mercyfull to such blasphemous acts as speaking against one of the upper nobility. Unthinkable how one could claim that his highnesses lover could have broken half of all laws. And then even the request for punishment, who do you think you are? ... a mere commoner. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I am the wisest man alive, for I know one thing, and that is that I know nothing. -- Socrates
On Tuesday 06 May 2008 03:45:47 Michael Niedermayer wrote:
On Tue, May 06, 2008 at 01:51:54AM +0300, Ivan Kalvachev wrote:
On Fri, Apr 25, 2008 at 10:42 AM, Ivan Kalvachev
I wonder if somebody got any kind of reply from any root about this issue?
Hello? Anybody?
Silence down there! Be glad the holy emperor diego just ordered your arms and legs cut off and in his endless mercy allowed you to continue to live to feed the royal rats. Its not customary that his highness is so mercyfull to such blasphemous acts as speaking against one of the upper nobility. Unthinkable how one could claim that his highnesses lover could have broken half of all laws. And then even the request for punishment, who do you think you are? ... a mere commoner.
[...]
Diego, indeed your silence on this subject is VERY annoying. I'd like to know why you never answered, even though I didn't ask Uoti's account suspension
On Tue, May 06, 2008 at 01:18:58PM +0200, Nico Sabbi wrote:
On Tuesday 06 May 2008 03:45:47 Michael Niedermayer wrote:
On Tue, May 06, 2008 at 01:51:54AM +0300, Ivan Kalvachev wrote:
On Fri, Apr 25, 2008 at 10:42 AM, Ivan Kalvachev
I wonder if somebody got any kind of reply from any root about this issue?
Hello? Anybody?
Silence down there! Be glad the holy emperor diego just ordered your arms and legs cut off and in his endless mercy allowed you to continue to live to feed the royal rats. Its not customary that his highness is so mercyfull to such blasphemous acts as speaking against one of the upper nobility. Unthinkable how one could claim that his highnesses lover could have broken half of all laws. And then even the request for punishment, who do you think you are? ... a mere commoner.
[...]
Diego, indeed your silence on this subject is VERY annoying.
I made a promise to myself to never let the commit : flame ratio drop below 1. This makes it hard to participate in extended flame wars. My time is more scarce than it used to be these days and my motivation to throw it away with silly bickering is lower than ever.
I'd like to know why you never answered, even though I didn't ask Uoti's account suspension
If I answered, flames would surely be the result, no matter what I said. And what do you expect me to do? With what rationale? With legitimacy granted by whom? These mailing lists are not a good place to resolve conflicts. There are far too many destructive flamers around. I have talked privately with Reimar and Uoti and a few other people. That was much more effective. Diego
On Wednesday 07 May 2008 01:10:12 Diego Biurrun wrote:
On Tue, May 06, 2008 at 01:18:58PM +0200, Nico Sabbi wrote:
I'd like to know why you never answered, even though I didn't ask Uoti's account suspension
If I answered, flames would surely be the result, no matter what I said.
And what do you expect me to do? With what rationale? With legitimacy granted by whom?
it seems obvious and simple to me: many developers against one asked Uoti's suspension, thus Uoti's account should have been suspended with the legitimacy given to you by the overwhelming majority of developers' requests
These mailing lists are not a good place to resolve conflicts. There are far too many destructive flamers around. I have talked privately with Reimar and Uoti and a few other people. That was much more effective.
Diego
with what result?
On Wednesday, 07 May 2008 at 10:58, Nico Sabbi wrote:
On Wednesday 07 May 2008 01:10:12 Diego Biurrun wrote: [...] it seems obvious and simple to me: many developers against one asked Uoti's suspension, thus Uoti's account should have been suspended with the legitimacy given to you by the overwhelming majority of developers' requests
These mailing lists are not a good place to resolve conflicts. There are far too many destructive flamers around. I have talked
BTW, it's funny of you to say that. I've seen far more flames on IRC than on the mailing lists recently.
privately with Reimar and Uoti and a few other people. That was much more effective.
with what result?
And why the secrecy? Regards, R. -- MPlayer contributor, RPMs maintainer: http://mplayerhq.hu http://rpm.livna.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan
On Wed, May 07, 2008 at 11:38:27AM +0200, Dominik 'Rathann' Mierzejewski wrote:
On Wednesday, 07 May 2008 at 10:58, Nico Sabbi wrote:
On Wednesday 07 May 2008 01:10:12 Diego Biurrun wrote: [...] it seems obvious and simple to me: many developers against one asked Uoti's suspension, thus Uoti's account should have been suspended with the legitimacy given to you by the overwhelming majority of developers' requests
These mailing lists are not a good place to resolve conflicts. There are far too many destructive flamers around. I have talked
BTW, it's funny of you to say that. I've seen far more flames on IRC than on the mailing lists recently.
I never said that IRC channels were better.
privately with Reimar and Uoti and a few other people. That was much more effective.
with what result?
And why the secrecy?
There was no secrecy involved, I have mentioned this on IRC several times. Talks are still ongoing. Diego
On Wed, May 07, 2008 at 10:58:28AM +0200, Nico Sabbi wrote:
On Wednesday 07 May 2008 01:10:12 Diego Biurrun wrote:
These mailing lists are not a good place to resolve conflicts. There are far too many destructive flamers around. I have talked privately with Reimar and Uoti and a few other people. That was much more effective.
with what result?
Basically Reimar and Uoti and I making amends, but talks are not yet finished. Diego
On Wed, 2008-05-07 at 10:58 +0200, Nico Sabbi wrote:
On Wednesday 07 May 2008 01:10:12 Diego Biurrun wrote:
And what do you expect me to do? With what rationale? With legitimacy granted by whom?
it seems obvious and simple to me: many developers against one asked Uoti's suspension, thus Uoti's account should have been
You think no one else would be against it? Really? Not even myself? If people counts should decide do you think there should be a vote again? Or do really think everyone already treated the posted flames as a vote and counting numbers from that would be meaningful?
suspended with the legitimacy given to you by the overwhelming majority of developers' requests
Even considering only the posted opinions, if you add just me to the public "against" side and then compare what each side has actually done for MPlayer during the last year which side do you think has done more? I think the suspension requests are in a pretty clear minority by that metric. And if you think that's not a fair metric, it's IMO a much better one than head count to predict which half of a project will be successful if people do consider the issue a "my way or I quit/fork" one. Even knowing the unusual tastes of some MPlayer developers I did not expect those commits to cause such controversy. That someone would use them as a reason to seriously demand revoking commit access crosses the line from reasonable disagreement to idiocy.
Uoti Urpala wrote:
On Wed, 2008-05-07 at 10:58 +0200, Nico Sabbi wrote:
On Wednesday 07 May 2008 01:10:12 Diego Biurrun wrote:
And what do you expect me to do? With what rationale? With legitimacy granted by whom?
it seems obvious and simple to me: many developers against one asked Uoti's suspension, thus Uoti's account should have been
You think no one else would be against it? Really? Not even myself?
Do you seriously mean you should be allowed to vote against your own account revocation ? Funny :-)
If people counts should decide do you think there should be a vote again? Or do really think everyone already treated the posted flames as a vote and counting numbers from that would be meaningful?
I think that counting numbers from that is meaningful. But if you think it's not, feel free to start a vote yourself !
suspended with the legitimacy given to you by the overwhelming majority of developers' requests
Even considering only the posted opinions, if you add just me to the public "against" side and then compare what each side has actually done for MPlayer during the last year which side do you think has done more?
Huh.. I fail to see how relevant this could be !
I think the suspension requests are in a pretty clear minority by that metric.
One can always find a metric which suits his own needs, whatever the issue is.
And if you think that's not a fair metric,
Obviously I do.
it's IMO a much better one than head count to predict which half of a project will be successful if people do consider the issue a "my way or I quit/fork" one.
Do you think other developers will quit/fork if your account is revoked ? Or do you think you've done more for mplayer than every other developers ?
Even knowing the unusual tastes of some MPlayer developers I did not expect those commits to cause such controversy.
You know very well that it's not only about those commits. It's about your constant refusal to follow commonly accepted rules. You are even denying that there are some commonly accepted rules. And you seem to deny that some kind of rules are necessary to do collaborative work. This kind of mentality is incompatible with having an svn account. And this is clearly explained in svn-howto.txt: What follows now is a basic introduction to Subversion and some MPlayer-specific guidelines. Read it at least once, if you are granted commit privileges to the MPlayer project you are expected to be familiar with these rules. Well, the wording may be a bit loose, but this just mean that accepting an svn account implies accepting written rules. Thus refusing those rules means you refuse your svn account.
That someone would use them as a reason to seriously demand revoking commit access crosses the line from reasonable disagreement to idiocy.
I will refrain responding to insults. Aurel
On Fri, May 09, 2008 at 02:22:39AM +0200, Aurelien Jacobs wrote:
Uoti Urpala wrote:
On Wed, 2008-05-07 at 10:58 +0200, Nico Sabbi wrote:
On Wednesday 07 May 2008 01:10:12 Diego Biurrun wrote:
And what do you expect me to do? With what rationale? With legitimacy granted by whom?
it seems obvious and simple to me: many developers against one asked Uoti's suspension, thus Uoti's account should have been
You think no one else would be against it? Really? Not even myself?
Do you seriously mean you should be allowed to vote against your own account revocation ? Funny :-)
Why should he not be allowed to vote? Do you consider all developers equal or not? Diego
On Fri, 2008-05-09 at 02:22 +0200, Aurelien Jacobs wrote:
Uoti Urpala wrote:
On Wed, 2008-05-07 at 10:58 +0200, Nico Sabbi wrote:
it seems obvious and simple to me: many developers against one asked Uoti's suspension, thus Uoti's account should have been
You think no one else would be against it? Really? Not even myself?
Do you seriously mean you should be allowed to vote against your own account revocation ? Funny :-)
Yes (even if there was a real vote, which the flaming has not been). A voting system which worked otherwise would have nasty problems. Consider a project with two developers. By your system both would have an overwhelming majority to expel the other. Or consider a vote to revoke multiple accounts. Either you'd inconsistently allow the the targets to vote now, or it would be possible to exclude a set of people from voting (in the extreme case a single developer proposing to expel everyone else and being the only one eligible to vote).
Even considering only the posted opinions, if you add just me to the public "against" side and then compare what each side has actually done for MPlayer during the last year which side do you think has done more?
Huh.. I fail to see how relevant this could be !
You think it's completely irrelevant who does actual development? And I did give more explanation in the following sentences.
I think the suspension requests are in a pretty clear minority by that metric.
One can always find a metric which suits his own needs, whatever the issue is.
If you have reasons why another metric would be better then state them. Making insinuations like your statement above is cheap rhetoric without any actual content.
And if you think that's not a fair metric,
Obviously I do.
Then which one is better? A pure head count even if it means there are the people who actually do things and others who interfere with work while doing little themselves?
it's IMO a much better one than head count to predict which half of a project will be successful if people do consider the issue a "my way or I quit/fork" one.
Do you think other developers will quit/fork if your account is revoked ? Or do you think you've done more for mplayer than every other developers ?
How many do you think will quit/fork if it is not revoked? I think I can do more for MPlayer than the people likely to quit. Plus I expect it to be easier to get new developers if there are less people with your attitude around.
Even knowing the unusual tastes of some MPlayer developers I did not expect those commits to cause such controversy.
You know very well that it's not only about those commits. It's about your constant refusal to follow commonly accepted rules. You are even denying that there are some commonly accepted rules. And you seem to deny that some kind of rules are necessary to do collaborative work.
Rules which override common sense are not required, nor rules that are enforced "because they're rules". Breaking a "rule" is never a reason to revert a commit, much less demand someone be expelled from the project, if you can't show actual harm independently of the rules. MPlayer does not have rules that could be enforced literally. I already gave examples why svn-howto.txt is not suitable for that earlier.
This kind of mentality is incompatible with having an svn account. And this is clearly explained in svn-howto.txt:
What follows now is a basic introduction to Subversion and some MPlayer-specific guidelines. Read it at least once, if you are granted commit privileges to the MPlayer project you are expected to be familiar with these rules.
Well, the wording may be a bit loose, but this just mean that accepting an svn account implies accepting written rules. Thus refusing those rules means you refuse your svn account.
svn-howto.txt is not a binding constitution that would define what having an svn account means. And as I already explained earlier you just CANNOT interpret the "rules" in that file literally. You're selectively choosing what you try to enforce.
On Fri, May 09, 2008 at 07:25:36PM +0300, Uoti Urpala wrote: [...]
it's IMO a much better one than head count to predict which half of a project will be successful if people do consider the issue a "my way or I quit/fork" one.
Do you think other developers will quit/fork if your account is revoked ? Or do you think you've done more for mplayer than every other developers ?
How many do you think will quit/fork if it is not revoked?
How many did already leave silently since you joined the project?
I think I can do more for MPlayer than the people likely to quit. Plus I expect it to be easier to get new developers if there are less people with your attitude around.
Well we have dozends of people complaining about you, and a small number who think your contributions outweight the damage you do. But we have none, not one complaining about aurel, reimar, roberto, me, alban, ... diego complained about ivan and arpi in the past, though both of them have contributed much more than you did so far.
Even knowing the unusual tastes of some MPlayer developers I did not expect those commits to cause such controversy.
You know very well that it's not only about those commits. It's about your constant refusal to follow commonly accepted rules. You are even denying that there are some commonly accepted rules. And you seem to deny that some kind of rules are necessary to do collaborative work.
Rules which override common sense are not required, nor rules that are
The problem is your common sense is very different from everyone elses common sense. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I am the wisest man alive, for I know one thing, and that is that I know nothing. -- Socrates
Hi! Wednesday 07 May 2008 01:10-kor Diego Biurrun ezt írta:
These mailing lists are not a good place to resolve conflicts. There are far too many destructive flamers around.
Thanks for the credit Diego :) I have not partcipated in the discussion before, but now that you ask, I will say that IMO it is not wise to complain about some ancient and not neccesserily consensual "cvs rules" by older inactive MPlayer developers, just to get rid of a newer - but one of the last active - MPlayer developer. I think a more forgiving and constructive environment would better serve the interests of the project.
Diego
best regards, Denes
On Thu, May 8, 2008 at 2:29 AM, Balatoni Denes <dbalatoni@interware.hu> wrote:
Hi!
Wednesday 07 May 2008 01:10-kor Diego Biurrun ezt írta:
These mailing lists are not a good place to resolve conflicts. There are far too many destructive flamers around.
Thanks for the credit Diego :) I have not partcipated in the discussion before, but now that you ask, I will say that IMO it is not wise to complain about some ancient and not neccesserily consensual "cvs rules" by older inactive MPlayer developers, just to get rid of a newer - but one of the last active - MPlayer developer. I think a more forgiving and constructive environment would better serve the interests of the project.
Where did you get the idea that this is some kind of conflict of the generations? You are the second person that puts this speculation, but this is the first time I see it in public. In short, this is not true. Reimar and Uoti are from the same generation and yet Uoti managed to infuriate Reimar too. (Reimar also used to be much more active than Uoti, in fact he still is) I'll tell it in another way - there are much newer recruits (than Uoti) that doesn't cause any kind of trouble. They don't have problem to follow every advice they get. The problem with Uoti is that he doesn't accept any kind of advice from anybody. --- Every project have some rules. Most of the projects don't have them written because it is enough developers to tell newbies how and why they do the thing this way. This is also the reason MPlayer "rules" are written in patch and commit manuals. MPlayer project rules are not something ancient put down by faceless gods, that nobody remembers anymore. They are in fact End Terms of many old (and forgotten for good) flamewars. Some of the rules have been revised after their initial writing. Throwing these rules away would simply restart all these flamewars again. The problem with Uoti is that he couldn't convince enough developers to change the rules to his liking, so he doesn't follow them. This causes flamewar on each commit that break some rule. And there is no end of it. --- It is completely normal somebody who doesn't want to play with the team, to be thrown out the team.
On Fri, May 09, 2008 at 04:08:42PM +0300, Ivan Kalvachev wrote:
On Thu, May 8, 2008 at 2:29 AM, Balatoni Denes <dbalatoni@interware.hu> wrote:
Hi!
Wednesday 07 May 2008 01:10-kor Diego Biurrun ezt írta:
These mailing lists are not a good place to resolve conflicts. There are far too many destructive flamers around.
Thanks for the credit Diego :) I have not partcipated in the discussion before, but now that you ask, I will say that IMO it is not wise to complain about some ancient and not neccesserily consensual "cvs rules" by older inactive MPlayer developers, just to get rid of a newer - but one of the last active - MPlayer developer. I think a more forgiving and constructive environment would better serve the interests of the project.
Where did you get the idea that this is some kind of conflict of the generations? You are the second person that puts this speculation, but this is the first time I see it in public.
Also there are plenty of new developers who strongly disagree with uoti, though they do not seem to dare to say so in public. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I count him braver who overcomes his desires than him who conquers his enemies for the hardest victory is over self. -- Aristotle
Michael Niedermayer wrote:
Also there are plenty of new developers who strongly disagree with uoti, though they do not seem to dare to say so in public.
Maybe if this issue got discussed on the proper mailing list it would receive more comments... lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero
On Wed, May 7, 2008 at 2:10 AM, Diego Biurrun <diego@biurrun.de> wrote:
On Tue, May 06, 2008 at 01:18:58PM +0200, Nico Sabbi wrote:
On Tuesday 06 May 2008 03:45:47 Michael Niedermayer wrote:
On Tue, May 06, 2008 at 01:51:54AM +0300, Ivan Kalvachev wrote:
On Fri, Apr 25, 2008 at 10:42 AM, Ivan Kalvachev
I wonder if somebody got any kind of reply from any root about this issue?
Hello? Anybody?
Silence down there! Be glad the holy emperor diego just ordered your arms and legs cut off and in his endless mercy allowed you to continue to live to feed the royal rats. Its not customary that his highness is so mercyfull to such blasphemous acts as speaking against one of the upper nobility. Unthinkable how one could claim that his highnesses lover could have broken half of all laws. And then even the request for punishment, who do you think you are? ... a mere commoner.
[...]
Diego, indeed your silence on this subject is VERY annoying.
I made a promise to myself to never let the commit : flame ratio drop below 1. This makes it hard to participate in extended flame wars. My time is more scarce than it used to be these days and my motivation to throw it away with silly bickering is lower than ever.
Your attempts to put the flames down won't work, even if you manage to do it temporally. As long as the gas continues to leak, every next flame would get bigger and more devastating. Even if I am not around to give it a spark. And, it have long went over the simple flamewar. This just won't go away. It is war on principles. For once you'll have to solve the problem in its root. Like it or not.
I'd like to know why you never answered, even though I didn't ask Uoti's account suspension
If I answered, flames would surely be the result, no matter what I said. And what do you expect me to do? With what rationale? With legitimacy granted by whom?
For the people from the people. (developers) You are server admin, you don't have to question official request.You are expected to do what you are told to do. Everything else is ABUSE of power you have been entrusted with. Your speculation that there is no authority and/or majority that could throw out a loose developer, is absurd on its own. I'll ask it in another way. Whom legitimacy would you accept?
Michael Niedermayer wrote:
On Mon, Apr 14, 2008 at 02:02:55PM +0300, Ivan Kalvachev wrote:
On Sun, Apr 13, 2008 at 4:09 PM, Michael Niedermayer <michaelni@gmx.at> wrote:
On Sun, Apr 13, 2008 at 02:23:47PM +0200, Alban Bedel wrote:
On Sun, 13 Apr 2008 02:48:26 +0300 Uoti Urpala <uoti.urpala@pp1.inet.fi> wrote: [...]
behaviour. Up to now in this thread we have had: 1 dev threatening to leave, 1 to fork, and 2 that asked for suspension of your svn account. Now seeing that you just seems to think such trivialities doesn't matter, you can add me to those voting for the suspension of your svn account.
I just wanted to say that i also officially ask for Uoti's svn account to be closed/removed/suspended. In case this wasn't obvious. So do I.
And to make sure this is officially known to root, iam CCing to them.
I, roberto, alban, aurel and ivan request uoti urpalas mplayer svn account to be immedeatly suspended/removed/closed.
For more details and wording of the requests of the mplayer developers see the thread on the mailinglist with the same subject.
which mailing list? which subject?
This request is unanimous, no single developer has objected.
I object since I have no much data and this thread in cvslog is an ugly hydra with too much content even for the main ml. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero
On 6/4/08, Luca Barbato <lu_zero@gentoo.org> wrote:
Michael Niedermayer wrote:
On Mon, Apr 14, 2008 at 02:02:55PM +0300, Ivan Kalvachev wrote:
On Sun, Apr 13, 2008 at 4:09 PM, Michael Niedermayer <michaelni@gmx.at> wrote:
On Sun, Apr 13, 2008 at 02:23:47PM +0200, Alban Bedel wrote:
On Sun, 13 Apr 2008 02:48:26 +0300 Uoti Urpala <uoti.urpala@pp1.inet.fi> wrote: [...]
behaviour. Up to now in this thread we have had: 1 dev threatening to leave, 1 to fork, and 2 that asked for suspension of your svn account. Now seeing that you just seems to think such trivialities doesn't matter, you can add me to those voting for the suspension of your svn account.
I just wanted to say that i also officially ask for Uoti's svn account to be closed/removed/suspended. In case this wasn't obvious. So do I.
And to make sure this is officially known to root, iam CCing to them.
I, roberto, alban, aurel and ivan request uoti urpalas mplayer svn account to be immedeatly suspended/removed/closed.
For more details and wording of the requests of the mplayer developers see the thread on the mailinglist with the same subject.
which mailing list? which subject?
It is written in the subject.
This request is unanimous, no single developer has objected.
I object since I have no much data and this thread in cvslog is an ugly hydra with too much content even for the main ml.
Where have you been the last 2 months. On the moon? ;) Just start reading, chronologically. If you want summary. Reimar was fed up with Uoti commit of some lame stuff and said he is going to limit his work only on keeping his own code working. Diego went on phone crusade to convince Raimar that he have to swallow everything that Uoti does, for the good of the project, and he succeeded. Other people said Uoti should go, because he haven't changed his ways. And gave recent examples. Diego at first did not even wanted to give official reply. Later he refused to execute his promise that if Uoti creates problems again he would "... comment out uoti from the passwd file with no qualms". He used same excuses as the last year. Oh, Uoti confessed that he never intended to follow any MPlayer rules.
Ivan Kalvachev wrote:
It is written in the subject.
[MPlayer-cvslog] r26411 - trunk/libmpdemux/demuxer.c then, wrong subject and wrong mailing list.
Where have you been the last 2 months. On the moon? ;)
It would had been a better place, yet it is unrelated.
Just start reading, chronologically.
I'm doing.
If you want summary.
Reimar was fed up with Uoti commit of some lame stuff and said he is going to limit his work only on keeping his own code working. Diego went on phone crusade to convince Raimar that he have to swallow everything that Uoti does, for the good of the project, and he succeeded.
Other people said Uoti should go, because he haven't changed his ways. And gave recent examples. Diego at first did not even wanted to give official reply. Later he refused to execute his promise that if Uoti creates problems again he would "... comment out uoti from the passwd file with no qualms". He used same excuses as the last year.
Oh, Uoti confessed that he never intended to follow any MPlayer rules.
I'll have to read the whole thread and reply =_= lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero
On Wed, Jun 04, 2008 at 03:22:54PM +0200, Luca Barbato wrote:
Ivan Kalvachev wrote: [...]
Just start reading, chronologically.
I'm doing.
If you want summary.
Reimar was fed up with Uoti commit of some lame stuff and said he is going to limit his work only on keeping his own code working. Diego went on phone crusade to convince Raimar that he have to swallow everything that Uoti does, for the good of the project, and he succeeded.
Other people said Uoti should go, because he haven't changed his ways. And gave recent examples. Diego at first did not even wanted to give official reply. Later he refused to execute his promise that if Uoti creates problems again he would "... comment out uoti from the passwd file with no qualms". He used same excuses as the last year.
Oh, Uoti confessed that he never intended to follow any MPlayer rules.
I'll have to read the whole thread and reply =_=
Yes, please do Also if you havnt seen the previous controversies surrounding uotis commits and his reaction to complaints. You should read them as well, looking just at this one gives a somewhat skewed picture. I did not vote for his account to be closed because he made a misstake but because this is the 3rd or 4th time he violates the same rules and he clearly said he would not follow any rule that differs from what he consideres common sense. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Concerning the gods, I have no means of knowing whether they exist or not or of what sort they may be, because of the obscurity of the subject, and the brevity of human life -- Protagoras
Ivan Kalvachev wrote:
On 6/4/08, Luca Barbato <lu_zero@gentoo.org> wrote:
Michael Niedermayer wrote:
This request is unanimous, no single developer has objected.
I object since I have no much data and this thread in cvslog is an ugly hydra with too much content even for the main ml.
Where have you been the last 2 months. On the moon? ;) Just start reading, chronologically.
If you want summary.
<snip>
Oh, Uoti confessed that he never intended to follow any MPlayer rules.
For the record, this - and only this - is why I would consider it reasonable, or perhaps even obligatory, to remove his commit access. I do not, and TTBOMM never did, consider any of his actual commits to be that severe of an offense, except as they represent manifestations of this point. Some of them would be offenses, yes, but so far as I recall none of them - not even collectively - would be enough to justify kicking him out. (I'm not sure why I'm bothering to mention this, since I'm not a developer and have no reason to expect any of those who are to value my opinion... but for some reason it feels worth mentioning anyway.) -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Secrecy is the beginning of tyranny.
The Wanderer wrote:
Ivan Kalvachev wrote:
On 6/4/08, Luca Barbato <lu_zero@gentoo.org> wrote:
I object since I have no much data and this thread in cvslog is an ugly hydra with too much content even for the main ml.
Where have you been the last 2 months. On the moon? ;) Just start reading, chronologically.
If you want summary.
<snip>
Oh, Uoti confessed that he never intended to follow any MPlayer rules.
For the record, this - and only this - is why I would consider it reasonable, or perhaps even obligatory, to remove his commit access. I do not, and TTBOMM never did, consider any of his actual commits to be that severe of an offense, except as they represent manifestations of this point. Some of them would be offenses, yes, but so far as I recall none of them - not even collectively - would be enough to justify kicking him out.
(I'm not sure why I'm bothering to mention this, since I'm not a developer and have no reason to expect any of those who are to value my opinion... but for some reason it feels worth mentioning anyway.)
I think I've figured out why I wanted to mention it. From my perspective, this is the single central issue at the core of all of this; if this is not considered to be a problem, then there effectively is no problem worth getting very excited about, certainly none worth going on about as long as this has gone. This issue has been raised a few times, by a few different people - all of them, as far as I remember, among those making a (fuss, stink, festering pit of flames) about the matters involved. I have not seen any of the people not fitting that description address it, with the exception of Uoti himself, and since he is the source of the issue he cannot resolve it on his own short of conceding entirely. Diego and the other people not in the "making a fuss" category seem to, in general, be of the opinion that what problem there may have been has been resolved, and there is no longer any remaining problem worth discussing here. From my perspective, and I think that of at least a few other people, this issue *is* a problem - indeed, as I said, the central problem - and as far as I can tell not only has it not been resolved, it has not even been acknowledged by those who consider the problem to be resolved. I do not think that this matter will die down, at least not permanently, unless and until this issue is dealt with. -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Secrecy is the beginning of tyranny.
On Sun, 2008-04-13 at 14:23 +0200, Alban Bedel wrote:
Because you regularly commits stuff that you very well know is controversial. You could do like everyone else, send a patch, wait a bit, then commit. But you don't, and as I can hardly believe that your understanding is so impaired, it can only be for the shake of trolling.
I did not expect these commits to cause such controversy. I think it should be obvious enough why I don't want to send a patch first for every change (it usually causes more overhead than the work needed for the actual change). And controversial or not I don't make commits for trolling purposes.
Uoti Urpala a écrit :
On Sun, 2008-04-13 at 14:23 +0200, Alban Bedel wrote:
Because you regularly commits stuff that you very well know is controversial. You could do like everyone else, send a patch, wait a bit, then commit. But you don't, and as I can hardly believe that your understanding is so impaired, it can only be for the shake of trolling.
I did not expect these commits to cause such controversy. I think it should be obvious enough why I don't want to send a patch first for every change (it usually causes more overhead than the work needed for the actual change). And controversial or not I don't make commits for trolling purposes.
It's hard to say but it'd be better if you do your own fork of MPlayer, development would go faster and you'd finally have the player the way you want it to be (obviously all other MPlayer devels are against you ...). For the record, my opinion doesn't matter much but I'd not vote for your account revocation if I was asked about, as I find this whole situation childish (and just writing so, I guess mine will be asked, but it's not like if I cared much loosing such a high privilege :-) The best for you (and probably other people) would be you start your own player based on ffmpeg libs only, getting rid of all old MPlayer code. What would you miss after all ? The only parts that are getting updated from MPlayer are everything that natively comes from ffmpeg and all the Makefile/configure stuff. Btw, what is the new MPlayer _development_ related mailing list email address ? I'd like to subscribe to, as this one seems not to serve this purpose any longer for quite a looooong time now. PS: yeah I know, it's always more oil on the fire PS2: flames are the only active parts of MPlayer. Ben
On Fri, May 09, 2008 at 04:48:34PM +0200, Benjamin Zores wrote:
For the record, my opinion doesn't matter much but I'd not vote for your account revocation if I was asked about,
Since when does your vote not count? Diego
Diego Biurrun a écrit :
On Fri, May 09, 2008 at 04:48:34PM +0200, Benjamin Zores wrote:
For the record, my opinion doesn't matter much but I'd not vote for your account revocation if I was asked about,
Since when does your vote not count?
Since I haven't contributed enough to MPlayer (especially on the past months) to consider myself as a genuine developer to the project. Hence, I do not consider myself as relevant for Uoti's trial. The problem to me is that I don't see much active developers any more. The few that used to be, generally try to work on FFMpeg instead, because trying to change Player is not worth the pain. One thing I've noticed over the years, working on different projects is that what most projects are missing are contributors. The lack of manpower is usually number one reason of project failure and I find it just sad that so much energy is wasted to flame and to depreciate people's work and motivation while it could be used instead to make the project grows. So yes, if you want my opinion, Uoti may have broken some rules (who the hell defined them after all, probably not a whole team) but all he wanted to do is contribute for the good of MPlayer and imho, he can't be blamed for that. Ironically, I see that some of the people who asked for his account revocation may indeed follow these rules, as the few times they actually commit something, they have few chances to break them (and no I won't give names, even under torture :-) Ben
On Fri, May 09, 2008 at 06:10:21PM +0200, Benjamin Zores wrote:
Diego Biurrun a écrit :
On Fri, May 09, 2008 at 04:48:34PM +0200, Benjamin Zores wrote:
For the record, my opinion doesn't matter much but I'd not vote for your account revocation if I was asked about,
Since when does your vote not count?
Since I haven't contributed enough to MPlayer (especially on the past months) to consider myself as a genuine developer to the project. Hence, I do not consider myself as relevant for Uoti's trial.
Hey, wait a moment there! You have committed 32 times this year and 144 times in the last year. Not one of the people who voted for closing Uoti's account comes even close to that, you have done more than all of them *combined*! Some numbers: 2007 2008 total roberto 58 21 79 ivan 24 9 33 alban 17 11 28 aurelien 8 0 8 michael 2 0 2 ------------------------------------- combined 109 31 140 Here are the rest of the people that committed in 2008 excluding translators that do not work on the code (voroshil does both) and FFmpeg-only developers, up to r26680 (also excluding homepage commits): diego 1038 504 1542 reimar 690 246 936 voroshil 312 8 320 nico 212 43 255 benjamin 144 32 176 ulion 153 13 166 eugeni 106 56 162 uoti 99 20 119 guillaume 93 24 117 compn 97 16 113 cehoyos 89 8 97 ivo 65 4 69 zuxy 55 12 67 vayne 14 3 17 corey 9 6 15 attila 10 5 15 loren 11 2 13 rik 1 3 4 So we have 7 people that are more active than any of the voters combined.
The problem to me is that I don't see much active developers any more. The few that used to be, generally try to work on FFMpeg instead, because trying to change Player is not worth the pain.
One thing I've noticed over the years, working on different projects is that what most projects are missing are contributors. The lack of manpower is usually number one reason of project failure and I find it just sad that so much energy is wasted to flame and to depreciate people's work and motivation while it could be used instead to make the project grows.
So yes, if you want my opinion, Uoti may have broken some rules (who the hell defined them after all, probably not a whole team) but all he wanted to do is contribute for the good of MPlayer and imho, he can't be blamed for that. Ironically, I see that some of the people who asked for his account revocation may indeed follow these rules, as the few times they actually commit something, they have few chances to break them (and no I won't give names, even under torture :-)
100% agreed. Diego
Diego Biurrun a écrit :
On Fri, May 09, 2008 at 06:10:21PM +0200, Benjamin Zores wrote:
Diego Biurrun a écrit :
On Fri, May 09, 2008 at 04:48:34PM +0200, Benjamin Zores wrote:
For the record, my opinion doesn't matter much but I'd not vote for your account revocation if I was asked about, Since when does your vote not count? Since I haven't contributed enough to MPlayer (especially on the past months) to consider myself as a genuine developer to the project. Hence, I do not consider myself as relevant for Uoti's trial.
Hey, wait a moment there! You have committed 32 times this year and 144 times in the last year. Not one of the people who voted for closing Uoti's account comes even close to that, you have done more than all of them *combined*! Some numbers:
2007 2008 total
roberto 58 21 79 ivan 24 9 33 alban 17 11 28 aurelien 8 0 8 michael 2 0 2 ------------------------------------- combined 109 31 140
Here are the rest of the people that committed in 2008 excluding translators that do not work on the code (voroshil does both) and FFmpeg-only developers, up to r26680 (also excluding homepage commits):
diego 1038 504 1542 reimar 690 246 936 voroshil 312 8 320 nico 212 43 255 benjamin 144 32 176 ulion 153 13 166 eugeni 106 56 162 uoti 99 20 119 guillaume 93 24 117 compn 97 16 113 cehoyos 89 8 97 ivo 65 4 69 zuxy 55 12 67 vayne 14 3 17 corey 9 6 15 attila 10 5 15 loren 11 2 13 rik 1 3 4
Thx for these valuable info. However, it's maybe only my opinion but I find these numbers damn small for such a project. From what I see here (2008 only), it looks like a 2-men project and considering that you mostly work on makefiles/configure/headers/copyright stuff only (there's no depreciation in there, don't take it wrong), it looks like Reimar's the only developer :-) However, one can't be judged only by the quantity of commits he did. Ironically, for Uoti's defense, he commited as much in 2007-2008 as his 5 opponents :-) Though, the above numbers just confirm my thoughts about the life status of the project ... sigh :-( Considering myself as inactive and being 2007's #6 and 2008's #5 is a bit weird to me. Ben
Hello, On Sat, May 10, 2008 at 01:38:06PM +0200, Diego Biurrun wrote:
diego 1038 504 1542 reimar 690 246 936 voroshil 312 8 320 nico 212 43 255 benjamin 144 32 176 ulion 153 13 166 eugeni 106 56 162 uoti 99 20 119 guillaume 93 24 117 compn 97 16 113 cehoyos 89 8 97 ivo 65 4 69 zuxy 55 12 67 vayne 14 3 17 corey 9 6 15 attila 10 5 15 loren 11 2 13 rik 1 3 4
Before anyone flames too hard: I asked for Diego to publish these numbers. The problem is, as some of those appearing later have shown, that we have no opinions from some important people. Thing is, I really want everyone to stay on this project and happily work together. Not sure if that is possible anymore - and in that case I want a more objective overview of the opinions that I currently have. To summarize the dilemma for me personally: I very much respect and agree with most of Michael's opinions, but there are a few problems: They basically result in a FFmpeg-style review policy. That works really great most of the time for FFmpeg, but I think it just can not work with MPlayer currently, we do not have enough people willing to do that kind of effort to get patches included. So from that perspective I do think it might be better for the long term good to basically let Uoti (and also other future developers) work mostly on their own conditions (though I seriously wish for a bit more consideration for other people from his side). But: I am not ready to do this in a "let the whole team roll over to accommodate one developer"-style. So if it is as it looked originally that everyone thinks this kind of thing is a bad idea, I would never propose it. But now with other developers showing up with different opinions things are a bit different. Now some of you probably wonder about my completely different opinion now, given I started the whole thing. Well, the thing is, this "proposed" kind of development is against my ideals of development: as accessible to as many as possible, evolutionary development, working as one team together etc. But I think that that style is just not bearable for MPlayer right now. I would find it very sad if taking such a direction will cause some of the long-time developers who did a lot for MPlayer to leave, but on the other hand almost all of these developers are active very rarely and on parts of MPlayer that are moving into FFmpeg and as much as I appreciate them or even consider friends, just doing what they want does not seem the right for MPlayer as a project either. I hope you understand that I kept out of this for so long, because any path I see here is one I'd hate to go. Greetings, Reimar Döffinger
Hi! Saturday 10 May 2008 14:20-kor Reimar Döffinger ezt írta:
They basically result in a FFmpeg-style review policy. That works really great most of the time for FFmpeg, but I think it just can not work with MPlayer currently, we do not have enough people willing to do that kind of effort to get patches included.
Actually, this was also my point before the current disagreement, when raising my concerns about your patch accaptance methods, also in agreement with Benjamin's observations. Now I feel vindicated :) (not that there is anything to be particalarly happy about right now).
Greetings, Reimar Döffinger
bye Denes
On Sat, May 10, 2008 at 02:45:49PM +0200, Balatoni Denes wrote:
Saturday 10 May 2008 14:20-kor Reimar Döffinger ezt írta:
They basically result in a FFmpeg-style review policy. That works really great most of the time for FFmpeg, but I think it just can not work with MPlayer currently, we do not have enough people willing to do that kind of effort to get patches included.
Actually, this was also my point before the current disagreement, when raising my concerns about your patch accaptance methods, also in agreement with Benjamin's observations. Now I feel vindicated :) (not that there is anything to be particalarly happy about right now).
I (as far as I remember) never disagreed with your concerns, I just said that that is all you will get from me, because it is simply the best can do concerning patch review, especially given the time I have. I do wish for others to do reviews and am happy if they are more kind to the submitters. Greetings, Reimar Döffinger
Hi! Saturday 10 May 2008 15:10-kor Reimar Döffinger ezt írta:
On Sat, May 10, 2008 at 02:45:49PM +0200, Balatoni Denes wrote:
Saturday 10 May 2008 14:20-kor Reimar Döffinger ezt írta:
They basically result in a FFmpeg-style review policy. That works really great most of the time for FFmpeg, but I think it just can not work with MPlayer currently, we do not have enough people willing to do that kind of effort to get patches included.
Actually, this was also my point before the current disagreement, when raising my concerns about your patch accaptance methods, also in agreement with Benjamin's observations. Now I feel vindicated :) (not that there is anything to be particalarly happy about right now).
I (as far as I remember) never disagreed with your concerns, I just said that that is all you will get from me, because it is simply the best can do concerning patch review, especially given the time I have. I do wish for others to do reviews and am happy if they are more kind to the submitters.
I am sorry, "your" meant the whole Mplayer project, not personally you. I actually agree with much of what you (and Benjamin) said - it doesn't matter, but that was all I wanted to point out.
Greetings, Reimar Döffinger
bye Denes
On Sat, May 10, 2008 at 3:20 PM, Reimar Döffinger <Reimar.Doeffinger@stud.uni-karlsruhe.de> wrote:
Hello, On Sat, May 10, 2008 at 01:38:06PM +0200, Diego Biurrun wrote:
diego 1038 504 1542 reimar 690 246 936 voroshil 312 8 320 nico 212 43 255 benjamin 144 32 176 ulion 153 13 166 eugeni 106 56 162 uoti 99 20 119
Reimar, looking at these numbers, I'd say that you are de-facto project leader. Diego is not coder and none of his commits changes the way MPlayer works. He is doing a lot of refactoring and cosmetics. Reimar, please take the Project Leader role and resolve the situation in the way you like it.
On Sat, May 10, 2008 at 04:27:50PM +0300, Ivan Kalvachev wrote:
On Sat, May 10, 2008 at 3:20 PM, Reimar Döffinger <Reimar.Doeffinger@stud.uni-karlsruhe.de> wrote:
Hello, On Sat, May 10, 2008 at 01:38:06PM +0200, Diego Biurrun wrote:
diego 1038 504 1542 reimar 690 246 936 voroshil 312 8 320 nico 212 43 255 benjamin 144 32 176 ulion 153 13 166 eugeni 106 56 162 uoti 99 20 119
Reimar, looking at these numbers, I'd say that you are de-facto project leader. Diego is not coder and none of his commits changes the way MPlayer works. He is doing a lot of refactoring and cosmetics.
Reimar, please take the Project Leader role and resolve the situation in the way you like it.
yes, seconded, and my emphasis is on _resolve_. Not the "playing deaf" diego does, the leader should make clear statements, not selective silence. democracy yes or no democracy? uoti keeps his account no matter what he does or not? and where is the line, how far can a developer go beforfe loosing his account? or is the line based on diegos personal feeling? He once wanted to close ivans ffmpegs svn account (that was around the time when he also wanted to close all doc maintainers access to ffmpeg svn), its in strong contrast to how uoti is treated. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No great genius has ever existed without some touch of madness. -- Aristotle
On Sat, May 10, 2008 at 05:21:59PM +0200, Michael Niedermayer wrote:
On Sat, May 10, 2008 at 04:27:50PM +0300, Ivan Kalvachev wrote:
On Sat, May 10, 2008 at 3:20 PM, Reimar Döffinger <Reimar.Doeffinger@stud.uni-karlsruhe.de> wrote:
On Sat, May 10, 2008 at 01:38:06PM +0200, Diego Biurrun wrote:
diego 1038 504 1542 reimar 690 246 936 voroshil 312 8 320 nico 212 43 255 benjamin 144 32 176 ulion 153 13 166 eugeni 106 56 162 uoti 99 20 119
Reimar, looking at these numbers, I'd say that you are de-facto project leader. Diego is not coder and none of his commits changes the way MPlayer works. He is doing a lot of refactoring and cosmetics.
Reimar, please take the Project Leader role and resolve the situation in the way you like it.
yes, seconded, and my emphasis is on _resolve_. Not the "playing deaf" diego
I will write up a statement/explanation before the weekend draws to a close. I have no time right now because I am meeting friends in a few minutes.
He once wanted to close ivans ffmpegs svn account
You are not giving a correct representation of the facts here. It was Mans that proposed closing Ivan's FFmpeg account, I just seconded that notion. You may, and you are certainly free to, disagree with me, but I don't consider committing non-free code to be in the same class of issue as removing parentheses in a commit (wrongly) labeled "indent". You were also not around when Mans and I discussed with a stubborn Ivan on IRC. But mind you, this issue is long forgotten, forgiven even, so let us please not start a subflamewar out of this.
(that was around the time when he also wanted to close all doc maintainers access to ffmpeg svn)
This is also not a correct retelling of the facts. In the beginning commit access to FFmpeg and MPlayer were the same thing. That meant that each and every FFmpeg committer had full commit access to MPlayer and vice versa. After the first Uoti incident, you wanted that changed and I implemented it, according to your instructions. I suggested removing the MPlayer translator which have never done any code changes from the list of FFmpeg committers. None of them had ever committed to FFmpeg (nor have they since) and I doubt they were or are really aware of the fact that they can. Their commit accounts were never intended for FFmpeg. You wanted to keep them, so I left them in the list of committers. Diego
On Sat, May 10, 2008 at 05:51:58PM +0200, Diego Biurrun wrote:
On Sat, May 10, 2008 at 05:21:59PM +0200, Michael Niedermayer wrote:
On Sat, May 10, 2008 at 04:27:50PM +0300, Ivan Kalvachev wrote:
On Sat, May 10, 2008 at 3:20 PM, Reimar Döffinger <Reimar.Doeffinger@stud.uni-karlsruhe.de> wrote:
On Sat, May 10, 2008 at 01:38:06PM +0200, Diego Biurrun wrote:
diego 1038 504 1542 reimar 690 246 936 voroshil 312 8 320 nico 212 43 255 benjamin 144 32 176 ulion 153 13 166 eugeni 106 56 162 uoti 99 20 119
Reimar, looking at these numbers, I'd say that you are de-facto project leader. Diego is not coder and none of his commits changes the way MPlayer works. He is doing a lot of refactoring and cosmetics.
Reimar, please take the Project Leader role and resolve the situation in the way you like it.
yes, seconded, and my emphasis is on _resolve_. Not the "playing deaf" diego
I will write up a statement/explanation before the weekend draws to a
thanks
close. I have no time right now because I am meeting friends in a few minutes.
He once wanted to close ivans ffmpegs svn account
You are not giving a correct representation of the facts here. It was Mans that proposed closing Ivan's FFmpeg account, I just seconded that notion. You may, and you are certainly free to, disagree with me, but I don't consider committing non-free code to be in the same class of issue as removing parentheses in a commit (wrongly) labeled "indent". You were also not around when Mans and I discussed with a stubborn Ivan on IRC.
Unless my brain rotted away, you wanted ivans svn access closed long before he commited the code you consider non free. From what i remember this was at the time uotis ffmpeg svn account was closed. You kept his account open after i pointed out that he is maintainer of XVMC in ffmpeg IIRC but note this is what i remember i did not search for the mails from back then to verify all fine details.
But mind you, this issue is long forgotten, forgiven even, so let us please not start a subflamewar out of this.
(that was around the time when he also wanted to close all doc maintainers access to ffmpeg svn)
This is also not a correct retelling of the facts. In the beginning commit access to FFmpeg and MPlayer were the same thing. That meant that each and every FFmpeg committer had full commit access to MPlayer and vice versa. After the first Uoti incident, you wanted that changed and I implemented it, according to your instructions.
I suggested removing the MPlayer translator which have never done any code changes from the list of FFmpeg committers. None of them had ever committed to FFmpeg (nor have they since) and I doubt they were or are really aware of the fact that they can. Their commit accounts were never intended for FFmpeg.
You wanted to keep them, so I left them in the list of committers.
yes all true [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I know you won't believe me, but the highest form of Human Excellence is to question oneself and others. -- Socrates
On Sat, May 10, 2008 at 06:40:11PM +0200, Michael Niedermayer wrote:
On Sat, May 10, 2008 at 05:51:58PM +0200, Diego Biurrun wrote:
On Sat, May 10, 2008 at 05:21:59PM +0200, Michael Niedermayer wrote:
He once wanted to close ivans ffmpegs svn account
You are not giving a correct representation of the facts here. It was Mans that proposed closing Ivan's FFmpeg account, I just seconded that notion. You may, and you are certainly free to, disagree with me, but I don't consider committing non-free code to be in the same class of issue as removing parentheses in a commit (wrongly) labeled "indent". You were also not around when Mans and I discussed with a stubborn Ivan on IRC.
Unless my brain rotted away, you wanted ivans svn access closed long before he commited the code you consider non free. From what i remember this was at the time uotis ffmpeg svn account was closed. You kept his account open after i pointed out that he is maintainer of XVMC in ffmpeg IIRC but note this is what i remember i did not search for the mails from back then to verify all fine details.
Nonono, you are misremembering. I passed you the list of people for which I was to create FFmpeg accounts and omitted Ivan from the list. But this was just an oversight on my part, nothing more. I was not aware that he was the XVMC maintainer in FFmpeg, because he did this work before I started following FFmpeg development. Diego
On Sat, May 10, 2008 at 05:51:58PM +0200, Diego Biurrun wrote:
On Sat, May 10, 2008 at 05:21:59PM +0200, Michael Niedermayer wrote:
On Sat, May 10, 2008 at 04:27:50PM +0300, Ivan Kalvachev wrote:
On Sat, May 10, 2008 at 3:20 PM, Reimar Döffinger <Reimar.Doeffinger@stud.uni-karlsruhe.de> wrote:
On Sat, May 10, 2008 at 01:38:06PM +0200, Diego Biurrun wrote:
diego 1038 504 1542 reimar 690 246 936 voroshil 312 8 320 nico 212 43 255 benjamin 144 32 176 ulion 153 13 166 eugeni 106 56 162 uoti 99 20 119
Reimar, looking at these numbers, I'd say that you are de-facto project leader. Diego is not coder and none of his commits changes the way MPlayer works. He is doing a lot of refactoring and cosmetics.
Reimar, please take the Project Leader role and resolve the situation in the way you like it.
yes, seconded, and my emphasis is on _resolve_. Not the "playing deaf" diego
I will write up a statement/explanation before the weekend draws to a close. I have no time right now because I am meeting friends in a few minutes.
Sorry, this took much longer than promised. I was very busy these past weeks and days and was away for a week without internet in between. Admittedly, I also always get carried away by maintenance duties and random issues. Probably also due to the fact that my motivation to flame is at an all-time low. Coding feels so much more fulfilling... I'm also very much torn between the desire to write this statement as promised and the fear (or rather certainty) that this will stir up flaming again and cause grief and time loss. Since I very much feel that everybody should try to look at the situation again with a cool head and not let emotions cloud their judgement, this long period of calm might not be such a bad thing in the end. We shall see. Anyway, here comes my position statement: Everybody should step back for a minute, calm down, and think about what it really is that we were debating: Uoti committed a bunch of cosmetic cleanups of different types together and labeled his commit as "indent". That was not good and I dislike bad commit messages more than the next guy, but it was not catastrophic. Plus, it was neither malicious, nor intentional. Uoti honestly did not expect this to be controversial. Then Reimar gets upset and heavy flaming, heavy even measured by MPlayer standards, erupts. I speak with Reimar, I speak with Uoti, Reimar eventually calms down again. As suggested by me, Uoti speaks with Reimar, they decide to find a way to work better together with less friction. Everything should be fine and dandy again, should it not? No, wait, of course flaming has not subsided, but reached epic proportions instead. The tides of the discussion go ever higher and none of the participants is helping it in any way. On the contrary, all sides are stubborn or prone to flames or both and generally have a number of character traits not conducive to resolving conflicts. But what has really happened? Whatever you may think of the policy, it does not contain a paragraph that forbids committing different types of cosmetic changes together. In fact, we had a precedent for a similar commit about half a year ago: ------------------------------------------------------------------------ r24911 | uau | 2007-11-01 07:51:38 +0100 (Thu, 01 Nov 2007) | 4 lines Changed paths: M /trunk/libmpcodecs/dec_audio.c Reindent dec_audio.c Also remove some commented out code ------------------------------------------------------------------------ No big controversy arose out of that one, nor was there reason to. There should be no reason now. The commit message has been fixed. Uoti had no malicious or trollish intent and has promised to mention such things in commit messages in the future. That said, he really is the last person that can be accused of writing bad commit message in general. If somebody wants to insist on separating cosmetic commits piece by piece, be my guest to do it yourself. I single-handedly reindented and prettyprinted all of FFmpeg to make it conform to the coding style. I know very well how much work and how little fun this is. I diligently split stuff myself, but I do not require the same level of pedantic attention to detail from others. I have been accused of abusing my powers. Let's face it, I am regarded as the de-facto project leader, I have heard it many times in private. Plus, in situations like these, I get treated as bearing all the responsibilities of a project leader - with no privileges. I am not trying to lament here, just stating facts. Leadership requires standing up and not following loud voices in the direction of least resistance. This is such a situation. We have 5 people (Michael, Ivan, Alban, Aurelien, Roberto) voting for Uoti's removal and 4 people speaking up against (Uoti, Eugeni, Benjamin, Diego). This is a far cry from a clear situation, especially given that each of the latter 4 is more active than all of the 5 combined. Notwithstanding the fact that I am not a fan of voting procedures to resolve conflicts in projects like this one, democratic voting procedures need to be fixed before the actual voting takes place. We would have to know who is eligible to vote (why should Uoti not be eligible?), what the required majorities are and what number of votes constitutes a quorum. As Michael said, I prefer to work in projects where the developers get to steer the direction of the project. But, let's face it, developers are not all equal, some are more active and/or more experienced and/or more merited than others. I applaud Benjamin's humility when he says that he does not consider himself in a position to vote here because he has not been active enough as of late. I wish more people were so humble, so hard-working and so averse to flaming. Nonetheless we have maneuvered us into a Mexican standoff. There is no way to satisfy everybody in this lose-lose situation and especially I can only choose between damaging my reputation in different ways. I cannot give in to the wishes of a vocal group of merited, but inactive developers. Nowadays other people do the heavy lifting on MPlayer. They should get to decide how the project works in exchange. Reimar has not voted in favor of removing Uoti's account; the voices of many active developers have remained mute. I do not wish to alienate anybody, but I have to think about the long-term well-being of the project. This projects has many problems, but renegade commits are not one of them. Lack of manpower is much more serious as is the constant flaming, intransigent insistence on minority standpoints and architectural issues in the codebase. Flaming a developer that works on architectural issues out of the project is not the way forward. We are not Linux kernel and we are not a wealthy company. We have very limited manpower and we cannot just go out and hire the people we want and need. We have to be content with whomever we've got aboard and with whatever skills and personality they have got. Let's face it: competent developers do not joing MPlayer every month. On the contrary, they are few and far between; a resource not to be squandered. If they happen to be difficult to work with (and we have many of those aboard), we have to find ways to make ends meet. Conflicts need to be mitigated and resolved, not fought out. The imperative should be to work constructively together and give each other a bit of leeway and the benefit of the doubt. This is what I attempted to do in this situation. I successfully mediated between Reimar and Uoti, which is where the problems originated. Extra parentheses in return statements will not be a source of problems again in the future, because I removed all of them. The same could be achieved with regard to indentation, it would just require some willingness to compromise from all sides. From then on, nobody would be able to step on any toes with cosmetic commits. Uoti's commits were reverted, but nobody bothered to recommit them. This way, everybody loses. I split the commits to make everybody happy and to improve the code, because this is what we should really strive for. I don't mind splitting a commit or two in the future, just as I - just to give an example - never minded writing documentation when Michael skipped that in his commits. Then just as now, shouting "policy violation", reverting commits and leaving things at that only makes things worse. MPlayer is not developed in a mail or IRC client, it is developed in a text editor. Flaming does not improve MPlayer as a project or as a codebase, on the contrary. It wastes precious time, makes everybody unhappy and people go find a different project to spend their time on. The constant flaming *must* end. I was very close to burnout during this conflict and had very much decided to pack it all in for good. Trying to work on MPlayer surrounded by people who appear to enjoy flaming more than coding and are stubborn and intransigent stops being fun at some point. Everybody (and i mean everybody) seemed to have gone mad. Sleeping things over and concentrating on coding instead of flaming does help, however. As I said earlier, please look at the issues again with a cool head and do not let emotions cloud your judgement. Diego
On Fri, May 30, 2008 at 03:04:14AM +0200, Diego Biurrun wrote:
On Sat, May 10, 2008 at 05:51:58PM +0200, Diego Biurrun wrote:
On Sat, May 10, 2008 at 05:21:59PM +0200, Michael Niedermayer wrote:
On Sat, May 10, 2008 at 04:27:50PM +0300, Ivan Kalvachev wrote:
On Sat, May 10, 2008 at 3:20 PM, Reimar Döffinger <Reimar.Doeffinger@stud.uni-karlsruhe.de> wrote:
On Sat, May 10, 2008 at 01:38:06PM +0200, Diego Biurrun wrote:
diego 1038 504 1542 reimar 690 246 936 voroshil 312 8 320 nico 212 43 255 benjamin 144 32 176 ulion 153 13 166 eugeni 106 56 162 uoti 99 20 119
Reimar, looking at these numbers, I'd say that you are de-facto project leader. Diego is not coder and none of his commits changes the way MPlayer works. He is doing a lot of refactoring and cosmetics.
Reimar, please take the Project Leader role and resolve the situation in the way you like it.
yes, seconded, and my emphasis is on _resolve_. Not the "playing deaf" diego
I will write up a statement/explanation before the weekend draws to a close. I have no time right now because I am meeting friends in a few minutes.
Sorry, this took much longer than promised. I was very busy these past weeks and days and was away for a week without internet in between. Admittedly, I also always get carried away by maintenance duties and random issues. Probably also due to the fact that my motivation to flame is at an all-time low. Coding feels so much more fulfilling...
I'm also very much torn between the desire to write this statement as promised and the fear (or rather certainty) that this will stir up flaming again and cause grief and time loss.
It seems you view any form of disscussion or critique as flame and bad. I think this is the wrong way to attack things. Critique means that there is a disagreement and these should be discussed and resolved, staying silent (or asking others to stay silent) does IMO achive the opposite. That is it angers everyone and does not resolve anything. And angry people do not code, so while staying silent might supress the public critique it wont turn these missing flames into existing code.
Since I very much feel that everybody should try to look at the situation again with a cool head and not let emotions cloud their judgement, this long period of calm might not be such a bad thing in the end. We shall see.
A: we have a problem B: yes admin: <silence> B: hey admin what will you do about the problem? admin: <long statement saying i wont do anything> time passes A: we still have the same problem B: yes 1 developer leaves admin: complaining about the low manpower goto begin
Anyway, here comes my position statement:
Everybody should step back for a minute, calm down, and think about what it really is that we were debating:
We are discussing a solution to the problem that a large number of the developers are quite incompatible with uotis provocative, arogant and egoistic way. The solution you as admin choose is to step back and let people kill each other. While complaining about the amount of flaming. Its quite ironic
Uoti committed a bunch of cosmetic cleanups of different types together and labeled his commit as "indent". That was not good and I dislike bad commit messages more than the next guy, but it was not catastrophic. Plus, it was neither malicious, nor intentional. Uoti honestly did not expect this to be controversial.
Then Reimar gets upset and heavy flaming, heavy even measured by MPlayer standards, erupts. I speak with Reimar, I speak with Uoti, Reimar eventually calms down again. As suggested by me, Uoti speaks with Reimar, they decide to find a way to work better together with less friction.
Everything should be fine and dandy again, should it not? No, wait, of course flaming has not subsided, but reached epic proportions instead. The tides of the discussion go ever higher and none of the participants is helping it in any way. On the contrary, all sides are stubborn or prone to flames or both and generally have a number of character traits not conducive to resolving conflicts.
But what has really happened? Whatever you may think of the policy, it does not contain a paragraph that forbids committing different types of cosmetic changes together.
It contains parts about not mixing cosmetics and functional changes it also contains parts about not commiting to code maintained by others and something about sending patches. [...]
I have been accused of abusing my powers. Let's face it, I am regarded as the de-facto project leader, I have heard it many times in private. Plus, in situations like these, I get treated as bearing all the responsibilities of a project leader - with no privileges.
You can step down from the position as root. But as long as you are root you will have to live with the critique about your decissions or lack thereof.
I am not trying to lament here, just stating facts. Leadership requires standing up and not following loud voices in the direction of least resistance. This is such a situation.
Leadership requires to solve problems and prevent the project from breaking apart. It also requires to create an environment in which developers feel comfortable to work in. If a "employee" wants plants in the room and a playboy pic on the wall and wants to work at night, a good leader does everything in his power to ensure that he gets what he wants. If two "employees" dont get along and no amount of discussions help a good leader puts them as far apart as possible, like in different rooms. If one "employee" harasses half of the others, a good leader warns him once, maybe twice and then fires him. If due to whatever reason he chooses not to fire him, he seperates the people who do not want to accept the harrasment to their own room and gives them a key to lock the door. Lets look at mplayer Voting rights about project decissions: no Protection from random changes by random other developers: no Any rules which are equally applied to all: no Democratic votes being ignored at will by the one in charge: yes Why is uotis commit access not limited to the files he maintains? Or a compromise, why can he commit to files i, aurel, iive,... maintain? I can and likely will fork if i see a single commit from uoti breaking the policy again. Just my personal fork in which i maintain my files and merge commits from mplayer as i see fit. It restores a environment in which i feel comfortable, one where no random messy commits pop up under my fingers.
We have 5 people (Michael, Ivan, Alban, Aurelien, Roberto) voting for Uoti's removal and 4 people speaking up against (Uoti, Eugeni, Benjamin, Diego). This is a far cry from a clear situation, especially given that each of the latter 4 is more active than all of the 5 combined.
Its true for the current activity but if i look at all commits of all times i much rather loose all of the later 4 than a single one of the first 5. Also you speak about this as a throw him out vs. keep him in the project. If one looks at it like that it surely is better to keep him, but its not so simple. its that >50% of the people do not get along with him and loosing 1 vs. loosing 50% of the developers is something quite different [...]
I do not wish to alienate anybody, but I have to think about the long-term well-being of the project.
You think about it but your actions are the ones which hurt the project more than any other possible choice of actions IMHO
This projects has many problems, but renegade commits are not one of them. Lack of manpower is much more serious
Well frankly the lack of manpower is caused by the hostile environment IMHO Let me repeat what i said above: Voting rights about project decissions: no Protection from random changes by random other developers: no Any rules which are equally applied to all: no Democratic votes being ignored at will by the one in charge: yes Would you join such a project? If you say yes, id like to point out how you complained about iive changing the spelling of xvid. Which honestly is totally irrelevant compared to changes to the code.
as is the constant flaming,
intransigent insistence on minority standpoints and architectural issues in the codebase. Flaming a developer that works on architectural issues out of the project is not the way forward.
Letting him bully 50% of the other developers out is so much better.
We are not Linux kernel and we are not a wealthy company. We have very limited manpower and we cannot just go out and hire the people we want and need. We have to be content with whomever we've got aboard and with whatever skills and personality they have got.
Let's face it: competent developers do not joing MPlayer every month. On the contrary, they are few and far between; a resource not to be squandered. If they happen to be difficult to work with (and we have many of those aboard), we have to find ways to make ends meet.
The problem is that you did not yet find a way to make ends meet. Convincing me or reimar on the phone does not solve the problem. Make uoti less arrogant and egoistic and we would be a long way toward a solution. But people are what they are, noone can change them ...
Conflicts need to be mitigated and resolved, not fought out. The imperative should be to work constructively together and give each other a bit of leeway and the benefit of the doubt.
This is what I attempted to do in this situation. I successfully mediated between Reimar and Uoti, which is where the problems originated.
You have convinced todays victim to accept the harrassment and not complain. You have not stoped the one harrassing ... This is not going to solve the issue. Maybe uoti will leave, maybe everyone else will leave but if neither does the whole will repeat eventually. Anyway, if you dislike that i replied, just delete my mail and ignore me. I could have stayed silent like i did many other times but it wouldnt have done any good. Maybe my mail here is also useless still i felt like i should reply. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No great genius has ever existed without some touch of madness. -- Aristotle
On Fri, May 30, 2008 at 04:58:34AM +0200, Michael Niedermayer wrote:
On Fri, May 30, 2008 at 03:04:14AM +0200, Diego Biurrun wrote:
On Sat, May 10, 2008 at 05:51:58PM +0200, Diego Biurrun wrote:
On Sat, May 10, 2008 at 05:21:59PM +0200, Michael Niedermayer wrote:
On Sat, May 10, 2008 at 04:27:50PM +0300, Ivan Kalvachev wrote:
On Sat, May 10, 2008 at 3:20 PM, Reimar Döffinger <Reimar.Doeffinger@stud.uni-karlsruhe.de> wrote:
On Sat, May 10, 2008 at 01:38:06PM +0200, Diego Biurrun wrote: > diego 1038 504 1542 > reimar 690 246 936 > voroshil 312 8 320 > nico 212 43 255 > benjamin 144 32 176 > ulion 153 13 166 > eugeni 106 56 162 > uoti 99 20 119
Reimar, looking at these numbers, I'd say that you are de-facto project leader. Diego is not coder and none of his commits changes the way MPlayer works. He is doing a lot of refactoring and cosmetics.
Reimar, please take the Project Leader role and resolve the situation in the way you like it.
yes, seconded, and my emphasis is on _resolve_. Not the "playing deaf" diego
I will write up a statement/explanation before the weekend draws to a close. I have no time right now because I am meeting friends in a few minutes.
Sorry, this took much longer than promised. I was very busy these past weeks and days and was away for a week without internet in between. Admittedly, I also always get carried away by maintenance duties and random issues. Probably also due to the fact that my motivation to flame is at an all-time low. Coding feels so much more fulfilling...
I'm also very much torn between the desire to write this statement as promised and the fear (or rather certainty) that this will stir up flaming again and cause grief and time loss.
It seems you view any form of disscussion or critique as flame and bad.
Wrong. I don't know where you get that idea, you have seen me discuss many many times (constructively) over the years. But discussions should be done with a clear head.
I think this is the wrong way to attack things. Critique means that there is a disagreement and these should be discussed and resolved, staying silent (or asking others to stay silent) does IMO achive the opposite. That is it angers everyone and does not resolve anything.
The emphasis needs to be put on the word *resolve*, yes. I'm not asking anybody to stay silent. I'm asking for people to step back and look at the issues without their emotions clouding their judgement. I believe that the flaming is blowing things out of proportion and everybody is getting worked up over pretty much nothing.
Anyway, here comes my position statement:
Everybody should step back for a minute, calm down, and think about what it really is that we were debating:
We are discussing a solution to the problem that a large number of the developers are quite incompatible with uotis provocative, arogant and egoistic way. The solution you as admin choose is to step back and let people kill each other. While complaining about the amount of flaming. Its quite ironic
Wrong. I have worked to *resolve* the problem, not fight it out, by talking to the parties where the conflict originated, namely Reimar and Uoti. I'm not particularly happy about how things played out in the end, nor would I claim not to have made mistakes. However, I was terminally frustrated and had basically decided to pack it all in. Had I decided to join the discussion, I would have kicked and screamed like everybody else when a clear head was needed. So I decided to work on the original causes of the problem. Has it occurred to you that you might be overreacting in this case?
Uoti committed a bunch of cosmetic cleanups of different types together and labeled his commit as "indent". That was not good and I dislike bad commit messages more than the next guy, but it was not catastrophic. Plus, it was neither malicious, nor intentional. Uoti honestly did not expect this to be controversial.
Then Reimar gets upset and heavy flaming, heavy even measured by MPlayer standards, erupts. I speak with Reimar, I speak with Uoti, Reimar eventually calms down again. As suggested by me, Uoti speaks with Reimar, they decide to find a way to work better together with less friction.
Everything should be fine and dandy again, should it not? No, wait, of course flaming has not subsided, but reached epic proportions instead. The tides of the discussion go ever higher and none of the participants is helping it in any way. On the contrary, all sides are stubborn or prone to flames or both and generally have a number of character traits not conducive to resolving conflicts.
But what has really happened? Whatever you may think of the policy, it does not contain a paragraph that forbids committing different types of cosmetic changes together.
It contains parts about not mixing cosmetics and functional changes it also contains parts about not commiting to code maintained by others and something about sending patches.
None of this applies in this particular case.
I am not trying to lament here, just stating facts. Leadership requires standing up and not following loud voices in the direction of least resistance. This is such a situation.
Leadership requires to solve problems and prevent the project from breaking apart. It also requires to create an environment in which developers feel comfortable to work in.
Precisely. The developers are the people doing the actual work on the project. They need to feel comfortable.
We have 5 people (Michael, Ivan, Alban, Aurelien, Roberto) voting for Uoti's removal and 4 people speaking up against (Uoti, Eugeni, Benjamin, Diego). This is a far cry from a clear situation, especially given that each of the latter 4 is more active than all of the 5 combined.
Its true for the current activity but if i look at all commits of all times i much rather loose all of the later 4 than a single one of the first 5.
I think your anger is clouding your judgement. You should try to reevaluate the contributions of all nine people mentioned above. I very much respect all the developers listed above, I know most of them personally, like them and the feeling is mutual. Nonetheless nowadays MPlayer is being developed by a new generation of people. That does not mean that the contributions of those people are insubstantial or that not appreciated. But you could go further back in history and find people that have done even more, like Nick and Arpi, yet are not steering this project any longer.
Also you speak about this as a throw him out vs. keep him in the project. If one looks at it like that it surely is better to keep him, but its not so simple. its that >50% of the people do not get along with him and loosing 1 vs. loosing 50% of the developers is something quite different
You assume that the majority (whatever that may be) shares your opinion. The majority is silent. The longer I look at the situation, the less I feel confident to predict what these other people think. It's also not as simple as you think. I surely do not want to work on a project where valuable contributors get thrown out like this. Of course, you have made it pretty clear above that you do not value my contributions. If everybody else agrees with this then I do indeed not see much point in continuing to waste my time here.
This projects has many problems, but renegade commits are not one of them. Lack of manpower is much more serious
Well frankly the lack of manpower is caused by the hostile environment IMHO
I am not denying this, but the question is what constitutes a hostile environment. I'll quote Denes Balatoni, one of the innocent bystanders on the fringe of this project: I have not partcipated in the discussion before, but now that you ask, I will say that IMO it is not wise to complain about some ancient and not neccesserily consensual "cvs rules" by older inactive MPlayer developers, just to get rid of a newer - but one of the last active - MPlayer developer. I think a more forgiving and constructive environment would better serve the interests of the project. Note that many many outsiders consider the environment around FFmpeg very hostile. Of course, FFmpeg can get away with it, because there is no alternative to it and it holds a monopoly on its "market". So people are willing to put up with more hardship or simply are forced to work with FFmpeg one way or the other because they cannot switch to an alternative. MPlayer cannot afford that luxury. I want the constant flaming to stop. People should concentrate on coding and reviewing instead of shouting at each other.
id like to point out how you complained about iive changing the spelling of xvid. Which honestly is totally irrelevant compared to changes to the code.
I did not complain about Ivan changing the spelling. I complained about Ivan reverting my commit without prior notice. If he had reverted just the files he maintains - fine. But he chose to revert the files I maintain as well. He did it on purpose. This is obviously a provocation. How come that you don't have an issue with such behavior? I find it very irritating that Ivan can get away with anything without attracting your wrath while others get attacked over much less. This behavior is incongruent, especially in light of the actual contributions that Ivan and other people do.
We are not Linux kernel and we are not a wealthy company. We have very limited manpower and we cannot just go out and hire the people we want and need. We have to be content with whomever we've got aboard and with whatever skills and personality they have got.
Let's face it: competent developers do not joing MPlayer every month. On the contrary, they are few and far between; a resource not to be squandered. If they happen to be difficult to work with (and we have many of those aboard), we have to find ways to make ends meet.
The problem is that you did not yet find a way to make ends meet. Convincing me or reimar on the phone does not solve the problem. Make uoti less arrogant and egoistic and we would be a long way toward a solution. But people are what they are, noone can change them ...
I found a way to make Reimar and Uoti resolve their differences. I found a way to avoid a return parentheses issues in the future. I have split the offending commits. This is much more than nothing. I have tried my best (however little that may be) to be _constructive_ and not destructive. Who else can claim that? In the medium term I think we will have to look at distributed revision control. This way, people will not have as many possibilities to step on each other's toes. I'm starting to familiarize myself with Mercurial and git. Unfortunately I do not have much time for this ATM. In the future, a way to avoid fights over reindent commits would be reindenting all of MPlayer. Problem solved once and for all. Diego
On Fri, May 30, 2008 at 07:49:24PM +0200, Diego Biurrun wrote:
On Fri, May 30, 2008 at 04:58:34AM +0200, Michael Niedermayer wrote:
On Fri, May 30, 2008 at 03:04:14AM +0200, Diego Biurrun wrote: [...] Has it occurred to you that you might be overreacting in this case?
Has it occured to you that you always play things down when uoti is involved but you turn every tiny fly into a dinosour when its related to iive or arpi.
Uoti committed a bunch of cosmetic cleanups of different types together and labeled his commit as "indent". That was not good and I dislike bad commit messages more than the next guy, but it was not catastrophic. Plus, it was neither malicious, nor intentional. Uoti honestly did not expect this to be controversial.
Then Reimar gets upset and heavy flaming, heavy even measured by MPlayer standards, erupts. I speak with Reimar, I speak with Uoti, Reimar eventually calms down again. As suggested by me, Uoti speaks with Reimar, they decide to find a way to work better together with less friction.
Everything should be fine and dandy again, should it not? No, wait, of course flaming has not subsided, but reached epic proportions instead. The tides of the discussion go ever higher and none of the participants is helping it in any way. On the contrary, all sides are stubborn or prone to flames or both and generally have a number of character traits not conducive to resolving conflicts.
But what has really happened? Whatever you may think of the policy, it does not contain a paragraph that forbids committing different types of cosmetic changes together.
It contains parts about not mixing cosmetics and functional changes it also contains parts about not commiting to code maintained by others and something about sending patches.
None of this applies in this particular case.
copy and paste below for your memory, this commit was to demux_mkv.c which has been written and is activly maintained by aurel
@@ -43,7 +43,7 @@ #include "libavutil/intreadwrite.h" #include "libavutil/avstring.h"
-static unsigned char sipr_swaps[38][2]={ +static const unsigned char sipr_swaps[38][2]={ {0,63},{1,22},{2,44},{3,90},{5,81},{7,31},{8,86},{9,58},{10,36},{12,68}, {13,39},{14,73},{15,53},{16,69},{17,57},{19,88},{20,34},{21,71},{24,46}, {25,94},{26,54},{28,75},{29,50},{32,70},{33,92},{35,74},{38,85},{40,56}, @@ -54,12 +54,13 @@ static unsigned char sipr_swaps[38][2]={ #define SIPR_FLAVORS 4 #define ATRC_FLAVORS 8 #define COOK_FLAVORS 34 -static int sipr_fl2bps[SIPR_FLAVORS] = {813, 1062, 625, 2000}; -static int atrc_fl2bps[ATRC_FLAVORS] = {8269, 11714, 13092, 16538, 18260, 22050, 33075, 44100}; -static int cook_fl2bps[COOK_FLAVORS] = {1000, 1378, 2024, 2584, 4005, 5513, 8010, 4005, 750, 2498, - 4048, 5513, 8010, 11973, 8010, 2584, 4005, 2067, 2584, 2584, - 4005, 4005, 5513, 5513, 8010, 12059, 1550, 8010, 12059, 5513, - 12016, 16408, 22911, 33506}; +static const int sipr_fl2bps[SIPR_FLAVORS] = {813, 1062, 625, 2000}; +static const int atrc_fl2bps[ATRC_FLAVORS] = {8269, 11714, 13092, 16538, 18260, 22050, 33075, 44100}; +static const int cook_fl2bps[COOK_FLAVORS] = { + 1000, 1378, 2024, 2584, 4005, 5513, 8010, 4005, 750, 2498, + 4048, 5513, 8010, 11973, 8010, 2584, 4005, 2067, 2584, 2584, + 4005, 4005, 5513, 5513, 8010, 12059, 1550, 8010, 12059, 5513, + 12016, 16408, 22911, 33506};
typedef struct {
Mix functional changes and cosmetics, revert. Ciao, Roberto [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB While the State exists there can be no freedom; when there is freedom there will be no State. -- Vladimir Lenin
On Fri, May 30, 2008 at 11:28:45PM +0200, Michael Niedermayer wrote:
On Fri, May 30, 2008 at 07:49:24PM +0200, Diego Biurrun wrote:
On Fri, May 30, 2008 at 04:58:34AM +0200, Michael Niedermayer wrote:
On Fri, May 30, 2008 at 03:04:14AM +0200, Diego Biurrun wrote: [...] Has it occurred to you that you might be overreacting in this case?
Has it occured to you that you always play things down when uoti is involved but you turn every tiny fly into a dinosour when its related to iive or arpi.
I could say the same about you and Ivan. Well, you don't have the pleasure of sharing IRC channels with him. Why you have to drag Arpi into the discussion now is beyond me.
Uoti committed a bunch of cosmetic cleanups of different types together and labeled his commit as "indent". That was not good and I dislike bad commit messages more than the next guy, but it was not catastrophic. Plus, it was neither malicious, nor intentional. Uoti honestly did not expect this to be controversial.
Then Reimar gets upset and heavy flaming, heavy even measured by MPlayer standards, erupts. I speak with Reimar, I speak with Uoti, Reimar eventually calms down again. As suggested by me, Uoti speaks with Reimar, they decide to find a way to work better together with less friction.
Everything should be fine and dandy again, should it not? No, wait, of course flaming has not subsided, but reached epic proportions instead. The tides of the discussion go ever higher and none of the participants is helping it in any way. On the contrary, all sides are stubborn or prone to flames or both and generally have a number of character traits not conducive to resolving conflicts.
But what has really happened? Whatever you may think of the policy, it does not contain a paragraph that forbids committing different types of cosmetic changes together.
It contains parts about not mixing cosmetics and functional changes it also contains parts about not commiting to code maintained by others and something about sending patches.
None of this applies in this particular case.
copy and paste below for your memory, this commit was to demux_mkv.c which has been written and is activly maintained by aurel
This one did not start the discussion. Anyway, we have a ton of precedents for committing consts right away, sending patches for this is silly. Plus, I split the patch myself, problem solved. But no, this is not enough, heads must roll. How long did it take you to review that patch? You are a much better C coder than I am, I would be very much surprised if it took you more than the few seconds I needed to review it. Diego
On Fri, May 30, 2008 at 07:49:24PM +0200, Diego Biurrun wrote:
On Fri, May 30, 2008 at 04:58:34AM +0200, Michael Niedermayer wrote:
On Fri, May 30, 2008 at 03:04:14AM +0200, Diego Biurrun wrote: [...]
We have 5 people (Michael, Ivan, Alban, Aurelien, Roberto) voting for Uoti's removal and 4 people speaking up against (Uoti, Eugeni, Benjamin, Diego). This is a far cry from a clear situation, especially given that each of the latter 4 is more active than all of the 5 combined.
Its true for the current activity but if i look at all commits of all times i much rather loose all of the later 4 than a single one of the first 5.
I think your anger is clouding your judgement. You should try to reevaluate the contributions of all nine people mentioned above.
I very much respect all the developers listed above,
Of course ... if anything i said sounded like i did not then this certainly was not intended.
I know most of them personally, like them and the feeling is mutual. Nonetheless nowadays MPlayer is being developed by a new generation of people. That does not mean that the contributions of those people are insubstantial or that not appreciated.
Yes but it also does not mean that the experience the "old generation" has collected over the years should be ignored like it is. The people not being against uoti are new people who do not yet have the same experience reimar, roberto, iive, ... have in respect to maintaining a large project with many developers working, joining and leaving ... If the "old genration" says mixing cosmetics and functional changes causes problems why would anyone think it is not so? Becasue the always better knowing uoti said it? On which big project has he worked in the past so he could even have that experience? Or the same about commiting with no warning to code actively maintained by others. Even if one ignores what the "old generation" says, just looking at the recent months shows how such commits get everyone near boiling. Even you go crazy if iive just changes xvids spelling. What if i did the same with indexes/indices? IMHO that change made absolutely no sense, both are correct and there was no need to clobber the history. Wouldnt you have been angry as well if someone (maybe iive) would have just reverted it? If you agree that a little bit of communication before commiting to code maintaned by others would be good then why is uoti apparently exempt from this rule?
But you could go further back in history and find people that have done even more, like Nick and Arpi, yet are not steering this project any longer.
it would be great if arpi would return and lead mplayer once again. The project really decayed after he left, back then noone complained about the too low manpower, because it wasnt too low ...
Also you speak about this as a throw him out vs. keep him in the project. If one looks at it like that it surely is better to keep him, but its not so simple. its that >50% of the people do not get along with him and loosing 1 vs. loosing 50% of the developers is something quite different
You assume that the majority (whatever that may be) shares your opinion. The majority is silent. The longer I look at the situation, the less I feel confident to predict what these other people think.
start a vote if you want to know the truth, but then you do not want to know it i think ...
It's also not as simple as you think. I surely do not want to work on a project where valuable contributors get thrown out like this. Of course, you have made it pretty clear above that you do not value my contributions. If everybody else agrees with this then I do indeed not see much point in continuing to waste my time here.
Your contributions are valuable, but iives, ... are as well. And you started wheighting peoples "worth", that is uoti is more worth than roberto, aurel, me, iive and alban. So if you feel depressed now, hell, the ones you indicated that they are less worth than uoti feel likely as well.
This projects has many problems, but renegade commits are not one of them. Lack of manpower is much more serious
Well frankly the lack of manpower is caused by the hostile environment IMHO
I am not denying this, but the question is what constitutes a hostile environment. I'll quote Denes Balatoni, one of the innocent bystanders on the fringe of this project:
I have not partcipated in the discussion before, but now that you ask, I will say that IMO it is not wise to complain about some ancient and not neccesserily consensual "cvs rules" by older inactive MPlayer developers, just to get rid of a newer - but one of the last active - MPlayer developer. I think a more forgiving and constructive environment would better serve the interests of the project.
Note that many many outsiders consider the environment around FFmpeg very hostile.
Note that many many pigs consider birds ugly. no i have no evidence but neither do you.
Of course, FFmpeg can get away with it,
away with what?
because there is no alternative to it and it holds a monopoly on its "market".
*GPL software cannot hold a monopoly, it can always be forked
So people are willing to put up with more hardship or simply are forced to work with FFmpeg one way or the other because they cannot switch to an alternative.
You should probably post a detailed list of what you think can be improved to ffmpeg-dev
MPlayer cannot afford that luxury. I want the constant flaming to stop. People should concentrate on coding and reviewing instead of shouting at each other.
So because the policy of "no flames, no deluser, no democracy" has driven most away. You now argue that it should be continued?
id like to point out how you complained about iive changing the spelling of xvid. Which honestly is totally irrelevant compared to changes to the code.
I did not complain about Ivan changing the spelling. I complained about Ivan reverting my commit without prior notice. If he had reverted just the files he maintains - fine. But he chose to revert the files I maintain as well. He did it on purpose. This is obviously a provocation.
hypocrite ...
How come that you don't have an issue with such behavior?
Lets see. * I do not know at all if Xvid or XviD is more correct. I do know it was XviD once in the past so this one can not be completely wrong now. * You changed the spelling to Xvid in files maintained by you and ivve * iive changed the spelling back to XviD in files maintained by you and ivve * he did the same you did, you started * you broke the policy he reverted the commit which broke the policy No the whole was not ideal but nothing bad happened we are just back at the start and have another chance to find a solution. If the spelling bothers you. Just start a discussion on mplayer-dev about it, like it should IMHO have been in the first place already. I know several xvid developers are subscribed to mplayer-dev. Maybe one will awnser it precissely in exchange of one of his patches being reviewed?
I find it very irritating that Ivan can get away with anything without attracting your wrath while others get attacked over much less. This behavior is incongruent, especially in light of the actual contributions that Ivan and other people do.
Who have i attacked due to reverting a policy violation? Or who have i attacked due to a change in capitalization in the docs? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have never wished to cater to the crowd; for what I know they do not approve, and what they approve I do not know. -- Epicurus
On Sat, 2008-05-31 at 00:58 +0200, Michael Niedermayer wrote:
On Fri, May 30, 2008 at 07:49:24PM +0200, Diego Biurrun wrote:
I know most of them personally, like them and the feeling is mutual. Nonetheless nowadays MPlayer is being developed by a new generation of people. That does not mean that the contributions of those people are insubstantial or that not appreciated.
Yes but it also does not mean that the experience the "old generation" has collected over the years should be ignored like it is. The people not being against uoti are new people who do not yet have the same experience reimar, roberto, iive, ... have in respect to maintaining a large project with many developers working, joining and leaving ...
I see no basis for a claim that older MPlayer developers would generally be better in skills specific to large projects. Also that has definitely NOT been a strong point of MPlayer historically. There have been developers with enough skill to hide most visible breakage (or patches from users) but IMO it's ridiculous to claim that MPlayer would have any tradition of good architecture design/refactoring or efficient cooperation between developers.
If the "old genration" says mixing cosmetics and functional changes causes problems why would anyone think it is not so? Becasue the always better knowing uoti said it? On which big project has he worked in the past so he could even have that experience?
No need to bring personal experience into that argument. You can look at other projects directly and see that they do not follow the kind of policy you want. You're also misrepresenting what the difference in opinion is. If you'd ask people "is it good to mix cosmetics and functional changes?" many would answer "no". They just wouldn't mean that as literally and with so little room for common sense as you do. Completely reformatting a file and doing bugfixes in the same commit is bad. Readjusting a couple of table rows when adding the word "static" in a commit labeled "Make table static" is good. Redundant commits are harmful and so pointless splitting should be avoided when the change is already obvious. Even in cases where a commit could in principle be improved using a lot of time to polish minor details is not a worthwhile activity when there are lots of real problems to fix in the code. You're paying far too much attention to a minor detail while ignoring more significant things.
Or the same about commiting with no warning to code actively maintained by others. Even if one ignores what the "old generation" says, just looking at the recent months shows how such commits get everyone near boiling.
s/everyone/mostly people who do little useful work/. And that's a circular argument anyway: you overreact to something, then argue "look it WAS really bad, it made me totally overreact!". The people who want to remove me from the project do not "actively maintain" any code, especially not demuxer.c or demux_mkv.c (even if still officially listed in MAINTAINERS).
Even you go crazy if iive just changes xvids spelling.
You're either being stupid or deliberately misunderstand. Obviously Diego would not have reacted that way if Ivan had just made to commit to change it to any consistent spelling before Diego's changes. What Iive did was revert changes Diego had just made. Iive can hardly claim to know the correct spelling with superior authority, had not been working on any related changes himself, was not directly affected by the changes, and there was no hurry to resolve the matter. It was obvious Diego wanted the other spelling as he had just changed it that way. Yet Iive changed the spelling back without any discussion, not even flaming that would have indicated there would be no agreement. Who maintains that code was not the issue, except that it showed even Iive himself doesn't in practice follow the rules he insists on.
This projects has many problems, but renegade commits are not one of them. Lack of manpower is much more serious
Well frankly the lack of manpower is caused by the hostile environment IMHO
If you're trying to imply that I would be responsible for the problems remember how I joined the project. I fixed some nasty longstanding bugs in the central timing code that apparently no existing developer understood. You can hardly claim that those old developers who now want to throw me out would have been doing fine before I joined.
On Sat, May 31, 2008 at 07:12:50AM +0300, Uoti Urpala wrote:
On Sat, 2008-05-31 at 00:58 +0200, Michael Niedermayer wrote:
On Fri, May 30, 2008 at 07:49:24PM +0200, Diego Biurrun wrote: [...] If the "old genration" says mixing cosmetics and functional changes causes problems why would anyone think it is not so? Becasue the always better knowing uoti said it? On which big project has he worked in the past so he could even have that experience?
No need to bring personal experience into that argument. You can look at other projects directly and see that they do not follow the kind of policy you want.
You're also misrepresenting what the difference in opinion is. If you'd ask people "is it good to mix cosmetics and functional changes?" many would answer "no". They just wouldn't mean that as literally and with so little room for common sense as you do. Completely reformatting a file
s/common sense/your common sense/ [... repeation of old argument that your personal oppinion overrides all rules and oppinions of others, no matter about what or where ...] [... argument that you are the only person who does any work and others are irrelevant ...]
Even you go crazy if iive just changes xvids spelling.
You're either being stupid or deliberately misunderstand. Obviously Diego would not have reacted that way if Ivan had just made to commit to change it to any consistent spelling before Diego's changes. What Iive did was revert changes Diego had just made.
Iive can hardly claim to know the correct spelling with superior authority,
That says the master of all knowledge and ultimate athority ...
had not been working on any related changes himself, was not directly affected by the changes, and there was no hurry to resolve the matter. It was obvious
Well iive used common sense like you do or should i rather say claim to do?
Diego wanted the other spelling as he had just changed it that way. Yet Iive changed the spelling back without any discussion, not even flaming that would have indicated there would be no agreement.
iive discussed as much as diego did, that was bad in both cases sure. [...]
This projects has many problems, but renegade commits are not one of them. Lack of manpower is much more serious
Well frankly the lack of manpower is caused by the hostile environment IMHO
If you're trying to imply that I would be responsible for the problems
not alone, no
remember how I joined the project. I fixed some nasty longstanding bugs in the central timing code that apparently no existing developer understood. You can hardly claim that those old developers who now want to throw me out would have been doing fine before I joined.
Thank you for your bug fixes and contributions [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I hate to see young programmers poisoned by the kind of thinking Ulrich Drepper puts forward since it is simply too narrow -- Roman Shaposhnik
On Sat, 2008-05-31 at 20:11 +0200, Michael Niedermayer wrote:
On Sat, May 31, 2008 at 07:12:50AM +0300, Uoti Urpala wrote:
You're also misrepresenting what the difference in opinion is. If you'd ask people "is it good to mix cosmetics and functional changes?" many would answer "no". They just wouldn't mean that as literally and with so little room for common sense as you do. Completely reformatting a file
s/common sense/your common sense/
[... repeation of old argument that your personal oppinion overrides all rules and oppinions of others, no matter about what or where ...]
[... argument that you are the only person who does any work and others are irrelevant ...]
If you're going to reply with only insults at least try to make them more interesting. Those are rather lame.
You're either being stupid or deliberately misunderstand. Obviously Diego would not have reacted that way if Ivan had just made to commit to change it to any consistent spelling before Diego's changes. What Iive did was revert changes Diego had just made.
Iive can hardly claim to know the correct spelling with superior authority,
That says the master of all knowledge and ultimate athority ...
Another lame insult that doesn't even match the content of what you're replying to except using some of the same words.
Diego wanted the other spelling as he had just changed it that way. Yet Iive changed the spelling back without any discussion, not even flaming that would have indicated there would be no agreement.
iive discussed as much as diego did, that was bad in both cases sure.
What Diego did was OK, what Ivan did was not. I already addressed the differences in the previous mail. See the part quoted earlier. If Ivan had made a commit to make the spellings consistent (even his way) before Diego did anything that would not have been so bad. What he did was change make an opposite change in response to Diego's change with no discussion.
On Sat, May 31, 2008 at 09:59:30PM +0300, Uoti Urpala wrote:
On Sat, 2008-05-31 at 20:11 +0200, Michael Niedermayer wrote:
On Sat, May 31, 2008 at 07:12:50AM +0300, Uoti Urpala wrote: [...]
Diego wanted the other spelling as he had just changed it that way. Yet Iive changed the spelling back without any discussion, not even flaming that would have indicated there would be no agreement.
iive discussed as much as diego did, that was bad in both cases sure.
What Diego did was OK, what Ivan did was not.
No, that is just your personal oppinion [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Everything should be made as simple as possible, but not simpler. -- Albert Einstein
On Sat, May 31, 2008 at 10:13:56PM +0200, Michael Niedermayer wrote:
On Sat, May 31, 2008 at 09:59:30PM +0300, Uoti Urpala wrote:
On Sat, 2008-05-31 at 20:11 +0200, Michael Niedermayer wrote:
On Sat, May 31, 2008 at 07:12:50AM +0300, Uoti Urpala wrote: [...]
Diego wanted the other spelling as he had just changed it that way. Yet Iive changed the spelling back without any discussion, not even flaming that would have indicated there would be no agreement.
iive discussed as much as diego did, that was bad in both cases sure.
What Diego did was OK, what Ivan did was not.
No, that is just your personal oppinion
Um, we can discuss the libmpcodecs changes, but the other parts were documentation related for which 1) Diego is (at least inofficially) the maintainer 2) It is his job to keep the documentation consistent 3) For documentation it was decided that Xvid is the correct spelling Now, Ivan did not notice 3) I guess, nor had much reason to read the documentation lately, so I will not throw blame in that direction either but both the kind of flames about a 'd' vs. 'D' (well, actually I do not really think that is actually what it is about) and keeping half of the stuff using a different spelling as the other half is quite ridiculous. As a compromise I suggest: flame the Xvid guys for the renaming while supporting it only half-assed in public and do something more productive for MPlayer. I am sure I can find everyone something to do if you can't by yourselves.... Greetings, Reimar Döffinger
On Sat, May 31, 2008 at 10:52:46PM +0200, Reimar Döffinger wrote:
On Sat, May 31, 2008 at 10:13:56PM +0200, Michael Niedermayer wrote:
On Sat, May 31, 2008 at 09:59:30PM +0300, Uoti Urpala wrote:
On Sat, 2008-05-31 at 20:11 +0200, Michael Niedermayer wrote:
On Sat, May 31, 2008 at 07:12:50AM +0300, Uoti Urpala wrote: [...]
Diego wanted the other spelling as he had just changed it that way. Yet Iive changed the spelling back without any discussion, not even flaming that would have indicated there would be no agreement.
iive discussed as much as diego did, that was bad in both cases sure.
What Diego did was OK, what Ivan did was not.
No, that is just your personal oppinion
Um, we can discuss the libmpcodecs changes, but the other parts were documentation related for which 1) Diego is (at least inofficially) the maintainer 2) It is his job to keep the documentation consistent 3) For documentation it was decided that Xvid is the correct spelling
Now, Ivan did not notice 3) I guess, nor had much reason to read the documentation lately, so I will not throw blame in that direction either
hmm, i was unaware of 3) myself, though i think diego even mentioned it in the flames today ... [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Observe your enemies, for they first find out your faults. -- Antisthenes
On Sat, May 31, 2008 at 11:16:54PM +0200, Michael Niedermayer wrote:
On Sat, May 31, 2008 at 10:52:46PM +0200, Reimar Döffinger wrote:
On Sat, May 31, 2008 at 10:13:56PM +0200, Michael Niedermayer wrote:
On Sat, May 31, 2008 at 09:59:30PM +0300, Uoti Urpala wrote:
On Sat, 2008-05-31 at 20:11 +0200, Michael Niedermayer wrote:
On Sat, May 31, 2008 at 07:12:50AM +0300, Uoti Urpala wrote: [...]
Diego wanted the other spelling as he had just changed it that way. Yet Iive changed the spelling back without any discussion, not even flaming that would have indicated there would be no agreement.
iive discussed as much as diego did, that was bad in both cases sure.
What Diego did was OK, what Ivan did was not.
No, that is just your personal oppinion
Um, we can discuss the libmpcodecs changes, but the other parts were documentation related for which 1) Diego is (at least inofficially) the maintainer 2) It is his job to keep the documentation consistent 3) For documentation it was decided that Xvid is the correct spelling
Now, Ivan did not notice 3) I guess, nor had much reason to read the documentation lately, so I will not throw blame in that direction either
hmm, i was unaware of 3) myself, though i think diego even mentioned it in the flames today ...
Well, I do not want to claim how much it was discussed anyway, but I do remember it, and I think the situation was even less clear back then, I think even the homepage was inconsistent back then, which AFAICT it is no longer. Everything IIRC, if nothing else take this just as an explanation how things can come to be viewed very differently, even if only through bad memory (e.g. it might be the major part of the discussion/research was on IRC, in which case you can not have known of it). Greetings, Reimar Döffinger
On 5/31/08, Diego Biurrun <diego@biurrun.de> wrote:
On Sat, May 31, 2008 at 08:51:17PM +0200, Michael Niedermayer wrote:
On Sat, May 31, 2008 at 05:23:32PM +0200, Diego Biurrun wrote:
On Sat, May 31, 2008 at 12:58:02AM +0200, Michael Niedermayer wrote:
On Fri, May 30, 2008 at 07:49:24PM +0200, Diego Biurrun wrote:
I know most of them personally, like them and the feeling is mutual. Nonetheless nowadays MPlayer is being developed by a new generation of people. That does not mean that the contributions of those people are insubstantial or that not appreciated.
Yes but it also does not mean that the experience the "old generation" has collected over the years should be ignored like it is. The people not being against uoti are new people who do not yet have the same experience reimar, roberto, iive, ... have in respect to maintaining a large project with many developers working, joining and leaving ...
Reimar never spoke in favor of removing Uoti.
Not litterally i think, but iam pretty sure he said something to the effect of him being in favor of uoti being removed if theres no other solution being found ...
.. i think .. pretty sure .. something to the effect of ..
He did not say anything like that literally, nor implied. I was the one to talk to him personally, not you. Let Reimar speak for himself, do not make guesses or assumptions about his opinions.
Or the same about commiting with no warning to code actively maintained by others. Even if one ignores what the "old generation" says, just looking at the recent months shows how such commits get everyone near boiling. Even you go crazy if iive just changes xvids spelling.
I did not "go crazy". I'm old enough to be able not to freak out over such silly provocations.
You always freak out about any flies from ivans direction.
No, I think that nowadays I can remain pretty calm when he tries to provoke me. You do not have the dubious pleasure of sharing IRC channels with him and don't know half of what goes on between us.
To say that Ivan and I do not get along well is an understatement. He has personally attacked and insulted me many times. I'm through with him. That said, I have to put up with him around here and try my best to ignore him.
Note that many many outsiders consider the environment around FFmpeg very hostile.
Note that many many pigs consider birds ugly. no i have no evidence but neither do you.
It seems that you move in FFmpeg-related circles only then. I have talked to people from many other multimedia projects and distributions. FFmpeg is very often viewed as a harsh and difficult environment with which communication is not easy and flames abound.
harsh/flames/... != hostile
That's a matter of perception. I do not see FFmpeg as hostile, but it surely can be intimidating for newcomers. And I have spoken to many people who do consider FFmpeg hostile.
So people are willing to put up with more hardship or simply are forced to work with FFmpeg one way or the other because they cannot switch to an alternative.
You should probably post a detailed list of what you think can be improved to ffmpeg-dev
I'm working on it all the time when I am in contact with other projects at LinuxTag, on IRC or wherever. You may have noticed the Debian patch I forwarded to ffmpeg-devel. I have been working with the new FFmpeg Debian maintainer these past few days reviewing their patchset. With my help he could determine that half of the patches are no longer necessary and delete them.
Speaking of that, i really would appreciate if all distros which package ffmpeg could send their patches to ffmpeg-dev. It would be of mutual benefit weeding out bad patches/bugs (which ruin ffmpegs good name as well as the distros) is mainly what iam thinkibng of ...
I 100% agree. At every opportunity I get I try to work with packagers of FFmpeg and MPlayer, try to make them send patches upstream and generally stay in contact when any issues appear.
id like to point out how you complained about iive changing the spelling of xvid. Which honestly is totally irrelevant compared to changes to the code.
I did not complain about Ivan changing the spelling. I complained about Ivan reverting my commit without prior notice. If he had reverted just the files he maintains - fine. But he chose to revert the files I maintain as well. He did it on purpose. This is obviously a provocation.
hypocrite ...
WTF? Have we descended towards throwing around insults already?
didnt you say something about being old enough to not be provocated easily just a few lines above?
No. I was talking about not being provoked by Ivan, at least not as easily as I used to. That does not mean that I do not find being called a hypocrite by you insulting.
So for the record: I do not consider myself a hypocrite and find the allegation very insulting.
Besides, hypocrite applies because you complain against iive while you really did nearly the same to him.
No, I did not. I did very much *not* revert his commits without any discussion or expressing dissent.
And it was actually intended to be more funny than insulting but ohh well ... Iam just ommiting the smilies because the ambiguity is funny in itself
Well, if this discussion is not serious, then I suggest we close the issue and be done with it. You are the one here behaving as if his life depended on the issues we are discussing. How you can start being funny now and expect others to understand your hidden jokes is beyond me.
How come that you don't have an issue with such behavior?
Lets see. * I do not know at all if Xvid or XviD is more correct. I do know it was XviD once in the past so this one can not be completely wrong now. * You changed the spelling to Xvid in files maintained by you and ivve * iive changed the spelling back to XviD in files maintained by you and ivve * he did the same you did, you started * you broke the policy he reverted the commit which broke the policy No the whole was not ideal but nothing bad happened we are just back at the start and have another chance to find a solution. If the spelling bothers you. Just start a discussion on mplayer-dev about it, like it should IMHO have been in the first place already.
Are you seriously suggesting that we should waste time on dev-eng discussing which way to spell Xvid? When this was hashed out and committed to the rest of the documentation in 2006?
If not then why are you complaining about iive changing it? Either it does matter or it does not ...
I'll assume that you are neither playing one of your weird jokes again nor being deliberately dense and repeat my explanation:
I'm not complaining about Ivan making the change. I'm not even complaining about Ivan reverting my changes to his files. However, when he reverts the changes I just did to files I maintain without prior notice or discussion and without even making me aware that he disagrees with my changes, then this is obviously and knowingly being done against my wishes and intentions and is bound to provoke and stir up controversy.
I did not made a "change". I reverted commit. Commits are reverted as a whole. I reverted the commit because few other developers had already questioned it. I reverted the commit because it changed files I maintain without prior notice. I reverted the commit because it mixed cosmetics (changes in comments) with functional changes (in strings and resulting binary). I reverted the commit because as Maintainer of XviD I do have closer knowledge about what is going on there. I had given short prior notice in the original thread why I do the revert. It is my fault that it was short, I thought the prior objection were clear sign, and Diego is deliberately ignoring objections (like always). I did my best to remain objective and to backup my decision with arguments. Like that the codec itself is using the name XviD, no matter what the website says, (and wikipedia uses the site as reference). And this is for version that were released after the website change. I could have used the rules as excuse, but I deliberately avoided doing so. Diego however tried to use the rules in his favor, claimed he maintains 3 files in this commit. Then he went ahead and recommitted his changes in 6 files.
On Sun, Jun 01, 2008 at 01:20:19AM +0300, Ivan Kalvachev wrote:
On 5/31/08, Diego Biurrun <diego@biurrun.de> wrote:
I'm not complaining about Ivan making the change. I'm not even complaining about Ivan reverting my changes to his files. However, when he reverts the changes I just did to files I maintain without prior notice or discussion and without even making me aware that he disagrees with my changes, then this is obviously and knowingly being done against my wishes and intentions and is bound to provoke and stir up controversy.
I did not made a "change". I reverted commit. Commits are reverted as a whole.
I reverted the commit because few other developers had already questioned it.
False.
I reverted the commit because it mixed cosmetics (changes in comments) with functional changes (in strings and resulting binary).
Ridiculous.
Diego is deliberately ignoring objections (like always).
False.
I did my best to remain objective and to backup my decision with arguments.
Laughable.
I could have used the rules as excuse, but I deliberately avoided doing so.
The contrary is true.
Diego however tried to use the rules in his favor, claimed he maintains 3 files in this commit.
I maintain the spelling in all of MPlayer. Diego P.S.: Get a grip on your broken mailer once and for all and teach it to break long lines.
On 31 May 2008, at 22:26, Reimar Döffinger wrote:
On Sat, May 31, 2008 at 11:16:54PM +0200, Michael Niedermayer wrote:
On Sat, May 31, 2008 at 10:52:46PM +0200, Reimar Döffinger wrote:
On Sat, May 31, 2008 at 10:13:56PM +0200, Michael Niedermayer wrote:
On Sat, May 31, 2008 at 09:59:30PM +0300, Uoti Urpala wrote:
On Sat, 2008-05-31 at 20:11 +0200, Michael Niedermayer wrote:
On Sat, May 31, 2008 at 07:12:50AM +0300, Uoti Urpala wrote: [...] > Diego wanted the other spelling as he had just changed it that > way. Yet > Iive changed the spelling back without any discussion, not > even flaming > that would have indicated there would be no agreement.
iive discussed as much as diego did, that was bad in both cases sure.
What Diego did was OK, what Ivan did was not.
No, that is just your personal oppinion
Um, we can discuss the libmpcodecs changes, but the other parts were documentation related for which 1) Diego is (at least inofficially) the maintainer 2) It is his job to keep the documentation consistent 3) For documentation it was decided that Xvid is the correct spelling
Now, Ivan did not notice 3) I guess, nor had much reason to read the documentation lately, so I will not throw blame in that direction either
hmm, i was unaware of 3) myself, though i think diego even mentioned it in the flames today ...
Well, I do not want to claim how much it was discussed anyway, but I do remember it, and I think the situation was even less clear back then, I think even the homepage was inconsistent back then, which AFAICT it is no longer. Everything IIRC, if nothing else take this just as an explanation how things can come to be viewed very differently, even if only through bad memory (e.g. it might be the major part of the discussion/research was on IRC, in which case you can not have known of it).
Not that it's worth much, nor do I care, but I always preferred 'XviD' though I do remember 'Xvid' being made the consistent spelling. Whichever is chosen, I don't think it really matters. It's not like either has a particularly functional or documentation-al benefit to the project. Even if it were inconsistent people would still be able to comprehend that 'Xvid'/'XviD' was the external project in question. Rob
On Sat, May 31, 2008 at 11:16:54PM +0200, Michael Niedermayer wrote:
On Sat, May 31, 2008 at 10:52:46PM +0200, Reimar Döffinger wrote:
On Sat, May 31, 2008 at 10:13:56PM +0200, Michael Niedermayer wrote:
On Sat, May 31, 2008 at 09:59:30PM +0300, Uoti Urpala wrote:
On Sat, 2008-05-31 at 20:11 +0200, Michael Niedermayer wrote:
On Sat, May 31, 2008 at 07:12:50AM +0300, Uoti Urpala wrote: [...]
Diego wanted the other spelling as he had just changed it that way. Yet Iive changed the spelling back without any discussion, not even flaming that would have indicated there would be no agreement.
iive discussed as much as diego did, that was bad in both cases sure.
What Diego did was OK, what Ivan did was not.
No, that is just your personal oppinion
Um, we can discuss the libmpcodecs changes, but the other parts were documentation related for which 1) Diego is (at least inofficially) the maintainer 2) It is his job to keep the documentation consistent 3) For documentation it was decided that Xvid is the correct spelling
Now, Ivan did not notice 3) I guess, nor had much reason to read the documentation lately, so I will not throw blame in that direction either
hmm, i was unaware of 3) myself, though i think diego even mentioned it in the flames today ...
Right. And this was decided back then by Guillaume, who maintains the Xvid documentation. I just noticed that some places had been overlooked and fixed them quickly. I routinely do these sorts of changes and do not remember any to have caused controversy before. Somebody may have commented, but surely nobody got "infuriated" and reverted my actions. Diego
Hello, On Sun, Jun 1, 2008 at 2:56 PM, Diego Biurrun <diego@biurrun.de> wrote: [..]
Right. And this was decided back then by Guillaume, who maintains the Xvid documentation. I just noticed that some places had been overlooked and fixed them quickly. I routinely do these sorts of changes and do not remember any to have caused controversy before. Somebody may have commented, but surely nobody got "infuriated" and reverted my actions.
I don't remember making a decision regarding the capitalization of xvid. I routinely use the capitalization "XviD" since it's the capitalization of the logo before some of the xvid folks tried to turn xvid into a company product. After doing a quick Google search, it looks to me that people use both capitalization, with a certain tentency for people who don't know xvid so well to capitalize it "Xvid", while xvid-nerds, like what you'd see on doom9 forum ( http://forum.doom9.org/forumdisplay.php?f=52 ) whould spell it XviD. All in all, I don't care which capitalization is used, I just prefer it to be consistent. Guillaume -- I don't measure a man's success by how high he climbs but how high he bounces when he hits bottom. -- George S. Patton
On Mon, Jun 02, 2008 at 12:01:12AM +0200, Guillaume POIRIER wrote:
On Sun, Jun 1, 2008 at 2:56 PM, Diego Biurrun <diego@biurrun.de> wrote:
[..]
Right. And this was decided back then by Guillaume, who maintains the Xvid documentation. I just noticed that some places had been overlooked and fixed them quickly. I routinely do these sorts of changes and do not remember any to have caused controversy before. Somebody may have commented, but surely nobody got "infuriated" and reverted my actions.
I don't remember making a decision regarding the capitalization of xvid. I routinely use the capitalization "XviD" since it's the capitalization of the logo before some of the xvid folks tried to turn xvid into a company product.
I stand corrected, it was Sebastian Krämer (German translator) who made the change. The following log message got me confused. ------------------------------------------------------------------------ r20899 | gpoirier | 2006-11-13 21:40:29 +0100 (Mon, 13 Nov 2006) | 2 lines Changed paths: M /trunk/DOCS/xml/fr/codecs.xml M /trunk/DOCS/xml/fr/encoding-guide.xml M /trunk/DOCS/xml/fr/faq.xml M /trunk/DOCS/xml/fr/mencoder.xml rename: XviD -> Xvid ------------------------------------------------------------------------ Since you usually always prepend such messages with a "synced with rXXXXX" I thought this was the original change, when in fact the original change was ------------------------------------------------------------------------ r20876 | kraymer | 2006-11-13 09:53:20 +0100 (Mon, 13 Nov 2006) | 2 lines Changed paths: M /trunk/DOCS/man/en/mplayer.1 M /trunk/DOCS/xml/en/codecs.xml M /trunk/DOCS/xml/en/encoding-guide.xml M /trunk/DOCS/xml/en/faq.xml M /trunk/DOCS/xml/en/mencoder.xml rename: XviD -> Xvid ------------------------------------------------------------------------ The relevant discussion happened in http://lists.mplayerhq.hu/pipermail/mplayer-docs/2006-November/008505.html Diego
On 6/2/08, Guillaume POIRIER <poirierg@gmail.com> wrote:
Hello,
On Sun, Jun 1, 2008 at 2:56 PM, Diego Biurrun <diego@biurrun.de> wrote:
[..]
Right. And this was decided back then by Guillaume, who maintains the Xvid documentation. I just noticed that some places had been overlooked and fixed them quickly. I routinely do these sorts of changes and do not remember any to have caused controversy before. Somebody may have commented, but surely nobody got "infuriated" and reverted my actions.
I don't remember making a decision regarding the capitalization of xvid. I routinely use the capitalization "XviD" since it's the capitalization of the logo before some of the xvid folks tried to turn xvid into a company product. After doing a quick Google search, it looks to me that people use both capitalization, with a certain tentency for people who don't know xvid so well to capitalize it "Xvid", while xvid-nerds, like what you'd see on doom9 forum ( http://forum.doom9.org/forumdisplay.php?f=52 ) would spell it XviD.
Well, said.
All in all, I don't care which capitalization is used, I just prefer it to be consistent.
The only person who insist on the Xvid spelling is Diego. As long as I am maintainer of XviD the source files won't be renamed, so they won't be consistent. However now that I've taken my stand Diego would never agree to revert all the changes and let me "win". Actually he restarted this thread only to use my rash revert as vehicle to indulge Uoti. He didn't restarted it at clear head at all, even if he claimed that. He is forcing his changes before we have chance to discuss it on clear heads. Even if this means breaking rule 12 that requires discussion on controversial changes. And after so many flame mails on the subject, nobody can argue the change is not controversial. Not that discussion would have any merits when your voice can override everybody else by definition. Diego, you are not suited for leader. A leader should never drop so low. Surrender now.
Ivan Kalvachev a écrit :
As long as I am maintainer of XviD the source files won't be renamed, so they won't be consistent.
As long as you are ...
However now that I've taken my stand Diego would never agree to revert all the changes and let me "win".
Everything will be so nice when you'll finally understand what a team actually is and that there's nothing to win ...
Diego, you are not suited for leader. A leader should never drop so low.
Actually, as low one can drop, there's a step that can't be reached. But you probably know what I'm talking about ;-) Ben
On Tue, Jun 03, 2008 at 12:36:18AM +0300, Ivan Kalvachev wrote:
However now that I've taken my stand Diego would never agree to revert all the changes and let me "win".
I don't give a flying rat's behind about the spelling as long as it is consistent. I do, however, mind the time that I keep losing because of this non-issue.
Diego, you are not suited for leader. A leader should never drop so low. Surrender now.
|o| There, my hands are up in the air. WTH do you want? That I leave the project? Diego P.S.: Your mailer sucks.
On 6/3/08, Diego Biurrun <diego@biurrun.de> wrote:
On Tue, Jun 03, 2008 at 12:36:18AM +0300, Ivan Kalvachev wrote:
However now that I've taken my stand Diego would never agree to revert all the changes and let me "win".
I don't give a flying rat's behind about the spelling as long as it is consistent. I do, however, mind the time that I keep losing because of this non-issue.
Diego, you are not suited for leader. A leader should never drop so low. Surrender now.
|o|
There, my hands are up in the air.
WTH do you want? That I leave the project?
That I've always wanted. You not setting the rules.
Diego
P.S.: Your mailer sucks.
Tell that to Google.
On Tuesday, 03 June 2008 at 10:32, Ivan Kalvachev wrote:
On 6/3/08, Diego Biurrun <diego@biurrun.de> wrote:
On Tue, Jun 03, 2008 at 12:36:18AM +0300, Ivan Kalvachev wrote:
However now that I've taken my stand Diego would never agree to revert all the changes and let me "win".
I don't give a flying rat's behind about the spelling as long as it is consistent. I do, however, mind the time that I keep losing because of this non-issue.
Diego, you are not suited for leader. A leader should never drop so low. Surrender now.
|o|
There, my hands are up in the air.
WTH do you want? That I leave the project?
That I've always wanted. You not setting the rules.
Ivan, you're out of line. You've let your personal feelings cloud your judgement. You've blown this issue out of proportion. Diego has done nothing wrong in this case. He is the maintainer of the documentation, so it is within his compentence to make such changes (that is, keeping spelling consistent). You've done little more than flame for a long time now, so please stop behaving like a child in a sandbox. I recognise your right to maintain the code you want to maintain, but let's be honest: you haven't done a lot of maintenance for quite some time and there are still some unfixed problems with your code (lack of XvMC detection, to name one). That, in my book, gives you little credibility. I think you're forgetting that open source is also about cooperation. Please try to be more cooperative and less inflammatory in the future.
P.S.: Your mailer sucks.
Tell that to Google.
Nobody is forcing you to use GoogleMail. Regards, R. -- MPlayer http://mplayerhq.hu | Livna http://rpm.livna.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan
On Tuesday, 03 June 2008 at 13:08, Dominik 'Rathann' Mierzejewski wrote: [...]
You've done little more than flame for a long time now, so please stop behaving like a child in a sandbox. I recognise your right to maintain the code you want to maintain, but let's be honest: you haven't done a lot of maintenance for quite some time and there are still some unfixed problems with your code (lack of XvMC detection, to name one).
I stand corrected. There is working autodetection, it's just not enabled. Still, there were reports about problems with menu IIRC. The point is, you're not very active in terms of code development right now and yet you usurp the right to know what's best for MPlayer. This is wrong. Regards, R. -- MPlayer http://mplayerhq.hu | Livna http://rpm.livna.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan
On Tue, Jun 03, 2008 at 02:49:17PM +0200, Dominik 'Rathann' Mierzejewski wrote:
On Tuesday, 03 June 2008 at 13:08, Dominik 'Rathann' Mierzejewski wrote: [...]
You've done little more than flame for a long time now, so please stop behaving like a child in a sandbox. I recognise your right to maintain the code you want to maintain, but let's be honest: you haven't done a lot of maintenance for quite some time and there are still some unfixed problems with your code (lack of XvMC detection, to name one).
I stand corrected. There is working autodetection, it's just not enabled.
Why is it not enabled if it works? The following line has been there ever since the first revision: _xvmc=no #auto when complete Diego
On 5/31/08, Reimar Döffinger <Reimar.Doeffinger@stud.uni-karlsruhe.de> wrote:
On Sat, May 31, 2008 at 10:13:56PM +0200, Michael Niedermayer wrote:
On Sat, May 31, 2008 at 09:59:30PM +0300, Uoti Urpala wrote:
On Sat, 2008-05-31 at 20:11 +0200, Michael Niedermayer wrote:
On Sat, May 31, 2008 at 07:12:50AM +0300, Uoti Urpala wrote: [...]
Diego wanted the other spelling as he had just changed it that way. Yet Iive changed the spelling back without any discussion, not even flaming that would have indicated there would be no agreement.
iive discussed as much as diego did, that was bad in both cases sure.
What Diego did was OK, what Ivan did was not.
No, that is just your personal oppinion
Um, we can discuss the libmpcodecs changes, but the other parts were documentation related for which 1) Diego is (at least inofficially) the maintainer 2) It is his job to keep the documentation consistent 3) For documentation it was decided that Xvid is the correct spelling
Now, Ivan did not notice 3) I guess, nor had much reason to read the documentation lately, so I will not throw blame in that direction either but both the kind of flames about a 'd' vs. 'D' (well, actually I do not really think that is actually what it is about) and keeping half of the stuff using a different spelling as the other half is quite ridiculous. As a compromise I suggest: flame the Xvid guys for the renaming while supporting it only half-assed in public and do something more productive for MPlayer. I am sure I can find everyone something to do if you can't by yourselves....
xvid.org now belongs to "Xvid Solutions GmbH". The firm formed by some of the (main) xvid developers. They turned their backs to the community and are developing their own proprietary codecs.
On Sat, 31 May 2008 22:13:56 +0200, Michael Niedermayer <michaelni@gmx.at> wrote:
On Sat, May 31, 2008 at 09:59:30PM +0300, Uoti Urpala wrote:
On Sat, 2008-05-31 at 20:11 +0200, Michael Niedermayer wrote:
On Sat, May 31, 2008 at 07:12:50AM +0300, Uoti Urpala wrote: [...]
Diego wanted the other spelling as he had just changed it that way. Yet Iive changed the spelling back without any discussion, not even flaming that would have indicated there would be no agreement.
iive discussed as much as diego did, that was bad in both cases sure.
What Diego did was OK, what Ivan did was not.
No, that is just your personal oppinion
guys guys.... do we need mplayer-flames back again ? hehe (its a joke, for those counting) -compn
On Sat, May 31, 2008 at 12:58:02AM +0200, Michael Niedermayer wrote:
On Fri, May 30, 2008 at 07:49:24PM +0200, Diego Biurrun wrote:
On Fri, May 30, 2008 at 04:58:34AM +0200, Michael Niedermayer wrote:
On Fri, May 30, 2008 at 03:04:14AM +0200, Diego Biurrun wrote: [...]
We have 5 people (Michael, Ivan, Alban, Aurelien, Roberto) voting for Uoti's removal and 4 people speaking up against (Uoti, Eugeni, Benjamin, Diego). This is a far cry from a clear situation, especially given that each of the latter 4 is more active than all of the 5 combined.
Its true for the current activity but if i look at all commits of all times i much rather loose all of the later 4 than a single one of the first 5.
I think your anger is clouding your judgement. You should try to reevaluate the contributions of all nine people mentioned above.
I very much respect all the developers listed above,
Of course ... if anything i said sounded like i did not then this certainly was not intended.
If your statement above was not intented to be disrespectful, then I must say you failed catastrophically.
I know most of them personally, like them and the feeling is mutual. Nonetheless nowadays MPlayer is being developed by a new generation of people. That does not mean that the contributions of those people are insubstantial or that not appreciated.
Yes but it also does not mean that the experience the "old generation" has collected over the years should be ignored like it is. The people not being against uoti are new people who do not yet have the same experience reimar, roberto, iive, ... have in respect to maintaining a large project with many developers working, joining and leaving ...
Reimar never spoke in favor of removing Uoti.
If the "old genration" says mixing cosmetics and functional changes causes problems why would anyone think it is not so?
You are completely exaggerating. The example that we are discussing here is trivial. The thing in front of your eyes is a fly, not an elephant.
Becasue the always better knowing uoti said it? On which big project has he worked in the past so he could even have that experience?
Which other projects have you worked on, BTW? Note that one of the reasons Loren Merritt keeps x264 out of FFmpeg is that he prefers mixing cosmetic and functional changes: http://akuvian.org/src/x264/why_x264_isnt_part_of_ffmpeg.txt I'm not saying that I support the position, but the assumption that no competent and reasonable programmers hold that point of view is false.
Or the same about commiting with no warning to code actively maintained by others. Even if one ignores what the "old generation" says, just looking at the recent months shows how such commits get everyone near boiling. Even you go crazy if iive just changes xvids spelling.
I did not "go crazy". I'm old enough to be able not to freak out over such silly provocations.
What if i did the same with indexes/indices? IMHO that change made absolutely no sense, both are correct and there was no need to clobber the history. Wouldnt you have been angry as well if someone (maybe iive) would have just reverted it?
The opposite happened. People expressed their concern in a calm and reasonable tone without jumping to action. I have absolutely no problem with that.
If you agree that a little bit of communication before commiting to code maintaned by others would be good then why is uoti apparently exempt from this rule?
Communicating every trivial change like adding a const or changing spelling is an unnecessary burden. We have countless precedents for committing such changes right away without previous discussion.
But you could go further back in history and find people that have done even more, like Nick and Arpi, yet are not steering this project any longer.
it would be great if arpi would return and lead mplayer once again. The project really decayed after he left, back then noone complained about the too low manpower, because it wasnt too low ...
Your memory is a bit too rosy. Arpi left MPlayer after realizing that he had constructed an unmaintainable monster. His attempt to rewrite it failed. And even back then many many patches fell through the cracks. Arpi himself complained about the lack of help he was getting when it came to reviewing patches.
Note that many many outsiders consider the environment around FFmpeg very hostile.
Note that many many pigs consider birds ugly. no i have no evidence but neither do you.
It seems that you move in FFmpeg-related circles only then. I have talked to people from many other multimedia projects and distributions. FFmpeg is very often viewed as a harsh and difficult environment with which communication is not easy and flames abound. We are making progress in the right direction, but we can still improve.
Of course, FFmpeg can get away with it, because there is no alternative to it and it holds a monopoly on its "market".
*GPL software cannot hold a monopoly, it can always be forked
A fork has to be able to survive and the benefit of forking has to outweigh the costs. This is not the case for FFmpeg, which is very much alive with competent and active developers that are not easily replaced. Also, no viable alternative to FFmpeg exists. If you don't like MPlayer, you can choose vlc or xine instead, like Mike did when he got fed up with Arpi.
So people are willing to put up with more hardship or simply are forced to work with FFmpeg one way or the other because they cannot switch to an alternative.
You should probably post a detailed list of what you think can be improved to ffmpeg-dev
I'm working on it all the time when I am in contact with other projects at LinuxTag, on IRC or wherever. You may have noticed the Debian patch I forwarded to ffmpeg-devel. I have been working with the new FFmpeg Debian maintainer these past few days reviewing their patchset. With my help he could determine that half of the patches are no longer necessary and delete them.
id like to point out how you complained about iive changing the spelling of xvid. Which honestly is totally irrelevant compared to changes to the code.
I did not complain about Ivan changing the spelling. I complained about Ivan reverting my commit without prior notice. If he had reverted just the files he maintains - fine. But he chose to revert the files I maintain as well. He did it on purpose. This is obviously a provocation.
hypocrite ...
WTF? Have we descended towards throwing around insults already?
How come that you don't have an issue with such behavior?
Lets see. * I do not know at all if Xvid or XviD is more correct. I do know it was XviD once in the past so this one can not be completely wrong now. * You changed the spelling to Xvid in files maintained by you and ivve * iive changed the spelling back to XviD in files maintained by you and ivve * he did the same you did, you started * you broke the policy he reverted the commit which broke the policy No the whole was not ideal but nothing bad happened we are just back at the start and have another chance to find a solution. If the spelling bothers you. Just start a discussion on mplayer-dev about it, like it should IMHO have been in the first place already.
Are you seriously suggesting that we should waste time on dev-eng discussing which way to spell Xvid? When this was hashed out and committed to the rest of the documentation in 2006? Are you seriously suggesting that I broke the policy by changing the spelling and, assuming that I did, it is OK to remedy that by breaking the policy again, i.e. two wrongs make a right? There was no previous indication that Ivan opposed the change and no time for me to react. At the same time it was obvious to Ivan that I would oppose him reverting my commit, at the very least for the files I maintain. Ivan chose to ignore that, making his course of action a needless trollish provocation that could lead to a commit war. How come you do not have an issue with this kind of behavior? The problem I have with you here is that you are applying double standards. On the one hand you insist on the strictest possible interpretation of the policy for issues that you care about like separation of whitespace changes from other types of changes and demand draconian punishments for offenders. On the other hand you are very lax yourself about issues you consider less important like adding full license headers to files or updating the documentation to match your code changes. You have behaved this way long before this incident, don't tell me it is a result of it. That you then go on to call me - the person that goes out of its way to split commits to your liking, writes the documentation for you, etc. - a hypocrite is galling and does add insult to previous injury. Diego
On Sat, May 31, 2008 at 05:23:32PM +0200, Diego Biurrun wrote:
On Sat, May 31, 2008 at 12:58:02AM +0200, Michael Niedermayer wrote:
On Fri, May 30, 2008 at 07:49:24PM +0200, Diego Biurrun wrote:
On Fri, May 30, 2008 at 04:58:34AM +0200, Michael Niedermayer wrote:
On Fri, May 30, 2008 at 03:04:14AM +0200, Diego Biurrun wrote: [...]
We have 5 people (Michael, Ivan, Alban, Aurelien, Roberto) voting for Uoti's removal and 4 people speaking up against (Uoti, Eugeni, Benjamin, Diego). This is a far cry from a clear situation, especially given that each of the latter 4 is more active than all of the 5 combined.
Its true for the current activity but if i look at all commits of all times i much rather loose all of the later 4 than a single one of the first 5.
I think your anger is clouding your judgement. You should try to reevaluate the contributions of all nine people mentioned above.
I very much respect all the developers listed above,
Of course ... if anything i said sounded like i did not then this certainly was not intended.
If your statement above was not intented to be disrespectful, then I must say you failed catastrophically.
I very rarely intent to actually be disrespectful or insulting. And i can assure you that i would not be using such ambigous statements if disrespectfullness where my goal. It is rather that i say what i think, and i belive it is better than lieing just because that would be more respectfull. And as said you compared people as well, so dont complain if you get your own "dissrespect" back.
I know most of them personally, like them and the feeling is mutual. Nonetheless nowadays MPlayer is being developed by a new generation of people. That does not mean that the contributions of those people are insubstantial or that not appreciated.
Yes but it also does not mean that the experience the "old generation" has collected over the years should be ignored like it is. The people not being against uoti are new people who do not yet have the same experience reimar, roberto, iive, ... have in respect to maintaining a large project with many developers working, joining and leaving ...
Reimar never spoke in favor of removing Uoti.
Not litterally i think, but iam pretty sure he said something to the effect of him being in favor of uoti being removed if theres no other solution being found ... [...]
Or the same about commiting with no warning to code actively maintained by others. Even if one ignores what the "old generation" says, just looking at the recent months shows how such commits get everyone near boiling. Even you go crazy if iive just changes xvids spelling.
I did not "go crazy". I'm old enough to be able not to freak out over such silly provocations.
You always freak out about any flies from ivans direction. [...]
Note that many many outsiders consider the environment around FFmpeg very hostile.
Note that many many pigs consider birds ugly. no i have no evidence but neither do you.
It seems that you move in FFmpeg-related circles only then. I have talked to people from many other multimedia projects and distributions. FFmpeg is very often viewed as a harsh and difficult environment with which communication is not easy and flames abound.
harsh/flames/... != hostile
We are making progress in the right direction, but we can still improve.
Of course, FFmpeg can get away with it, because there is no alternative to it and it holds a monopoly on its "market".
*GPL software cannot hold a monopoly, it can always be forked
A fork has to be able to survive and the benefit of forking has to outweigh the costs. This is not the case for FFmpeg, which is very much
exactly, there is no reason for people to fork ffmpeg, but in case of mplayer there is a reason ...
alive with competent and active developers that are not easily replaced.
Also, no viable alternative to FFmpeg exists. If you don't like MPlayer, you can choose vlc or xine instead, like Mike did when he got fed up with Arpi.
So people are willing to put up with more hardship or simply are forced to work with FFmpeg one way or the other because they cannot switch to an alternative.
You should probably post a detailed list of what you think can be improved to ffmpeg-dev
I'm working on it all the time when I am in contact with other projects at LinuxTag, on IRC or wherever. You may have noticed the Debian patch I forwarded to ffmpeg-devel. I have been working with the new FFmpeg Debian maintainer these past few days reviewing their patchset. With my help he could determine that half of the patches are no longer necessary and delete them.
Speaking of that, i really would appreciate if all distros which package ffmpeg could send their patches to ffmpeg-dev. It would be of mutual benefit weeding out bad patches/bugs (which ruin ffmpegs good name as well as the distros) is mainly what iam thinkibng of ...
id like to point out how you complained about iive changing the spelling of xvid. Which honestly is totally irrelevant compared to changes to the code.
I did not complain about Ivan changing the spelling. I complained about Ivan reverting my commit without prior notice. If he had reverted just the files he maintains - fine. But he chose to revert the files I maintain as well. He did it on purpose. This is obviously a provocation.
hypocrite ...
WTF? Have we descended towards throwing around insults already?
didnt you say something about being old enough to not be provocated easily just a few lines above? Besides, hypocrite applies because you complain against iive while you really did nearly the same to him. And it was actually intended to be more funny than insulting but ohh well ... Iam just ommiting the smilies because the ambiguity is funny in itself
How come that you don't have an issue with such behavior?
Lets see. * I do not know at all if Xvid or XviD is more correct. I do know it was XviD once in the past so this one can not be completely wrong now. * You changed the spelling to Xvid in files maintained by you and ivve * iive changed the spelling back to XviD in files maintained by you and ivve * he did the same you did, you started * you broke the policy he reverted the commit which broke the policy No the whole was not ideal but nothing bad happened we are just back at the start and have another chance to find a solution. If the spelling bothers you. Just start a discussion on mplayer-dev about it, like it should IMHO have been in the first place already.
Are you seriously suggesting that we should waste time on dev-eng discussing which way to spell Xvid? When this was hashed out and committed to the rest of the documentation in 2006?
If not then why are you complaining about iive changing it? Either it does matter or it does not ...
Are you seriously suggesting that I broke the policy by changing the spelling and, assuming that I did, it is OK to remedy that by breaking the policy again, i.e. two wrongs make a right?
Are you seriously suggesting that we discuss about these 2 flies? [... biology discussion about flies ...] ;)
The problem I have with you here is that you are applying double standards.
On the one hand you insist on the strictest possible interpretation of the policy for issues that you care about like separation of whitespace changes from other types of changes and demand draconian punishments for offenders.
On the other hand you are very lax yourself about issues you consider less important like adding full license headers to files or updating the documentation to match your code changes. You have behaved this way long before this incident, don't tell me it is a result of it.
That you then go on to call me - the person that goes out of its way to split commits to your liking, writes the documentation for you, etc. - a hypocrite is galling and does add insult to previous injury.
Well you care about spelling, consistency, licenses, ... i care about clean commits, ... I do not care much about spelling, consistency, licenses, ... You do not care much about clean commits Now you complain about me applying double standards while you do the very same, just the other way around. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB While the State exists there can be no freedom; when there is freedom there will be no State. -- Vladimir Lenin
On Sat, May 31, 2008 at 08:51:17PM +0200, Michael Niedermayer wrote:
On Sat, May 31, 2008 at 05:23:32PM +0200, Diego Biurrun wrote:
On Sat, May 31, 2008 at 12:58:02AM +0200, Michael Niedermayer wrote:
On Fri, May 30, 2008 at 07:49:24PM +0200, Diego Biurrun wrote:
I know most of them personally, like them and the feeling is mutual. Nonetheless nowadays MPlayer is being developed by a new generation of people. That does not mean that the contributions of those people are insubstantial or that not appreciated.
Yes but it also does not mean that the experience the "old generation" has collected over the years should be ignored like it is. The people not being against uoti are new people who do not yet have the same experience reimar, roberto, iive, ... have in respect to maintaining a large project with many developers working, joining and leaving ...
Reimar never spoke in favor of removing Uoti.
Not litterally i think, but iam pretty sure he said something to the effect of him being in favor of uoti being removed if theres no other solution being found ...
.. i think .. pretty sure .. something to the effect of .. He did not say anything like that literally, nor implied. I was the one to talk to him personally, not you. Let Reimar speak for himself, do not make guesses or assumptions about his opinions.
Or the same about commiting with no warning to code actively maintained by others. Even if one ignores what the "old generation" says, just looking at the recent months shows how such commits get everyone near boiling. Even you go crazy if iive just changes xvids spelling.
I did not "go crazy". I'm old enough to be able not to freak out over such silly provocations.
You always freak out about any flies from ivans direction.
No, I think that nowadays I can remain pretty calm when he tries to provoke me. You do not have the dubious pleasure of sharing IRC channels with him and don't know half of what goes on between us. To say that Ivan and I do not get along well is an understatement. He has personally attacked and insulted me many times. I'm through with him. That said, I have to put up with him around here and try my best to ignore him.
Note that many many outsiders consider the environment around FFmpeg very hostile.
Note that many many pigs consider birds ugly. no i have no evidence but neither do you.
It seems that you move in FFmpeg-related circles only then. I have talked to people from many other multimedia projects and distributions. FFmpeg is very often viewed as a harsh and difficult environment with which communication is not easy and flames abound.
harsh/flames/... != hostile
That's a matter of perception. I do not see FFmpeg as hostile, but it surely can be intimidating for newcomers. And I have spoken to many people who do consider FFmpeg hostile.
So people are willing to put up with more hardship or simply are forced to work with FFmpeg one way or the other because they cannot switch to an alternative.
You should probably post a detailed list of what you think can be improved to ffmpeg-dev
I'm working on it all the time when I am in contact with other projects at LinuxTag, on IRC or wherever. You may have noticed the Debian patch I forwarded to ffmpeg-devel. I have been working with the new FFmpeg Debian maintainer these past few days reviewing their patchset. With my help he could determine that half of the patches are no longer necessary and delete them.
Speaking of that, i really would appreciate if all distros which package ffmpeg could send their patches to ffmpeg-dev. It would be of mutual benefit weeding out bad patches/bugs (which ruin ffmpegs good name as well as the distros) is mainly what iam thinkibng of ...
I 100% agree. At every opportunity I get I try to work with packagers of FFmpeg and MPlayer, try to make them send patches upstream and generally stay in contact when any issues appear.
id like to point out how you complained about iive changing the spelling of xvid. Which honestly is totally irrelevant compared to changes to the code.
I did not complain about Ivan changing the spelling. I complained about Ivan reverting my commit without prior notice. If he had reverted just the files he maintains - fine. But he chose to revert the files I maintain as well. He did it on purpose. This is obviously a provocation.
hypocrite ...
WTF? Have we descended towards throwing around insults already?
didnt you say something about being old enough to not be provocated easily just a few lines above?
No. I was talking about not being provoked by Ivan, at least not as easily as I used to. That does not mean that I do not find being called a hypocrite by you insulting. So for the record: I do not consider myself a hypocrite and find the allegation very insulting.
Besides, hypocrite applies because you complain against iive while you really did nearly the same to him.
No, I did not. I did very much *not* revert his commits without any discussion or expressing dissent.
And it was actually intended to be more funny than insulting but ohh well ... Iam just ommiting the smilies because the ambiguity is funny in itself
Well, if this discussion is not serious, then I suggest we close the issue and be done with it. You are the one here behaving as if his life depended on the issues we are discussing. How you can start being funny now and expect others to understand your hidden jokes is beyond me.
How come that you don't have an issue with such behavior?
Lets see. * I do not know at all if Xvid or XviD is more correct. I do know it was XviD once in the past so this one can not be completely wrong now. * You changed the spelling to Xvid in files maintained by you and ivve * iive changed the spelling back to XviD in files maintained by you and ivve * he did the same you did, you started * you broke the policy he reverted the commit which broke the policy No the whole was not ideal but nothing bad happened we are just back at the start and have another chance to find a solution. If the spelling bothers you. Just start a discussion on mplayer-dev about it, like it should IMHO have been in the first place already.
Are you seriously suggesting that we should waste time on dev-eng discussing which way to spell Xvid? When this was hashed out and committed to the rest of the documentation in 2006?
If not then why are you complaining about iive changing it? Either it does matter or it does not ...
I'll assume that you are neither playing one of your weird jokes again nor being deliberately dense and repeat my explanation: I'm not complaining about Ivan making the change. I'm not even complaining about Ivan reverting my changes to his files. However, when he reverts the changes I just did to files I maintain without prior notice or discussion and without even making me aware that he disagrees with my changes, then this is obviously and knowingly being done against my wishes and intentions and is bound to provoke and stir up controversy. I ask you again: Why is such behavior not objectionable to you? This is being done deliberately, Uoti did not act deliberately in this way. He did not expect any controversy. The same cannot be said about Ivan.
The problem I have with you here is that you are applying double standards.
On the one hand you insist on the strictest possible interpretation of the policy for issues that you care about like separation of whitespace changes from other types of changes and demand draconian punishments for offenders.
On the other hand you are very lax yourself about issues you consider less important like adding full license headers to files or updating the documentation to match your code changes. You have behaved this way long before this incident, don't tell me it is a result of it.
That you then go on to call me - the person that goes out of its way to split commits to your liking, writes the documentation for you, etc. - a hypocrite is galling and does add insult to previous injury.
Well you care about spelling, consistency, licenses, ... i care about clean commits, ...
I do not care much about spelling, consistency, licenses, ...
Correct.
You do not care much about clean commits
Nonsense.
Now you complain about me applying double standards while you do the very same, just the other way around.
No, I do not have double standards. I adapt to your wishes, as you very well know. I have always done everything exactly according to your wishes in FFmpeg and changed whatever you did not like. I commit nothing to MPlayer that you object to. I am willing to give everybody a bit of leeway and the benefit of the doubt. I even go the extra mile and do extra work *myself* to make everybody happy. You, on the other hand, want to see heads roll the second somebody does something you disagree with, even if it is totally minor, as in this case. At the same time, you violate the same set of rules that you insist on continuously. But only the rules that you do not care about of course. That others do care about them is irrelevant to you. This is the very same behavior that you accuse Uoti of. And that, Michael, is applying double standards. Diego
On Sat, May 31, 2008 at 10:08:29PM +0200, Diego Biurrun wrote:
On Sat, May 31, 2008 at 08:51:17PM +0200, Michael Niedermayer wrote:
On Sat, May 31, 2008 at 05:23:32PM +0200, Diego Biurrun wrote:
Reimar never spoke in favor of removing Uoti.
Not litterally i think, but iam pretty sure he said something to the effect of him being in favor of uoti being removed if theres no other solution being found ...
.. i think .. pretty sure .. something to the effect of ..
He did not say anything like that literally, nor implied. I was the one to talk to him personally, not you. Let Reimar speak for himself, do not make guesses or assumptions about his opinions.
Well, I guess about them myself. I did say and mean something to the effect that loosing one good developer might be worth it if it means and is the only way of getting peace and everyone else work more productive again - but unfortunately making that happen requires far more. Also note that I did say this a somewhat long time ago. Greetings, Reimar Döffinger
On 5/31/08, Reimar Döffinger <Reimar.Doeffinger@stud.uni-karlsruhe.de> wrote:
On Sat, May 31, 2008 at 10:08:29PM +0200, Diego Biurrun wrote:
On Sat, May 31, 2008 at 08:51:17PM +0200, Michael Niedermayer wrote:
On Sat, May 31, 2008 at 05:23:32PM +0200, Diego Biurrun wrote:
Reimar never spoke in favor of removing Uoti.
Not litterally i think, but iam pretty sure he said something to the effect of him being in favor of uoti being removed if theres no other solution being found ...
.. i think .. pretty sure .. something to the effect of ..
He did not say anything like that literally, nor implied. I was the one to talk to him personally, not you. Let Reimar speak for himself, do not make guesses or assumptions about his opinions.
Well, I guess about them myself. I did say and mean something to the effect that loosing one good developer might be worth it if it means and is the only way of getting peace and everyone else work more productive again - but unfortunately making that happen requires far more. Also note that I did say this a somewhat long time ago.
Well, make decision and give clear answer. Do you want Uoti to remain as developer or you want him to be removed. It is your call.
On Sat, May 31, 2008 at 11:47:13PM +0300, Ivan Kalvachev wrote:
On 5/31/08, Reimar Döffinger <Reimar.Doeffinger@stud.uni-karlsruhe.de> wrote:
On Sat, May 31, 2008 at 10:08:29PM +0200, Diego Biurrun wrote:
On Sat, May 31, 2008 at 08:51:17PM +0200, Michael Niedermayer wrote:
On Sat, May 31, 2008 at 05:23:32PM +0200, Diego Biurrun wrote:
Reimar never spoke in favor of removing Uoti.
Not litterally i think, but iam pretty sure he said something to the effect of him being in favor of uoti being removed if theres no other solution being found ...
.. i think .. pretty sure .. something to the effect of ..
He did not say anything like that literally, nor implied. I was the one to talk to him personally, not you. Let Reimar speak for himself, do not make guesses or assumptions about his opinions.
Well, I guess about them myself. I did say and mean something to the effect that loosing one good developer might be worth it if it means and is the only way of getting peace and everyone else work more productive again - but unfortunately making that happen requires far more. Also note that I did say this a somewhat long time ago.
Well, make decision and give clear answer.
Do you want Uoti to remain as developer or you want him to be removed. It is your call.
No, as I tried to say there is no point at all now, for all I can tell. And I object to the term "want". I considered it as a kind of quick-and-dirty solution, in addition at a point where I seriously considered if someone might be acting in genuine bad faith. Greetings, Reimar Döffinger
On Sat, May 31, 2008 at 10:40:23PM +0200, Reimar Döffinger wrote:
On Sat, May 31, 2008 at 10:08:29PM +0200, Diego Biurrun wrote:
On Sat, May 31, 2008 at 08:51:17PM +0200, Michael Niedermayer wrote:
On Sat, May 31, 2008 at 05:23:32PM +0200, Diego Biurrun wrote:
Reimar never spoke in favor of removing Uoti.
Not litterally i think, but iam pretty sure he said something to the effect of him being in favor of uoti being removed if theres no other solution being found ...
.. i think .. pretty sure .. something to the effect of ..
He did not say anything like that literally, nor implied. I was the one to talk to him personally, not you. Let Reimar speak for himself, do not make guesses or assumptions about his opinions.
Well, I guess about them myself. I did say and mean something to the effect that loosing one good developer might be worth it if it means and is the only way of getting peace and everyone else work more productive again - but unfortunately making that happen requires far more. Also note that I did say this a somewhat long time ago.
I can confirm that this was the statement i meant ... Thank you, i already wondered if my memory failed totally [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In a rich man's house there is no place to spit but his face. -- Diogenes of Sinope
On Sat, May 31, 2008 at 10:08:29PM +0200, Diego Biurrun wrote:
On Sat, May 31, 2008 at 08:51:17PM +0200, Michael Niedermayer wrote:
On Sat, May 31, 2008 at 05:23:32PM +0200, Diego Biurrun wrote:
On Sat, May 31, 2008 at 12:58:02AM +0200, Michael Niedermayer wrote:
On Fri, May 30, 2008 at 07:49:24PM +0200, Diego Biurrun wrote:
I know most of them personally, like them and the feeling is mutual. Nonetheless nowadays MPlayer is being developed by a new generation of people. That does not mean that the contributions of those people are insubstantial or that not appreciated.
Yes but it also does not mean that the experience the "old generation" has collected over the years should be ignored like it is. The people not being against uoti are new people who do not yet have the same experience reimar, roberto, iive, ... have in respect to maintaining a large project with many developers working, joining and leaving ...
Reimar never spoke in favor of removing Uoti.
Not litterally i think, but iam pretty sure he said something to the effect of him being in favor of uoti being removed if theres no other solution being found ...
.. i think .. pretty sure .. something to the effect of ..
He did not say anything like that literally, nor implied. I was the one to talk to him personally, not you. Let Reimar speak for himself, do not make guesses or assumptions about his opinions.
Yes please, reimar, maybe i remember wrong but my memory said you did in one of these past flames with uoti on a public mailinglist say something to the effect that it would be better under "some circumstances" to close his account. As said i do not remember the exact wording ... If you (reimar) dont remember it ill of course retract my statement. [...]
Besides, hypocrite applies because you complain against iive while you really did nearly the same to him.
No, I did not. I did very much *not* revert his commits without any discussion or expressing dissent.
You commited to code maintained by him, he commited to code maintained by you That part is the same ... [...]
How come that you don't have an issue with such behavior?
Lets see. * I do not know at all if Xvid or XviD is more correct. I do know it was XviD once in the past so this one can not be completely wrong now. * You changed the spelling to Xvid in files maintained by you and ivve * iive changed the spelling back to XviD in files maintained by you and ivve * he did the same you did, you started * you broke the policy he reverted the commit which broke the policy No the whole was not ideal but nothing bad happened we are just back at the start and have another chance to find a solution. If the spelling bothers you. Just start a discussion on mplayer-dev about it, like it should IMHO have been in the first place already.
Are you seriously suggesting that we should waste time on dev-eng discussing which way to spell Xvid? When this was hashed out and committed to the rest of the documentation in 2006?
If not then why are you complaining about iive changing it? Either it does matter or it does not ...
I'll assume that you are neither playing one of your weird jokes again nor being deliberately dense and repeat my explanation:
I'm not complaining about Ivan making the change. I'm not even complaining about Ivan reverting my changes to his files. However, when he reverts the changes I just did to files I maintain without prior notice or discussion and without even making me aware that he disagrees with my changes, then this is obviously and knowingly being done against my wishes and intentions and is bound to provoke and stir up controversy.
I ask you again: Why is such behavior not objectionable to you?
Ivans behavior is objectionable to me but so was your original commit. Why cant you and ivan not just accept that you both made a mistake by taking an action that provocated the other, deliberate or not?
This is being done deliberately,
I belive ivan thinks that of your commit as well. Also if someone bumps into you and you spill your coffee all over your clothes and you think that he did it deliberately and as a result you take the little bit left in the cup and spill it over his head. Who is the evil one? The guy who did walk with his eyes on the secretary to his right who unintentionally bumped into you or You who now deliberately dumped the remaining brown liquid over his head?
Uoti did not act deliberately in this way. He did not expect any controversy. The same cannot be said about Ivan.
I belive that ivan belives that you did it intentionally. Besides you, ivan and uoti are all totally incapable of resolving the controversy they caused non deliberately. Neither of you is capable to just say "sorry, i thought that wouldnt be controversal, ill revert and we can discuss what course of action that would satisfy everyone involved" Its because you all are a bunch of <censored> who all know they are always correct and who dont yield 1 hairbreadth.
The problem I have with you here is that you are applying double standards.
On the one hand you insist on the strictest possible interpretation of the policy for issues that you care about like separation of whitespace changes from other types of changes and demand draconian punishments for offenders.
On the other hand you are very lax yourself about issues you consider less important like adding full license headers to files or updating the documentation to match your code changes. You have behaved this way long before this incident, don't tell me it is a result of it.
That you then go on to call me - the person that goes out of its way to split commits to your liking, writes the documentation for you, etc. - a hypocrite is galling and does add insult to previous injury.
Well you care about spelling, consistency, licenses, ... i care about clean commits, ...
I do not care much about spelling, consistency, licenses, ...
Correct.
You do not care much about clean commits
Nonsense.
Now you complain about me applying double standards while you do the very same, just the other way around.
No, I do not have double standards. I adapt to your wishes, as you very well know. I have always done everything exactly according to your wishes in FFmpeg and changed whatever you did not like. I commit nothing to MPlayer that you object to.
I am willing to give everybody a bit of leeway and the benefit of the doubt. I even go the extra mile and do extra work *myself* to make everybody happy.
You, on the other hand, want to see heads roll the second somebody does something you disagree with, even if it is totally minor, as in this case.
you are confused, a single polite reply from uoti would have made a huge difference to me. But the only thing he tells us is that he is correct that the policy is irrelevant and that he will act by only his common sense. And that he of course never made any mistake and will never correct any commit others complain about ... (of course except the commit message noone complained about except himself) [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is not what we do, but why we do it that matters.
On Sat, May 31, 2008 at 11:03:14PM +0200, Michael Niedermayer wrote:
Its because you all are a bunch of <censored> who all know they are always correct and who dont yield 1 hairbreadth.
While not literally, I agree at least with the sentiment here... Though at least between Ivan and Diego I think that is an acquired trait. Greetings, Reimar Döffinger
On Sat, May 31, 2008 at 11:03:14PM +0200, Michael Niedermayer wrote:
On Sat, May 31, 2008 at 10:08:29PM +0200, Diego Biurrun wrote:
On Sat, May 31, 2008 at 08:51:17PM +0200, Michael Niedermayer wrote:
On Sat, May 31, 2008 at 05:23:32PM +0200, Diego Biurrun wrote:
On Sat, May 31, 2008 at 12:58:02AM +0200, Michael Niedermayer wrote: Besides, hypocrite applies because you complain against iive while you really did nearly the same to him.
No, I did not. I did very much *not* revert his commits without any discussion or expressing dissent.
You commited to code maintained by him, he commited to code maintained by you That part is the same ...
"That part", yes, but there is a difference between committing and reverting, as you very well know.
I ask you again: Why is such behavior not objectionable to you?
Ivans behavior is objectionable to me but so was your original commit. Why cant you and ivan not just accept that you both made a mistake by taking an action that provocated the other, deliberate or not?
There is a difference between deliberate provocation and accidental provocation.
This is being done deliberately,
I belive ivan thinks that of your commit as well.
Also if someone bumps into you and you spill your coffee all over your clothes and you think that he did it deliberately and as a result you take the little bit left in the cup and spill it over his head.
Who is the evil one?
The one who takes revenge of course since two wrongs don't make a right. The one who bumps into the other is not evil because his spilling was an accident.
Uoti did not act deliberately in this way. He did not expect any controversy. The same cannot be said about Ivan.
I belive that ivan belives that you did it intentionally. Besides you, ivan and uoti are all totally incapable of resolving the controversy they caused non deliberately.
Neither of you is capable to just say "sorry, i thought that wouldnt be controversal, ill revert and we can discuss what course of action that would satisfy everyone involved"
I already said that I did not expect this to be controversial. I can of course restate that if it makes you happy. I merely noticed that some renaming work done by Guillaume on the documentation in 2006 was incomplete and filled in the remaining bits. I routinely do similar changes to MPlayer without causing any sort of controversy, I did not expect this to be different. Also note that Guillaume is the Xvid documentation maintainer and he also knows his way around Xvid. The xvid.org homepage and other sources on the net have been using this name for a long time.
Its because you all are a bunch of <censored> who all know they are always correct and who dont yield 1 hairbreadth.
That's precisely the feeling I have been having since the beginning of this silly conflict. I'm glad you know how I have felt. In between I was very tempted to speak my mind and fill that <censored> block with a page full of expletives.
You, on the other hand, want to see heads roll the second somebody does something you disagree with, even if it is totally minor, as in this case.
you are confused, a single polite reply from uoti would have made a huge difference to me.
Without a doubt Uoti's behavior is not conducive to amicably resolving conflicts and I would love if he was not so difficult to work with at times. Unfortunately this is a character trait shared by far too many MPlayer developers. Uoti did, however, write the following: Date: Fri, 09 May 2008 16:57:46 +0300 I did not expect these commits to cause such controversy. I think it should be obvious enough why I don't want to send a patch first for every change (it usually causes more overhead than the work needed for the actual change). And controversial or not I don't make commits for trolling purposes.
(of course except the commit message noone complained about except himself)
I complained about the commit message, as did Reimar. Diego
On 6/1/08, Diego Biurrun <diego@biurrun.de> wrote:
There is a difference between deliberate provocation and accidental provocation.
"Accidental provocation" This is work of genius! The more you go beyond ridiculous the funnier it gets.
Ivan Kalvachev wrote:
On 6/1/08, Diego Biurrun <diego@biurrun.de> wrote:
There is a difference between deliberate provocation and accidental provocation.
"Accidental provocation"
This is work of genius!
The more you go beyond ridiculous the funnier it gets.
Simply put: "Shut up YOU troll". lu - iterate over every people writing is this thread, me included. -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero
Seperate reply as it doesnt fit in the "serious" flame On Fri, May 30, 2008 at 07:49:24PM +0200, Diego Biurrun wrote: [...]
We are not Linux kernel and we are not a wealthy company. We have very limited manpower and we cannot just go out and hire the people we want and need. We have to be content with whomever we've got aboard and with whatever skills and personality they have got.
Let's face it: competent developers do not joing MPlayer every month. On the contrary, they are few and far between; a resource not to be squandered. If they happen to be difficult to work with (and we have many of those aboard), we have to find ways to make ends meet.
The problem is that you did not yet find a way to make ends meet. Convincing me or reimar on the phone does not solve the problem. Make uoti less arrogant and egoistic and we would be a long way toward a solution. But people are what they are, noone can change them ...
I found a way to make Reimar and Uoti resolve their differences.
You found a way to silence them
I found a way to avoid a return parentheses issues in the future. I have split the offending commits.
This is much more than nothing. I have tried my best (however little that may be) to be _constructive_ and not destructive. Who else can claim that?
Maria Theresa
In the medium term I think we will have to look at distributed revision control.
What will svn think of you for betraying her like that ... [...]
In the future, a way to avoid fights over reindent commits would be reindenting all of MPlayer. Problem solved once and for all.
You have my support for that big reindent but i fear others will run amok on the mere suggestion. Though you and uoti might be able to do it anyway Sauron and his child wielding the one root ehh i mean ring. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No human being will ever know the Truth, for even if they happen to say it by chance, they would not even known they had done so. -- Xenophanes
On Sat, May 31, 2008 at 01:03:32AM +0200, Michael Niedermayer wrote:
Seperate reply as it doesnt fit in the "serious" flame
Why you start making jokes now is beyond me...
On Fri, May 30, 2008 at 07:49:24PM +0200, Diego Biurrun wrote: [...]
We are not Linux kernel and we are not a wealthy company. We have very limited manpower and we cannot just go out and hire the people we want and need. We have to be content with whomever we've got aboard and with whatever skills and personality they have got.
Let's face it: competent developers do not joing MPlayer every month. On the contrary, they are few and far between; a resource not to be squandered. If they happen to be difficult to work with (and we have many of those aboard), we have to find ways to make ends meet.
The problem is that you did not yet find a way to make ends meet. Convincing me or reimar on the phone does not solve the problem. Make uoti less arrogant and egoistic and we would be a long way toward a solution. But people are what they are, noone can change them ...
I found a way to make Reimar and Uoti resolve their differences.
You found a way to silence them
Bullshit. Are you calling me a liar? Who talked to those two? You surely did not. Why don't you ask them yourself if you don't believe me?
[flaming]
In the future, a way to avoid fights over reindent commits would be reindenting all of MPlayer. Problem solved once and for all.
You have my support for that big reindent but i fear others will run amok on the mere suggestion.
Noted. Diego
Il Saturday 31 May 2008 06:04:55 Diego Biurrun ha scritto:
[flaming]
In the future, a way to avoid fights over reindent commits would be reindenting all of MPlayer. Problem solved once and for all.
You have my support for that big reindent but i fear others will run amok on the mere suggestion.
Noted.
Diego
I can swear on my wallet that the reformatting won't solve anything, but if it will make Uoti cooperate with the others you can reformat my files, too, although I always opposed this make-up in the past
On 5/30/08, Diego Biurrun <diego@biurrun.de> wrote:
On Fri, May 30, 2008 at 04:58:34AM +0200, Michael Niedermayer wrote:
On Fri, May 30, 2008 at 03:04:14AM +0200, Diego Biurrun wrote:
On Sat, May 10, 2008 at 05:51:58PM +0200, Diego Biurrun wrote:
On Sat, May 10, 2008 at 05:21:59PM +0200, Michael Niedermayer wrote:
On Sat, May 10, 2008 at 04:27:50PM +0300, Ivan Kalvachev wrote:
On Sat, May 10, 2008 at 3:20 PM, Reimar Döffinger <Reimar.Doeffinger@stud.uni-karlsruhe.de> wrote: > On Sat, May 10, 2008 at 01:38:06PM +0200, Diego Biurrun wrote: >> diego 1038 504 1542 >> reimar 690 246 936 >> voroshil 312 8 320 >> nico 212 43 255 >> benjamin 144 32 176 >> ulion 153 13 166 >> eugeni 106 56 162 >> uoti 99 20 119
Reimar, looking at these numbers, I'd say that you are de-facto project leader. Diego is not coder and none of his commits changes the way MPlayer works. He is doing a lot of refactoring and cosmetics.
Reimar, please take the Project Leader role and resolve the situation in the way you like it.
yes, seconded, and my emphasis is on _resolve_. Not the "playing deaf" diego
I will write up a statement/explanation before the weekend draws to a close. I have no time right now because I am meeting friends in a few minutes.
Sorry, this took much longer than promised. I was very busy these past weeks and days and was away for a week without internet in between. Admittedly, I also always get carried away by maintenance duties and random issues. Probably also due to the fact that my motivation to flame is at an all-time low. Coding feels so much more fulfilling...
I'm also very much torn between the desire to write this statement as promised and the fear (or rather certainty) that this will stir up flaming again and cause grief and time loss.
It seems you view any form of disscussion or critique as flame and bad.
Wrong. I don't know where you get that idea, you have seen me discuss many many times (constructively) over the years. But discussions should be done with a clear head.
I think this is the wrong way to attack things. Critique means that there is a disagreement and these should be discussed and resolved, staying silent (or asking others to stay silent) does IMO achive the opposite. That is it angers everyone and does not resolve anything.
The emphasis needs to be put on the word *resolve*, yes. I'm not asking anybody to stay silent. I'm asking for people to step back and look at the issues without their emotions clouding their judgement. I believe that the flaming is blowing things out of proportion and everybody is getting worked up over pretty much nothing.
Anyway, here comes my position statement:
Everybody should step back for a minute, calm down, and think about what it really is that we were debating:
We are discussing a solution to the problem that a large number of the developers are quite incompatible with uotis provocative, arogant and egoistic way. The solution you as admin choose is to step back and let people kill each other. While complaining about the amount of flaming. Its quite ironic
Wrong. I have worked to *resolve* the problem, not fight it out, by talking to the parties where the conflict originated, namely Reimar and Uoti.
I'm not particularly happy about how things played out in the end, nor would I claim not to have made mistakes. However, I was terminally frustrated and had basically decided to pack it all in. Had I decided to join the discussion, I would have kicked and screamed like everybody else when a clear head was needed. So I decided to work on the original causes of the problem.
Has it occurred to you that you might be overreacting in this case?
Uoti committed a bunch of cosmetic cleanups of different types together and labeled his commit as "indent". That was not good and I dislike bad commit messages more than the next guy, but it was not catastrophic. Plus, it was neither malicious, nor intentional. Uoti honestly did not expect this to be controversial.
Then Reimar gets upset and heavy flaming, heavy even measured by MPlayer standards, erupts. I speak with Reimar, I speak with Uoti, Reimar eventually calms down again. As suggested by me, Uoti speaks with Reimar, they decide to find a way to work better together with less friction.
Everything should be fine and dandy again, should it not? No, wait, of course flaming has not subsided, but reached epic proportions instead. The tides of the discussion go ever higher and none of the participants is helping it in any way. On the contrary, all sides are stubborn or prone to flames or both and generally have a number of character traits not conducive to resolving conflicts.
But what has really happened? Whatever you may think of the policy, it does not contain a paragraph that forbids committing different types of cosmetic changes together.
It contains parts about not mixing cosmetics and functional changes it also contains parts about not commiting to code maintained by others and something about sending patches.
None of this applies in this particular case.
I am not trying to lament here, just stating facts. Leadership requires standing up and not following loud voices in the direction of least resistance. This is such a situation.
Leadership requires to solve problems and prevent the project from breaking apart. It also requires to create an environment in which developers feel comfortable to work in.
Precisely. The developers are the people doing the actual work on the project. They need to feel comfortable.
We have 5 people (Michael, Ivan, Alban, Aurelien, Roberto) voting for Uoti's removal and 4 people speaking up against (Uoti, Eugeni, Benjamin, Diego). This is a far cry from a clear situation, especially given that each of the latter 4 is more active than all of the 5 combined.
Its true for the current activity but if i look at all commits of all times i much rather loose all of the later 4 than a single one of the first 5.
I think your anger is clouding your judgement. You should try to reevaluate the contributions of all nine people mentioned above.
I very much respect all the developers listed above, I know most of them personally, like them and the feeling is mutual. Nonetheless nowadays MPlayer is being developed by a new generation of people. That does not mean that the contributions of those people are insubstantial or that not appreciated. But you could go further back in history and find people that have done even more, like Nick and Arpi, yet are not steering this project any longer.
Also you speak about this as a throw him out vs. keep him in the project. If one looks at it like that it surely is better to keep him, but its not so simple. its that >50% of the people do not get along with him and loosing 1 vs. loosing 50% of the developers is something quite different
You assume that the majority (whatever that may be) shares your opinion. The majority is silent. The longer I look at the situation, the less I feel confident to predict what these other people think.
It's also not as simple as you think. I surely do not want to work on a project where valuable contributors get thrown out like this. Of course, you have made it pretty clear above that you do not value my contributions. If everybody else agrees with this then I do indeed not see much point in continuing to waste my time here.
This projects has many problems, but renegade commits are not one of them. Lack of manpower is much more serious
Well frankly the lack of manpower is caused by the hostile environment IMHO
I am not denying this, but the question is what constitutes a hostile environment. I'll quote Denes Balatoni, one of the innocent bystanders on the fringe of this project:
I have not partcipated in the discussion before, but now that you ask, I will say that IMO it is not wise to complain about some ancient and not neccesserily consensual "cvs rules" by older inactive MPlayer developers, just to get rid of a newer - but one of the last active - MPlayer developer. I think a more forgiving and constructive environment would better serve the interests of the project.
Note that many many outsiders consider the environment around FFmpeg very hostile. Of course, FFmpeg can get away with it, because there is no alternative to it and it holds a monopoly on its "market". So people are willing to put up with more hardship or simply are forced to work with FFmpeg one way or the other because they cannot switch to an alternative.
MPlayer cannot afford that luxury. I want the constant flaming to stop. People should concentrate on coding and reviewing instead of shouting at each other.
id like to point out how you complained about iive changing the spelling of xvid. Which honestly is totally irrelevant compared to changes to the code.
I did not complain about Ivan changing the spelling. I complained about Ivan reverting my commit without prior notice. If he had reverted just the files he maintains - fine. But he chose to revert the files I maintain as well. He did it on purpose. This is obviously a provocation.
How come that you don't have an issue with such behavior?
I find it very irritating that Ivan can get away with anything without attracting your wrath while others get attacked over much less. This behavior is incongruent, especially in light of the actual contributions that Ivan and other people do.
We are not Linux kernel and we are not a wealthy company. We have very limited manpower and we cannot just go out and hire the people we want and need. We have to be content with whomever we've got aboard and with whatever skills and personality they have got.
Let's face it: competent developers do not joing MPlayer every month. On the contrary, they are few and far between; a resource not to be squandered. If they happen to be difficult to work with (and we have many of those aboard), we have to find ways to make ends meet.
The problem is that you did not yet find a way to make ends meet. Convincing me or reimar on the phone does not solve the problem. Make uoti less arrogant and egoistic and we would be a long way toward a solution. But people are what they are, noone can change them ...
I found a way to make Reimar and Uoti resolve their differences. I found a way to avoid a return parentheses issues in the future. I have split the offending commits.
This is much more than nothing. I have tried my best (however little that may be) to be _constructive_ and not destructive. Who else can claim that?
In the medium term I think we will have to look at distributed revision control. This way, people will not have as many possibilities to step on each other's toes. I'm starting to familiarize myself with Mercurial and git. Unfortunately I do not have much time for this ATM.
In the future, a way to avoid fights over reindent commits would be reindenting all of MPlayer. Problem solved once and for all.
I was really hoping that Michael wise words could reach you. Unfortunately his words went into deaf ears. I'll try another approach. It have worked in ancient times maybe it could work today. I'll tell you a parable. (btw the plural of sheep is sheep, not-sheeps) --- Once upon a time some man got a flock and became shepherd. But a wolf in sheep's clothing got into the shepherds flock. Most of the sheep started complaining from the wolf, but the shepherd didn't listen. He calmed them down and did what he can to make them comfortable. But the wolf been a wolf, started eating one sheep every week and the flock started getting smaller. Some of the sheep that didn't got eaten started running away. Some of the remaining sheep complained again to the shepherd, but he told them "I can not get rid of that sheep, it is healthy and big, it eats a lot, it is one of my best in the flock. My flock is small and I need every sheep." When one day neighborhood shepherd who had big and healthy flock, come to the first one and told him "I know your sheep, some of them have been in my flock too. Listen to them. Remove that sheep because it is wolf in disguise and wastes your flock". The first shepherd replied "You are wrong. Your flock is healthy and big, but mine is small and sheep are skinny. That sheep is from my flock and it is big and healthy. I don't see why I should get rid of it. It may be wolf, but I think the others just misunderstand it. I'll talk to them and I will comfort them and everything will be fine." "If I had to get rid of some sheep, it would be that old skinny one that is always stalking me and bleating at me and eating my robe. It makes other sheep unrest and causes me a lot of worries. I won't be surprised if it is the wolf." Time passed until nothing was left from the flock, even the wolf went somewhere. Then the shepherd said "I did nothing wrong. I always did the best for my flock. I cleaned every sheep every day. But the grass wasn't green enough, most of the sheep were skinny and lazy and were bleating instead of eating. And it was so hard to get new sheep in my flock. It wasn't my fault.". Then the man went to other shepherds to help them with their flocks. --- These who have ears will hear. These who have eyes will see. These who have mind will understand. Pity on these who don't have anything.
On Fri, 30 May 2008 03:04:14 +0200, Diego Biurrun <diego@biurrun.de> wrote:
On Sat, May 10, 2008 at 05:51:58PM +0200, Diego Biurrun wrote:
On Sat, May 10, 2008 at 05:21:59PM +0200, Michael Niedermayer wrote:
On Sat, May 10, 2008 at 04:27:50PM +0300, Ivan Kalvachev wrote:
On Sat, May 10, 2008 at 3:20 PM, Reimar Döffinger <Reimar.Doeffinger@stud.uni-karlsruhe.de> wrote:
On Sat, May 10, 2008 at 01:38:06PM +0200, Diego Biurrun wrote:
diego 1038 504 1542 reimar 690 246 936 voroshil 312 8 320 nico 212 43 255 benjamin 144 32 176 ulion 153 13 166 eugeni 106 56 162 uoti 99 20 119
Reimar, looking at these numbers, I'd say that you are de-facto project leader. Diego is not coder and none of his commits changes the way MPlayer works. He is doing a lot of refactoring and cosmetics.
Reimar, please take the Project Leader role and resolve the situation in the way you like it.
yes, seconded, and my emphasis is on _resolve_. Not the "playing deaf" diego
I will write up a statement/explanation before the weekend draws to a close. I have no time right now because I am meeting friends in a few minutes.
Sorry, this took much longer than promised. I was very busy these past weeks and days and was away for a week without internet in between. Admittedly, I also always get carried away by maintenance duties and random issues. Probably also due to the fact that my motivation to flame is at an all-time low. Coding feels so much more fulfilling...
I'm also very much torn between the desire to write this statement as promised and the fear (or rather certainty) that this will stir up flaming again and cause grief and time loss.
Since I very much feel that everybody should try to look at the situation again with a cool head and not let emotions cloud their judgement, this long period of calm might not be such a bad thing in the end. We shall see.
Anyway, here comes my position statement:
Everybody should step back for a minute, calm down, and think about what it really is that we were debating:
Uoti committed a bunch of cosmetic cleanups of different types together and labeled his commit as "indent". That was not good and I dislike bad commit messages more than the next guy, but it was not catastrophic. Plus, it was neither malicious, nor intentional. Uoti honestly did not expect this to be controversial.
Then Reimar gets upset and heavy flaming, heavy even measured by MPlayer standards, erupts. I speak with Reimar, I speak with Uoti, Reimar eventually calms down again. As suggested by me, Uoti speaks with Reimar, they decide to find a way to work better together with less friction.
Everything should be fine and dandy again, should it not? No, wait, of course flaming has not subsided, but reached epic proportions instead. The tides of the discussion go ever higher and none of the participants is helping it in any way. On the contrary, all sides are stubborn or prone to flames or both and generally have a number of character traits not conducive to resolving conflicts.
But what has really happened? Whatever you may think of the policy, it does not contain a paragraph that forbids committing different types of cosmetic changes together.
In fact, we had a precedent for a similar commit about half a year ago:
------------------------------------------------------------------------ r24911 | uau | 2007-11-01 07:51:38 +0100 (Thu, 01 Nov 2007) | 4 lines Changed paths: M /trunk/libmpcodecs/dec_audio.c
Reindent dec_audio.c Also remove some commented out code ------------------------------------------------------------------------
No big controversy arose out of that one, nor was there reason to.
There should be no reason now. The commit message has been fixed. Uoti had no malicious or trollish intent and has promised to mention such things in commit messages in the future. That said, he really is the last person that can be accused of writing bad commit message in general.
If somebody wants to insist on separating cosmetic commits piece by piece, be my guest to do it yourself. I single-handedly reindented and prettyprinted all of FFmpeg to make it conform to the coding style. I know very well how much work and how little fun this is. I diligently split stuff myself, but I do not require the same level of pedantic attention to detail from others.
I have been accused of abusing my powers. Let's face it, I am regarded as the de-facto project leader, I have heard it many times in private. Plus, in situations like these, I get treated as bearing all the responsibilities of a project leader - with no privileges.
I am not trying to lament here, just stating facts. Leadership requires standing up and not following loud voices in the direction of least resistance. This is such a situation.
We have 5 people (Michael, Ivan, Alban, Aurelien, Roberto) voting for Uoti's removal and 4 people speaking up against (Uoti, Eugeni, Benjamin, Diego). This is a far cry from a clear situation, especially given that each of the latter 4 is more active than all of the 5 combined.
Notwithstanding the fact that I am not a fan of voting procedures to resolve conflicts in projects like this one, democratic voting procedures need to be fixed before the actual voting takes place. We would have to know who is eligible to vote (why should Uoti not be eligible?), what the required majorities are and what number of votes constitutes a quorum.
As Michael said, I prefer to work in projects where the developers get to steer the direction of the project. But, let's face it, developers are not all equal, some are more active and/or more experienced and/or more merited than others.
I applaud Benjamin's humility when he says that he does not consider himself in a position to vote here because he has not been active enough as of late. I wish more people were so humble, so hard-working and so averse to flaming.
Nonetheless we have maneuvered us into a Mexican standoff. There is no way to satisfy everybody in this lose-lose situation and especially I can only choose between damaging my reputation in different ways.
I cannot give in to the wishes of a vocal group of merited, but inactive developers. Nowadays other people do the heavy lifting on MPlayer. They should get to decide how the project works in exchange. Reimar has not voted in favor of removing Uoti's account; the voices of many active developers have remained mute.
I do not wish to alienate anybody, but I have to think about the long-term well-being of the project.
This projects has many problems, but renegade commits are not one of them. Lack of manpower is much more serious as is the constant flaming, intransigent insistence on minority standpoints and architectural issues in the codebase. Flaming a developer that works on architectural issues out of the project is not the way forward.
We are not Linux kernel and we are not a wealthy company. We have very limited manpower and we cannot just go out and hire the people we want and need. We have to be content with whomever we've got aboard and with whatever skills and personality they have got.
Let's face it: competent developers do not joing MPlayer every month. On the contrary, they are few and far between; a resource not to be squandered. If they happen to be difficult to work with (and we have many of those aboard), we have to find ways to make ends meet.
Conflicts need to be mitigated and resolved, not fought out. The imperative should be to work constructively together and give each other a bit of leeway and the benefit of the doubt.
This is what I attempted to do in this situation. I successfully mediated between Reimar and Uoti, which is where the problems originated.
Extra parentheses in return statements will not be a source of problems again in the future, because I removed all of them. The same could be achieved with regard to indentation, it would just require some willingness to compromise from all sides. From then on, nobody would be able to step on any toes with cosmetic commits.
Uoti's commits were reverted, but nobody bothered to recommit them. This way, everybody loses. I split the commits to make everybody happy and to improve the code, because this is what we should really strive for.
I don't mind splitting a commit or two in the future, just as I - just to give an example - never minded writing documentation when Michael skipped that in his commits. Then just as now, shouting "policy violation", reverting commits and leaving things at that only makes things worse.
MPlayer is not developed in a mail or IRC client, it is developed in a text editor. Flaming does not improve MPlayer as a project or as a codebase, on the contrary. It wastes precious time, makes everybody unhappy and people go find a different project to spend their time on.
The constant flaming *must* end. I was very close to burnout during this conflict and had very much decided to pack it all in for good. Trying to work on MPlayer surrounded by people who appear to enjoy flaming more than coding and are stubborn and intransigent stops being fun at some point. Everybody (and i mean everybody) seemed to have gone mad.
Sleeping things over and concentrating on coding instead of flaming does help, however. As I said earlier, please look at the issues again with a cool head and do not let emotions cloud your judgement.
Diego
basically, mplayer needs a project leader to solve this issue quickly. also to kill off some of the flames and trouble that the project has suffered :) is anyone opposed to reimar as project leader? -compn
On Sat, May 10, 2008 at 05:21:59PM +0200, Michael Niedermayer wrote:
On Sat, May 10, 2008 at 04:27:50PM +0300, Ivan Kalvachev wrote:
Reimar, please take the Project Leader role and resolve the situation in the way you like it.
yes, seconded, and my emphasis is on _resolve_. Not the "playing deaf" diego does, the leader should make clear statements, not selective silence.
I am not a fan of clear statements since my opinions are not clear. But if that is what most desire I will try my best. And since my opinion and clear statements are asked for:
democracy yes or no democracy?
No democracy. Consensus must be the goal, if that is unreachable voting will not fix anything, in particular not if the voting procedure - whichever is chosen - can be disputed with good reasons.
uoti keeps his account no matter what he does or not?
Certainly not.
and where is the line, how far can a developer go beforfe loosing his account?
That is the big problem. The honest but useless answer is "unless the right people agree a developer costs more than his work is worth". I seriously doubt it is possible to give clear rule that is worth anything. I think something in the direction of non-trivial (> 20 lines) change to something well-maintained (maintainer usually responds within 3 days, maintainer is listed in MAINTAINERS) without sending a patch first and breaking a feature without discussing it on the list first and refusing to fix (by reverting or otherwise) within a reasonable time (usually 7 days) is a good approximation though. This still has obvious issues, like what counts as feature, what counts as discussion, and how relevant is the result of the discussion. Hm, that reminds me, does svn-howto state that libswscale belongs to FFmpeg? This will need to be made clear if MPlayer adapts a different commit policy.
or is the line based on diegos personal feeling? He once wanted to close ivans ffmpegs svn account (that was around the time when he also wanted to close all doc maintainers access to ffmpeg svn), its in strong contrast to how uoti is treated.
I think that was just an attempt to separate FFmpeg and MPlayer commit rights. Nevertheless I would appreciate if Diego and Ivan could find an agreement that goes beyond Ivan criticizing at length everything Diego does suboptimally and Diego ignoring Ivan's (except for the insistence) largely correct criticism, one behaviour amplifying the other... Greetings, Reimar Döffinger
On Sat, May 10, 2008 at 06:25:35PM +0200, Reimar Döffinger wrote:
On Sat, May 10, 2008 at 05:21:59PM +0200, Michael Niedermayer wrote:
On Sat, May 10, 2008 at 04:27:50PM +0300, Ivan Kalvachev wrote:
Reimar, please take the Project Leader role and resolve the situation in the way you like it.
yes, seconded, and my emphasis is on _resolve_. Not the "playing deaf" diego does, the leader should make clear statements, not selective silence.
I am not a fan of clear statements since my opinions are not clear. But if that is what most desire I will try my best. And since my opinion and clear statements are asked for:
democracy yes or no democracy?
No democracy. Consensus must be the goal, if that is unreachable voting will not fix anything, in particular not if the voting procedure - whichever is chosen - can be disputed with good reasons.
What is consensus? Does a 70% majority imply consensus? a 90% majority? can a single developer veto a consensus? can 2? How do we determine that a consensus has been reached? Is diego to be the one to determine it based on his personal oppinion? Democracy means "rule by the people", no democracy means the opposite, that is that someone or something else than the people rules. You say "no democracy" but at the same time you speak of a vague alternative as if it was exactly democracy. democracy does not implicate voting. Just that the final decission is made by the people. I will reformulate my question, do you want mplayer to be ruled by all the mplayer developers? [...]
or is the line based on diegos personal feeling? He once wanted to close ivans ffmpegs svn account (that was around the time when he also wanted to close all doc maintainers access to ffmpeg svn), its in strong contrast to how uoti is treated.
I think that was just an attempt to separate FFmpeg and MPlayer commit rights. Nevertheless I would appreciate if Diego and Ivan could find an agreement that goes beyond Ivan criticizing at length everything Diego does suboptimally and Diego ignoring Ivan's (except for the insistence) largely correct criticism, one behaviour amplifying the other...
ivan and diego should meet each other in person, i belive that would help resolve their disagreements. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have never wished to cater to the crowd; for what I know they do not approve, and what they approve I do not know. -- Epicurus
On Sat, May 10, 2008 at 7:54 PM, Michael Niedermayer <michaelni@gmx.at> wrote:
On Sat, May 10, 2008 at 06:25:35PM +0200, Reimar Döffinger wrote:
On Sat, May 10, 2008 at 05:21:59PM +0200, Michael Niedermayer wrote:
On Sat, May 10, 2008 at 04:27:50PM +0300, Ivan Kalvachev wrote:
Reimar, please take the Project Leader role and resolve the situation in the way you like it.
yes, seconded, and my emphasis is on _resolve_. Not the "playing deaf" diego does, the leader should make clear statements, not selective silence.
I am not a fan of clear statements since my opinions are not clear. But if that is what most desire I will try my best. And since my opinion and clear statements are asked for:
democracy yes or no democracy?
No democracy. Consensus must be the goal, if that is unreachable voting will not fix anything, in particular not if the voting procedure - whichever is chosen - can be disputed with good reasons.
What is consensus?
Does a 70% majority imply consensus? a 90% majority? can a single developer veto a consensus? can 2?
How do we determine that a consensus has been reached? Is diego to be the one to determine it based on his personal oppinion?
Democracy means "rule by the people", no democracy means the opposite, that is that someone or something else than the people rules.
You say "no democracy" but at the same time you speak of a vague alternative as if it was exactly democracy.
democracy does not implicate voting. Just that the final decission is made by the people.
I will reformulate my question, do you want mplayer to be ruled by all the mplayer developers?
I think that the definition of consensus is even more strict than of majority vote. Consensus requires 100% agreement among all participants. We do need some form of fairness. Authoritarian rule "could" be the most effective form on government. However it is also most vulnerable to abuse of power, that promotes conflicts and quick decline (turns into dictatorship). The democracy is a feedback method that ensures that the power won't be abused. (This is why democracies are more stable, but are still vulnerable to slow degradation). If the project leader doesn't ignore developers opinion based on some frivolous criteria and if there is no abuse of power, we may never need to vote. But we still need some way to control and prevent abuse. [...]
or is the line based on diegos personal feeling? He once wanted to close ivans ffmpegs svn account (that was around the time when he also wanted to close all doc maintainers access to ffmpeg svn), its in strong contrast to how uoti is treated.
I think that was just an attempt to separate FFmpeg and MPlayer commit rights. Nevertheless I would appreciate if Diego and Ivan could find an agreement that goes beyond Ivan criticizing at length everything Diego does suboptimally and Diego ignoring Ivan's (except for the insistence) largely correct criticism, one behaviour amplifying the other...
ivan and diego should meet each other in person, i belive that would help resolve their disagreements.
Please, think of the planet. This is going to either bring new Ice Age or cause Flame War big enough to melt down all ice on the planet (or both ;) I don't think that meeting in person could resolve our conflict. I'm sure that if there is arbiter respected by both of us and there is no more abuse of power then the conflict could just go away. I'd like things resolved on the logic of arguments, not based on who is telling them. I wonder if Diego have ever thought of following my advices as way to end the conflict. If an advice turns out to be bad (or worse) then I would have to stop giving more of them :P
On Sat, May 10, 2008 at 7:25 PM, Reimar Döffinger <Reimar.Doeffinger@stud.uni-karlsruhe.de> wrote:
I am not a fan of clear statements since my opinions are not clear.
We need clear answer.
On Sat, May 10, 2008 at 02:20:15PM +0200, Reimar Döffinger wrote:
Hello, On Sat, May 10, 2008 at 01:38:06PM +0200, Diego Biurrun wrote:
diego 1038 504 1542 reimar 690 246 936 voroshil 312 8 320 nico 212 43 255 benjamin 144 32 176 ulion 153 13 166 eugeni 106 56 162 uoti 99 20 119 guillaume 93 24 117 compn 97 16 113 cehoyos 89 8 97 ivo 65 4 69 zuxy 55 12 67 vayne 14 3 17 corey 9 6 15 attila 10 5 15 loren 11 2 13 rik 1 3 4
Before anyone flames too hard: I asked for Diego to publish these numbers. The problem is, as some of those appearing later have shown, that we have no opinions from some important people. Thing is, I really want everyone to stay on this project and happily work together. Not sure if that is possible anymore - and in that case I want a more objective overview of the opinions that I currently have. To summarize the dilemma for me personally: I very much respect and agree with most of Michael's opinions, but there are a few problems:
They basically result in a FFmpeg-style review policy. That works really great most of the time for FFmpeg, but I think it just can not work with MPlayer currently, we do not have enough people willing to do that kind of effort to get patches included.
ffmpegs policy text was copied from mplayers ... besides i think the effort which would have been needed to cleanly commit the few controversal things would not have been that huge.
So from that perspective I do think it might be better for the long term good to basically let Uoti (and also other future developers) work mostly on their own conditions (though I seriously wish for a bit more consideration for other people from his side).
This attitude was what lead to the mess mplayer is currently. Uoti can argue that the rules about indention caused bugs, sec holes and so on but its obvious that the lack of proper reviews and rejection of bad patches and commits was much more responsible for it. If you now allow commits which mix cosmetics and functional changes and other unreviewable mixes. Then this will only make mplayer a even bigger mess than it already is. And even if uoti never makes a mistake in his unreviewable commits, others will follow and work under the same rules. These other people will make mistakes and introduce many bugs.
But: I am not ready to do this in a "let the whole team roll over to accommodate one developer"-style. So if it is as it looked originally that everyone thinks this kind of thing is a bad idea, I would never propose it. But now with other developers showing up with different opinions things are a bit different. Now some of you probably wonder about my completely different opinion
no iam, not surprised at all, humans are strongly pulled toward supporting the person "closer" to them. This has been nicely shown in various variations of milgrams experiment if you dont belive it ... personal talks with diego shifts ones position toward his side, ive experienced that myself as well, I doubt it would work a second time though :) [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many things microsoft did are stupid, but not doing something just because microsoft did it is even more stupid. If everything ms did were stupid they would be bankrupt already.
On Sat, 10 May 2008 22:38:07 +0200 Michael Niedermayer <michaelni@gmx.at> wrote:
On Sat, May 10, 2008 at 02:20:15PM +0200, Reimar Döffinger wrote:
Hello, On Sat, May 10, 2008 at 01:38:06PM +0200, Diego Biurrun wrote:
diego 1038 504 1542 reimar 690 246 936 voroshil 312 8 320 nico 212 43 255 benjamin 144 32 176 ulion 153 13 166 eugeni 106 56 162 uoti 99 20 119 guillaume 93 24 117 compn 97 16 113 cehoyos 89 8 97 ivo 65 4 69 zuxy 55 12 67 vayne 14 3 17 corey 9 6 15 attila 10 5 15 loren 11 2 13 rik 1 3 4
Before anyone flames too hard: I asked for Diego to publish these numbers. The problem is, as some of those appearing later have shown, that we have no opinions from some important people. Thing is, I really want everyone to stay on this project and happily work together. Not sure if that is possible anymore - and in that case I want a more objective overview of the opinions that I currently have. To summarize the dilemma for me personally: I very much respect and agree with most of Michael's opinions, but there are a few problems:
They basically result in a FFmpeg-style review policy. That works really great most of the time for FFmpeg, but I think it just can not work with MPlayer currently, we do not have enough people willing to do that kind of effort to get patches included.
ffmpegs policy text was copied from mplayers ... besides i think the effort which would have been needed to cleanly commit the few controversal things would not have been that huge.
So from that perspective I do think it might be better for the long term good to basically let Uoti (and also other future developers) work mostly on their own conditions (though I seriously wish for a bit more consideration for other people from his side).
This attitude was what lead to the mess mplayer is currently. Uoti can argue that the rules about indention caused bugs, sec holes and so on but its obvious that the lack of proper reviews and rejection of bad patches and commits was much more responsible for it. If you now allow commits which mix cosmetics and functional changes and other unreviewable mixes. Then this will only make mplayer a even bigger mess than it already is. And even if uoti never makes a mistake in his unreviewable commits, others will follow and work under the same rules. These other people will make mistakes and introduce many bugs.
fwir of mplayer development, i agree 100% with this. but i also remember diego saying (i think!) that it was possible to have a human readable diff from a cosmetic+functional change would it be possible, and fix this issue, if the -cvslog diffs were made human readable? -compn
On Sat, 2008-05-10 at 22:38 +0200, Michael Niedermayer wrote:
On Sat, May 10, 2008 at 02:20:15PM +0200, Reimar Döffinger wrote:
So from that perspective I do think it might be better for the long term good to basically let Uoti (and also other future developers) work mostly on their own conditions (though I seriously wish for a bit more consideration for other people from his side).
This attitude was what lead to the mess mplayer is currently. Uoti can argue that the rules about indention caused bugs, sec holes and so on but its obvious that the lack of proper reviews and rejection of bad patches and commits was much more responsible for it.
IMO what caused much of the existing ugliness was adding features in a minimally invasive way as hacks on top of existing code when more of the existing code should have been rewritten to make an overall consistent system. Anyway the current problem is not that any particularly ugly code would be added but that there is lots of old code which is significantly worse than anything new and needs to be cleaned up. Trying to polish minor details of commits or nitpicking about them is not a good use of time when there are much more significant problems to fix in the existing code.
If you now allow commits which mix cosmetics and functional changes and other unreviewable mixes. Then this will only make mplayer a even bigger mess than it already is.
I don't agree with claims about my commits being "unreviewable", and I doubt people in many other projects would make such claims. MPlayer has historically had extremely strict practices in some areas such as separation of whitespace changes and very lax ones in others such as commit messages. I think it's completely ridiculous to claim that my commits would make MPlayer worse than the existing code.
And even if uoti never makes a mistake in his unreviewable commits, others will follow and work under the same rules. These other people will make mistakes and introduce many bugs.
I don't agree about my commits being "unreviewable", but I do make changes that an "average" developer probably shouldn't attempt. However I don't think I should avoid them just because someone else is likely to fail if they try to do the same, and I don't really see that as a big practical problem.
Benjamin Zores wrote:
So yes, if you want my opinion, Uoti may have broken some rules (who the hell defined them after all, probably not a whole team)
AFAIR, they were defined by suggestion and consensus over the course of time. If you think there's a problem with the current rules, you can and probably should push for them to be changed - but when your adherence or lack thereof to the rules affects other people, you are not justified in ignoring the rules while they exist. If what Uoti, Diego, yourself, and perhaps a few other people are saying is correct - if the bulk of the developers, particularly of the active developers, do not care about the rules which have been being broken - then there is little enough support for those rules that it would probably be easy to get them changed. As far as I can tell, however, no attempt to change them by consensus - or even by majority - has been made; I do not recall even a suggestion of a specific change, much less a posted patch. What Uoti is doing is simply ignoring the rules he does not like. He is no more justified in that than I would, if I still had commit access or were sending in patches, be in ignoring the rules I don't like - and there is indeed at least one rule I think is stupid to the point of being offensive. I do not think that Diego (or the rest of root) would unilaterally change the rules (i.e. commit a substantive change to one of the relevant files) without consulting the developer base - but, by refusing to enforce the rules not only when violations are seen but when people specifically ask for those rules to be enforced, that is exactly what he is effectively doing: changing the rules on his own authority, and worse, doing so without that change being visible to someone who goes looking for the rules. I am emphatically not in favor of a hard "no exceptions" approach to rules; there must always be wiggle room, and it should always be possible to ask for consensus about letting the rules not apply in a particular case. I would, furthermore, probably support ignoring a rule when doing so does not in practice affect anyone beyond the person ignoring it. That does *not*, however, justify simply unilaterally ignoring rules which *do* affect other people.
but all he wanted to do is contribute for the good of MPlayer and imho, he can't be blamed for that.
No, he can't. He *can*, however, be blamed for refusing to accept the rules (responsibilities) which go along with the privileges of having commit access to the MPlayer repository. I am of the opinion that no single developer of any project, with the possible exception of one who would be capable of carrying the entire project on his or her own, can possibly make contributions valuable enough to outweigh actively rejecting the rules which govern the project. Refraining from violating those rules while pushing for them to be changed would be more than acceptable; violating them whenever one sees fit, much less while not even trying to get them changed, is emphatically not so.
Ironically, I see that some of the people who asked for his account revocation may indeed follow these rules, as the few times they actually commit something, they have few chances to break them (and no I won't give names, even under torture :-)
My only comment on this is more a response to Diego: it's not exactly fair to count Michael's low MPlayer commit numbers in the same way as those of the others, since his primary area of activity is FFmpeg, and commits there are at least as valuable to MPlayer as commits in the MPlayer repository itself... -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Secrecy is the beginning of tyranny.
On Sat, May 10, 2008 at 08:28:51AM -0400, The Wanderer wrote:
Benjamin Zores wrote:
So yes, if you want my opinion, Uoti may have broken some rules (who the hell defined them after all, probably not a whole team)
AFAIR, they were defined by suggestion and consensus over the course of time.
Not really. Most of it was written by Arpi with some modifications done over the course of time.
Ironically, I see that some of the people who asked for his account revocation may indeed follow these rules, as the few times they actually commit something, they have few chances to break them (and no I won't give names, even under torture :-)
My only comment on this is more a response to Diego: it's not exactly fair to count Michael's low MPlayer commit numbers in the same way as those of the others, since his primary area of activity is FFmpeg, and commits there are at least as valuable to MPlayer as commits in the MPlayer repository itself...
I have the highest respect for Michael both as a person and as a developer. However, FFmpeg is not MPlayer. They are entirely different projects, even though some developers are shared. Michael's work on FFmpeg is valuable for MPlayer, as is the work of all the other developers. Nonetheless, status cannot be translated 1:1 from one project to the other. Diego
Diego Biurrun wrote:
On Sat, May 10, 2008 at 08:28:51AM -0400, The Wanderer wrote:
Benjamin Zores wrote:
So yes, if you want my opinion, Uoti may have broken some rules (who the hell defined them after all, probably not a whole team)
AFAIR, they were defined by suggestion and consensus over the course of time.
Not really. Most of it was written by Arpi with some modifications done over the course of time.
Then it's entirely possible that the rules as they are presently defined (or possibly ill-defined) may be out of date, and it may be appropriate to update them - ideally with consensus from the entire development team, preferably at least with the support of a majority, and certainly with public discussion beforehand. It is *not* appropriate to simply ignore them, unless the idea is to throw the rules out wholesale and not put anything else in their place - that is, to move to a situation of "no rules at all". (FTLIW, I do seem to remember various rules - from "no mixing of cosmetic and functional changes" through "don't casually commit to code maintained by other people" to the rules embodied in the pre-commit hooks - being discussed on the mailing lists and agreed upon by some form of consensus, or at least strong majority... they may have existed beforehand, but that does not mean they were not agreed upon.)
Ironically, I see that some of the people who asked for his account revocation may indeed follow these rules, as the few times they actually commit something, they have few chances to break them (and no I won't give names, even under torture :-)
My only comment on this is more a response to Diego: it's not exactly fair to count Michael's low MPlayer commit numbers in the same way as those of the others, since his primary area of activity is FFmpeg, and commits there are at least as valuable to MPlayer as commits in the MPlayer repository itself...
I have the highest respect for Michael both as a person and as a developer. However, FFmpeg is not MPlayer. They are entirely different projects, even though some developers are shared. Michael's work on FFmpeg is valuable for MPlayer, as is the work of all the other developers. Nonetheless, status cannot be translated 1:1 from one project to the other.
I don't entirely disagree, but my point remains. "Cannot be translated 1:1" does not remotely equal "does not carry over at all", as the numbers as posted would appear to indicate. -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Secrecy is the beginning of tyranny.
On Sat, 2008-05-10 at 10:14 -0400, The Wanderer wrote:
Then it's entirely possible that the rules as they are presently defined (or possibly ill-defined) may be out of date, and it may be appropriate to update them - ideally with consensus from the entire development team, preferably at least with the support of a majority, and certainly with public discussion beforehand.
My goal is not to make a different set of rules and then strictly follow those, but to make people stop treating any set of written rules as the ultimate authority.
It is *not* appropriate to simply ignore them, unless the idea is to throw the rules out wholesale and not put anything else in their place - that is, to move to a situation of "no rules at all".
To me this paragraph seems to indicate that you don't have a realistic view of the situation. Some rules are already ignored; and more important, it's not the rules which prevent people from doing harmful things. "No rules at all" does not equal "everyone is free to erase all files in the repository or do any other idiotic thing". There are already lots of harmful things you could do which are not forbidden by any rules. Rules which even tried to cover everything would need to be very long. Removing official rules, even those rules that make sense and should almost always be followed, won't make much difference overall as most things won't be covered by them anyway.
(I'm not sure I'm completely awake yet, but hopefully I've managed to avoid making any terrible mistakes this time.) Uoti Urpala wrote:
On Sat, 2008-05-10 at 10:14 -0400, The Wanderer wrote:
Then it's entirely possible that the rules as they are presently defined (or possibly ill-defined) may be out of date, and it may be appropriate to update them - ideally with consensus from the entire development team, preferably at least with the support of a majority, and certainly with public discussion beforehand.
My goal is not to make a different set of rules and then strictly follow those, but to make people stop treating any set of written rules as the ultimate authority.
I'm not sure if I understand what you mean by "ultimate authority" here. I've only managed to come up with two interpretations, one of which is more or less exactly the same as my already-stated "there must be room for exceptions" (i.e., everything must be considered on a case-by-case basis, rather than mindlessly applying the rules), the other of which makes this more or less equivalent to attempting to eliminate "rules" entirely.
It is *not* appropriate to simply ignore them, unless the idea is to throw the rules out wholesale and not put anything else in their place - that is, to move to a situation of "no rules at all".
To me this paragraph seems to indicate that you don't have a realistic view of the situation. Some rules are already ignored;
Then that is inappropriate, and either they should be enforced, or the rules should be changed to reflect reality.
and more important, it's not the rules which prevent people from doing harmful things.
No; it's the judgment and consciences of individual developers. What the rules do is provide criteria, ideally gathered by consensus from the developers en masse, for what to do when individual developers disagree. Without rules, whenever there was such a disagreement the question would have to be put to the developers at large, which would result in duplication of effort if the same question arose more than once and which could easily result in different, er, results just based on who happened to get involved each time - and which would, in any case, be quite time-consuming. Gathering the answers the first time the question arises (or the first time it becomes apparent that it is a common question), recording them someplace 'official', and then updating that record when it becomes appropriate to do so is simply a way of 'caching the results', as it were. Note also, please, that the definition of "harm" is a complicated issue, and may be considered to be very broad. By some standards - of difficulty of review, difficulty of reading the commit history, and I think at least one other thing I've forgotten - your own commit which started this thread would be considered harmful. (For that matter, by some standards any commit at all to code someone else is working on could be considered harmful, because it could require the someone else to do extra work to allow their changes to have the desired effect - or could even render those changes moot entirely. This is probably beyond the limit of what I would consider valid to include in the definition, but that is part of the reason to have rules to spell out where the boundaries are.)
"No rules at all" does not equal "everyone is free to erase all files in the repository or do any other idiotic thing".
If there were no rules at all, then yes, everyone with the ability to do so would be free to do so. The fact is that even with no written rules, there would almost certainly be *implicit* ones, based on individual developers' judgment (and the consensus arising therefrom) of what is and is not appropriate.
There are already lots of harmful things you could do which are not forbidden by any rules.
I'm having a hard time thinking of many offhand which would not be covered and prevented by the review policy...
Rules which even tried to cover everything would need to be very long. Removing official rules, even those rules that make sense and should almost always be followed, won't make much difference overall as most things won't be covered by them anyway.
"Because the rules cannot cover most things, it does not make much difference whether or not there are any rules at all." I can't quite identify a fallacy this corresponds to, but it just seems so ludicrous to me that if you don't see what's wrong with it I'm not sure there's much chance of our coming to agreement. -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Secrecy is the beginning of tyranny.
On Sun, 2008-05-11 at 07:33 -0400, The Wanderer wrote:
Uoti Urpala wrote:
and more important, it's not the rules which prevent people from doing harmful things.
No; it's the judgment and consciences of individual developers. What the rules do is provide criteria, ideally gathered by consensus from the developers en masse, for what to do when individual developers disagree. Without rules, whenever there was such a disagreement the question would have to be put to the developers at large, which would result in duplication of effort if the same question arose more than once and which could easily result in different, er, results just based on who happened to get involved each time - and which would, in any case, be quite time-consuming. Gathering the answers the first time the question arises (or the first time it becomes apparent that it is a common question), recording them someplace 'official', and then updating that record when it becomes appropriate to do so is simply a way of 'caching the results', as it were.
Your view of the role of rules here seems inconsistent with your earlier argument that rules need to be specified in advance and a state of "no rules" must be avoided. If you view rules as a collection of precedents about how controversial issues were resolved in the past, meant to reduce duplication of effort when the same issue arises again, why would that collection have to be filled in advance?
Note also, please, that the definition of "harm" is a complicated issue, and may be considered to be very broad. By some standards - of difficulty of review, difficulty of reading the commit history, and I think at least one other thing I've forgotten - your own commit which started this thread would be considered harmful.
(For that matter, by some standards any commit at all to code someone else is working on could be considered harmful, because it could require the someone else to do extra work to allow their changes to have the desired effect - or could even render those changes moot entirely. This is probably beyond the limit of what I would consider valid to include in the definition, but that is part of the reason to have rules to spell out where the boundaries are.)
IMO those issues are simply too complicated to be described by literal rules. You can't make a rule which would forbid a significant amount of undesirable actions without making it overbroad and also forbidding lots of things that should be allowed.
"No rules at all" does not equal "everyone is free to erase all files in the repository or do any other idiotic thing".
If there were no rules at all, then yes, everyone with the ability to do so would be free to do so. The fact is that even with no written rules, there would almost certainly be *implicit* ones, based on individual developers' judgment (and the consensus arising therefrom) of what is and is not appropriate.
Whether you call that "rules" or not is a matter of wording. Usually I would not refer to that as "rules" like in "you must not erase all files because there's an implicit rule against it".
There are already lots of harmful things you could do which are not forbidden by any rules.
I'm having a hard time thinking of many offhand which would not be covered and prevented by the review policy...
I suppose you mean the "send patch to mplayer-dev-eng if you think the change is going to be controversial" part. It doesn't say anything about what effect (if any) the possible discussion on mplayer-dev-eng should have. If you interpret it as "every change could be controversial and requires getting full consensus first" then obviously a single developer cannot do harmful changes, but OTOH interpreted that way it'd have negative effects. More practical interpretations rely on the personal judgment of developers. If you're willing to trust the their personal judgment enough then you could say that a single rule "don't do harmful changes" would prevent anything harmful.
Rules which even tried to cover everything would need to be very long. Removing official rules, even those rules that make sense and should almost always be followed, won't make much difference overall as most things won't be covered by them anyway.
"Because the rules cannot cover most things, it does not make much difference whether or not there are any rules at all." I can't quite identify a fallacy this corresponds to, but it just seems so ludicrous to me that if you don't see what's wrong with it I'm not sure there's much chance of our coming to agreement.
I don't see how you could claim that to be a fallacy. IMO it's obviously true if you take "cannot cover most" mean an insignificant enough part can be covered, so there cannot be a flaw in the general argument. You could try to argue that somehow the rules could cover enough to make a big difference, but that still wouldn't show any _logical_ flaw in my argument.
(Doesn't this discussion - the entire thing, not just this subthread I'm involved in - belong on -dev-eng or the like by now?) Uoti Urpala wrote:
On Sun, 2008-05-11 at 07:33 -0400, The Wanderer wrote:
Uoti Urpala wrote:
and more important, it's not the rules which prevent people from doing harmful things.
No; it's the judgment and consciences of individual developers. What the rules do is provide criteria, ideally gathered by consensus from the developers en masse, for what to do when individual developers disagree. Without rules, whenever there was such a disagreement the question would have to be put to the developers at large, which would result in duplication of effort if the same question arose more than once and which could easily result in different, er, results just based on who happened to get involved each time - and which would, in any case, be quite time-consuming. Gathering the answers the first time the question arises (or the first time it becomes apparent that it is a common question), recording them someplace 'official', and then updating that record when it becomes appropriate to do so is simply a way of 'caching the results', as it were.
Your view of the role of rules here seems inconsistent with your earlier argument that rules need to be specified in advance and a state of "no rules" must be avoided. If you view rules as a collection of precedents about how controversial issues were resolved in the past, meant to reduce duplication of effort when the same issue arises again, why would that collection have to be filled in advance?
It wouldn't have to - but in this case, it (at least purportedly) already has been, viz. the written rules you seem to be saying are a bad thing ab initio. The case where the collection has not been filled is not a case of "no rules", it's a case of "no indication of what the rules are" - which is also bad, but in a different way and for different reasons. When the rules as collected become different from the rules as enforced and/or the rules as the community expects them to be followed, there is again no reliable indication of what the rules are, and so either the reality needs to be changed to match the collected rules or that collection needs to be updated to reflect reality. In most cases, the latter is more appropriate.
Note also, please, that the definition of "harm" is a complicated issue, and may be considered to be very broad. By some standards - of difficulty of review, difficulty of reading the commit history, and I think at least one other thing I've forgotten - your own commit which started this thread would be considered harmful.
(For that matter, by some standards any commit at all to code someone else is working on could be considered harmful, because it could require the someone else to do extra work to allow their changes to have the desired effect - or could even render those changes moot entirely. This is probably beyond the limit of what I would consider valid to include in the definition, but that is part of the reason to have rules to spell out where the boundaries are.)
IMO those issues are simply too complicated to be described by literal rules. You can't make a rule which would forbid a significant amount of undesirable actions without making it overbroad and also forbidding lots of things that should be allowed.
(Actually, you can - but the resulting text would almost certainly constitute legalese, and even though I can read and write that sort of thing I certainly don't think it's appropriate for all contexts; I am therefore going to ignore the possibility for the moment.) And that's why, no matter how important the rule, there must always be room to allow exceptions in particular cases, in a unanimous-consent "No objection, so ordered" sort of way. That doesn't mean that effort should not go into attempting to ensure that rules are not overly broad, but it does mean that there's no need to worry about getting it exactly perfect, unless of course you're into that kind of thing.
There are already lots of harmful things you could do which are not forbidden by any rules.
I'm having a hard time thinking of many offhand which would not be covered and prevented by the review policy...
I suppose you mean the "send patch to mplayer-dev-eng if you think the change is going to be controversial" part. It doesn't say anything about what effect (if any) the possible discussion on mplayer-dev-eng should have.
No, it doesn't. I suspect that it was intended to be implied as obvious that the results of the discussion would govern the action to be taken. It would be possible to spell out that sort of thing, but doing so is one step closer to legalese and the legalistic mindset, which though sometimes valuable is not really appropriate in many cases.
If you interpret it as "every change could be controversial and requires getting full consensus first" then obviously a single developer cannot do harmful changes, but OTOH interpreted that way it'd have negative effects. More practical interpretations rely on the personal judgment of developers. If you're willing to trust the their personal judgment enough then you could say that a single rule "don't do harmful changes" would prevent anything harmful.
Except for the difficulty of defining "harm". By some lights, the increased difficulty of review (not only in a pre-commit sense, but in a "going back to review past changes" sense) involved in commits such as the one which started this thread might constitute harm; by others, it would not.
Rules which even tried to cover everything would need to be very long. Removing official rules, even those rules that make sense and should almost always be followed, won't make much difference overall as most things won't be covered by them anyway.
"Because the rules cannot cover most things, it does not make much difference whether or not there are any rules at all." I can't quite identify a fallacy this corresponds to, but it just seems so ludicrous to me that if you don't see what's wrong with it I'm not sure there's much chance of our coming to agreement.
I don't see how you could claim that to be a fallacy.
I didn't - I said I couldn't identify one which corresponds to it. It does look like the type of statement which I often see matched to one fallacy or another, but that doesn't necessarily mean that it is in fact fallacious. That does not mean that it isn't still wrong, just that if so it would be wrong for different reasons. -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Secrecy is the beginning of tyranny.
On Sun, May 11, 2008 at 1:42 PM, Uoti Urpala <uoti.urpala@pp1.inet.fi> wrote:
On Sat, 2008-05-10 at 10:14 -0400, The Wanderer wrote:
Then it's entirely possible that the rules as they are presently defined (or possibly ill-defined) may be out of date, and it may be appropriate to update them - ideally with consensus from the entire development team, preferably at least with the support of a majority, and certainly with public discussion beforehand.
My goal is not to make a different set of rules and then strictly follow those, but to make people stop treating any set of written rules as the ultimate authority.
You probably haven't read my mail about rules at all. I'll copy/paste the relevant part. "Every project have some rules. Most of the projects don't have them written because it is enough developers to tell newbies how and why they do the thing this way. This is also the reason MPlayer "rules" are written in patch and commit manuals. MPlayer project rules are not something ancient put down by faceless gods, that nobody remembers anymore. They are in fact End Terms of many old (and forgotten for good) flamewars. Some of the rules have been revised after their initial writing. Throwing these rules away would simply restart all these flamewars again. The problem with Uoti is that he couldn't convince enough developers to change the rules to his liking, so he doesn't follow them. This causes flamewar on each commit that break some rule. And there is no end of it." Uoti, you never accepted any kind of advice from anybody. You never reverted any commit of yours. You never admitted doing anything wrong. Every time when somebody asked you to do things in the usual way you respond with "Who are you to tell me what to do. I do the work so I can do it the way I please". I do blame Diego for you fall, because most of the ideology you use to justify your action is invented by him, this meritocracy based on number of commits, these imaginary forks, these arbitrary laws. But even Diego admits he can't control you. And all this lead us to this situation.
It is *not* appropriate to simply ignore them, unless the idea is to throw the rules out wholesale and not put anything else in their place - that is, to move to a situation of "no rules at all".
To me this paragraph seems to indicate that you don't have a realistic view of the situation. Some rules are already ignored; and more important, it's not the rules which prevent people from doing harmful things. "No rules at all" does not equal "everyone is free to erase all files in the repository or do any other idiotic thing". There are already lots of harmful things you could do which are not forbidden by any rules. Rules which even tried to cover everything would need to be very long. Removing official rules, even those rules that make sense and should almost always be followed, won't make much difference overall as most things won't be covered by them anyway.
You are talking about laws. It was Diego who mislead people into thinking that these rules are some kind of written laws and then like a real lawyer said that they didn't explicitly forbid what you have done, so they don't apply to you. It was just a transparent way of saving your ass. But you assumed is the normal way we operate here. It is not. On a side note. Uoti, would you accept Reimar as Project Leader.
On Sun, 2008-05-11 at 18:14 +0300, Ivan Kalvachev wrote:
MPlayer project rules are not something ancient put down by faceless gods, that nobody remembers anymore. They are in fact End Terms of many old (and forgotten for good) flamewars.
Flamewars between largely different active developers, which aren't necessarily much more relevant to currently active developers than the rules of any other project. The traditional MPlayer development practices have also been demonstrated not to work too well.
Uoti, you never accepted any kind of advice from anybody.
False.
You never reverted any commit of yours. You never admitted doing anything wrong.
I have not claimed that everything I've done would have been perfect. However none of my commits have had such problems that they should have been reverted. You've never admitted that your responses to what I've done have been ridiculous overreactions or completely off the mark.
Every time when somebody asked you to do things in the usual way you respond with "Who are you to tell me what to do. I do the work so I can do it the way I please".
"The usual way" with the usual problems. Most of the traditional MPlayer practices should not be used except as warning examples.
I do blame Diego for you fall, because most of the ideology you use to justify your action is invented by him, this meritocracy based on number of commits, these imaginary forks, these arbitrary laws. But even Diego admits he can't control you.
I don't believe that trying to do more of what has failed to fix MPlayer's problems would fix them now. I've never intended to work according to traditional MPlayer practices. IMO skills and activity should have a big effect on how much your opinion counts, but contrary to what you say I have not proposed using raw commit counts as a measure of that.
It was Diego who mislead people into thinking that these rules are some kind of written laws and then like a real lawyer said that they didn't explicitly forbid what you have done, so they don't apply to you.
You'd rather interpret the rules to forbid anything you don't like or are not used to. Do you consider "blame Diego for everything" to be one of those implicit rules by now?
It was just a transparent way of saving your ass. But you assumed is the normal way we operate here. It is not.
I assumed no such thing. I know you and some others want to do things differently. I think your way sucks and would not be good for MPlayer development. And when you don't even do much and just complain from the side there's not much reason to even try cooperating with you.
On a side note.
Uoti, would you accept Reimar as Project Leader.
He usually avoids controversy and so most people probably wouldn't oppose him as a leader. However as a leader avoiding controversy mainly maps to not using any powers in the role of a leader. I don't have much idea what if anything he'd actually do with leader privileges (whatever those would be).
On Tue, May 13, 2008 at 5:47 PM, Uoti Urpala <uoti.urpala@pp1.inet.fi> wrote:
I've never intended to work according to traditional MPlayer practices.
Uoti Urpala wrote:
I don't believe that trying to do more of what has failed to fix MPlayer's problems would fix them now. I've never intended to work according to traditional MPlayer practices.
Then you must have accepted your MPlayer commit access under false pretenses, since accepting that implies acceptance of the rules - which, in this case, appears to include some things you are describing as "traditional MPlayer practices". -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Secrecy is the beginning of tyranny.
On Fri, May 09, 2008 at 05:06:31PM +0200, Diego Biurrun wrote:
On Fri, May 09, 2008 at 04:48:34PM +0200, Benjamin Zores wrote:
For the record, my opinion doesn't matter much but I'd not vote for your account revocation if I was asked about,
Since when does your vote not count?
Since when does anyones vote but your own count? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I do not agree with what you have to say, but I'll defend to the death your right to say it. -- Voltaire
On Sat, Apr 12, 2008 at 07:30:49PM +0200, Alban Bedel wrote:
On Sat, 12 Apr 2008 18:23:08 +0200 Reimar Döffinger <Reimar.Doeffinger@stud.uni-karlsruhe.de> wrote:
On Sat, Apr 12, 2008 at 05:51:08PM +0200, uau wrote:
Author: uau Date: Sat Apr 12 17:51:08 2008 New Revision: 26411
Log: Reindent demuxer.c
This is not only a reindentation, this also does other cosmetic changes, which makes this simply unreviewable, and also you are supposed to ask about cosmetic changes before for code you don't maintain. I have simply had enough, if this is the only way you can behave, I simply can't and don't want to work with you, no matter how good your code may be.
I'll maintain my code as long as that is desired, but I simply don't want to actively work in this environment anymore.
I can only second that.
So do i, maybe its time to search for a new place for mplayer svn/git? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is dangerous to be right in matters on which the established authorities are wrong. -- Voltaire
Reimar Döffinger wrote:
On Sat, Apr 12, 2008 at 05:51:08PM +0200, uau wrote:
Author: uau Date: Sat Apr 12 17:51:08 2008 New Revision: 26411
Log: Reindent demuxer.c
This is not only a reindentation,
It is, at least if you consider reindent as "do what indent does" Uoti please try to warn a bit about such commits so people won't jump on guns just because it is a large patch and does things they don't understand on the first sight (even if the terse comment explains it) lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero
On Wed, Jun 04, 2008 at 05:34:13PM +0200, Luca Barbato wrote:
Reimar Döffinger wrote:
On Sat, Apr 12, 2008 at 05:51:08PM +0200, uau wrote:
Author: uau Date: Sat Apr 12 17:51:08 2008 New Revision: 26411
Log: Reindent demuxer.c
This is not only a reindentation,
It is, at least if you consider reindent as "do what indent does"
@@ -357,11 +376,8 @@ } -void ds_add_packet(demux_stream_t *ds,demux_packet_t* dp){ -// demux_packet_t* dp=new_demux_packet(len); -// stream_read(stream,dp->buffer,len); -// dp->pts=pts; //(float)pts/90000.0f; -// dp->pos=pos; +void ds_add_packet(demux_stream_t *ds, demux_packet_t *dp) +{ // append packet to DS stream: ++ds->packs; ds->bytes+=dp->len; ..... resize_demux_packet(dp, len); - dp->pts=pts; //(float)pts/90000.0f; + dp->pts = pts; dp->pos=pos; dp->flags=flags; // append packet to DS stream: ..... -int demux_fill_buffer(demuxer_t *demux,demux_stream_t *ds){ +int demux_fill_buffer(demuxer_t *demux, demux_stream_t *ds) +{ // Note: parameter 'ds' can be NULL! -// printf("demux->type=%d\n",demux->type); return demux->desc->fill_buffer(demux, ds); } ..... --ds->packs; - return 1; //ds->buffer_size; + return 1; } ..... @@ -689,11 +749,9 @@ */ static demuxer_t* demux_open_stream(stream_t *stream, int file_format, - int force, int audio_id, int video_id, int dvdsub_id, - char* filename) { - -//int file_format=(*file_format_ptr); - + int force, int audio_id, int video_id, + int dvdsub_id, char *filename) +{ demuxer_t *demuxer=NULL; sh_video_t *sh_video=NULL; @@ -702,12 +760,12 @@ int fformat = 0; int i; -//printf("demux_open(%p,%d,%d,%d,%d) \n",stream,file_format,audio_id,video_id,dvdsub_id); - // If somebody requested a demuxer check it if (file_format) { if ((demuxer_desc = get_demuxer_desc_from_type(file_format ..... - demuxer->stream->eof=0; // clear eof flag + demuxer->stream->eof = 0; demuxer->video->eof=0; demuxer->audio->eof=0; -#if 0 - if(sh_audio) sh_audio->timer=sh_video->timer; -#else - if(sh_video) sh_video->timer=0; // !!!!!! -#endif + if (sh_video) + sh_video->timer = 0; // !!!!!! if(flags & SEEK_ABSOLUTE) pts = 0.0f; ---------------------------------------- These remove comments, remove outcommented code, ... this definitly is not what indent does and its just what i quickly spotted And thats why such commits are so bad and why we all complain, they are a nightmare to review, you missed the things above, others missed them too. What if there where security related changes? Intentionally placed buffer overflows or some, send /etc/shadow to badguy@badplace.com? All code that goes into svn has to be reviewed or mplayer will become a time bomb. Its trivial to get a svn account if one wanted to do something nasty, reviews are the only way to avoid such issues. Also the very next commit from uoti is a shorter example of a mix of cosmetics and functional changes Besides demuxer.c is not maintained by uoti ... [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Asymptotically faster algorithms should always be preferred if you have asymptotical amounts of data
On Wed, Jun 04, 2008 at 09:29:19PM +0200, Michael Niedermayer wrote:
On Wed, Jun 04, 2008 at 05:34:13PM +0200, Luca Barbato wrote:
Reimar Döffinger wrote:
On Sat, Apr 12, 2008 at 05:51:08PM +0200, uau wrote:
Log: Reindent demuxer.c
This is not only a reindentation,
It is, at least if you consider reindent as "do what indent does"
---------------------------------------- These remove comments, remove outcommented code, ... this definitly is not what indent does and its just what i quickly spotted
We've been over this before. The commit message was bad, it has been fixed. You can hardly accuse Uoti of writing bad commit messages in general.
And thats why such commits are so bad and why we all complain, they are a nightmare to review, you missed the things above, others missed them too.
I posted a diff without whitespace changes to this thread. It was not at all hard to review. Move on, nothing to see here...
Besides demuxer.c is not maintained by uoti ...
Other files were reindented without a big outcry before. Diego
On Thursday, 05 June 2008 at 10:28, Diego Biurrun wrote:
On Wed, Jun 04, 2008 at 09:29:19PM +0200, Michael Niedermayer wrote:
On Wed, Jun 04, 2008 at 05:34:13PM +0200, Luca Barbato wrote:
Reimar Döffinger wrote:
On Sat, Apr 12, 2008 at 05:51:08PM +0200, uau wrote:
Log: Reindent demuxer.c
This is not only a reindentation,
It is, at least if you consider reindent as "do what indent does"
---------------------------------------- These remove comments, remove outcommented code, ... this definitly is not what indent does and its just what i quickly spotted
We've been over this before. The commit message was bad, it has been fixed. You can hardly accuse Uoti of writing bad commit messages in general.
And thats why such commits are so bad and why we all complain, they are a nightmare to review, you missed the things above, others missed them too.
I posted a diff without whitespace changes to this thread. It was not at all hard to review. Move on, nothing to see here...
And that's what should've been committed.
Besides demuxer.c is not maintained by uoti ...
Other files were reindented without a big outcry before.
That doesn't make it right. He should've asked in the mailing list first. Isn't it standard procedure? Post a patch, ask for objections and threaten to commit in X days if there aren't any. It's not too much to ask IMHO. Besides, what happened to your promise to revert and fix all Uoti's bad commits? Regards, R. -- MPlayer http://mplayerhq.hu | Livna http://rpm.livna.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan
On Thu, Jun 05, 2008 at 12:46:01PM +0200, Dominik 'Rathann' Mierzejewski wrote:
On Thursday, 05 June 2008 at 10:28, Diego Biurrun wrote:
On Wed, Jun 04, 2008 at 09:29:19PM +0200, Michael Niedermayer wrote:
Besides demuxer.c is not maintained by uoti ...
Other files were reindented without a big outcry before.
That doesn't make it right. He should've asked in the mailing list first. Isn't it standard procedure? Post a patch, ask for objections and threaten to commit in X days if there aren't any. It's not too much to ask IMHO.
It was not done maliciously, so no need to get worked up over things. There were precedents which did not cause trouble, so no trouble was to be expected in this case. Sending patches gives extra assurance, but I can understand that it is burdensome when you are carrying around a lot of changes. I have the same problem myself. I don't even mind commits getting (civilly) criticized, even reverted. There's just no need to hack somebody's hand off for such things. Revert, split, change, transmogrify the commit, move on. That said, I welcome each file that gets reindented.
Besides, what happened to your promise to revert and fix all Uoti's bad commits?
I split the demux_mkv thing, I removed unnecessary parentheses from all files that are not imported libraries. I can go ahead and remove the commented out stuff and reindent the file as well, sure. Diego
On Thu, Jun 05, 2008 at 10:28:34AM +0200, Diego Biurrun wrote:
On Wed, Jun 04, 2008 at 09:29:19PM +0200, Michael Niedermayer wrote:
On Wed, Jun 04, 2008 at 05:34:13PM +0200, Luca Barbato wrote:
Reimar Döffinger wrote:
On Sat, Apr 12, 2008 at 05:51:08PM +0200, uau wrote:
Log: Reindent demuxer.c
This is not only a reindentation,
It is, at least if you consider reindent as "do what indent does"
---------------------------------------- These remove comments, remove outcommented code, ... this definitly is not what indent does and its just what i quickly spotted
We've been over this before. The commit message was bad, it has been fixed. You can hardly accuse Uoti of writing bad commit messages in general.
The commit was bad and i suspect that was because uoti did not review what he commited before he commited it. Otherwise why would he have missed that it was not just a reindentation?
And thats why such commits are so bad and why we all complain, they are a nightmare to review, you missed the things above, others missed them too.
I posted a diff without whitespace changes to this thread. It was not at all hard to review. Move on, nothing to see here...
you posted a >40k diff -uwbBE This diff was still 90% whitespace changes and very hard to review, the mere size showed that. I did manually look over it and posted the hunks which where not whitespace changes.
Besides demuxer.c is not maintained by uoti ...
Other files were reindented without a big outcry before.
* which files where reindented without spoken or unspoken approval of the maintainer? * demuxer.c was NOT just reindented, comments and outcommented code was removed as well. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The greatest way to live with honor in this world is to be what we pretend to be. -- Socrates
On Thu, Jun 05, 2008 at 07:52:36PM +0200, Michael Niedermayer wrote:
On Thu, Jun 05, 2008 at 10:28:34AM +0200, Diego Biurrun wrote:
On Wed, Jun 04, 2008 at 09:29:19PM +0200, Michael Niedermayer wrote:
On Wed, Jun 04, 2008 at 05:34:13PM +0200, Luca Barbato wrote:
Reimar Döffinger wrote:
On Sat, Apr 12, 2008 at 05:51:08PM +0200, uau wrote:
Log: Reindent demuxer.c
This is not only a reindentation,
It is, at least if you consider reindent as "do what indent does"
---------------------------------------- These remove comments, remove outcommented code, ... this definitly is not what indent does and its just what i quickly spotted
We've been over this before. The commit message was bad, it has been fixed. You can hardly accuse Uoti of writing bad commit messages in general.
The commit was bad and i suspect that was because uoti did not review what he commited before he commited it. Otherwise why would he have missed that it was not just a reindentation?
Uoti did not expect a commit that mixes different kinds of cosmetic changes to cause such a commotion. He made a mistake, it got fixed. So let's cut his head off, shall we? Why are we discussing this for the nth time? Nothing to see here really, move on.
And thats why such commits are so bad and why we all complain, they are a nightmare to review, you missed the things above, others missed them too.
I posted a diff without whitespace changes to this thread. It was not at all hard to review. Move on, nothing to see here...
you posted a >40k diff -uwbBE This diff was still 90% whitespace changes and very hard to review, the mere size showed that.
I had no trouble reviewing it. I just did it *again*, it took me about 5 minutes. There's a simple solution for the future: Get it over with and reindent all of MPlayer.
Besides demuxer.c is not maintained by uoti ...
Other files were reindented without a big outcry before.
* which files where reindented without spoken or unspoken approval of the maintainer?
We've already discussed this before. ------------------------------------------------------------------------ r24911 | uau | 2007-11-01 07:51:38 +0100 (Thu, 01 Nov 2007) | 4 lines Changed paths: M /trunk/libmpcodecs/dec_audio.c Reindent dec_audio.c Also remove some commented out code ------------------------------------------------------------------------ No trouble caused by this.
* demuxer.c was NOT just reindented, comments and outcommented code was removed as well.
You are repeating yourself. All the changes were cosmetic changes. We have discussed all of this before. Diego
On Sat, 12 Apr 2008 17:51:08 +0200 (CEST) uau <subversion@mplayerhq.hu> wrote:
Author: uau Date: Sat Apr 12 17:51:08 2008 New Revision: 26411
Log: Reindent demuxer.c
Modified: trunk/libmpdemux/demuxer.c
Policy violation, revert. And I'm officially asking to remove uau svn write access because of repeated violation of MPlayer rules, and refusal to accept any rule he doesn't agree with. uau,if you want to play by your own rules then fork your personal version of MPlayer. Ciao, Roberto -- Better is the enemy of good enough.
On Sun, 13 Apr 2008 01:28:08 +0200 Roberto Togni <rxt@rtogni.it> wrote:
On Sat, 12 Apr 2008 17:51:08 +0200 (CEST) uau <subversion@mplayerhq.hu> wrote:
Author: uau Date: Sat Apr 12 17:51:08 2008 New Revision: 26411
Log: Reindent demuxer.c
Modified: trunk/libmpdemux/demuxer.c
Policy violation, revert.
And I'm officially asking to remove uau svn write access because of repeated violation of MPlayer rules, and refusal to accept any rule he doesn't agree with.
uau,if you want to play by your own rules then fork your personal version of MPlayer.
A week passed with no reaction, so I reverted this patch myself. I reverted also r26412, Aurel asked Uoti to revert it but nothing happened also for that. Ciao, Roberto -- Better is the enemy of good enough.
participants (19)
-
Alban Bedel -
Aurelien Jacobs -
Balatoni Denes -
Benjamin Zores -
Compn -
Diego Biurrun -
Dominik 'Rathann' Mierzejewski -
Evgeniy Stepanov -
Guillaume POIRIER -
Ivan Kalvachev -
Luca Barbato -
Michael Niedermayer -
Nico Sabbi -
Reimar Döffinger -
Robert Swain -
Roberto Togni -
The Wanderer -
uau -
Uoti Urpala