Re: Reconsidering the work flow and how the SCM system fits in

["Mike (mwester)" <mwester@dls.net>]

Paul Sokolovsky wrote:
> Hello,
> 
> On Tue, 11 Mar 2008 09:47:19 +0100
> Esben Haabendal <EsbenHaabendal@gmail.com> wrote:
> 
> []
> 
>>> comments? agreement?
>>>   
>> Without going into the specifics of the SCM tools discussion, I would
>> just like to say that I would REALLY REALLY love to see branches being
>> used actively in OE development, 
> 
> Oh really? Because I would think that loving to see them makes little
> sense. It makes sense only to use them. And who will use them?
> Because if people wanted to use them, they would do that already.
> Actually, people who want, do.

Hogwash!  It is true that there are a set of people who do not and will 
not use SCM tools.  However, there are numerous others, right here on 
this list, who have *attempted* to use that abomination known as "mtn" 
and discovered that branching with mtn is easy, but merging anything 
"real" is an absolute nightmare.  I will not go into the specific list, 
but merging with mtn is a "cross your fingers and pray" experience.

This is made worse by the fact that there is no culture around mtn. 
Hence there's no sense of "mtn is goodness" as there is developing 
around git.  That's important.  Perhaps not for you, but for many others 
the community help and wisdom around git that's lacking for mtn is what 
will make using branches practical and make merges sucessful.

>> especially for feature development
>> (such as sysroot, packaged-staging, and so on) and for release
>> engineering.
>>
>> For OE to really reach it's potential we have to be able add even more
>> features while at the same time delivering stable releases/branches
>> for distro and product developers to work from.
>>
>> When Joe-average-embedded-product-developer comes along, shopping for
>> which embedded Linux tool to use for his embedded product, he really
>> should be able to checkout a stable version of OE and be able to
>> build a toolchain and a simple image for all supported targets. And
>> this is certainly not the situation right now.
> 
> Typical mistake. There's stable branch in OE, and based on the
> experience with the previous branches, best-practices change control
> procedure was applied to it. Now, based on 2.5 month existence of that
> branch, I have following observations:
> 
> 1. People don't know about that branch.
> 2. Once made known, people still pretend that there's none, and
> continue to complain about stability.
> 3. Most of the rest of people don't put slightest effort into
> maintenance of that branch.
> 4. Those who try, complain that the change control procedure is ...
> complex! But it is only a separate branch + pre-review of changes + "all
> changes are merged from main branch" rule of thumb.

The issue is *not* the stable branch; the issue is that individual 
developers cannot reasonably go off an work on a branch, merge when they 
are satisified, and expect that it will just work.  This is NOT about 
the stable branch.

> 
> Having more branches is not going to help with this at all. 

Quite wrong!  Unstable broken stuff happens in .dev because developers 
dare not venture into the dark horrors of mtn to make their 
destabilizing changes in isolation on a private branch.

>> /Esben
> 
> []
> 

Mike (mwester)