[Ffmpeg-devel] swscale recently broke (in mplayer)
Diego Biurrun
diego
Mon Aug 21 02:19:34 CEST 2006
Let's both please calm down before this degenerates into flames. I do
believe I can handle Subversion repositories well and estimate and
control the risks of modifying them. Yes, I made a mistake, but I have
reason to think it will not happen again. IMO the loss of confidence is
an (understandable) overreaction.
Asynchronous communication by email may not be the best way to discuss
this. I suggest meeting on IRC to discuss this, I think I will be able
to better explain there. I might also give you a phone call.
On Sat, Aug 19, 2006 at 02:44:14AM +0200, Michael Niedermayer wrote:
>
> On Fri, Aug 18, 2006 at 05:27:02PM +0200, Diego Biurrun wrote:
> [...]
> >
> > If you are referring to the MPlayer repository in general, then no it does
> > not match history. It never has because the CVS repository from which it
> > was created has had *massive* manual fiddling applied to it. It's closer
>
> well, i agree though "*massive*" sounds exagerated a little ...
This is relative and thus debatable of course, but there were numerous
renames done manually (I'd guess >20 offhand), some through copying RCS
files, others through directly moving them. A few directories have been
moved to a different repository for obsolete stuff, I'm not entirely
sure how. So let's just say that there have been extensive manual
modifications :)
> > > furthermore iam asking the admin team offically to NEVER attempt to rebuild
> > > the ffmpeg repository no matter what the reason, this is far too dangerous
> > > a single typo can wipe out the whole repo and whats worse errors can sneak
> > > in unnoticed and throw everything into an inconsistant state
> >
> > Admins can always do massive damage with single typos, that's why it's
> > so important to make backups. We have daily backups of all repositories
> > so the window for dataloss is 24h
>
> with the img_format.[ch] issue it took more then a month to be noticed
> thats much more then 24h, and backups arent that usefull for that anymore
I was being imprecise there, let me try to rephrase my point more
clearly.
With window for dataloss I was referring to the time between backups. If
disaster strikes just before or while the next backup is run up to 24h
of work may be lost.
We keep old backups around, I have all backups since July, Attila since
much longer. We don't keep daily backups forever, after some time we
just keep one per week and eventually one per month.
And no, the backups *are* useful. As long as you have one from before
the disaster you are able to restore/fix the damage.
> > and it's not very hard to recreate
> > commits from the mailing list archive.
>
> if the repo is in a messed up state then fixing it is generally not possible
> without breaking existing checkouts, the question is just how many are
> affected, that could be none if the mess is in the distant past or noticed
> quickly if its noticed after several month then many checkouts might break
> thats unacceptable, especially when you consider that these rebuilds are
> done to fix minor errors in the history, things which cvs could not
> represent correctly, IMO NONE of these fixes should have ever been done
> after the svn repo had been created, the advantages simply are non existant
> while the risks are massive
Some people value the fixed history, some don't. You value the history
for things like libswscale very much, I appreciate being able to
check out the very first versions of MPlayer. We just have different
priorities.
Unfortunately we were forced to switch to Subversion in a hurry because
mphq1 died, thus I could not finish doing the conversion as thorough as
I had wished. The idea was that some changes could still be made later
on and getting the repositories online quick was more important.
Please have a little faith. One misstep does not mean that the risks are
huge and/or uncontrollable.
> i dont want to think about what would happen if revision numbers would
> change during such a messup/fix
It's impossible to inadvertently add or remove revisions.
> > When I work on the repository I of course never work on the live
> > repository, but on a copy. There is no way that the live copy can ever
> > be wiped out.
> >
> > I'll make sure to triplecheck next time I make changes to a repository,
> > but given how many times I made changes my record is still not bad.
>
> you should IMO post every change in some way to mplayer-dev before doing it
Sure, I can do that to make things more transparent.
> > Anyway, I'm not aware of any outstanding issues with the FFmpeg
> > repository so the point is moot.
>
> maybe, but i say it again, DO NOT rebuild the ffmpeg repository
> ever,
I'll say it explicitly just to make sure: I won't touch it without your
permission.
> if ffmpeg where hosted somewhere else i would have moved it away
> by now already, the admin team is not there to mess with the internals
> of projects, the admin team should keep the server running and it should
> do the admin jobs which the users need and want done but cant do themselfs
> its not the admins job to invent rules interfering with internal
> project work (cvs admin -o / svn cp reversal rules) and even less is it
> the admins job to try to improve the repository by rebuilding it constantly
>
> and diego, sorry for the flames, i really didnt want to flame but i really
> think the admin team is "overdoing" things a little and that these repo
> rebuilds need to be disscussed more carefully and not just done because
> one or two persons think its a good idea and just a minor change ...
> IMO and i think not only mine it is a very bad idea and very intrusive
> change, not something which should be done as daily excercise
You're flaming now. You do have some valid points, but I think you're
getting carried away a little bit. I'll answer one by one trying to
calm things down a tad.
First off, the admin team, i.e. Attila, Mans and myself share duties and
Subversion is my area. So any blame is mine alone and should not be
attributed to all three of us.
The repositories are not being rebuilt constantly as a daily exercise,
that's an exaggeration. I haven't touched FFmpeg since it went live
and MPlayer only twice.
I'm not messing with the internals of projects. You make it sound as if
I was interfering with internal project operations that I have no
business taking part in. I am a (active) developer as well as the
repository admin and I know a bit about Subversion, so I do believe I
qualify to take part in revision control policy discussions. The whole
Subversion reversal issue is completely separate from repository
rebuilding, so let's please not mix things up.
If you wish to have repository rebuilds discussed/announced beforehand,
then yes, you have a valid point as I said above.
Diego
More information about the ffmpeg-devel
mailing list