Re: prominent message on website about "use only on

Thomas Orgis <[email protected]> Tue, 1 Aug 2017 11:58:51 +0200
Newsgroups gmane.comp.audio.mp3.lame
Message-ID <20170801115851.6e58b92c@sturbolzen>
Disclaimer: Pointless ranting about revision control systems where
discussion about technical issues is demanded. You may skip reading
this mail if you are short on time and not in it for the fun of it;-)

Am Tue, 1 Aug 2017 11:27:18 +0200
schrieb "Fabian Greffrath" <[email protected]>: 

> I tend to disagree here! GIT has become so popular exactly because it
> makes it so easy to start contributing: You clone a repo, create a branch,
> commit your changes and push them.

It only really became easy enough with github. Plain git needs you to
get the mental image of all the stuff happening behind the scenes to
survive your first merge conflict (then you're off haunting
stackoverflow for the magic incanations to fix things). The one thing I
really miss in Subversion is offline commits … which are in the
pipeline since some time now. Some local messing with history since
last commit (push) is indeed valuable, but I really like my official
history being monotonic and unchanging unless some real effort is
excerted (dump, mangle, re-create repo).

> For me, the sheer prospective of having to fight around with CVS causes me
> to not even check out the repo and move along to another project instead.

Not trying to insult you personally, but I think it is sad that someone
who actually has the ability to work on Lame code (which needs more
skill than your average web framework) should already give up at the option of

a) Doing the CVS dance. Just copy the lines mentioned under ‘getting the
   source code’. Edit. do `cvs diff > my.patch` and attach the patch to a
   mail or

b) Just grabbing the source tarball (e.g. from the debian src package),
   edit, diff for a patch, send patch.

But yes, it is a fact that CVS is a barrier for people who only know
git. And one might attract more (good?) developers if switching from
it. But even then, what Lame needs is a cleanup of the current
situation (not sexy, not for newcomers) and after that mainly dutiful
maintenance (boring). Is there big new functionality expected? Are we
adding MP3 surround which nobody uses? I entertain the idea that Lame
is basically finished apart from bug fixes. You might want to add
intensity stereo coding for completeness sake (I had to hunt down
mp3enc in an old VM to get those sample files for libmpg123), but how
much is there to play around and get exited about?

In the end there will be about one person doing the job, and it's of
course fine that this person eventually migrates the tools to what
suits them. Who does the work does the calls.

If someone has scientific ideas about a new psy model, that's so
involved that I have a hard time imagining that having to learn
$ANY_RCS_TOOL is a serious barrier above that.

To get back to the point: I will hack libmpg123 usage into lame over
the weekend, hopefully. I plan to also dig into mp3x to get mpglib
truly replaced. I will then do a `cvs diff` and send the resulting
patch to this list, the traditional way.


Alrighty then,

Thomas
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Lame-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/lame-dev