Is there a release process?

["John D. Ament" <jo...@apache.org>]

Maybe I'm missing something, but is there some kind of release process for
pony mail? Or even a build process?  Might be good to test that out.

John

Re: Is there a release process?

[Ulises <ul...@gmail.com>]

I suspect it depends on what's meant by lower level tests.

As for UI tests (ala selenium, etc.) I cannot be more +1 on this. However,
before this, we'd have to have the ability to spin up a PM instance with
data so that we could test these things. Nothing earth shattering there,
just time consuming.

Bonus side effect would be that _if_ we ran the tests against a docker PM
image, we could even offer that one as a quick sandbox for people to toy
with PM.

U

On Sun, 10 Jul 2016 at 18:52 Daniel Gruno <hu...@apache.org> wrote:

> On 07/10/2016 07:36 PM, John D. Ament wrote:
> > On Sun, Jul 10, 2016 at 1:18 PM Daniel Gruno <hu...@apache.org>
> wrote:
> >
> >> On 07/10/2016 04:31 PM, John D. Ament wrote:
> >>> Maybe I'm missing something, but is there some kind of release process
> >> for
> >>> pony mail? Or even a build process?  Might be good to test that out.
> >>>
> >>> John
> >>>
> >>
> >> The software does not require anything to be built (other than some
> >> JavaScript files to be concatenated, which I regularly do as part of the
> >> development cycle), so no, there's no build process per se. To release,
> >> one simply bundles the appropriate branch and crosses ones fingers :).
> >>
> >>
> > mmm ok.
> >
> >
> >> Likewise with testing, it's about interacting with the software. the
> >> vast majority of it is a javascript UI library, which makes it nigh
> >> impossible to write tests for it. It's mostly about the look and feel
> >> and response to (mostly) random user events.
> >>
> >
> > We should consider looking into grunt/gulp/karma/jasmine to do some UI
> > testing.  I agree that this is the bulk of the app, but that's the case
> > these days.  It would be awesome to have ponymail as an npm module or
> > something like that.
> >
>
> Interesting - I hope to be able to look into this when I have some spare
> cycles.
>
> >
> >>
> >> I suggest people familiarize themselves with the INSTALL document, which
> >> should explain in detail how to get things up and running.
> >>
> >
> > I'm assuming you mean this one:
> > https://github.com/apache/incubator-ponymail/tree/master/docs
> >
> >
> >
> >>
> >> For the server-side of things, you can test by importing archives in
> >> bulk (for instance, from mod_mbox or an mbox archive file) and then
> >> browse the resulting contents. The best unit test I've come accross was
> >> importing the entire ASF archive, though that can take a few days :)
> >>
> >> It should be possible, Docker aside, to write an auto-installer of the
> >> system for quick tests (setup.py accepts being auto-configured), but I
> >> haven't written a FLOSS version of that myself yet.
> >>
> >
> > These solutions all sound like purely integration/f-tests.  I'd still
> like
> > to see some lower level tests.  Does ponymail take care of the importing
> of
> > archives to ES?
>
> Yes it does, that is usually the chief source of my tests - importing
> and seeing if the imports _work_ as intended. There are two ways of
> importing, either by loading old archives with import-mbox.py or by
> live-archiving via archiver.py. both have a --help command line option
> for more details, and are documented in the install docs.
>
> I don't think there's a single soul wanting fewer tests ;) You are most
> welcome to get started on low level tests if you like, though I am
> personally unsure how one would go about doing this.
>
> With regards,
> Daniel.
>
> >
> >
> >>
> >> If there is a specific interest in having a test environment, we could
> >> request a VM for this, where the podling members can try out an
> >> instance, although one might just as well get a cheap VPS box
> somewhere...
> >>
> >> With regards,
> >> Daniel.
> >>
> >
>
>

Re: Is there a release process?

[Daniel Gruno <hu...@apache.org>]

On 07/10/2016 07:36 PM, John D. Ament wrote:
> On Sun, Jul 10, 2016 at 1:18 PM Daniel Gruno <hu...@apache.org> wrote:
> 
>> On 07/10/2016 04:31 PM, John D. Ament wrote:
>>> Maybe I'm missing something, but is there some kind of release process
>> for
>>> pony mail? Or even a build process?  Might be good to test that out.
>>>
>>> John
>>>
>>
>> The software does not require anything to be built (other than some
>> JavaScript files to be concatenated, which I regularly do as part of the
>> development cycle), so no, there's no build process per se. To release,
>> one simply bundles the appropriate branch and crosses ones fingers :).
>>
>>
> mmm ok.
> 
> 
>> Likewise with testing, it's about interacting with the software. the
>> vast majority of it is a javascript UI library, which makes it nigh
>> impossible to write tests for it. It's mostly about the look and feel
>> and response to (mostly) random user events.
>>
> 
> We should consider looking into grunt/gulp/karma/jasmine to do some UI
> testing.  I agree that this is the bulk of the app, but that's the case
> these days.  It would be awesome to have ponymail as an npm module or
> something like that.
> 

Interesting - I hope to be able to look into this when I have some spare
cycles.

> 
>>
>> I suggest people familiarize themselves with the INSTALL document, which
>> should explain in detail how to get things up and running.
>>
> 
> I'm assuming you mean this one:
> https://github.com/apache/incubator-ponymail/tree/master/docs
> 
> 
> 
>>
>> For the server-side of things, you can test by importing archives in
>> bulk (for instance, from mod_mbox or an mbox archive file) and then
>> browse the resulting contents. The best unit test I've come accross was
>> importing the entire ASF archive, though that can take a few days :)
>>
>> It should be possible, Docker aside, to write an auto-installer of the
>> system for quick tests (setup.py accepts being auto-configured), but I
>> haven't written a FLOSS version of that myself yet.
>>
> 
> These solutions all sound like purely integration/f-tests.  I'd still like
> to see some lower level tests.  Does ponymail take care of the importing of
> archives to ES?

Yes it does, that is usually the chief source of my tests - importing
and seeing if the imports _work_ as intended. There are two ways of
importing, either by loading old archives with import-mbox.py or by
live-archiving via archiver.py. both have a --help command line option
for more details, and are documented in the install docs.

I don't think there's a single soul wanting fewer tests ;) You are most
welcome to get started on low level tests if you like, though I am
personally unsure how one would go about doing this.

With regards,
Daniel.

> 
> 
>>
>> If there is a specific interest in having a test environment, we could
>> request a VM for this, where the podling members can try out an
>> instance, although one might just as well get a cheap VPS box somewhere...
>>
>> With regards,
>> Daniel.
>>
> 

Re: Is there a release process?

["John D. Ament" <jo...@apache.org>]

On Sun, Jul 10, 2016 at 1:18 PM Daniel Gruno <hu...@apache.org> wrote:

> On 07/10/2016 04:31 PM, John D. Ament wrote:
> > Maybe I'm missing something, but is there some kind of release process
> for
> > pony mail? Or even a build process?  Might be good to test that out.
> >
> > John
> >
>
> The software does not require anything to be built (other than some
> JavaScript files to be concatenated, which I regularly do as part of the
> development cycle), so no, there's no build process per se. To release,
> one simply bundles the appropriate branch and crosses ones fingers :).
>
>
mmm ok.


> Likewise with testing, it's about interacting with the software. the
> vast majority of it is a javascript UI library, which makes it nigh
> impossible to write tests for it. It's mostly about the look and feel
> and response to (mostly) random user events.
>

We should consider looking into grunt/gulp/karma/jasmine to do some UI
testing.  I agree that this is the bulk of the app, but that's the case
these days.  It would be awesome to have ponymail as an npm module or
something like that.


>
> I suggest people familiarize themselves with the INSTALL document, which
> should explain in detail how to get things up and running.
>

I'm assuming you mean this one:
https://github.com/apache/incubator-ponymail/tree/master/docs



>
> For the server-side of things, you can test by importing archives in
> bulk (for instance, from mod_mbox or an mbox archive file) and then
> browse the resulting contents. The best unit test I've come accross was
> importing the entire ASF archive, though that can take a few days :)
>
> It should be possible, Docker aside, to write an auto-installer of the
> system for quick tests (setup.py accepts being auto-configured), but I
> haven't written a FLOSS version of that myself yet.
>

These solutions all sound like purely integration/f-tests.  I'd still like
to see some lower level tests.  Does ponymail take care of the importing of
archives to ES?


>
> If there is a specific interest in having a test environment, we could
> request a VM for this, where the podling members can try out an
> instance, although one might just as well get a cheap VPS box somewhere...
>
> With regards,
> Daniel.
>

Re: Is there a release process?

[Daniel Gruno <hu...@apache.org>]

On 07/10/2016 04:31 PM, John D. Ament wrote:
> Maybe I'm missing something, but is there some kind of release process for
> pony mail? Or even a build process?  Might be good to test that out.
> 
> John
> 

The software does not require anything to be built (other than some
JavaScript files to be concatenated, which I regularly do as part of the
development cycle), so no, there's no build process per se. To release,
one simply bundles the appropriate branch and crosses ones fingers :).

Likewise with testing, it's about interacting with the software. the
vast majority of it is a javascript UI library, which makes it nigh
impossible to write tests for it. It's mostly about the look and feel
and response to (mostly) random user events.

I suggest people familiarize themselves with the INSTALL document, which
should explain in detail how to get things up and running.

For the server-side of things, you can test by importing archives in
bulk (for instance, from mod_mbox or an mbox archive file) and then
browse the resulting contents. The best unit test I've come accross was
importing the entire ASF archive, though that can take a few days :)

It should be possible, Docker aside, to write an auto-installer of the
system for quick tests (setup.py accepts being auto-configured), but I
haven't written a FLOSS version of that myself yet.

If there is a specific interest in having a test environment, we could
request a VM for this, where the podling members can try out an
instance, although one might just as well get a cheap VPS box somewhere...

With regards,
Daniel.