Re: [Openbts-discuss] (new release organization etc.)

[Kurtis H. <khe...@cs...>]

I agree with all of this, but I'd say that #2 is met by git-svn as
well. I don't think we'll need active branches in the repository, as
we can individually publish the modified git repositories (as thomas
has on multiple occasions). These can be linked on the wiki for those
wishing to try out the new features.

On Tue, Nov 1, 2011 at 3:39 AM, Andrew Gordon <op...@ar...> wrote:
> On Mon, 31 Oct 2011, Kurtis Heimerl wrote:
>>
>> First, I'm going to discontinue most of the tarball releases. The
>> public release should be retrieved primarily through direct access to
>> the repository. This will keep me (and the other developers) honest,
>> as well as provide every user the best, most current release. Tarballs
>> will still be available for major releases, but that will mostly be
>> for archival purposes and not for most users.
>>
>> ... and more...
>
> There have been various replies commenting on what you are proposing, but
> the discussion risks getting tied up in the details of the tools, when (IMO)
> the problem is actually one of trying to squeeze several different functions
> into one place.  If it is clear how each function is achieved, then the
> exact choice of tool is less important.
>
> I think the project needs:
>
> 1) A place for newcomers to download something that is expected to work to a
> known level of functionality: both to ensure that newcomers have a good
> experience, and so that when they ask for help on the mailing list, everyone
> understands what version it is and what it is expected to do. There's even
> some advantage in being marginally out-of-date from that point of view.
>
> 2) A place where the latest (finished) developments are distributed - the
> starting point for anybody adding new work, and the place they commit their
> work back to when finished.  With the best will in the world, this can't be
> the same as 1) - if you try to demand perfection, there's a catch 22 in that
> a change won't be fully tested until it has been tried in setups unrelated
> to the reason it was developed, and people running those setups won't run
> changes they have no particular interest in until those changes are part of
> the general distribution.
>
> 3) A mechanism for developers collaborating on new features to share
> incomplete code for review and early testing (and to make such work visible
> to avoid duplication of effort).
>
>
> The traditional tarball releases usually satisfy requirement 1), but it
> could equally be a tag/branch in the repository as you suggest - just not
> the same one as requirement 2).
>
> Requirement 2) is obviously met by a branch in the repository - whether this
> is the HEAD and the more stable releases are a side branch or vice-versa is
> fairly arbitrary.
>
> Requirement 3) can be met by private git-svn repositories if there's a
> reason not to have this work as branches in the main repository, though it's
> helpful to have them visible/advertised by the project.
>
>
>
> [note: I'm aware that I am not an active contributor to this project - just
> posting the above in the hope that it's helpful to the discussion]
>