Re: Thoughts about DEVELOPERS.md WAS: [travis-ci - fvwm.git master branch is "protected"]

2016-03-25 Thread Thomas Funk 
"Thomas Adam"  wrote:
> On Fri, Mar 25, 2016 at 12:25:09PM +0100, Thomas Funk wrote:
> > I think we should. It's better to have such in the documentation so no
> > questions appears anymore ;)
> > 
> > I can add it to the document, no prob.
> 
> I've added a few words about this, without making this a rule, which
> hopefully people will follow.

That's fine, thanks.

> 
> -- Thomas Adam
> 
> -- 
> "Deep in my heart I wish I was wrong.  But deep in my heart I know I am
> not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.)
> 
>

Re: Thoughts about DEVELOPERS.md WAS: [travis-ci - fvwm.git master branch is "protected"]

2016-03-25 Thread Thomas Adam 
On Fri, Mar 25, 2016 at 12:25:09PM +0100, Thomas Funk wrote:
> I think we should. It's better to have such in the documentation so no
> questions appears anymore ;)
> 
> I can add it to the document, no prob.

I've added a few words about this, without making this a rule, which
hopefully people will follow.

-- Thomas Adam

-- 
"Deep in my heart I wish I was wrong.  But deep in my heart I know I am
not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.)

Re: Thoughts about DEVELOPERS.md WAS: [travis-ci - fvwm.git master branch is "protected"]

2016-03-25 Thread Thomas Funk 
"Thomas Adam"  wrote:
> On Fri, Mar 25, 2016 at 03:30:03AM +0100, Thomas Funk wrote:
> > One point:
> > Should we use for development branches a special nomination like 
> > feature_xy, fix_abc?
> > Or only a README which describes the feature/fix?
> 
> I don't think that's necessary.  Typically, you have this pattern:
> 
> initials/rough-branch-description
> 
> Which denotes---by the initials---who's mainly working on the branch,
> so for example:
> 
> ta/fix-clang-warnings
> 
> Should denote that I am working on a branch which fixes warnings from
> Clang.  Similarly, there's also "git branch --edit-description" which
> can further annotate a branch, usually more helpful when issuing
> pull-requests.
> 
> Perhaps in a more wider-context, if a branch ends up not having a
> prefix, it might mean more than one person is working on it.
> 
> But I don't think this really needs documenting.

I think we should. It's better to have such in the documentation so no
questions appears anymore ;)

I can add it to the document, no prob.

> 
> > To think about this point: 
> > http://nvie.com/posts/a-successful-git-branching-model/
> 
> Hmm.  I have always been against this design---this is what lead to the
> whole git-flow set of tooling, which completely locks you in to one way
> of working.  We really do not need anything as complicated as that.

Ok.

> 
> -- Thomas Adam
> 
> -- 
> "Deep in my heart I wish I was wrong.  But deep in my heart I know I am
> not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.)
> 
>

Thoughts about DEVELOPERS.md WAS: [travis-ci - fvwm.git master branch is "protected"]

2016-03-24 Thread Thomas Funk 
"Thomas Adam"  wrote:
> I was thinking along the lines of this diff:
> 
> https://github.com/fvwmorg/fvwm/commit/f81b2f4d7412813f12b235d8f1914409da0bbae9.patch
> 
> Which you can view rendered here:
> 
> https://github.com/fvwmorg/fvwm/blob/ta/git-docs/docs/DEVELOPERS.md
> 
> What do others think?

Thanks Thomas! It is really good and detailed instruction.

One point:
Should we use for development branches a special nomination like feature_xy, 
fix_abc?
Or only a README which describes the feature/fix?

To think about this point: 
http://nvie.com/posts/a-successful-git-branching-model/

-- Thomas --

Re: travis-ci - fvwm.git master branch is "protected"

2016-03-24 Thread Thomas Adam 
On Thu, Mar 24, 2016 at 05:48:55PM +0100, Viktor Griph wrote:
> Cool. Would it be possible to stick some unit test framework to it as well?

Sorry, Viktor, I missed this point the last time round.  Yes, that's
possible, and depending on how we decide to write unit tests, it can
just hook into the Travis configuration.  This isn't something I'm
wanting to look at myself just yet, but feel free to do so!

> Is our strategy for handling of branches and pull requests summarized
> anywhere?

I was thinking along the lines of this diff:

https://github.com/fvwmorg/fvwm/commit/f81b2f4d7412813f12b235d8f1914409da0bbae9.patch

Which you can view rendered here:

https://github.com/fvwmorg/fvwm/blob/ta/git-docs/docs/DEVELOPERS.md

What do others think?

-- Thomas Adam

-- 
"Deep in my heart I wish I was wrong.  But deep in my heart I know I am
not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.)

Re: travis-ci - fvwm.git master branch is "protected"

2016-03-24 Thread Viktor Griph 
Den 24 mar 2016 5:22 em skrev "Thomas Adam" :
>
> Hi all,
>
> I've to document this formally, but I wanted to let you know of a few
options
> I've enabled for the "master" branch on the main fvwm Git repository.
>
> All pushes by default (across all branches) will now have Travis CI ran
> against them.  Travis is a Continuous Integration tool[1] which allows the
> code to be compiled.  If there's any errors, an email is sent out
indicating
> where the logs can be found[2].

Cool. Would it be possible to stick some unit test framework to it as well?

> Additionally, the master branch (which is where all the stable code
intended
> for releases ends up) now has protection enabled, which means code will
not be
> merged there by default, should Travis CI be unable to build it.  This
should
> help things be more robust, and provides a much more powerful alternative
to
> the old snapshot mechanisms of yesteryear.  This also means commits
directly
> on master are discouraged---but that's OK because we've discussed that
before.

Is our strategy for handling of branches and pull requests summarized
anywhere?

/Viktor

Re: travis-ci - fvwm.git master branch is "protected"

2016-03-24 Thread Thomas Adam 
On Thu, Mar 24, 2016 at 05:48:55PM +0100, Viktor Griph wrote:
> Is our strategy for handling of branches and pull requests summarized
> anywhere?

I'm working on that.  Will put that out for tenure later on today.

-- Thomas Adam

travis-ci - fvwm.git master branch is "protected"

2016-03-24 Thread Thomas Adam 
Hi all,

I've to document this formally, but I wanted to let you know of a few options
I've enabled for the "master" branch on the main fvwm Git repository.

All pushes by default (across all branches) will now have Travis CI ran
against them.  Travis is a Continuous Integration tool[1] which allows the
code to be compiled.  If there's any errors, an email is sent out indicating
where the logs can be found[2].  Note that I've set up a matrix job, which
means that _both_ GCC and clang builds have to succeed in order for a build to
be successful.  Over the last few years, I've found clang/LLVM to often give
better indications of problems than GCC, hence why I've enabled both.

Additionally, the master branch (which is where all the stable code intended
for releases ends up) now has protection enabled, which means code will not be
merged there by default, should Travis CI be unable to build it.  This should
help things be more robust, and provides a much more powerful alternative to
the old snapshot mechanisms of yesteryear.  This also means commits directly
on master are discouraged---but that's OK because we've discussed that before.

Any questions, do please let me know.

[1] https://travis-ci.org/
[2] https://travis-ci.org/fvwmorg/fvwm/builds