You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@marmotta.apache.org by Sergio Fernández <se...@salzburgresearch.at> on 2013/10/31 09:36:00 UTC
branching workflow
Hi,
with the email from Eranda Sooriyabandara, for me it is clear we are
confusing our users with our current branching approach.
Refreshing what we discussed back in February/March, and what we claim
at the web page:
http://marmotta.incubator.apache.org/development.html
http://git-scm.com/book/en/Git-Branching-Branching-Workflows
Marmotta uses a branching workflow, where we have a stable
master branch and a unstable develop branch. Besides, optionally
topic branches could be open for some topics/issues, which don’t
necessarily need to be pushed to the public repository.
With the topic branches I thing we are doing quite good in the last
months, nothing to say about that.
But, regarding master vs. develop, not so. I think our error has been to
continue developing always on develop, so it became the de facto master
branch. And, according the branching workflow:
Many Git developers have a workflow that embraces this approach,
such as having only code that is entirely stable in their master
branch — possibly only code that has been or will be released.
They have another parallel branch named develop or next that they
work from or use to test stability — it isn’t necessarily always
stable, but whenever it gets to a stable state, it can be merged
into master.
what we are misunderstanding here in the concept of "stable code".
Besides the wrong merge Sebastian did (see INFRA-6876), we are
considering only releases as stable code. And I thing we should do that
more often. The criteria would need to be discussed, but could be
something as simple as "periodically, if jenkins' builds are stable, all
tests passing and no critical/blocking issues open, we could merge
develop into master". This could be done by any committer, a special
person, or even the release manager, I don't know.
What do you think? This discussions is very important, since it'll
affect how we all are working.
Cheers,
--
Sergio Fernández
Senior Researcher
Knowledge and Media Technologies
Salzburg Research Forschungsgesellschaft mbH
Jakob-Haringer-Straße 5/3 | 5020 Salzburg, Austria
T: +43 662 2288 318 | M: +43 660 2747 925
sergio.fernandez@salzburgresearch.at
http://www.salzburgresearch.at
Re: branching workflow
Posted by Sergio Fernández <se...@salzburgresearch.at>.
On 08/11/13 15:28, Andrea Di Menna wrote:
> I am getting a 404 on this URL.
That happens while the CMS is re-building the staging site because new
changes are coming. And just now Sebastian is pushing new documentation
there, so it might be temporally unavailable while rebuilding.
For avoiding those issues, the new site has been already published, so
you can access the content at:
http://marmotta.incubator.apache.org/development.html
Hope this has clarified the issues.
Cheers,
--
Sergio Fernández
Senior Researcher
Knowledge and Media Technologies
Salzburg Research Forschungsgesellschaft mbH
Jakob-Haringer-Straße 5/3 | 5020 Salzburg, Austria
T: +43 662 2288 318 | M: +43 660 2747 925
sergio.fernandez@salzburgresearch.at
http://www.salzburgresearch.at
Re: branching workflow
Posted by Andrea Di Menna <ni...@gmail.com>.
Hi,
I am getting a 404 on this URL.
Cheers
Andrea
2013/11/8 Sergio Fernández <se...@salzburgresearch.at>
> Hi,
>
> I spent some time updating the development documentation to better reflect
> the gitflow Marmotta is following. Please, take a look at the staging site:
>
> http://marmotta.staging.apache.org/development.html
>
> Feedback would be welcomed ;-)
>
>
> Cheers,
>
> --
> Sergio Fernández
> Senior Researcher
> Knowledge and Media Technologies
> Salzburg Research Forschungsgesellschaft mbH
> Jakob-Haringer-Straße 5/3 | 5020 Salzburg, Austria
> T: +43 662 2288 318 | M: +43 660 2747 925
> sergio.fernandez@salzburgresearch.at
> http://www.salzburgresearch.at
>
Re: branching workflow
Posted by Sergio Fernández <se...@salzburgresearch.at>.
Hi,
I spent some time updating the development documentation to better
reflect the gitflow Marmotta is following. Please, take a look at the
staging site:
http://marmotta.staging.apache.org/development.html
Feedback would be welcomed ;-)
Cheers,
--
Sergio Fernández
Senior Researcher
Knowledge and Media Technologies
Salzburg Research Forschungsgesellschaft mbH
Jakob-Haringer-Straße 5/3 | 5020 Salzburg, Austria
T: +43 662 2288 318 | M: +43 660 2747 925
sergio.fernandez@salzburgresearch.at
http://www.salzburgresearch.at
Re: branching workflow
Posted by Sergio Fernández <wi...@apache.org>.
Apologize if someone consider this marketing, but I find it relevant for
this thread: on Thursday November 21st Atlassian is organizing a
webinar about git branching for agile teams: http://ow.ly/qtXEp
Looks interesting; I hope to have time to attend it.
On 03/11/13 08:22, Sergio Fernández wrote:
> Hi,
>
> On 31/10/13 23:31, Peter Ansell wrote:
>>> On 31 Oct 2013 09:36, "Sergio Fernández"wrote:
>>>
>>> (...) we are considering only releases as stable code. And I think
>>> we should do that more often.
>>
>> GitFlow is a well known and accepted distributed VCS strategy [1].
>> Rather than changing that strategy, potential developers who want to
>> work with the codebase should be learning it (and the other main Git
>> workflows [2]) as a Git exercise. They are likely to need to use it or
>> similar workflows on other open source projects in the future.
>
> So, it I understood correctly, according GitFlow we are doing right
> considering stable code (so merging to master) only releases, is that
> correct?
>
> If we all agree, that's fine for me. We'd just need to update the
> documentation. And, of course, be aware all team of such workflow. After
> all, we are learning in the trip :-)
>
> Thanks Peter for the clarification.
>
> Cheers,
>
--
Sergio Fernández
Senior Researcher
Knowledge and Media Technologies
Salzburg Research Forschungsgesellschaft mbH
Jakob-Haringer-Straße 5/3 | 5020 Salzburg, Austria
T: +43 662 2288 318 | M: +43 660 2747 925
sergio.fernandez@salzburgresearch.at
http://www.salzburgresearch.at
Re: branching workflow
Posted by Sergio Fernández <se...@salzburgresearch.at>.
Hi,
On 31/10/13 23:31, Peter Ansell wrote:
>> On 31 Oct 2013 09:36, "Sergio Fernández"wrote:
>>
>> (...) we are considering only releases as stable code. And I think
>> we should do that more often.
>
> GitFlow is a well known and accepted distributed VCS strategy [1].
> Rather than changing that strategy, potential developers who want to
> work with the codebase should be learning it (and the other main Git
> workflows [2]) as a Git exercise. They are likely to need to use it or
> similar workflows on other open source projects in the future.
So, it I understood correctly, according GitFlow we are doing right
considering stable code (so merging to master) only releases, is that
correct?
If we all agree, that's fine for me. We'd just need to update the
documentation. And, of course, be aware all team of such workflow. After
all, we are learning in the trip :-)
Thanks Peter for the clarification.
Cheers,
--
Sergio Fernández
Senior Researcher
Knowledge and Media Technologies
Salzburg Research Forschungsgesellschaft mbH
Jakob-Haringer-Straße 5/3 | 5020 Salzburg, Austria
T: +43 662 2288 318 | M: +43 660 2747 925
sergio.fernandez@salzburgresearch.at
http://www.salzburgresearch.at
Re: branching workflow
Posted by Peter Ansell <an...@gmail.com>.
On 1 November 2013 04:00, Jakob Frank <ja...@apache.org> wrote:
> On 31 Oct 2013 09:36, "Sergio Fernández" <
> sergio.fernandez@salzburgresearch.at> wrote:
>>
>> what we are misunderstanding here in the concept of "stable code".
> Besides the wrong merge Sebastian did (see INFRA-6876), we are considering
> only releases as stable code. And I thing we should do that more often. The
> criteria would need to be discussed, but could be something as simple as
> "periodically, if jenkins' builds are stable, all tests passing and no
> critical/blocking issues open, we could merge develop into master". This
> could be done by any committer, a special person, or even the release
> manager, I don't know.
> I would prefer an automatic approach, e.g. after a stable Jenkins build
> (all tests passing).
> I see two issues with that: first, the apache Jenkins is not really stable
> itself and second, we are missing postgres and mysql databases for testing
> there.
>
> But for a start, we could try to manually merge back to master once a week
> (iff all tests pass, including postgres and mysql)
>
> What is important: the version on master MUST be working! It is the first
> impression someone will have when checking out the code.
>
> Best
> Jakob
GitFlow is a well known and accepted distributed VCS strategy [1].
Rather than changing that strategy, potential developers who want to
work with the codebase should be learning it (and the other main Git
workflows [2]) as a Git exercise. They are likely to need to use it or
similar workflows on other open source projects in the future.
Peter
[1] http://nvie.com/git-model
[2] https://www.atlassian.com/git/workflows
Re: branching workflow
Posted by Jakob Frank <ja...@apache.org>.
On 31 Oct 2013 09:36, "Sergio Fernández" <
sergio.fernandez@salzburgresearch.at> wrote:
>
> what we are misunderstanding here in the concept of "stable code".
Besides the wrong merge Sebastian did (see INFRA-6876), we are considering
only releases as stable code. And I thing we should do that more often. The
criteria would need to be discussed, but could be something as simple as
"periodically, if jenkins' builds are stable, all tests passing and no
critical/blocking issues open, we could merge develop into master". This
could be done by any committer, a special person, or even the release
manager, I don't know.
I would prefer an automatic approach, e.g. after a stable Jenkins build
(all tests passing).
I see two issues with that: first, the apache Jenkins is not really stable
itself and second, we are missing postgres and mysql databases for testing
there.
But for a start, we could try to manually merge back to master once a week
(iff all tests pass, including postgres and mysql)
What is important: the version on master MUST be working! It is the first
impression someone will have when checking out the code.
Best
Jakob