{"thread":{"id":"24040","subject":"Slaughtering the sacred cow","startedAt":"2010-06-08T09:34:16Z","lastAt":"2010-06-08T09:50:11Z","messageCount":2,"participants":["Michael J Gruber","Ramkumar Ramachandra"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"143219","messageId":"4C0E0E98.6080806@drmicha.warpmail.net","threadId":"24040","inReplyTo":null,"subject":"Slaughtering the sacred cow","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2010-06-08T09:34:16Z","receivedAt":"2010-06-08T09:34:16Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Now that I got your attention, here are some observations and thoughts\nabout our development model for git.git. In fact I think we have a\nsuccessful model (and a great maintainer) but there is always room for\nimprovement.\n\nThe sacred cow from the subject line is backwards compatibility, and it\nis sacred for a good reason. People can happily run git.git's master or\neven next without too many surprises as long as they're on their watch\nfor some slightly larger changes in 1.x.0 releases. Distros choose to\nfollow maint or master.\n\nStill, lately several discussions here have put me in a slaughterous\nmood so to say. Our code base is \"naturally grown\", and as much as I\nlike that for a garden, it basically makes any attempts at providing a\nconsistent and smooth sur^Winterface impossible, because this always\nrequires some cuts. So, why not let the cow do the greenkeeping to get\nthe ball rolling smoothly again ;)\n\nI think the technical reason behind this issue is the short-livedness of\nour topic branches and pu. Who's looking at any 10+ patch series? I\nmean, it was always easy to, say,\n\ngit merge $(git rev-parse \":/Merge branch\n'mg/rev-parse-lrbranches-locals\")^2\n\nfor stuff on pu and this is even easier now with the topic branches\npushed out by Junio to github. But large series simply get over-grown.\n\nWe don't have a place like kernel-next for large structural incompatible\nchanges. Our \"next\" is a very stable branch with what will be the next\nsmall increments on master, and it serves a very good purpose.\n\nShortly before an upcoming 1.x.0 we often have \"for-1.x.0\"-topics but I\ndon't think that can house large developments like\n\n- consistent interface for subcommands (\"branch --setupstream\" vs.\n\"remote add\" etc.),\n\n- consistent approach on DWImery (may require removing some, or making\nit dependent on config),\n\n- consistent treatment of porcelain/plumbing hermaphrodites (may require\nbreaking some assumptuous scripts).\n\nThose are just a few examples of issues which are confusing for new\nusers, which are there just because they grew to be there (or because of\nimplementation details), and which don't go away because of that cow.\n\nI don't pretend to have a perfect solution for this, but I'm wondering\nwhether a longer-lived for-1.x.0 branch (with or without an extra pu,\ni.e. not rewinding itself [leaving that for the extra pu] or rewinding)\nwould be feasible which gets everything from next-master-maint and which\nwould also be a place to cook larger structural, backwards incompatible\nchanges. An alternative would be to have a branch like that for a\nspecific large topic (like one of the above) and focus on that for the\nupcoming release.\n\nThe idea behind all this is that it would allow to work on a large topic\n(breaking compatibility) early on, right after a 1.x.0 (which is\nimpossible right now), and hopefully have it exposed to more people,\nmaybe providing an integration branch if we go with the \"long lived\nlarge topic branch\" approach rather then the first one described above.\n\nAs time goes by the cow can do her thing, and people can be aware of\nupcoming changes much earlier. Then it should be alright to break a few\nmore scripts in a 1.x.0 release - we always broke a few, so people would\nalways have to check before switching anyways.\n\nCheers,\nMichael\n"},{"id":"143220","messageId":"AANLkTilzPoCBFEJiJBHubIjqcN7fQdI2Eg8tsGuiSfGZ@mail.gmail.com","threadId":"24040","inReplyTo":"4C0E0E98.6080806@drmicha.warpmail.net","subject":"Re: Slaughtering the sacred cow","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2010-06-08T09:50:11Z","receivedAt":"2010-06-08T09:50:11Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Hi,\n\nMichael J Gruber wrote:\n> I don't pretend to have a perfect solution for this, but I'm wondering\n> whether a longer-lived for-1.x.0 branch (with or without an extra pu,\n> i.e. not rewinding itself [leaving that for the extra pu] or rewinding)\n> would be feasible which gets everything from next-master-maint and which\n> would also be a place to cook larger structural, backwards incompatible\n> changes. An alternative would be to have a branch like that for a\n> specific large topic (like one of the above) and focus on that for the\n> upcoming release.\n\nI'm relatively new to the list but from what I've seen, I think\nkeeping a longer-lived branch that accepts less-than-complete patches\nis a good idea. Small patches that break backward compatibility are\noften criticized (often leading to rejection), while larger patches\nwith the promise of showing the whole picture often tend to be ignored\ndue to their sheer size.\n\n-- Ram\n"}]}