Re: [boost] RE process (prospective from a retired FreeBSD committer)...

Subject: Re: [boost] RE process (prospective from a retired FreeBSD committer)...
From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2011-01-30 12:24:19

On Sun, Jan 30, 2011 at 9:23 PM, Vladimir Prus
<vladimir_at_[hidden]> wrote:
> Dean Michael Berris wrote:
>
>> On Sat, Jan 29, 2011 at 3:55 PM, Vladimir Prus
>>>
>>> - Only release managers "pull" into the unified thing
>>
>> Not really. Every developer can do the same thing that release
>> managers do. To get a full Boost locally, you pull from multiple
>> repositories, and you develop against a "stable" or "tagged" version
>> of each library in your local repository.
>
> Just to clarify, by "unified thing" I mean a specific URL that everybody
> can use to checkout/clone/fork/whatever a version of boost with all the
> current changes. You suggestion that I manually pull from N different
> repositories seems like a mess to me, sorry.
>

Nope. I still meant cloning from one URL. git has sub-trees and
sub-modules support -- think of it as svn:externals only distributed
and generally "better". When you say 'git pull' or 'git submodule
update', well it does the correct thing and updates the local repo
from different places.

>>> - Release managers only pull "releases", which, together with delays
>>> added by release managers, means that a fix to a component will be added
>>> to the unified thing after considerable delay
>>
>> Not really either. Release managers can just pull from libraries that
>> have updates, and even do that incrementally.
>>
>> More to the point, developers willing to work on just getting a stable
>> release out (maybe a stable release team or "support engineers") can
>> contribute to the libraries "upstream" fixes that are found to be
>> required for the "STABLE" versions for integration to happen.
>>
>> Actually I would even think that "STABLE" in each library would be a
>> branch, typically "master" or could easily be just another branch, so
>> changes that are specific to the "STABLE" version stay in that branch.
>
> I am not sure this addresses my concern in any way. Right now, if I have
> a one-letter typo in my library, I fix it, do "svn commit" and then everybody
> who checks out trunk a second later gets that fix. With your workflow, it's
> necessary that:
>
> 1. I commit the fix locally
> 2. I push to a publicly available repository

This 1 and 2 is similar to your 'svn commit'.

> 3. I mark the current state of publically available repository as good for
> pull

Nope, by pushing to the repository that's already done for you.

> 4. Release managers pull into the official master repository.
>
> It's about 99.9% probability that if (4) requires manual action, it means my
> fix won't appear for a month at least. And while you can probably can script
> (4), the question arises why we need all this mess, as opposed to direct push
> into the official master repository. I am sure that most Boost developers will
> prefer this model, as opposed to being forced to "release" their libraries
> separately.
>

I obviously don't qualify for "Boost developers" I think so I can't
really say. But largely from the library developers' perspective, what
can happen is that he can just worry about the things he's doing
locally and pulling regularly -- because git pulls are pretty much
painless even if you have local modifications that aren't in the
remote repo that you're pulling from.

Less synchronization means very little need for waiting -- the release
managers (or whoever for that matter) can absolutely fix any broken
local libraries they're dealing with, submit the patches upstream and
not worry about whether those patches make it or not because then they
have a repository that works locally that they can deal with. If the
original maintainer doesn't introduce the patch to his repository the
release managers can choose to incorporate it. Instead of a
centralized approach, you solve the problem in a distributed approach.

So now from the maintainer's perspective, what would happen is he
doesn't merge anything to the 'STABLE' branch until he's sufficiently
satisfied that it's OK. Now once he does that though, the release
managers can choose to: 1) pull everything and trust the maintainer on
it -- assuming that it works with other STABLE release branches of
dependency libraries -- or 2) revert their local repo to a previous
version until failures are fixed in co-existing libraries.

If someone -- doesn't need to be a release manager -- wants to fix the
whole mess locally in their repos, and then submit the patches
upstream to the offending libraries that break each other, then that's
largely possible and *seamless* to the whole process. This is what
encourages people to fix things locally and submit patches upstream,
mainly because they: 1) don't need permission to do this and 2)
because it's so painless to do it.

>>
>> If everybody had a way of pulling the "latest and greatest" of all the
>> "STABLE" branches of all the libraries they want to use into their own
>> git repo, I don't see what's the difference from having everything in
>> the same place.
>>
>> Am I missing something?
>
> I might have missed your proposed way for such pulling of everything. Could
> you spell it again?
>

Git sub-trees and sub-modules.

>>> So, to reiterate, no matter what tools are proposed, I strongly thing that
>>> there should always be UNIFIED in-development tree of ENTIRE BOOST to which
>>> all library maintainers can add changes without coordination with release
>>> managers.
>>>
>>
>> Everyone can have that locally as a conglomeration of all the
>> libraries they're interested in. I don't see why it has to be just one
>> server.
>
> Why should it be multiple servers? Apparently, having multiple servers is MORE
> work, not less, and so far, I don't see Boost developers voting for having
> their libraries hosted elsewhere.
>

Why would it be more work? I don't see why you think it would be more
work. If the server choices are github, gitorious, sourceforge git
repos, or your own publicly accessible server, who does it have to be
more work for? And to that point, if pulling from multiple sources is
just one command, why would that even be more work?

-- 
Dean Michael Berris
about.me/deanberris