Workflow

[Tux]

• Do we need to document the workflow to the group?
• Do we want a Label that members cat put with an issue like "Taken" or "Work in progress" so it is easier to pick issues to work on?

[jmdh]

On Sun, Oct 15, 2017 at 01:28:08PM +0000, H.Merijn Brand wrote: • Do we need to document the workflow to the group?

I assume by workflow you mean the PR workflow and merge policy you outlined in person yesterday? If so then yes, definitely.

• Do we want a Label that members cat put with an issue like "Taken" or "Work in progress" so it is easier to pick issues to work on?

Github supports an assignee and requested reviewers, so I suggest this be used to indicate this. We can define other github labels as needed, but not sure if we have a definite need for this at the moment. Dominic.

[Tux]

How about this?

1. Create a new branch in metaconfig

2. Create a new branch in perl

3. Hack hack hack

4. test :: pass ? 5 : 3

5. Commit to metaconfig

6. Push new metaconfig branch

7. Push new perl branch

8. Create a PR on the github → This can cause comments

9. Someone merges PR to metaconfig

10. Someone runs mlint and mconfig to regenerate Configure and friends

11. That someone checks against the new perl branch and commits to perl

12. Delete metaconfig branch

13. Profite

[jmdh]

I'm not too sure it makes sense to create a branch in perl.git. The person reviewing the PR would also generate Configure and see the changes there, and it would be good to have this process runnable by people without a commit bit. Also, steps 9-12 should always be performed by the same person.

That reduces it to

1. Create a new branch in metaconfig (or a fork, if you are not a member of the metaconfig organisation)
   • you might also want to create a separate branch in your local perl repository but this won't immediately be pushed
2. Hack hack hack
3. test :: pass ? 5 : 3
4. Commit to metaconfig
5. Push new metaconfig branch
6. Create a PR on the github → This can cause comments
7. Once approved, the person who will merge the changes (who must be a committer here and on perl.git) does the following:
   • merge PR to metaconfig
   • runs mlint and mconfig to regenerate Configure and friends one more time
   • checks against the new perl branch and commits to perl
8. Delete metaconfig branch

[Tux]

The perl-git branch makes sense for changes that are handwork, like configure.com and the choice of the default in regenerating the related files. So yes, that would be optional, but very welcome for people that have commit bits. If this all is documented, that would be a good addition as comment.