Re: [CORE] Restore-reliability mode

On Mon, Jun 8, 2015 at 12:14 PM, Geoff Winkless <pgsqladmin(at)geoff(dot)dj> wrote:

> On 8 June 2015 at 17:03, Claudio Freire <klaussfreire(at)gmail(dot)com> wrote:
>
>> It's not about the 5 minutes of compile time, it's about the signalling.
>>
>> Just *when* is git ready for testing? You don't know from the outside.
>>
>> I do lurk here a lot and still am unsure quite often.
>>
>> Even simply releasing an alpha *tarball* would be useful enough. What
>> is needed is the signal to test, rather than a fully-built package.
>>
>
> ​I can see that, and can absolutely get behind the idea of a nightly being
> flagged as an alpha, since it should involve next to no developer time.
>
>
​Nightly where? This is an international community.

The tip of the master branch is the current "alpha" - so the question is
whether a tar bundle should be provided instead of asking people to simply
keep their Git clone up-to-date. These both have the flaw of excluding
people who would test the application if it could simply be installed like
any other package on their system. But I'm not seeing where there would be
a huge group of people who would test an automatically generated source
tar-ball but would not be willing to use Git. Or are we talking about a
non-source tar-ball?

Maybe packagers could be convinced to bundle up the master branch on a
monthly basis and simply call it Master-SNAPSHOT. No alpha, no beta, no
version number. I've never packaged before so I don't know but while the
project should encourage this as things currently standard the core project
is doing its job by ensuring that the tip of master is always in a usable
state.

Or, whenever a new patch release goes out packagers can also bundle up the
current master at the same time.

David J.