Re: [stan-users] Stan v1.3 manual - typo

[Bob Carpenter]

What should our process be for this? It seems VERY
heavy to have to create a pull request to fix a single
typo, yet I don't want to pile them into other pull requests
like riders on a bill in congress.

Also, I'd like to make sure we don't forget to add people
to the acknowledgments section that send us typo corrections
and patches.

Thanks.

- Bob

On 6/17/13 1:27 PM, Daniel Lee wrote:
> Sean, thanks for letting us know. I'll get it fixed.
>
>
> Daniel
>
>
>
> On Mon, Jun 17, 2013 at 9:56 AM, Sean O'Riordain <seor...@tcd.ie <mailto:seor...@tcd.ie>> wrote:
>
> I can't see at the moment if it has already been fixed, but on page 56 of the Stan manual v1.3 the word
> "discimrinativess" on the last line of the page (in Section 11.8) could well be a typo...
>
> Kind regards,
>
> Sean O'Riordain
> seor...@tcd.ie <mailto:seor...@tcd.ie>
>
>
> --
> You received this message because you are subscribed to the Google Groups "stan users mailing list" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to
> stan-users+...@googlegroups.com <mailto:stan-users%2Bunsu...@googlegroups.com>.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
> --
> You received this message because you are subscribed to the Google Groups "stan users mailing list" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to stan-users+...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Marcus Brubaker]

On Mon, Jun 17, 2013 at 5:11 PM, Bob Carpenter <ca...@alias-i.com> wrote:

What should our process be for this?  It seems VERY
heavy to have to create a pull request to fix a single
typo, yet I don't want to pile them into other pull requests
like riders on a bill in congress.

I've been thinking about this as well.  I think it might make sense to always have a running feature branch with routine manual corrections/updates which everyone can commit to more or less free form.  This branch would then get merged either periodically, or prior to a release.

This would be distinct from changes that are meant to accompany features which I think should be in their respective feature branches.

Cheers,

Marcus

[Daniel Lee]

I would prefer to have pull requests. All that needs to be done is to state in one of the comments that the manual has been built and that's that.

If you can fix multiple typos at once, that's fine, but I don't care if we end up with one pull request per typo. As of now, pull requests aren't backing up due to the process taking too long. They're backing up because I missed the fact that our build was broken (misconfiguration of Jenkins and pull requests not actually being tested by the ones submitting them).

--
You received this message because you are subscribed to the Google Groups "stan development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to stan-dev+u...@googlegroups.com.

[Bob Carpenter]

On 6/17/13 5:43 PM, Daniel Lee wrote:
> I would prefer to have pull requests.

OK. I'd rather have you decide because you're doing all the work!

> All that needs to be done is to state in one of the comments that the manual has
> been built and that's that.

What I was whinging on about is that I can't remember
how to do a pull request or branch, so every time I have
to pull out or doc and follow it. And I still never figured
out how to remove the merge bubbles, so I don't even know
if I'm doing the right thing with merges from develop.

Maybe you could fix our doc to indicate the right thing to do
to get rid of or work with the merge bubbles? Should I just
be pushing them? Or is there something to do to control
fast forwards? (If so, could you write it into the Wiki? I
know you explained it on e-mail, but I couldn't quite follow
the explanation then got distracted.)

> If you can fix multiple typos at once, that's fine, but I don't care if we end up with one pull request per typo. As of
> now, pull requests aren't backing up due to the process taking too long. They're backing up because I missed the fact
> that our build was broken (misconfiguration of Jenkins and pull requests not actually being tested by the ones
> submitting them).

I'm just finding all the traffic about testing and
what-not very hard to follow, so I just ignore most of it.
As such, it adds noise to the signal I'm getting about the
state of our system, the sum total of which is that I'm
pretty confused about where we're at. I'm sure I'll eventually
get the hang of it so it doesn't feel so clunky.

- Bob

[Daniel Lee]

On Mon, Jun 17, 2013 at 5:51 PM, Bob Carpenter <ca...@alias-i.com> wrote:

On 6/17/13 5:43 PM, Daniel Lee wrote:

I would prefer to have pull requests.

OK.  I'd rather have you decide because you're doing all the work!

All that needs to be done is to state in one of the comments that the manual has
been built and that's that.

What I was whinging on about is that I can't remember
how to do a pull request or branch, so every time I have
to pull out or doc and follow it.  And I still never figured
out how to remove the merge bubbles, so I don't even know
if I'm doing the right thing with merges from develop.

Maybe you could fix our doc to indicate the right thing to do
to get rid of or work with the merge bubbles?  Should I just
be pushing them?  Or is there something to do to control
fast forwards?  (If so, could you write it into the Wiki?  I
know you explained it on e-mail, but I couldn't quite follow
the explanation then got distracted.)

Will do. I'll put something up on the Wiki.

 

If you can fix multiple typos at once, that's fine, but I don't care if we end up with one pull request per typo. As of
now, pull requests aren't backing up due to the process taking too long. They're backing up because I missed the fact
that our build was broken (misconfiguration of Jenkins and pull requests not actually being tested by the ones
submitting them).

I'm just finding all the traffic about testing and
what-not very hard to follow, so I just ignore most of it.
As such, it adds noise to the signal I'm getting about the
state of our system, the sum total of which is that I'm
pretty confused about where we're at.  I'm sure I'll eventually
get the hang of it so it doesn't feel so clunky.

Yes, I'll document what happens with the interaction between Jenkins and GitHub with our pull request builder. I think I understand the interaction well enough to doc it. I'll throw that up on the Wiki too.

Daniel