[bt-devel] Suggestion: New Workflow

[Martin Gruner]

Hi Raoul,

with Git what you'd probably do is set up another repository
(bibletime-staging ?) where more people have write access. Or they can
work in their own private repositories, sending merge requests when they
are finished.

Your suggestion encourages good programming practices, such as reviews,
enforcing standards, good documentation etc. That is very commendable.
However, I am not sure if at this stage of things it would be good to do
so. We don't really have a large number of submissions coming in from,
and the submissions we do have are coming from the 'core' team. There
was at least one person requesting write access (Jonathan) that I
discussed the issue with and we agreed that he does not need write
access at this point because of the possibility of merge requests.
Whenever submissions of this nature come, they will naturally have to be
reviewed by a someone who does have write access. So in fact, we already
kindof have what you are proposing.

I would be glad if we could take some time to get used to Git and its
workflows, and then revisit this issue. What do you think?

Regards, mg

Am 19.08.10 17:18, schrieb Raoul Snyman:
> Hi folks,
>
> Now that we're using a DVCS, perhaps we can implement a slightly different 
> workflow to what we're used with Subversion.
>
> Gitorious has the ability to propose (or request, in Gitorious terms) merges. 
> I think this provides us with the perfect opportunity to have a little bit of 
> peer review in our development process.
>
> I'd like to suggest we use a workflow similar to the process my OpenLP project 
> uses. Each developer has a clone of the main repository, and then develops in 
> their own branches. Once they're happy with their changes, and have tested 
> them, they push their branch up to Gitorious and request a merge to master. 
> Then one or two "core" developers can review the merge, and can allow the 
> merge to continue.
>
> On the pro side, we'll have code that is cleaner, higher quality, and has less 
> bugs. On the con side, the commit to master process will be a little longer, 
> and will require at least 1 "core" developer to approve the merge. I believe 
> that the pros outweigh the cons in this process.
>
> I'm not sure how Gitorious works, but on Launchpad, I can set up multiple 
> teams for the project. With OpenLP, we have a "core" team which is allowed to 
> commit to trunk (or master), and a "developers" team which is not allowed to 
> commit to trunk. All developers are part of the "developers" team, and thus 
> can follow various aspects of the project, while the "core" team maintains the 
> master code base. It might be an idea to set up something like this on 
> Gitorious if possible.
>
> Thoughts?
>
>