Merging 5.8-dev into master is next

[Edward K. Ream]

Please hold commits into master for just a bit longer.

Edward

[Edward K. Ream]

On Tuesday, February 27, 2018 at 11:02:02 AM UTC-6, Edward K. Ream wrote:

Please hold commits into master for just a bit longer.

I have just deleted the 5.8-dev branch.  The master branch is now open.

Feel free to create branches as needed for your own projects.

Edward

[Matt Wilkie]

Please hold commits into master for just a bit longer.

I have just deleted the 5.8-dev branch.  The master branch is now open.

Feel free to create branches as needed for your own projects.

Would it be easier to invert the process, and have dedicated releases branches and then master never needs to be frozen?  That seems more logical to me (but I'm not that branch savvy, probably missing something).

matt

[Edward K. Ream]

On Tue, Feb 27, 2018 at 2:19 PM, Matt Wilkie <map...@gmail.com> wrote:

Would it be easier to invert the process, and have dedicated releases branches and then master never needs to be frozen?

​Anything is possible, but I don't see how doing all the work outside of master is any improvement.  At some point we have to freeze something. Furthermore, the scheme you suggests seems to make master almost irrelevant, which does not seem reasonable.

Edward

[Terry Brown]

I think what you suggest is probably more common. master is sort of
the "~finished work being tested" branch, and new features are
developed in feature branches, which are merged into master when
they're ready. Then when a release is desired, a release branch is
made from master and then that's tested / packaged etc. Then after the
release I suppose you merge the release branch back into master,
although not much may have changed in that sense.

But at the end of the day whatever works works, someone who wants to
keep pushing their work to the main repo. can always use a feature
branch while master's closed. I guess currently master is
effectively being used as a release branch.

Cheers -Terry

[Terry Brown]

On Tue, 27 Feb 2018 14:36:08 -0600
"Edward K. Ream" <edre...@gmail.com> wrote:

> On Tue, Feb 27, 2018 at 2:19 PM, Matt Wilkie <map...@gmail.com> wrote:
>
> Would it be easier to invert the process, and have dedicated releases
> > branches and then master never needs to be frozen?
>
> ​Anything is possible, but I don't see how doing all the work outside
> of master is any improvement. At some point we have to freeze

> *something*. Furthermore, the scheme you suggests seems to make

> master almost irrelevant, which does not seem reasonable.
>
> Edward

I think with the release branch approach master is the place for
finished projects being tested, sort of what it is now, it's just that
instead of people having to switch between "ok to use master" and "not
ok to use master", it's always ok to use master - all you have to do
is not put new breaky stuff in the release branch, which no one
would do by accident anyway.

Cheers -Terry

[Edward K. Ream]

On Tue, Feb 27, 2018 at 3:41 PM, Terry Brown wrote:

I think with the release branch approach master is the place for
finished projects being tested, sort of what it is now, it's just that
instead of people having to switch between "ok to use master" and "not
ok to use master", it's always ok to use master - all you have to do
is not put new breaky stuff in the release branch, which no one
would do by accident anyway.

​I like this approach. The difference is that people aren't supposed to push to the release branch, which is less restrictive than not pushing to master. Pushing to a release branch is also less likely to happen by accident.  And having a separate release branch is the natural place for all release-related commits.

I'll use this for all future releases.

Edward

[Marcel Franke]

 The usual way to do this today:

master as stable.
develop as unstable.
release as pre-stable.

Everthing new comes from develop and goes to develop.

When you prepare a new release you branch "develop" to "release", are doing your tests and patches on it. When everything is finished, you merge "release" to "master" and(!) "develop" (when you patched something in "relase"). Then optionally delete "release" to start fresh on the next release. And now you pull all your stuff for the world from "master".

Nobody except the maintainer is supposed to work on "release" or "master", so nobody needs to hold back or knows what is going on in them. Everyone can be happyly hacking on "develop", and live with the stablity from "master".

Some visualisation of it:  https://blog.seibert-media.net/wp-content/uploads/2014/03/Gitflow-Workflow-3.png

[Edward K. Ream]

On Wed, Feb 28, 2018 at 3:39 AM, 'Marcel Franke' via leo-editor <leo-e...@googlegroups.com> wrote:

 The usual way to do this today:

master as stable.
develop as unstable.
release as pre-stable.

Some visualization of it:  https://blog.seibert-media.net/wp-content/uploads/2014/03/Gitflow-Workflow-3.png

​It's a nice visualization. It's easy to see why it's a popular model.

However, Leo's master branch is stable enough for daily use, despite being the target of all development. The point, imo, of pulling master is too get bleeding edge stuff.

Edward

[Marcel Franke]

 The purpose is seperation of responsability, decoupling of processes and enforcing more repitation to get better control of code.

It doesn't matter how stable or unstable develop-branch becomes, but master has to be stable and reliable all the time, always. It's the version you sell to the customer, the front that delivers the product. If you fuck up something in develop, it doesn;t matter for the customer, because they use stable. If someone brings in harmful code, it's doesn't matter, because nobody is supposed to have access to master except the maintainer, and he reviews and knows everything that goes in master and should see the harmful code. Additionally because everything should be already reviewed when being merged to develop, with the review of the release-code you make a second review. But this time it's a release-wide review, a more global view you could say, compared to the more local review of a featuer-merge. The reviewer is able to see how the differnt seperate features fit together, and simply makes a second run on the code. It doesn't matter how stable you think your code is, or how good of a coder you are, testing things multiple times always enhances quality because you iterate the code now with the knowledge you gained from previous reviews and all development that happend in the meanwhile. And of course, as a human you always miss something because nobody is perfect all the time.

For any mildly complex project a proper wokflow is neccessary to not drift into low quality and building technical debt.

[Edward K. Ream]

On Wed, Feb 28, 2018 at 4:21 AM, 'Marcel Franke' via leo-editor <leo-e...@googlegroups.com> wrote:

It doesn't matter how stable or unstable develop-branch becomes, but master has to be stable and reliable all the time, always.

​I can understand why organizations might adopt this point of view.

To my knowledge, having Leo's master be the bleeding edge has never caused anyone significant problems.

Edward

[Kent Tenney]

Although the Leo way is working, it might be advantageous  to

adopt what has become standard, making potential contributers

more comfortable: working on a develop branch instead of master.

Along these lines, issuing pull requests instead of pushing is a

good way for changes to be vetted.

I was interested to see that Jim Fulton issues pull requests for

his changes to his own code base, allowing users to see what

he is up to.

Certainly hard to know the cost/benefit of any of this stuff.

--
You received this message because you are subscribed to the Google Groups "leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscribe@googlegroups.com.
To post to this group, send email to leo-e...@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

[Edward K. Ream]

On Wed, Feb 28, 2018 at 9:34 AM, Kent Tenney <kte...@gmail.com> wrote:

Although the Leo way is working, it might be advantageous  to

adopt what has become standard, making potential contributors

more comfortable: working on a develop branch instead of master.

Along these lines, issuing pull requests instead of pushing is a

good way for changes to be vetted.

I was interested to see that Jim Fulton issues pull requests for

his changes to his own code base, allowing users to see what

he is up to.

Certainly hard to know the cost/benefit of any of this stuff.

​Thanks for these comments.  For now I'd like things to remain as they are.  The "standard" work flow is certainly reasonable for larger groups of programmers.

Also, I don't understand how we tell people to get bleeding edge code if master is stodgy.

Any other comments?

Edward

[Matt Wilkie]

Any other comments?

Just that I'm grateful for all comments in the thread. It's helped me gain a little elevation :-)

matt

 

[Edward K. Ream]

On Thu, Mar 1, 2018 at 10:56 AM, Matt Wilkie <map...@gmail.com> wrote:

Just that I'm grateful for all comments in the thread. It's helped me gain a little elevation :-)

​So am I. I think the master/devel/feature organization​

 

​of work makes a lot of sense. I'm already wondering why we ever used the "commit everything into master" flow.

It's no big deal if someone pushes to master by mistake.  We would just merge master into devel, and revert master.

Edward