ETOOMANYBRANCHES and Contributing.md

ETOOMANYBRANCHES and Contributing.md

[Henning Schild]

Hi,

in my point of view upstream Isar has way to many branches and it is
unclear how there are used.

I propose to clean that up and come up with a description of what the
remaining branches are and what they do.

Here is how that could be done:
1. remove personal branches of developers, they should use clones not
upstream
2. agree on having at least two branches "master" and "next"
 - master would be stable and rebasing/force-pushing not allowed
 - next would be the rebasing/staging branch for master
3. everything that goes to master has to sit in next for a while
4. everything that goes to next has to show up on the mailinglist for
public review ... TODO Contributing.md

Henning

Re: ETOOMANYBRANCHES and Contributing.md

[Jan Kiszka]

On 2017-08-08 05:03, [ext] Henning Schild wrote:
> Hi,
> 
> in my point of view upstream Isar has way to many branches and it is
> unclear how there are used.
> 
> I propose to clean that up and come up with a description of what the
> remaining branches are and what they do.>
> Here is how that could be done:
> 1. remove personal branches of developers, they should use clones not
> upstream
> 2. agree on having at least two branches "master" and "next"
>  - master would be stable and rebasing/force-pushing not allowed
>  - next would be the rebasing/staging branch for master
> 3. everything that goes to master has to sit in next for a while
> 4. everything that goes to next has to show up on the mailinglist for
> public review ... TODO Contributing.md

Right.

Historic things shall either be removed or put into some "historic/"
namespace if they still keep relevant bits.

There has to be an official staging branch. If you and Baurzhan are
rotating maintainer roles, make clear who is when in charge, but use the
same branch so that contributors can build upon.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux