lintian overrirede shlib-with-non-pic-codeshlib-with-non-pic-code, was: [SCM] FFmpeg packaging branch, master, updated. debian/0.5+svn20090609-1-22-g6b646aa

[Fabian Greffrath]

Reinhard Tartler schrieb:
> rebase will "break" all working copies of the other team
> members. Morover, you will not be able to 'fast-forward' push to our
> repository, so you'd have to override existing revisions. Please avoid
> that.

Erm, okay, but from our private mail of July 13th I understood that 
rebase was the way to go.

> A static diff against master can always be generated by using 'git diff
> master..master.extra'. Diffs against the lastest upload from master is
> analog: 'git diff debian/$version..master.extra'

Sure, I know how to create a diff between two branches. I just want to 
achive that this diff is always the same between master and 
master.extra, i.e. that master.extra gets the same changes applied as 
master and that the real difference between both branches is only 
applied once and for all.

> I don't think it is worth the efford to keep the HEAD of master
> up-to-date in the master.extra branch. Way more efficient is to
> regularily merge the latest upload (which is represented by a tag) into
> master.extra. This merge *should* go without any conflicts, however if
> they are indeed conflicts, they will only appear *exactly once*, as
> their resolution is recorded then.

Alright, that's also a reasonable approach.

> This approach has the obvious drawback that when there are commits in
> master that are not uploaded yet, there is no easy way to get them into
> master.extra. I see this as a positive feature, as it increases the
> preasure to first work on master, get it into shape and uploaded, so
> that work on master.extra can continue.

Okay, then let's wait for the next upload of master until we care 
about master.extra again.

> In the case you want to experiment with the ffmpeg-extra and
> unuploaded-yet commits, I'd suggest to create a local scratch branch and
> merge in the missing revisions from master. If this causes conflicts,
> then we probably have divergence that should be fixed in either master
> or master.extra.

Thank you for another lesson in GIT. ;)

> Coming back to the topic: what's the general feeling of the status of
> 'master'. Do you feekl it is ready for upload?

I am still not sure about the B-D on yasm, but generally I would say 
we should upload fast and often. ;)


-- 
Dipl.-Phys. Fabian Greffrath

Ruhr-Universität Bochum
Lehrstuhl für Energieanlagen und Energieprozesstechnik (LEAT)
Universitätsstr. 150, IB 3/134
D-44780 Bochum

Telefon: +49 (0)234 / 32-26334
Fax:     +49 (0)234 / 32-14227
E-Mail:  greffrath at leat.ruhr-uni-bochum.de