Dean Michael Berris wrote:
On Sat, Jan 29, 2011 at 3:55 PM, Vladimir Prus <vladimir@codesourcery.com> wrote:
Dave Abrahams wrote:
However, my vision for Boost is a bit different:
* each library has its own Git repo
* each library maintainer tests and produces versioned releases of that library on his/her own timetable
* the latest release of a library is tagged "STABLE"
* When assembling a new Boost release, the release manager marks the "STABLE" revision from each library and begins boost-wide integration/interoperability testing on those revisions
I am rather sceptical about this approach. The goodness of what we have now is that there's a single trunk that holds code that is:
- supposedly not worse in test results in all other code, - is the newest one satisfying the above constraint
Therefore, if I wish to make sure my code works with new release of Boost, of if I wish to check if some bug is fixed, that is the place to go. Further, this place is jointly updated by every boost developer.
What you propose breaks this useful thing, because:
- 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.
- 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 3. I mark the current state of publically available repository as good for pull 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.
- In practice, release managers will only pull a week or two before the release, therefore the unified thing we have now will no longer exists, and two weeks before the release we'll get a frankenstein creature that might technically pass all tests (though I doubt that), but won't be tested by any users in real projects.
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?
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. - Volodya -- Vladimir Prus Mentor Graphics +7 (812) 677-68-40