[Libre-soc-dev] git.libre-soc.org mesa repo branch

[Hendrik Boom]

On Thu, Sep 10, 2020 at 09:53:49AM -0400, Hendrik Boom wrote:
> On Thu, Sep 10, 2020 at 12:57:00PM +0100, Luke Kenneth Casson Leighton wrote:
> > On Thu, Sep 10, 2020 at 12:49 PM Hendrik Boom <hendrik at topoi.pooq.com> wrote:
> > 
> > > The developers of monotone, another distributed revision control
> > > system, recommend making a branch for every bug, and pushing it to
> > > any central repositories early in the process, before it's even
> > > debugged.  That way anyone in the project can look at it and offer
> > > reviews and advice.  This does mean a lot of short-term named
> > > branches, but a problem with a not-yet-tested fix wont shut
> > > anyone else out of their work.
> > 
> > i totally get it.  it's basically the "github" way of working (github
> > is based around "Pull Requests" which can only be done through
> > branches.   see below about that).
> 
> I've always thought the overhead in pull requests makes it all 
> excessively formal.  And therefore slow.

I meant communication overhead btween people here, not hardware and 
software delays. 

-- hendrik

> 
> > 
> > this works extremely well for products that are on an "incremental
> > development cycle".  where it falls down is where the product is on a
> > "rapid development and prototyping cycle".
> 
> I see.
> 
> > 
> > > > to give you an example of why committing and pushing is so important: only
> > > > last week i lost git commits not once but TWICE due to a faulty laptop PSU.
> > >
> > > Feeling free to push early to a branch without fear of
> > > interfering with others' work would make this less likely.
> > 
> > i've done this before: it resulted not in review and collaboration but
> > in total isolation and, ultimately, made months to literally years of
> > work utterly pointless because the branch was completely and utterly
> > ignored.
> 
> The kind of branches I was thinking of last of the order of days,
> at most a week or so, never never months.
> 
> You make a change, someone reviews it, you fix it, you commit to the 
> main development branch.
> 
> Actually, though, you mae a change in a bugfix branch, you commit it, 
> you push it to any central repository there might be, someone reviews 
> it, and you merge into the main development branch and push it.
> 
> I guess monotone goes well with a slightly different style of 
> developer interaction.
> 
> > 
> > the lesson that i learned is that it is better for people to stop
> > seeing it as "fear of interference" and to instead view it as being a
> > necessary and beneficial *need* for the team to communicate and
> > ultimately learn to collaborate and work together.
> 
> I see.  It's a different, and effective, way of living with different 
> tools but achieveng similar communication and collaboration. 
> 
> -- hendrik
> 
> _______________________________________________
> Libre-soc-dev mailing list
> Libre-soc-dev at lists.libre-soc.org
> http://lists.libre-soc.org/mailman/listinfo/libre-soc-dev