Document key-priorieties for development

[6543]

1. provide sensible defaults
2. provide good and consistent documentation
3. make sure to write generic func and split up big func into sub functions
4. use packages for each topic and if to big split asap in subtopics

---

#1860 (comment)

[qwerty287]

@6543 did most of this with #3184, but I don't think we can close this.

Some points which need to be discussed (I think):

1. Which features do we implement/accept? Currently, we accept almost all features, even though if they are really rare usecases.
2. Support for backends: Currently, we state WP on our website kind of as "container-first" which is wrong. However, there are a lot of features just usable with docker (see Rename registries #3191, More docker backend test remove more undocumented #3156).
3. What should be supported out-of-the-box, what should be moved to addons? Esp. with these in mind:
   • Deprecate HTTP config service #3179
   • Which new backends are allowed to be added to the core repo? (Just take a look at https://github.com/woodpecker-ci/woodpecker/discussions?discussions_q=is%3Aopen+label%3Abackend)
   • Which new forges are allowed to be added to the core repo?

[6543]

TLDR: we should encourage contributions into our project ... and acept such too

[qwerty287]

That's basically what I'd say too.

If it would violate our core dev gidelines

Now the question would be what "core dev guidelines" are. Because if I think about forges, I'd say a forge must at least support these features:

• OAuth2
• Hooks

to be merged into our core.

But let's not discuss this here, but rather use a new discussion if we finished discussion about the general points.

[6543]

Agree :)

PS: i created #3364

Feel free to summarize things a bit as code comment, else just wait and review the contribution addressing this issue :)

[zc-devs]

Almost all maintainers are active...

That is good. It was just my feeling about main repo, because addons was/is about main repo.

Kubernetes has enough users and external contributions and also some maintainers do use it

Now. I chose it even though it was experimental. I invested my efforts (as others) and look at it now.: sometimes it beats even Docker :) What if it was some third-party addon?

ssh backend which was removed in v2

Was it hard? It looks like click-click-delete to me, just removing a couple of packages. More managerial work than technical.

I don't like that gitea is that bloated

I was concerned too.

• But first of all, nobody stays behind me with a gun and push me to use features.
• Secondly, it is designed for small-meduim teams, I think.
  I started using image registry in Gitea. It was as simple as click-enable, push, pull. Awesome. Then I moved to Harbor.
  If I want to use software packages registry, I'll probably start with Gitea because of simplicity. And then, probably, move to Nexus, for example.
• As an admin I dont have to search addons, plugins and so on. I just go to admin console, enable LDAP/OAuth, Issues, Wiki. Just click-click and done. I dont have to deploy Jira, Confluence or whatever.

gitea has iirc about 120 mb which is too much

Gitea 1.21.5 - 65.21 MB

I have nice example: nextcloud - 404.44 MB. They have modules, cool. But all core modules in the image. Yet, users have to build own images. You know what after all? I dont care about half GB size. I'm not on dialup or GPRS and can afford a couple of minutes to download image. And it happens once per month (?). I just use it.

clean code structure

This. Agree.

I do this sometimes
they might not need a feature

Me too. But it is not just random thought from my mind. I need it / would like to use it. Or someone need it and I just like it and curious to implement. There is always request (issue).

requirements change, this is nothing unusual

Of course. Life flows. It always changes. See comment about Gitea.
But should it be a reason to reject contribution?
Let's consider Bitbucket Server / Kubernetes. I'm evaluating the project.
When was it started? Pretty long time ago (+).
Is it active? Yes (+).
Is it one/two persons project? No (+), Yes(-).
Does it support Kubernetes without DinD? Yes (+), but experimental. OK, will see how it goes. Oh, there is couple of bugs... I can fix / workaround that.
Does it support Bitbucket Server? No (-). Not even buggy implementation that I can fix.

What do you mean with "subrequest"?

Like I were merged libvirt/podman/etc initial/experimental support and It's not my problem anymore. I want this and this. Let maintainers do it now.
I'm alone here and have to rely on myself. There is a chance that I won't be alone. But if that initial implementation wasn't merged, chances are going down.

we should encourage contributions into our project ... and acept such too

You are way more better explained my thoughts than I 🤣

---

Sorry for long post and offtopic sometimes.

[qwerty287]

Now. I chose it even though it was experimental. I invested my efforts (as others) and look at it now.: sometimes it beats even Docker :) What if it was some third-party addon?

Sure, we need a starting point for some features. But take a look at the original issue: #9. It has 12 ❤️ reactions so it was kinda clear that this feature will have a lot of users.

Gitea 1.21.5 - 65.21 MB

I mainly mean the binary directly:

---

However, it looks like in general we all agree to the same points @6543 wrote above:

If it is a unicorn one shot thing: let it be an addon
If it would violate our core dev gidelines: also addon

Else: just let it be merged into our codebase and document it as experimental.
If it sees high usage or contributions, we should considder it usefull and mark it as stable if we are confident enouth that it will stay.

(core dev guidelines do not exist yet, so this is next discussion point)