[gtkada] SVN

[John Marino]

On 7/4/2013 09:45, Emmanuel Briot wrote:
>> To be clear, a "release" in this context means a source tarball.
>> I'm not talking about providing executables.  So it's not a "huge
>> amount of work", it's making a branch of the trunk and creating an
>> official tarball from it.  I say this because it looks like we are
>> talking apples to oranges here.
>
> That's a very limited view. A release requires fully quality
> testing, it isn't just making a tar ball from any random source at
> any random date, of course.

This is the same testing that theoretically is already being done, the
only difference is that builds are based on release branches, not trunk. 
  After release, any future commits to the branch are verified bug 
fixes.  Once could either let users pull those fixes via SVN or 
periodically repackage them in a point release.

> I am sure the release team will be happy to learn they need
> training. I will stop participating in this thread which is becoming
> slightly aggressive, and not bringing any value to GtkAda users.

Of course, I did not say anything about the release team.  The previous 
threads said that exposing an additional SVN branch publicly was an 
overwhelming task.  The three possibilities is A) that's true B) it's 
not really true, but a way of excusing why not, or C) it shouldn't be 
difficult but for some reason the admin is challenged by it.  The 
"training" comment was addressing the possibility of C.

>> Obviously done, but it's working around some seriously
>> non-standard work practices.
>
> I doubt there are may companies for which it is standard to do *any*
> public release at all of their sources, let alone their svn.

Compare apples to apples.  When the source is open, its normally fully 
open.  Look at GCC.  It has had many releases, each on their own branch. 
Every GCC release branch from 4.6 and earlier is closed and no more 
commits will occur, yet they are still available from the repository.

And to be fair to companies that don't expose the repo at all but 
provide source tarballs, they still have the traditional periodic bug 
fix releases clearly based on branches.

This correspondence is not intended to be "aggressive".  somebody at 
adacore asked why people wanted the branches and I'm trying to tell you. 
  Only exposing the trunk is not at all common and really this should 
not be a surprise to Adacore.  Only exposing part of an open source 
project raises all sorts of questions, especially when it's trivial to 
expose all of it.

John