search

cmangos / issues

This repository is used as a centralized point for all issues regarding CMaNGOS.
180 stars 47 forks source link

🚀 [Feature] Protect Master Branches From Being Pushed to Without Review and Build Check #1949

Closed ulfgebhardt closed 4 years ago

ulfgebhardt commented 5 years ago

🚀 Feature

Protect master branches from beeing pushed without review and build check

Github allows to protect branches in order to prevent contributors to push directly to them. Instead opening a PR is required. This results in more stable branches, since a review has to be made and all build checks have to pass before merging into the protected branch.

I open this request in light of recently merged PR-Templates to the cores (thanks @Muehe )

Visualisation

Example of Overview for protected branches: image

Example of a Protection rule: image image

Benefits & Purpose

Currently it happens quite often that Travis fails on the master branch since changes are merged in directly. It is common practice to keep the master stable. A protected master branch has the side effect, if configured that way, that before anything is merged into master all build checks have to pass. image

Besides the stability aspect it has several other beneficial effects:

This whole mechanic is common practice in OpenSource Projects, comes with small overhead and increases stability, sustainability and reliability, while encouraging other developers to contribute.

Open Questions

There is this mechanic called backporting which is used to share commits between cores. Since it is undocumented I cannot tell how exactly it is done, but from my knowledge it includes cherry picking and pushing directly to the master. It is to explore if a protected master interferes with that mechanic so its either not possible anymore or become way more complicated. Certainly for a backport with a protected master branch a PR has to be made and merged via Github.

Suggestion how to adjust branch settings in CMaNGOS

Closing Words

Please discuss wether you want to use this mechanic or if it would interfere with your day to day workings on this project in such an impactful way that you rather not continue on that path.

I think it could benefit the project in alot of ways since currently most people cannot interact with most of the features github provides for there Repos - and those who can are largely unknown to those who cannot. Responsibilities are unclear and those with the permissions to take those responsibilities are mostly overworked to follow those. The suggested settings would allow to share those responsibilities with a larger group of people in the future without endangering the project and therefore stepping up the pace <3 .

Special thanks to @jimmybrancaccio @Muehe and all the others helping me to get the Templates merged in.

Thanks to all contributors making this project as awesome as it is!

evil-at-wow commented 5 years ago

There is this mechanic called backporting which is used to share commits between cores. Since it is undocumented I cannot tell how exactly it is done, but from my knowledge it includes cherry picking and pushing directly to the master.

But it is documented, my young padawan! Your summary "cherry pick and push" is fairly accurate though (although I personally always add 'build and smoke test' before a push). See our wiki.

One bonus of this is that people will finally have to stop doing force pushes :smile:

I'm not sure if we'll see an influx of merge commits because of this. I hope not. Depending on how people merge, it doesn't need to be that way I think (but I'm not sure I fully understood everything yet). I often see merge commits popping up for no good reason and personally I find it usually clutters history. I certainly don't mind a larger feature or refactoring to be pull-requested as a list of sensible commits that don't get squashed and get merged with a correspondig merge request. In cases like this it makes sense IMHO because it's easier to show the history of that feature/refactor vs the rest of the branch. But seeing for example a commit "fix typo" and an associated merge commit for merging the typo fix commit always makes me cry a bit.

ulfgebhardt commented 5 years ago

Hah I did not know that this was documented - you always learn.

Regarding merge commits - I think Github will always create merge commits:

image

The commit log contains the full history of commits tho:

image

You can enforce History not to be multi-lane with the Require branches to be up to date before merging tho I guess

image

Who would be able to change those repo settings - in case we decide to push this forward? @killerwife ? @cyberium ?

ghost commented 5 years ago

If i understood things correctly, you believe this change will:

Well... here's my, probably very flawed or biased, point of view:

On "stability":

Protecting master doesn't make it "more stable just because" -- PRs are also being reviewed!

So far review process has always been slow for different AFK and historical reasons and is not the best tool to prevent slip-ups. Good architecture, automated testing, clear development roadmap and predictable developer availability are the best tools to improve things.

So you want major contributors / owners to stop directly committing for stability sake? We don't even have a notion of "stable" besides versioned releases! And even those are feature-driven by far.

Stability could be and should be improved through implementation of unit- and integration- testing, improvement of documentation and actual peer review of existing code.

Stable branch? Yeah, sounds cool. But what are the implications?

Besides, CMaNGOS is already a "development branch" of another major project.

On "amount of stuff getting into the core":

It allows in a second step to loosen the security rules on this repo in oder to find more people willing to contribute

The suggested settings would allow to share those responsibilities with a larger group of people in the future without endangering the project and therefore stepping up the pace

CMaNGOS historically has been a "hidden Cathedral" -- in that it's supposedly an open-source project where everyone can contribute, yet there is a hidden, foggy hierarchy which filters through things that make it in.

Yet, even this circle isn't exactly a single locomotive of decision, nor is a single person. Several groups of DB devs, core devs along with bunch of highly-influentual members otherwise discuss and work on things in their own spare free time.

This "hidden Cathedral" was and will continue to be the ultimate decision making machine on what's being integrated. Quite often it so as happen to be in favor of contributors, in fact. It's just a very slow process.

Still, read up on this quote from CMaNGOS README.md:

To be able to accomplish these goals, we support and promote:

  • Freedom
    • of our work: Our work - including our code - is released under the GPL. So everybody is free to use and contribute to this open source project.
    • for our developers and contributors on things that interest them. No one here is telling anybody what to do. If you want somebody to do something for you, pay them, but we are here to enjoy.
    • to have FUN with developing.

Lack of contribution effort, in my opinion, has roots within incomplete / assorted / somewhat vague / not very well maintained documentation. That and the largely misunderstood / disregarded project self-statement (the README).

Do people think it's some "official" stuff noone should touch"? Just dig in. Review code randomly, fork, play around with it, patch, get lost in codebase, send those PRs. Write tests! Improve docs! Promote the project, if everything else fails.

Speaking of fails: fail! Fail and speak up about it, bring attention and keep bringing attention to issues.

In my experience, a lot of things in documentation are the real points of failure, misunderstanding and needless complexity.

Maybe if we can provide graphs, give a high-level explanation on how modules / systems / subsystems are interacting between each other, where they are implemented, where their code entry points -- maybe then more people will understand what's going on with the core to actually contribute.

On the other hand, do not "live to get the code merged". We are a slow-moving mastodon with very few people onboard. Testing shouldn't be done just on code entry. Developers shouldn't be the only ones "responsible for code review". Raid some of those stale PRs and leave feedback -- we have a live feed of things that's watched over, dig into issues and help with those!

To summarize: Promoting good practices through docs, better architecture coverage, dependency graphs and other meaningful ways to provide quick insight into the things might actually win more souls than trying to unclog PR process.

Which brings us to main point: There are not enough (interested?) people to process PRs.

It increases the chance that PRs from occasional contributors are inspected, reviewed and finally merged since all contributors have to deal with the same cluttered PR List when they are not.

Nothing like a fresh breeze of free time and more people actually leaving a comment here and there will make this process faster.

berserkingyadis commented 5 years ago

I feel alot what Levi talked about is part of a "bigger" issue, and not sure if it should be disussed here.

Documentation is not good enough? Change it or encourage ppl to make more Wiki edits. Open another issue highlighting the specific weaknesses of the current documentation and allow others to add their points aswell. Be the change you want to see, and this issue is one step in the direction.

If there are not enough people to process PRs we should make more ppl able to. See if a few people distinguish themselves by being active enough on Github and with the code. Some maybe already are.

BenDol commented 5 years ago

I'll start by saying that I am fairly new here, so I appreciate that you're interested in my feedback on the matter.

I have a few questions in regard to the core in order to give a useful opinion from my point of view:

  1. Who will be in charge of reviewing and managing the merges into master?
  2. Who is currently vetting changes into master?
  3. Will availability of the key reviewers cause massive delays to anything?
  4. Will there be clear outlines to the standards in the wiki/documentation?

Besides these questions my thoughts are mostly supportive of this method. I think controlling what gets into master and treating it as the "stable" release candidate is ultimately the best route. This is how we manage our production builds for my work projects. One thing I am noticing a lot whilst digging through the code, is there are a lot of narrowly focused fixes that have been applied retroactively to many of the core systems. While this is to be expected, it is always harder to recognize the full impact of those changes and ultimately can lead to massive regressions. I think a majority of the issues I've been addressing lately are almost all these types of changes. So having a more "aggressive" review process to the master branch would have saved me and many of the devs some pain I think.

One downside to this, is that it obviously creates another layer of red tape that devs will need to understand and manage among three separate projects which I think is already stretching peoples free time pretty thin. Does this downside outweigh the benefit of a more controlled release pipeline? I don't think so personally.

I think when this is implemented we should also consider creating a dev branch that gives access to bleeding edge changes to anyone interested in testing.

ulfgebhardt commented 5 years ago

@BenDol Thanks for your input. Regarding your questions:

1. Who will be in charge of reviewing and managing the merges into master

This addresses the second part of this feature I would like to propose in a separate issue. But to outline what I am thinking about:

I would like to have the permission structure of the cmangos organisation refactored:

cmangos_permissions (Note: this graphic does not represent the Github Permission levels)

Outside Collaborateurs

Member

Reviewers

Owners

Github Permissions

Currently its not clear to me which Github Permissions each group would need in oder to archive that. I have to research it. My guess is: Owners in this scenario would be Admin or Owner in Github. Reviewers would be Member with write permission and team member of a code ownership team. Members would be Members with write permissions. Outside Collaborateurs would be no one in the Orga.

Furthermore I would like that everyone can promote others to his level of access, but it is currently unclear to me if that is possible in Github.

2. Who is currently vetting changes into master?

No one particular as it seems - there is 20 members of the cmangos Organisation which might have the right to do so. The permission structure is not visible to outsiders tho. PRs get approved occasionally and mostly those of people already beeing part of the developer community. Reviews are rare especially for outside collaborateurs. Most changes are pushed directly to master by individuals without any (visible) review or check.

3. Will availability of the key reviewers cause massive delays to anything?

This is currently already the case - see question 2..

4. Will there be clear outlines to the standards in the wiki/documentation?

If wished for I would take the responsibility to document this.

5. Layer of Redtape

One downside to this, is that it obviously creates another layer of red tape that devs will need to understand and manage among three separate projects which I think is already stretching peoples free time pretty thin. Does this downside outweigh the benefit of a more controlled release pipeline? I don't think so personally.

I think the benefits are outweighing the downsides by alot if you assume the Permission refactoring will be done as outlined in 1. . For a small window of time it will be harder to merge Stuff in even for devs pushing to master at the moment. This will hopefully result in a spark of communication e.g. in Discord Please approve my PR xy and will force contributors to communicate more closely.

For the future with permissions refactored assume following scenario:

@BenDol you are currently Outside Collaborateur. But @AnonXS - a member of cmangos orga - likes what you are doing (which is certainly the case <3) so he can promote you to Member. Now you don't have to fork the Repo anymore, but can work directly here. You would be just prohibited to review PRs (you cannot review your own PRs anyway) or push to the master branch. Now assume you commited alot of changes over time and @killerwife is confident you know what you are doing and therefore promotes you to Reviewer. Now you can review PRs of others and merge them into the master. Furthermore you have contributed over a very long period of time, you are very well known in the community and provide alot of quality content to the Repos. Therefore @cyberium will promote you to Owner in oder to spread responsibility to keep this repo maintained in the future.

Additional Context

The current permission structure looks like this (from an outside collaborateur's view):

cmangos_permissions (1)

There are no Teams defined to find out who's responsible/has permission for what. Its just a plain list of 20 members:

cmangos members
BenDol commented 5 years ago

Thanks for the response, how about the idea of a dev branch which is where the dev changes go before hitting master? That way we add a nice bridge in there for people that want bleeding edge changes to test and in turn help make things more stable?

ulfgebhardt commented 5 years ago

@BenDol With the proposed changes that would be easily possible - but the question here would be again: who manages it? ;-)

BenDol commented 5 years ago

Well the way I figure is that dev becomes what master is now and master is more rarely merged to once dev changes are deemed "release ready". Shouldn't be more than teaching people that they need to PR against dev.

cyberium commented 5 years ago

First, nice to see some idea comming from new members. Thanks for this discution.

You have to know that this discution already happened more than one time between devs. I personaly read some of those arguments but i you summarized them nicely in a long well explained post.

However there is no progress on this matter since for the major reason. Who will take the responsability to merge pr, to keep master code as clean as possible (without merge commit please) and with enough knowledge to been able to say "with those news code addition it will still be stable".

I think no one is able to write real "stable" code. There will be always uknown/untested cases. So we generaly tend to make master as much stable as possible and also we resposabilize devs with push right to at least give support for their changes. So when a dev push something related to some specific features or bug fixe we assume that it will be under some radar at least for some time.

Iam not against a real master branch. It is just more work, more time and also more responsability that's why it never was changed. We choose the "Stable, Release candidate, Devellopement branches" organization then i remember some started to complain that they don't know how to manage multiples branches (some devs). We gave up from that time :D.

So i need to think of it, i am just back from some time without looking at cmangos code and i think there is already alot of work i have to done on my side.

Concerning you @BenDol as a dev i need to know you a bit. Feel free to contact me on discord i should be there a bit more than last months.

Cheers

ulfgebhardt commented 5 years ago

@cyberium Thanks for your response,

To clarify things: The aim of this Feature-Request is not stability. I think that cannot be done easily without extensive Unit/Fullstack Tests. The aim of this Feature Request is to increase the amount of contributions and active members working on this repository. The stability part is just a side effect.

I am aiming for:

I actually think, if moving this forward, the workload of those currently working on the project will decrease and they can focus on what they want to do instead of beeing nagged by contributors to merge their code.

What I would like to see is that cmangos becomes more progressive and more open to contributors which are certainly available if you look on how many people open new issues and PRs. Integrating them into the development workflow would hold a lot of benefits to the project.

Since i am talking all in theory I would like to give an practical example: Currently anyone can open an issue, but will be unable to assign labels or assignees. The issues have been dormant for quite some time and piled up to ~1500 till @jimmybrancaccio was promoted and took responsibility. Since then he labeled alot of issues, motivated people to check if they are still valid or closed old badly described or incomplete ones. Now we are at ~400 issues. By opening up the membership to those who want to contribute this task can be done directly by the issuer or anyone else willing to take the responsibility.

And back to theory: As you can see with this simple example, sharing responsibilities and powers will in most cases result in a better and more functional outcome. This is the case if you make sure the bad guys cannot do anything too bad that easily. A wrongly labeled issue will not break anyones heart (except @jimmybrancaccio 's maybe), but a virus pushed to the master, as it has happend quite some time ago, does.

Therefore i pledge @cyberium Please change your mind:

However there is no progress on this matter [...]

Protect the master branch and invite anyone to the organisation (after refactoring the permissions ofc) who is willing to contribute in any way. Out of this pool you then can recruit those you want in the core-team, able to review and merge.

More people - more fun!

<3

@BenDol I, personally, am against a dev branch, since I have bad experience with it - nevertheless it is a common schema which might be valid if properly used ;-)

cala commented 5 years ago

Thanks all of you for this enlightening discussion. 👍

I have mixed feelings about this feature request.

@cyberium made previously the choice to open access to master branch in a effort to speed up the development pace of CMaNGOS which is quite slow (even to my own standards) in comparison to, let say, TrinityCore. The downside was an increased risk of so-so commits or even regressions, but the idea was that it was still possible to revert bad commits and it was also an intend to give responsibility to devs to take care of their contributions (supporting, debugging and so on).

Let me sleep on this, I'll give a better answer tomorrow. :)

jimmybrancaccio commented 5 years ago

I think this is a very well put together discussion. I appreciate everyone who's commented and provided input thus far. My thoughts in a nutshell:

  1. I think this could definitely help with providing less issues/bugs in code in a master/stable branch. Oddly enough I have been seeing developers use 'master' as a dev-type branch and creating another branch for "stable" code, usually called 'stable'.
  2. I would love to see more code review before something is put into the stable branch.
  3. My current labelling system kind of attempts to do this by having issues start at Needs Replication, then to Replicated & Needs Development, then to Needs Testing, and if fixed the issue closes out, if not fixed, then back to Needs Development.
  4. However it would be great to see some sort of labelling automatic transitioning. Perhaps using GitHub Projects feature could do this.

All in all, I am always for improvement of the development process/lifecycle. Whatever is easiest on the developers and contributors and makes sense is good in my book.

Complexity is the enemy.

ulfgebhardt commented 5 years ago

@cala you wanted to submit a more detailed feedback - just pinging you here again @cyberium can you report a status for the discussion with the core-dev-team? Is there new arguments not yet discussed?

cyberium commented 5 years ago

Yes there is some news. We are moving to a new workflow.

Idea is to not change devs habits. So me and those who want to join the effort will manage release branch and release candidate. Issues will be closed only when merging to release repos. Release repos will be a bit different that dev branch and will content a frozen state of full content db.

Newcomers will have just to clone release repo and download or extract themselves clients files to get a working server. (They will not have to manage different repos for core and db).

We will be more permissive on dev branch, less permissive on RC branch and more protective on release repos.

For RC branch we have still to discuss about who will choose what commit should be in there and from when we will decide it stable enough to go in release repos. Release repos will be updated with a changelog and i hope every 2 months maximum.

Ofc i will need your help to make this happen and viable in long term so apply is open. I need devs, release candidate reviewers, changelog writer's and issues managers.

Yes its more work than what it is described here but less changes for actual devs they can keep their workflows. Only thoses who want to apply will have more work by managing with me rc and release.

Cheers

ghost commented 5 years ago

Hell yiss! +1 the change~ A "soft palm" approach :3.

Changelog writers, you say? Aka sort of documentation?~ Consider me!

ulfgebhardt commented 5 years ago

@cyberium That sound like more overhead then suggested by me, but if you say that is a good approach :-)

Regarding many repos I have to warn you - more repos means more management overhead. You can see what mangos did there - it is totally confusing and alot of overhead:

Therefore they do not have any contributors.

Regarding:

They will not have to manage different repos for core and db

I think this is a totally different issue which should be addressed and would have been raised by me in another Issue called coupling of Core and DB. Since coupling those two would give an easy approach to do more build tests.

Tho I am glad that you and your team thinks about changes in development, I have to warn you about building structures with alot of overhead just to keep ineffective learned structures. I would suggest to reduce the amount of repos by merging similar stuff together rather then creating new ones.

We will be more permissive on dev branch

This is great news and the thing I was aiming for - looking forward to the changes <3

Also I would apply for a non-coding position. For now I would say Issue management - but i am able to do other stuff when I find the time and have the required knowledge.

ghost commented 5 years ago

@ulfgebhardt The example you have provided is somewhat remote from our reality: we have exactly three versions of the core, not six -- and the "release" set could be single repo with multiple branches, if that will become a problem.

About merging DB and the core together -- two separate sets of people do things there, mainly; giving everyone a chance to mess commit history further complicating things also doesn't seem like a great idea to me.

And i think there are other reasons why we all lack contributors, rather than multiples of repositories.

Like scattered documentation.

ulfgebhardt commented 5 years ago

@Levitanious even tho this is a bit off topic...

I talked about coupling of Core and DB - that does not mean to merge corresponding repos together, tho that would be an option to archive coupling. Another option would be an submodule or even a script pulling the correct database commit... There is many options. I certainly gave the impression to merge database and core when I said reduce repos and also talked about core-database-coupling - those are two separated issues tho.

When I say I would suggest reducing the amount of repos I was talking about an discussion I had with @cyberium where I suggested to merge all cores into one repo to remove the requirement of backporting and allow an intelligent refactoring of the parts of the core which are not yet game-version-agnostic.

But lets not talk about this here - i am sure alot of alarms are ringing by some of the readers when I say such things. Lets wait for suggested changes and things to settle - then I will make a separate issue for those suggestions outlining what the benefits and downsides are from my point of view.

About the mangos example. It surely is quite far away from what cmangos is - since those links i provided are all separate orgas - with the same people in it - which is kinda ridiculous.

My argument is still valid: More Repos, more release system equals more effort to maintain it.

From my point of view it would be wise to tag releases / pre-releases and provide binaries, database and so on in the Release on Github in the same repo. An example can be seen here: https://github.com/demokratie-live/democracy-development/releases/tag/1.2.2-production%2Bclient This release contains a binary (the apk file) which is automatically uploaded via travis if the corresponding tag is set. This mechanic would keep everything in one repo - there is no need to have aditional everlasting effort. You just have to configure travis once in order to always archive this. (@cyberium )

Regarding the lack of contributors i would say the following reasons apply:

Consider the two scenarios:

Coredev:

Outsider:

My suggestion just says: Level those to processes to be the same:

Anyone:

You can see this mechanic on almost every Open Source project and quite successfully. An example is TrinityCore: https://github.com/TrinityCore/TrinityCore/pulls?q=is%3Apr+is%3Aclosed

The Resuls can clearly be seen - this is one month of contributions on Trinity: image

And this is one month of contributions on CMangos-Classic: image

cyberium commented 5 years ago

No moment of success due to merges taking very long time and eventually get closed

Proposing a pr doesn't mean it will be accepted. Proposing a PR require to core dev to review it and thus those core devs should know what they are doing. In my case when it come to script and spell related fix iam unconfortable. Its hard to say if its a good PR or not. And often its not because it seem to work that it really work and does not add regression or too much code complexities that we'll have to manage in the futur.

Uncertain powerstructures which do contributions and get merged (or directly pushed in most cases) - but no effort is taken to review the work of outsiders ->

No effort? We cannot count all issues/PR we tryed to resolve/review, explain to the author... I think you missed the point here.

No onboarding process for newcomers

What? We maybe have to define newcomers and onboarding. I am rarely proposing myself to someone to get involved/join our team. I try instead to encourage everyone who want to first do some PR so we can know him/her then contact me or another dev to apply if he/she is interested. Intention have to comme from you. So no pression from our side in any way.

No clear documentation how to contribute

We have to explain more than https://github.com/cmangos/mangos-wotlk/blob/master/CONTRIBUTING.md how to contribute? Well if you think so, WIKI is opened to everyone so feel free to modify it and stop complaining.

People have to know how to fork - you cannot contribute to the repo directly which involves several additional steps to complete. While the core team just pushes to the master.

I dont even know a dev that don't know how to fork. Its even not a command but rather a one click button. Its almost the first thing that people do when they got their github account. I'll tell it that way. Is a dev doesn't know how to fork i doubt that it will propose anything interesting for our code.

Lack of structure in the development - Sometimes a review is given or people are assigned to the issue, but it is never actually merged and eventually closed after some time

Wow you give the impression that we dont care about people contribution. Now i see more clearly what you are refering. https://github.com/cmangos/mangos-tbc/pull/168

So all of this is getting personal infact. Well suffice to say "Hey even if its an old PR iam here and this should be merged in my opinion" instead of all of this. That one had @cala assigned an i did a mistake by not asking him before closing it. He will merge it when he can/have time.

Do that next time. We can also make mistake. Its not a reason to see only bad sides of this project.

BenDol commented 5 years ago

I don't really have much more to say on this topic given that I think the main team has already decided what they think is the best option and that at the end of the day that is all that matters. But I will say that I think creating a new repository for release sounds like a terrible idea. There should be no reason we couldn't just create a dev branch and have that be what master branch is now and then master becomes the release branch that dev is merged into. So then the bot that builds nightly compilation will build off of dev while major hard defined releases will be done off the master branch. I can write a guide on how to switch branches for all the devs git checkout dev, then all the existing open PR's could either still make it into master during the transition to the new structure or they are switched to PR against dev.

Anyway that's how I would manage it for this open source project, simple and adds a good bleeding edge layer for the devs to work off. However too many cooks in the kitchen once the decision is made by the core team is just noise at that point.

joao-fidalgo commented 5 years ago

Imho i would use 2 branches, develop and master. For releases i would use tags and would build the binaries for all supported operating systems.

Regarding versioning and changelog i would take a look into conventionalcommits.

Muehe commented 5 years ago

Well the separate repo would be for having a specific core and DB commit in one place, and different expansions on different branches of that repo. It would then run a build script and create a download for Windows and Linux that includes the binaries and a single sql-file for the DB. But this is just the idea so far, nothing is set in stone yet.

Btw. the plan is to use the git subtree command for managing state, so the process of updating the release repo would be two git subtree pull's, which is easily scriptable and could be triggered by setting tags on the master and/or dev branch.

Note: git subtree is not the same as git subtree merging or git submodule, don't get confused (as I did).

cala commented 5 years ago

The main difficulty with this change is to balance expectations from basic users that almost want a "download'n'play" server out of the box, with devs expectations that want robust yet quick workflows and finally, project owners expectations that want to satisfy both while keeping the project quality level.

Add to this equation developers habits: "why don't you do it that way, it works" (missing the " for me") and you get something more complex than it seems at first.

From a developer PoV, I would fully agree with the use of dev branch, master branch, feature PRs,, rights management and regular releases/tags (we already use most of these for Classic-DB).

But I also remember when I first joined mangos project (years ago before the split), building was far from easy, it was only possible for Windows and I had to struggle a lot to build on macOS. So I understand why @cyberium want to ease onboarding by making an easily identifiable object "stable and easy to pick for first starters" without master degree in some IT field as a prerequist.

We must also keep in mind that CMaNGOS strongly relies on the philosophy of doing the things right. This means taking the time to do them properly and sometimes/often denying PRs. Let us be clear: this displease new comers: "why is development so slow?", "why was my submission rejected/ignored?" and many people prefer other projects for these reasons. Unfortunately, this is amplified by the fact we are not that many active people.

This is again about balance: increasing contributions without decreasing code quality or core stability. Whatever solution is picked, at the end of the day, more quality control and checks means more work for people that will be in charge of it. Thus it is very important that the chosen solution ensure that they can do it. I trust @cyberium in making something that is as much automated as possible to reduce this workload.

Having working for years on worldwide industrial projects, I know too well that the most viable solutions are not the ones with the perfect technical approach (or even the ones vouched by the team) but in the long the ones with the best balance between resources usage, time, technical constraints and customer satisfaction.

So let's start for now with separated repositories for stable branches versus regular development. This is not a one way road and we will still have the possibility to move back to something else is this does not work.

berserkingyadis commented 4 years ago

Some time has passed after this discussion. Are there new opinions, requirements or news from the people who already wrote in here?

killerwife commented 4 years ago

My stance is still the same, even stronger. I am barely able to push my usual 6 month export and noone is qualified to review most of my commits without considerable time investment. I know this because even in my own team people struggle to review the 1% of commits I need reviewed.

cyberium commented 4 years ago

I have lacked to find motivation to finish cmangos-release repository as i wanted to do for a workaround on this. I think we can close this, no real change have been done since and the couple of force pushing happening here and there plus no one really review the code itself (only result will be reviewed by user and often only by accident when they need that feature to work) are not going to help implementing this. So for everyone who still wondering, yes cmangos is a development repository and nothing is tagged really as release. You'll have to deal with that until someone will take the decision to handle a release branch/repos. That's open for everybody who want to contribute, know c++, cmake, sql, git and is able to manage a project by selecting what is releasable or not. Contact me if you are interested.