← Back to team overview

openerp-community team mailing list archive

Re: Proposal to improve communication and make more efficient the inclusion of new branches.

 

2013/10/28 Olivier Dony <odo@xxxxxxxxxxx>

> Yes I saw the spreadsheet and I had a quick look at your patches to runbot
> too, but I don't think we'll want to merge that. We would prefer if not
> everyone is allowed to setup sticky branches, as people are very good at
> misusing the tools you give them, and the cases where a sticky branch is
> needed should be fairly limited.
>

I am agreed on block the feature, but it can be blocked too easyly (with
pasword or something).

BTW, the main reason is that between "Ask the sticky" and "Have the sticky"
passed ~4 month since OpenDays.

It means, if we have more easy to use tools, it will e more easy and less
time consuming for eveybody.

BTW, yes don't merge it, it is too risky allow everybody create sticky
branches due to limitation of hardware.

But we think we need at least 3 brothers as "sticky" not teams or (sticky
on teams maybe):

6.1-ocb
7.0-ocb
trunk-ocb

In this way everybody can test everything easily.

In terms of processes IMHO the OCB should be a "community reviewed"
branches pre-merged in core, it should be the best approach for everybody.

And obviously as the "active" field in journal argumentation (as an
example) you can discuss if something is merged or not.

Thanks a lot or your time.

Regards.

PS: We develop other feature over runbot too!

Pre-Test branches "MErge Proposal Based" to allow Quality Reviewers test
the MP when it is GREEN before merge without download the MP, Something
like "Team Based" but listed based on MP. It makes really usefull the Merge
approach where we have Bug linked, Blueprint, approver and team, the MP
itself has more information than the branch, and says "Ready to review".

Other approach we think is necesary is the "Include/Exclude" Modules, to be
able to verify if it is an specific module which generate the problem
_before_ debug, we have community modules where by definition are
incompatible with some others.

+2 extra branches:

It is the best one, we have +40 community branches, 2 is not enought to
test the, even we have implementations where we use +10 branches at same
time, It is done too in our runbot's branches.

I really appreciate Hold the horses jejejeej but is difficult if you have
the Idea very clear, don't you think?





-- 
--------------------
Saludos Cordiales

Nhomar G. Hernandez M.
+58-414-4110269
Skype: nhomar00
Web-Blog: http://geronimo.com.ve
Servicios IT: http://vauxoo.com
Linux-Counter: 467724
Correos:
nhomar@xxxxxxxxxxxxxx
nhomar@xxxxxxxxxx
twitter @nhomar

References