Further discussion about project organisation

[xor-gate]

I would like to followup on your comments of the pull request (PR #434) when it took me long time to make the windows MSYS build work again, as people have silently broken it in the past time.

Hi,

regarding the Windows support, let me know when the documentation is
updated and we will merge. Thanks for that !

It is good to add some support for continuous integration, but I do not
want
it to drive important decisions such as changing the project organization,
or
put constraints on the maintainers personal accounts.

I agree 100% it is bad to put constrains on personal accounts for integration with other services (continues integration, continues deployment). Hopefully you understand I want to take the project to a higher level for first-time users, and enhance the flow and documentation for older users. And give better support for contributions and issue tracking.

I completely understand you can not do this alone, and I highly appreciate you made me als collaborator and maintainer. Github organisations are made for this purpose and I already own a few which enhances collaboration.

To take the project to the next level with correct continues integration and binary releases I have the following suggestions:

• Continue development in github.com/stlink/stlink as I already created and have configured AppVeyor (windows) and Travis (linux/mac).

Or

• Leave github.com/texane/stlink as-is.
• Use github.com/stlink/stlink only for integration and releasing

The problem with approach two is that all the issues and pull-request will be resolved and merged into texane/master and I have to manually do everything in stlink/stlink.

With the first approach all the history, pull-requests and issues are transfered to stlink/stlink and you are also granted admin rights on the organisation stlink. And then you can revoke all your private access to 3th party integrations on your personal account.

@texane let me know what you think, and how you would like to continue.

[texane]

I have to think about it as it is an important decision for the project.

In the short term (ie. coming months), we will continue working in
texane/stlink. It includes the release process. If you want to use
stlink/stlink for CI purpose, that is fine.

2016-06-19 11:50 GMT+02:00 Jerry Jacobs [email protected]:

I would like to followup on your comments of the pull request when it took
me long time to make the windows MSYS build work again.

Hi,

regarding the Windows support, let me know when the documentation is
updated and we will merge. Thanks for that !

It is good to add some support for continuous integration, but I do not
want
it to drive important decisions such as changing the project organization,
or
put constraints on the maintainers personal accounts.

I agree 100% it is bad to put constrains on personal accounts for
integration with other services (continues integration, continues
deployment). Hopefully you understand I want to take the project to a
higher level for first-time users, and enhance the flow and documentation
for older users. And give better support for contributions and issue
tracking.

I completely understand you can not do this alone, and I highly appreciate
you made me als collaborator and maintainer. Github organisations are made
for this purpose and I already own a few which enhances collaboration.

To take the project to the next level with correct continues integration
and binary releases I have the following suggestions:

• Continue development in github.com/stlink/stlink as I already
  created and have configured AppVeyor (windows) and Travis (linux/mac).

Or

• Leave github.com/texane/stlink as-is.
• Use github.com/stlink/stlink only for integration and releasing

The problem with approach two is that all the issues and pull-request will
be resolved and merged into texane/master and I have to manually do
everything in stlink/stlink.

With the first approach all the history, pull-requests and issues are
transfered to stlink/stlink and you are also granted admin rights on the
organisation stlink. And then you can revoke all your private access to
3th party integrations on your personal account.

@texane https://github.com/texane let me know what you think, and how
you would like to continue.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#437, or mute the thread
https://github.com/notifications/unsubscribe/AAEeH9xWYLO3ktAN2MA9z1jNevfiewefks5qNREBgaJpZM4I5IYF
.

[xor-gate]

I understand it is not an easy decision, and in a few months we can reconsider how we want to continue. Because stlink/stlink is a fork of texane/stlink and I would not diverge development I will figure out a way how to keep it in-sync. Continues-integration is useless when I need to do everything by hand.

And as you have seen by PR #434 it took me more time than expected to make it work again on windows. I'm not fixing windows for myself, as I only use *nix, and OS X machines. And I would be very sad if in the meantime the windows build is broken again when there are pull-request contributions.

As you are aware of my rate of development and contributions, and funding by Dual Inventive. I would like not to get stuck when the tooling is not sufficient.

[texane]

I understand well what you say.

I am not against changing the project organization. In fact, I have thought
about it already, but decided it is not the right time yet. If we are still
the only
2 people in charge in the coming months, then we will discuss about the
project organization. It directly impacts the project long term directions,
so
it will discuss independent of technical/infrastructure matters.

2016-06-19 13:27 GMT+02:00 Jerry Jacobs [email protected]:

I understand it is not an easy decision, and in a few months we can
reconsider how we want to continue. Because stlink/stlink is a fork of
texane/stlink and I would not diverge development I will figure out a way
how to keep it in-sync. Continues-integration is useless when I need to do
everything by hand.

And as you have seen by PR #434
#434 it took me more time than
expected to make it work again on windows. I'm not fixing windows for
myself, as I only use *nix, and OS X machines. And I would be very sad if
in the meantime the windows build is broken again when there are
pull-request contributions.

As you are aware of my rate of development and contributions, and funding
by Dual Inventive. I would like not to get stuck when the tooling is not
sufficient.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#437 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AAEeHwKrbf62FE8G2yR9Y8YvaJMA89hvks5qNSelgaJpZM4I5IYF
.

[Nightwalker-87]

I currently see no reason to move anything out of GitHub in the near future.

Since February we have a separate development branch where all recent changes should go. The master branch should be reserved for minor, non-code-specific fixes (e.g. documentation), hotfixes and releases. Continuous integration is ensured by continued use of Travis CI. Besides from Linux and macOS this is to be used for Windows as well.

[Nightwalker-87]

This project has been transferred to a git-organisation today, as agreed between @texane, @xor-gate and @Nightwalker-87. This will ease collaboration and possible transitions between maintainers in the future, as this project is now hosted within a shared account. Also it will offer new possibilities and features for further evolution of this project.

I'll leave it at that for now and may go into details at a later point in time...

[xor-gate]

Thanks @Nightwalker-87 for the public update. If you need some ideas please drop them here so we can discus. I will make time for it to move the project further and give my advice.

[xor-gate]

Also a big thanks to @texane and the other contributors who took care of the project while I was busy with life of course ;=)

[Nightwalker-87]

The reorganisation of the project and the related transfer to a public git-organisation seem to have resolved this issue. All further general notes related to this project will be published in #874.
Against this background I am closing this issue now.