[FFmpeg-devel] release work

[Frans de Boer]

On Sun, 2009-02-01 at 02:43 +0000, M?ns Rullg?rd wrote:
> Frans de Boer <frans at fransdb.nl> writes:
> 
> > Personal note: Some time ago I forced the FFmpeg community to tell the
> > public what the last version was of their so called v51 sources. I
> 
> I can assure you, that you have forced us to do nothing at all.  I do
> remember you busting in here, shouting about how we should be doing
> things.  If I remember correctly, you were thoroughly ridiculed and
> sent back under the rock from whence you came.  I'll do it again if
> you tempt me.
> 
Oh, mister Mans, please forgive me that I laugh at your remark. You seem
to be the typical 'engineer' if I recall correctly. I had private
e-mails of others who 'warned' me of you and your way of communicating.
if you want to make it personal, bite me!!

> > mentioned also something about releases and version control. I mean,
> > what is the use of having version control systems if you don't share the
> > version changes properly with your public?
> 
> I don't understand what you mean.  Version control is useful to any
> developer.  Our version control system is open to the public, so they
> can always have the latest source code.  We feel that this benefits
> both sides since users get new features and bug fixes quicker, and it
> is easier for others to contribute patches.  The use of, and the
> openness of, a version control system has little, if anything, to do
> with release management per se.  A good version control system can of
> course aid in making and maintaining releases through tagging,
> branching etc.
> 
Yes, I agree. But providing usable and stable sources to your intended
public - not being your co-developers - is not the same as opening up
your svn/git repositories.

> > So, I am pleased that the FFMPEG community is getting more mature and
> 
> We'd be pleased if you could spell FFmpeg correctly.
> 
> > finally accepts the idea that coding is one thing, communications is a
> > whole different ball game preferably left to people who have learned how
> > to communicate with none-developers albeit (sometimes) seasoned
> > engineers.
> 
> An engineer who doesn't do development at some level is no engineer.
> 
> > As a old-time developer myself I feel that you can't just output sources
> 
> You can't stop calling on your "vast" experience to prove your points,
> can you?
Can you? My point is that I know this engineering world but have grown
beyond it and thus understand that no matter how good one can be at a
given taks, it all boils down being able to effectively communicate.

> 
> > to the public as is. You have a (morale) obligation to make sure that
> > your code is correct and relatively stable.
> 
> We have no obligations whatsoever, moral or otherwise.  Our license
> terms make that quite clear.  If you do not agree to those terms,
> please do not use our code.
Hm, truly spoken as an engineer without to much contacts to the real
world. My opinion: if you don't care about your public, hush up and stay
in your dark corner inventing/developing the marbles others can use. Let
PR in the hands of those who do care.

> 
> > This means, any API/ABI change MUST be communicated between
> > developers as well as your public.
> 
> Yes, when the header files change, there has been a change.
> 
> > Speaking of your public, what better way than to use releases in a
> > form of completed Tar files? Just let developers use the git
> > repositories as intended, and the rest of us can use Tar file.
> 
> The tar files are already there, updated every night.  Is there
> something wrong with them?
That the Tar files incorporate accepted but not well tested changes
also, simply because they are a reflection of the current repository and
do not represent a 'properly released' product.

Mr. Mans, I have seen many mailings of you. I think you are a good
engineer, but please leave the communication with none-developers to
others. In fact, I think, people like you might hurt the FFmpeg
community because of your not so eloquent way of communication.

Thanks anyhow for your remarks,
Frans.