[Slackbuilds-users] Question about git workflow

[Willy Sudiarto Raharjo]

> I am pretty sure that this, more cvs/svn orientated branching strategy is
> not optimal.
> 
> There is no need for users to have branches, they should have forks.
> There they can branch, and create for these branches pull requests.
> 
> Of course you can create also branches per user, but this only pollutes the
> repo with unnecessary stuff.

this branch strategy works like forks, but instead you are given a
privileges to write your changes to our GIT repository directly instead
of doing it on your own public space.

Also, you no longer need to send a pull requests, since by using cgit,
we can see other's changes and notify them if something needs to be
fixed before next public update.

Once a week, i simply run a script to merge them all to master and then
remove all those branches and maintainers can rebase their branches to
the latest master again. It's all very efficient in GIT, but maybe not
in CVS/SVN.

> You could take pull requests from every trust able person fore each
> package, the maintainer models is total obsolete that only scales bad,
> distributes work bad, and is a bottleneck by design.

That's what we do :)
we gave "some" maintainers privileges to push it directly to our GIT
repository. We will be adding more maintainers from time to time.
There's no written requirements, but these two should be a good start:
- active maintainer
- understand GIT basics
- having public GIT repository is an added value :)

Please note that maintainers in SBo differs from maintainers in Linux
Kernel project where they took all changes in their subsystem from other
people as well. In SBo, maintainers are responsible for their own
scripts. That's why they write it on their own branch.

> Honestly, if, for example, Niki would make a pull request for some package
> update because he needs it in MELD, I would pull it in if he is the
> maintainer or not.
> Maybe with a 'next release branch' for some time to give early adopter
> chance to do additional testing, which his more a useful branching strategy
> than per 'trusted user'.

since all the changes can be seen in the cgit, users who are willing to
try can just clone the SBo repository and switch to anyone's branch and
test whether it works or not.


-- 
Willy Sudiarto Raharjo

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.slackbuilds.org/pipermail/slackbuilds-users/attachments/20170306/6d500298/attachment.asc>