What kind of workflow should we follow in Pagure?

[John W. Himpel]

I'm obviously a newbie at Git and Pagure.  But even a quick scan of the
web soon leads to a decision point.  What workflow model should be
used.

A cursory scan of the web suggests three possibilities:
1) GitFlow
2) GitHub Flow
3) GitLab Flow

I don't know enough to even venture much of a guess as to which model
we should follow.

Another question enters my mind.  Should the workflow for docs and the
workflow for Ansible modules be the same?  Or are there enough
differences that each should have it's own separate workflow?

Before I begin committing my Ansible Modules, I would like us to reach
a consensus so that we don't have to make major workflow revisions
later.

Let the discussion begin!

[Emmanuel Seyman]

* John W. Himpel [31/07/2024 17:27] :
> I don't know enough to even venture much of a guess as to which model
> we should follow.

Our worflow is documented here:
https://docs.fedoraproject.org/en-US/server-working-group/usr-docs-maintenan...
> Another question enters my mind.  Should the workflow for docs and the
> workflow for Ansible modules be the same?  Or are there enough
> differences that each should have it's own separate workflow?

At least for the time being, I'ld rather have one workflow for
everything. If we see Ansible-related content requires a different workflow,
we can always define a workflow for that (and hopefully only have to do
it once).

Emmanuel

[Peter Boy]

> Am 01.08.2024 um 00:27 schrieb John W. Himpel :
>
> I'm obviously a newbie at Git and Pagure.  But even a quick scan of the
> web soon leads to a decision point.  What workflow model should be
> used.
>
> A cursory scan of the web suggests three possibilities:
> GitFlow
> GitHub Flow
> GitLab Flow

Given those models, we currently use more or less a GitFlow Workflow of a mixture of GitFlow and Github workflow.
(See e.g. https://www.eisquare.co.uk/blogs/how-to-choose-your-branching-strategy)

The main characteristic is that 
(a) we don’t produce release branches
(b) we develop *major* features / changes in a devel branch (stg/staging) and merge this into main branch.
(c) once a feature (i.e. an article) is ready and published in main, we update minor changes in main. The version in staging is put on hold. Any additional (minor) work is done in main (hot fixes). 
(d) as soon as we plan a major change in an article, we would copy it back into staging (never happened so far).
(e) individual developers / authors may/should use additional feature branches to simplify work. During development they can merge into stg for others to check and discuss, when finished merge into main. (Alternatively you may copy the finished article into main)
(f) Changes by WG members may go into a fork or or into the main repo (not to be confused with main branch). That’s up to the member.

We are a bit lazy with back porting fixes in main into staging.
> Another question enters my mind.  Should the workflow for docs and the
> workflow for Ansible modules be the same?  Or are there enough
> differences that each should have it's own separate workflow?

I think, because we aim to achieve with Ansible the same as with manual work we should use the same workflow. Just in case we late want another workflow, that’s not a big issue.

I’ll probably update / expand your contribution doc with my latest notes over the weekend.

Best
Peter

--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
[e-mail]

Timezone: CET (UTC+1) / CEST (UTC+2)

Fedora Server Edition Working Group member
Fedora Docs team contributor and board member
Java developer and enthusiast

--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
[e-mail]

Timezone: CET (UTC+1) / CEST (UTC+2)

Fedora Server Edition Working Group member
Fedora Docs team contributor and board member
Java developer and enthusiast