#5911 Rules for private/topic branches in dist-git
Closed: Invalid 6 years ago Opened 9 years ago by hhorak.

Since the email to fedora-infra nor fedora-rel-eng ML did not work, I'm trying my luck here.

I've found a proposal [1] and 'removal manual' [2] for private topic branches in Fedora dist-git, but no official documentation for that.

What I'm looking for is a way to collaborate on some bigger change between co-maintainers or keeping a different dist-git content for copr build for example.

I tried to create one such a topic branch with private- as a prefix and it seems to work fine. If that is an expected way to do such things, is there any documentation I just have not found or should we create one?

I believe we should have a documentation at least for:
* rules for naming the private branches (if they should be prefixed by private-)
* who has rw access for such branches
* how to delete them (is the rel-eng ticket the only way to do it?)

[1] http://fedoraproject.org/wiki/Dist_Git_Branch_Proposal

[2] http://fedoraproject.org/wiki/Dist_Git_Branch_Redux

Bonus: would it be possible to think about creating even new ad-hoc repositories (with the private branches only)?


We have a policy of not deleting branches.

Metadata Update from @ausil:
- Issue close_status updated to: None

7 years ago

Metadata Update from @ausil:
- Issue tagged with: meeting

7 years ago

So what is the policy for private branches then?

$ git push origin private-ttomecek-modularity
FATAL: W any rpms/automake ttomecek DENIED by fallthru
(or you mis-spelled the reponame)
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

There is no policy on private branches. there is protections stopping you creating branches that are elXX, epelXX, and fXX. however none of the branches you make can be deleted.

Is this relevant when pagure becomes front-end for dist-git? I'm assuming that pull-request workflow will be common then.

Make sure this policy is documented.

Closing the ticket for now and we will revisit it once we have everything in place and the policy is documented.

Metadata Update from @mohanboddu:
- Issue close_status updated to: Invalid
- Issue status updated to: Closed (was: Open)

6 years ago

Login to comment on this ticket.

Metadata