On 1 November 2013 04:00, Jakob Frank <ja...@apache.org> wrote: > On 31 Oct 2013 09:36, "Sergio Fernández" < > sergio.fernan...@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
