[FFmpeg-devel] release work
Frans de Boer
Sun Feb 1 04:25:38 CET 2009
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,
More information about the ffmpeg-devel