I like all of Cassio's recommendations. For everything but project work that requires major change, how about a Linux-style regular cycle for submitting private branches to Gama for merge into main? Say, every first Monday of the month or something similarly easy-to-remember? Combined with a rule that no private branch should go >2 months out of date, this would encourage regular checkins (of course, each developer would be free to merge local changes to a regularly-main-merged private branch at whatever frequency is desired).
If I grok project merging as discussed, we'll create a new permanent branch 'testing', and using PLN as an example the process would be: - rebase testing on main - rebase pln on main - merge pln into testing - announce that people should *test* or *hack* or *whatever* on testing - merge testing into main - close and remove the pln branch - wash, rinse, repeat For reference for this thread, everyone should re-read (and edit or comment as pleases you!) http://opencog.org/wiki/Development_standards and add their branch to http://opencog.org/wiki/Branches (we'll format/organize this page later). -dave On Thu, Sep 18, 2008 at 10:20 AM, Cassio Pennachin <[EMAIL PROTECTED]>wrote: > Hi, > > One of the major benefits of DVCS is easy branching, and there should be a > good reason for a policy that strongly discourages branches. What is that > reason? > > I can quickly think of numerous reasons in favor of branches. For > instance, Joel's work involves lots of changes to lots of different parts of > the code. The natural way to do this is by branching and merging once all > changes are completed and tested. This is true for any such change, even if > the resulting branch would be short lived. Discouraging branches for this > kind of thing encourages people not to commit their work. > > Also, based on Novamente's development history, one can expect that many > OpenCog macro-tasks will require extensive fiddling with different aspects > of the codebase, often in unexpected places. While it's certainly possible > to perform all these experiments within the main trunk without breaking > anything, that's not the most likely outcome. The most likely outcome is > that breakage from experimental work will happen often if the default policy > is to work directly from main. This is especially true for AI researchers / > scientists who aren't experienced software engineers, yet can be invaluable > for OpenCog. In this regard, OpenCog development is very different from > regular software development, and I think our policies have to consider > this. > > Finally, the "everyone works directly from main" means we have essentially > no gatekeeper to decide what gets merged into main, and I don't think this > is a good idea, at least now and in the short term future. > > I believe we need a set of practices and guidelines for development and > merging in order to minimize breakage, overhead for maintainers, and overall > frustration. But I'm not sure these guidelines should be > single-branch-based. > > >> - make a temporary 'stable' snapshot branch of main >> - merge major work branches into main (at least thee of these: Gama's >> work, Joel's work, Erickson's work) >> - together, hammer on main until everyone is happy with it again >> > > On a more detailed note, shouldn't it be the other way around? Keep main > "stable" and have an unstable branch where stuff is merged onto, and then > ported over to main? I.e., don't break the main build. > > - exceptions (i.e. new branches) should be discussed here or #opencog >> - EVERY new branch should be preceded by a wiki page that describes its >> location, purpose and plan for merging back into main >> > > I believe these are good ideas with a bit of flexibility. First, I think > branching should be the default. But I think every branch that's expected > to be merged back into main should be announced here or #opencog and > documented in the wiki. > > We should meet briefly once per week on IRC just for status, notice of >> upcoming merges, gripes, etc. I suggest the 15 minutes before Ben's OCP >> tutorial each Wednesday tutorial at #opencog-dev (can be created ad-hoc). >> > > And this, definitely, is a great idea. > > Cassio >
_______________________________________________ Mailing list: https://launchpad.net/~opencog-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~opencog-dev More help : https://help.launchpad.net/ListHelp
