[FFmpeg-cvslog] r19321 - branches/0.5/doc/ffmpeg-doc.texi
Sun Jul 5 02:09:20 CEST 2009
On 7/3/09, Diego Biurrun <diego at biurrun.de> wrote:
> On Fri, Jul 03, 2009 at 02:39:50PM +0100, Robert Swain wrote:
>> On Fri, 03 Jul 2009 15:14:07 +0200, Diego Biurrun <diego at biurrun.de>
>> > On Fri, Jul 03, 2009 at 01:25:23PM +0200, Stefano Sabatini wrote:
>> > > On date Friday 2009-07-03 11:19:27 +0200, Diego Biurrun wrote:
>> > > > On Wed, Jul 01, 2009 at 10:14:19PM +0200, stefano wrote:
>> > > > >
>> > > > > Log:
>> > > > > Update ffmpeg documentation regarding metadata setting. -title,
>> > > > > -author, -copyright, -track, -album, and -year options have been
>> > > > > dropped in favor of -metadata.
>> > > > >
>> > > > > Backfix of r19285, r19287, and r19320.
>> > > > >
>> > > > > Modified:
>> > > > > branches/0.5/doc/ffmpeg-doc.texi
>> > > >
>> > > > It seems I didn't flame hard enough the last time around. One
>> > > > more try:
>> > > >
>> > > > Stop "backporting" unapproved patches to the 0.5 branch THIS
>> > > > FUCKING INSTANT! Much less if you haven't bothered to RTFM to
>> > > > find out how to do it properly. Now revert this mess.
>> > >
>> > > Done.
>> > >
>> > > Now, would you be kind enough to explain which is the procedure to
>> > > follow for making backports?
>> > As I said, RTFM.
>> Stefano is trying to be helpful and improve the quality of the
> The sentiment is appreciated, but the net result of his actions is
> further delaying the point release.
>> As far as I can discover from trunk or the branch, we don't have any
>> documented procedure for backporting changes to the release branch.
>> Grepping the entire trees case insensitively for 'backport', 'branch'
>> or 'release' throws nothing relevant. This suggests there is no manual
>> to read on such. Where is it documented?
> The documentation of Subversion itself of course. Branching and merging
> do not work by simply applying patches, on the contrary, you should use
> the revision control system itself.
> People who do not know or understand that should not touch branches.
> Here's the relevant part of the Subversion documentation:
> Go and read it, Subversion's documentation is second to none.
>> Also, why did you get so angry? The change could be easily reverted and
>> this isn't happening so regularly as for your response to be the
>> result of growing weary of telling people. As far as I'm aware there was
>> one previous instance where something was committed to the branch that
>> you didn't approve.
>> I'm not saying people should commit unapproved patches to the branch,
>> not at all, just that I think your response was rude, discouraging and
>> an overreaction.
> There was one previous instance where it was done completely wrong, now
> a second one. My time is very limited at the moment, I do not want to
> waste it on more flaming and reverting other people's fixes. To prevent
> this from happening for a third time (or more) I flamed harder this time
> around. It appears that I succeeded at getting my point across.
> Note that I'm working on 0.5.1 for some time already and it is delayed.
> I asked for help identifying security-relevant fixes and got no
> responses. Fine, I'm not complaining. If somebody wants to help,
> great, if nobody is motivated to help, bad luck, I'll have to do it
> What I do *not* want is people putting obstacles in my way and wasting
> the little time that I have available. Unfortunately, this is the
> situation right now and there is no way I can tolerate that if I want
> to get any productive work done at all, sorry.
Maybe you should just make svn reject all commits to 0.5 branch
that are not done by you.
This would probably save a lot of innocent souls.
More information about the ffmpeg-cvslog