On Sun, Jan 30, 2011 at 9:23 PM, Vladimir Prus <vladimir@codesourcery.com> 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