On 2017-05-23 21:19, Marco van de Voort wrote:
I was not asking for ideally. I was asking very specifically how a GIT in a
FPC team group would work.
And no, sending 40+ pull requests to all members of core does not count. So
there is one golden repo and that is what I'm talking about.
And like I explicitly said, read the well documented processes followed
by the Linux Kernel or on a much smaller scale, the Git development itself.
I would like to have lots of extra manpower too, but I rather not spend it
on what in practice would be rubberstamping commits (and delays in
distribution till something is approved if the reviewers are AFK).
Once again, read how the Git project deals with it. That workflow could
suite FPC quite well. In summary, feature are in separate branch. There
is a public "testing stablish changes" and a public "testing unstable"
branches. Everything stays in branches until they are signed off and
merged into "master" (aka Trunk). Then less than 5 minutes is spend
doing a "octopus merge" of all branches that have been well tested and
signed.
If you don't know, a octopus merge is a single merge command but merges
2+ branches all in one go. eg:
git checkout master
git merge feature1 feature2 feature3 feature4 feature5
...where "featureX" is a branch name.
Unlike SubVersion, you don't waste a whole day "rubber stamping"
commits. Such micro-management doesn't exist in Git. Git was designed to
work better that SubVersion, and specificall at branch management and
merging.
Hence my earlier WTF comment when I read the LLVM team want- to ban
merge commits! That person clearly has no f**ken idea how Git works.
In distributed, volunteer driven, projects, people are away/nonresponsive for
extended periods of time, working hours (and days) don't match. Also working
this out via mail is much less productive.
Then simply don't pull or merge their work. Simple as that. Once again,
you are thinking in terms of SubVersion. Don't!
You don't see the Linux Kernel project come to halt when somebody fucks
up a commit - they just don't merge that commit or branch until the
idiot fixed his work. And neither do they have communications problems
via emails or the mailing list - they have tens of thousands of
contributors spanning the globe. So I don't understand why you think
such a small project like FPC will have communication issues. That's
just laughable.
Sorry to say, but I didn't find anything new or usable in this post.
Actually, it's only your stubbornness showing. I thought Karoly's reply
was very informative.
Regards,
Graeme
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/
My public PGP key: http://tinyurl.com/graeme-pgp
_______________________________________________
fpc-other maillist - fpc-other@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
