Next focus: PROCESS

[foobar]

On Monday, 17 December 2012 at 22:02:45 UTC, foobar wrote:
> On Monday, 17 December 2012 at 21:03:04 UTC, Rob T wrote:
>> On Monday, 17 December 2012 at 18:14:54 UTC, foobar wrote:
>>> At the moment we may use git commands but really we are still 
>>> developing on mostly a subversion model. Walter used to 
>>> accept patches and those were simply replaced by pull 
>>> requests. There isn't any change in the mental model required 
>>> to really benefit from a decentralized system such as git. 
>>> This is what the process discussion is ultimately meant to 
>>> fix.
>>
>> I think you've made a very good point. In order to make the 
>> most out of the way decentralized systems work vs a 
>> centralized one, will require an adjustment in the way people 
>> think. If we choose to follow the centralized model nothing 
>> will be gained when using a decentralized service, however 
>> centralization has its place and there's an obvious need to 
>> merge decentralized branches into a common centralize branch 
>> so that there's a common branch to use for testing and 
>> performing releases (etc).
>>
>> I find it's great to debate ideas in here first, not the talk 
>> page, but any conclusions or interesting points of view should 
>> be posted into the wiki talk page so that it is not lost. IMO 
>> this one should go in the wiki if only to remind people that 
>> we have the flexibility of decentralized model to take 
>> advantage of.
>>
>> --rt
>
> DVCS is not about centralized vs. non centralized. This is a 
> common misunderstanding which I too had when I started using 
> git.
> The actual difference is a client-server topology (CVS, SVN, 
> etc) vs. P2P or perhaps "free-form" topology. By making all 
> users equal with their own full copies of the repository, git 
> and similar systems made the topology an aspect of the human 
> work-flow instead of part of the technical design & 
> implementation.
>
> This gives you the freedom to have whatever topology you want - 
> a star, a circle, whatever. For instance, Linux is developed 
> with a "web of trust". the topology represents trust 
> relationships. Thus, all the people Linus is pulling from 
> directly are "core" developers he personally trust. They in 
> turn trust other developers, and so on and so forth. Linus's 
> version is the semi-official release of the Linux kernel but it 
> is not the only release. For instance, Linux distributions can 
> have their own repositories, and Google maintains their own 
> repository for the android fork. So in fact, there are 
> *multiple* repositories that represent graph roots in this "web 
> of trust" topology.
>
> What about D?
> The current git-hub repository owned by Walter and the core 
> devs (the github organization) is the official repository. 
> *But*, we could also treat other compilers as roots. more over, 
> there's no requirement for developers to go through the "main" 
> github repository to share and sync. E.g Walter can pull 
> directly from Don's repository *without* going through a formal 
> branch on github. This in fact should be *the default workflow* 
> for internal collaboration to reduce clutter and facilitate 
> better organization.
>
> This is why I'm arguing fiercely against having any sort of 
> official alpha stage. There is no need standardizing this and 
> it only mixes "private" developer only code and builds with 
> builds aimed at end-users (those would be us, people writing D 
> code and compiling with DMD). If you look on SVN servers, you 
> often find an endless list of developer folders, "test" 
> branches, "experimental" branches, etc, etc.
>
> As a user, this is highly annoying to figure out what branches 
> are meant for user consumption (releases, betas, preview for a 
> new feature) and what isn't, dev X's private place to conduct 
> experiments. This is only a result of the client-server 
> topology imposed by svn architecture.
>
> The official process should only standardize and focus on the 
> points where integration is required. Everything else is much 
> better served as being left alone. On the other hand, I think 
> that we need to add more focus on pre/post stages of the actual 
> coding. This means, the planning, setting priorities (aka 
> roadmap, mile-stones, etc) as well as reducing regressions. I 
> saw a post suggesting an automated build-bot that will run the 
> test suit and build nightlies. What about DIPs, how do they 
> integrate in the work-flow?
> I think Andrei talked about the DIPs before but I don't thik it 
> was discussed as part of this thread.

I forgot to explain that the multiple roots is applicable to D as 
well in that we have there fully working compilers - LDC, GDC and 
DMD. They currently share the same front-end - GDC and LDC merge 
DMD's code. This situation is also sub optimal and requires 
manual work and has redundancies in the process. E.g. what if the 
LDC guys fix a bug in the "shared" front-end? Should this be 
integrated back to DMD? What if Walter comes up with a different 
fix?