Hello.
On 07/22/2017 11:22 PM, Andrew Williams wrote:
Hi eflers :)
So after thinking about issue management and planning milestones I thought
more about our source control. We currently have various different models
used but the bottom line is that it all hits master all the time which can
lead to less stability than ideal and also makes stabilisation windows
critical to enforce.
As a suggestion I think we should consider agreeing on a singlet branching
model and I'd recommend GitFlow (described quite well here
https://www.atlassian.com/git/tutorials/comparing-workflows#gitflow-workflow).
As well as being well organised there is a solid gitflow plugin that helps
to manage branches and workflows.
I read the tutorial now. It is the first time I ever encountered this
workflow. Do you know any bigger FOSS projects that use this? The ones
I'm familiar with do not (not even EDI, which is unstable on master from
time to time. ;))
Bottom line: main development moves from "master" to "develop" and master
then remains the most recent release (always stable ;) ). Releases then are
created on a branch rather than being branched after release.
If we are going to add more process overhead it need to yield a
significant improvement somewhere. Best would be a significant
measurable improvement (e.g. the work on meson in different project is
really driven by the potential speed improvement it can bring to the
development).
I have a hard time seeing this big improvement coming from an additional
buffer branch (develop) before things hit master. How would we define
that develop is ready to be merged into master? If we would have a magic
script that tells us if a branch is stable or even releasable we could
apply the same for commits to master in our current setup.
Social wise I have also a hard time to see who in our community would
actually handle merges from develop to master. Who would test master?
Most of the active devs I would expect to stay on develop and on their
feature branches. Neglecting master or the release branches as they have
no use for it and want to focus on their work.
Hotfixes
merge into develop and master which makes it easier to ensure we don't
forget to backport fixes :).
Err, wait. A current hotfix workflow looks like this
Report -> fix in master -> backport to release branch
with the gitflow model it looks like this:
Report -> fix in hotfix branch -> merge hotfix branch to master -> merge
hotfix branch to develop.
How would that be easier? When you forget the backport you could also
forget to merge the hotfix branch into master.
Let me know what you think - it's worked quite well in previous groups but
I appreciate it may not for us and I expect there are a lot of experiences
here that could feed in :)
What have these previous groups been? A company or a FOSS project? I
just ask because enforcing such strict rules is way easier in a company
environment compared to an very old FOSS project with grumpy people from
many different backgrounds :)
Bottom line: I do not want to shoot this down but I want to see it in
use somewhere before I would even think about all the impacts it might
have when using it in efl. I also think that we should not try to make
such big changes on our biggest and most complicated project (efl) first
but try things out elsewhere.
regards
Stefan Schmidt
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
enlightenment-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
