{"thread":{"id":"12297","subject":"Instituting feature and infrastructure enhancement proposal window?","startedAt":"2008-02-24T19:33:13Z","lastAt":"2008-02-25T03:25:37Z","messageCount":5,"participants":["Junio C Hamano","Linus Torvalds","Shawn O. Pearce","Daniel Barkalow"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"69812","messageId":"7v8x1ataiu.fsf@gitster.siamese.dyndns.org","threadId":"12297","inReplyTo":null,"subject":"Instituting feature and infrastructure enhancement proposal window?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-02-24T19:33:13Z","receivedAt":"2008-02-24T19:33:13Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"As I mentioned, I'd like to keep each cycle manageably shorter\nthan 1.5.4 (which took 5 months that is 2 months too many).\n\nThis is still \"a weather balloon\", but I'd like to establish for\neach development cycle a feature and infrastructure enhancement\nproposal window, just like the kernel folks have \"merge window\".\n\n * These are outside of the scope:\n\n - Well-contained minor bugfixes,\n - Documentation updates,\n - Additional tests.\n - Updates to contrib/ and (what I consider) non-core parts,\n like gitweb.\n\n * Fixes to serious issues can delay and prolong the cycle.\n\n * The mailing list discussions and patch reviews are expected\n to continue as before, however:\n\n - Isolated new features that come after the window closes may\n be merged to \"next\" but won't graduate until the new release.\n\n - Infrastructure changes that have wider impact that come\n after the window closes won't even hit \"next\" until the\n new release.\n\nIf this proposal is accepted favorably by the list and is\nimplemented, a release cycle will look like this:\n\n * A release from 'master' is made (e.g. v1.5.4 gets released on\n Feb 1st).\n\n * The release is merged to 'maint'.\n\n * Fix-ups to v1.5.4 start flowing and get applied to 'maint',\n and merged to 'master'. At some point, the first maintenance\n release is made (e.g. v1.5.4.1 was released on Feb 10th).\n\n * The topics that have been cooking in 'next' may be rebased to\n v1.5.4, and 'next' is rebuilt on top of 'master' with them\n (e.g. this happened on Feb 17th for this cycle).\n\n * New topics start appearing in 'next', cook and graduate to\n 'master' as before.\n\n * The window closes. We pick what topics we should have in the\n new release.\n\n * We continue as before, but with the understanding that some\n topics in 'next' won't graduate before the new release.\n\n * Tag -rc1. 'next' really closes and we go into feature\n freeze.\n\n * RC cycle continues. Perhaps one or two RCs every week, as before.\n\n * The new release is made (hopefully within 3 months since the\n beginning of the cycle).\n\nThe important dates in the above would be (in parentheses are my\nstraw-mans):\n\n * The first maintenance release (+1 week from the last release)\n\n * The rebuilding of 'next' (immediately after the first maint)\n\n * The close of the window (+6 weeks from the last release)\n\n * The -rc1 (+8 weeks from the last release)\n\n * The new release (+12 weeks from the last release)\n\nFor 1.5.5, I'd like to make the above +6 weeks a bit short and\nmake it by the end of this month, though, so upcoming dates\nwould roughly be:\n\n - By the end of February, the 1.5.5 window closes;\n - By mid March, 1.5.5-rc1 is tagged;\n - By early April, 1.5.5 is released.\n\nWhich would make this week for the discussion to pick which\ntopic should be in 1.5.5.\n\nHere are the current candidates I personally have in mind for\ntopics that should be in 1.5.5:\n\n * describe --exact (Shawn)\n * checkout in C (Daniel)\n * format-patch --cover-letter (Daniel)\n * autodetect ncpu in threaded pack (Andreas Ericsson)\n * stash delete / stash pop (Dscho, Brandon Casey)\n * run-command API clean-ups (Johannes Sixt)\n * local branch tracking (Jay Soffian)\n * url rewriting (Daniel)\n * low-level merge improvements (Dscho)\n * apply --whitespace=fix improvements (me)\n * diff --relative (me)\n * diff --dirstat (Linus)\n - mergetool updates (Charles Bailey)\n - bisect vs cg-seek (Carl Worth)\n - worktree setup (Nguyễn Thái Ngọc Duy)\n - tightened object parser and walker safety (Martin Koegler)\n\nOne topic that is missing from the above list, which is queued\nin 'pu', worth mentioning is \"gitdir: $path in .git\" by Lars\nHjemli. The situation is like Dscho's \"reflog delete\" before we\ndid v1.5.4 in that it is waiting for a real user to prove this\nis a good enhancement. I am sure that later rounds would build\nenhancements to \"git submodule\" on top of this, and I think it\nis better to wait until that effort starts cooking.\n\nThoughts?\n"},{"id":"69815","messageId":"alpine.LFD.1.00.0802241226340.21332@woody.linux-foundation.org","threadId":"12297","inReplyTo":"7v8x1ataiu.fsf@gitster.siamese.dyndns.org","subject":"Re: Instituting feature and infrastructure enhancement proposal window?","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-02-24T20:42:47Z","receivedAt":"2008-02-24T20:42:47Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 24 Feb 2008, Junio C Hamano wrote:\n>\n> The important dates in the above would be (in parentheses are my\n> straw-mans):\n\nOn the merge window issue: I can heartily recommend it, but for the kernel \nwe have noticed:\n\n - people get really antsy it the releases are more than two months apart. \n Quite frankly, six weeks would be better, but it's just not realistic.\n\n - the kernel has to have a long stabilization phase, and I largely blame \n the fact that we have so much different hardware (and driver and arch \n changes are generally much more than 50% of all changes anyway). So we \n arguably need wider testing than projects that are more \"repeatable\" on \n a smaller set of machines.\n\nSo I think the merge window has worked out beautifully, but in a perfect \nworld, I'd make the window be roughly half the time of the release (rather \nthan about 20% as it is for the kernel), and aiming for a six-week release \ntiming. And I think both of those should be reasonably easy to hit within \nthe git development model.\n\nSo I would basically cut you target timeframes into half (except for the \nfirst -rc release - there's no point in making that less than a week). \nThree months is just going to make people who miss the release window \nantsy. It's what the kernel has in practice, and I would *not* advocate it \nas ideal - I actually aim for 2 months and we then invariably slip a bit..\n\nSo I'd suggest:\n - first -rc in 1 week\n - window closes in 3 weeks\n - next release in 6 weeks\n - rinse and repeat\n\nand if you worry that there won't be enough changes to merit a release, \ntrust me, that's the *good* schenario. Nobody will ever mind releases that \naren't disruptive, and you'll have an easy case with making them too. \nThere really are no downsides to having an easy release cycle with not a \nlot of big changes. I _wish_ I had more of those.\n\nAnd on exactly that note:\n\n> * diff --dirstat (Linus)\n\nI actually actively use this (not just for -rc releases, but I find it \nnice to do occasionally in other cases too), so it would be really nice if \nat least the initial version got merged soon. Even if it gets the binary \ncase wrong, and even if the statistics would arguably be better based on \n\"damage\" instead of just number of lines.\n\nOf course, I have it in my tree regardless, but especially with me then \npublicising the feature in my -rc releases (another one coming up today), \nI'd hope that you'd merge it so that others can use it too.. If this was \nat the end of a merge window, I'd hate to have to wait 1.5 months for the \nnext one to open.\n\n\t\t\tLinus\n"},{"id":"69835","messageId":"20080225005254.GJ8410@spearce.org","threadId":"12297","inReplyTo":"alpine.LFD.1.00.0802241226340.21332@woody.linux-foundation.org","subject":"Re: Instituting feature and infrastructure enhancement proposal window?","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-02-25T00:52:54Z","receivedAt":"2008-02-25T00:52:54Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Linus Torvalds wrote:\n> On Sun, 24 Feb 2008, Junio C Hamano wrote:\n> >\n> > The important dates in the above would be (in parentheses are my\n> > straw-mans):\n> \n> So I would basically cut you target timeframes into half (except for the \n> first -rc release - there's no point in making that less than a week). \n> Three months is just going to make people who miss the release window \n> antsy. It's what the kernel has in practice, and I would *not* advocate it \n> as ideal - I actually aim for 2 months and we then invariably slip a bit..\n> \n> So I'd suggest:\n> - first -rc in 1 week\n> - window closes in 3 weeks\n> - next release in 6 weeks\n> - rinse and repeat\n\nYea, I agree with Linus suggestion of cutting the time windows\ndown to closer to 2 months per release. 1.5.4 took a long time.\nIt doesn't really affect me as I usually run the bleeding edge\n'next', but I think most of our users feel warm and fuzzy about\nrunning a released version. As a community we need to help Junio\nget stable releases out more often, so users can benefit from the\nimprovements we've made.\n\n-- \nShawn.\n"},{"id":"69837","messageId":"7vir0dsto4.fsf@gitster.siamese.dyndns.org","threadId":"12297","inReplyTo":"alpine.LFD.1.00.0802241226340.21332@woody.linux-foundation.org","subject":"Re: Instituting feature and infrastructure enhancement proposal window?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-02-25T01:37:15Z","receivedAt":"2008-02-25T01:37:15Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> And on exactly that note:\n>\n>> * diff --dirstat (Linus)\n>\n> I actually actively use this (not just for -rc releases, but I find it \n> nice to do occasionally in other cases too), so it would be really nice if \n> at least the initial version got merged soon. Even if it gets the binary \n> case wrong,...\n\nI am planning to do this (dropping the \"damange\" one I\npreviously showed and queued in 'pu') and merge to 'master' for\nnow.\n\n-- >8 --\n[PATCH] diff --dirstat: saner handling of binary and unmerged files\n\nWe do not account binary nor unmerged files when --shortstat is\nasked for (or the summary stat at the end of --stat). \n\nThe new option --dirstat should work the same way as it is about\nsummarizing the changes of multiple files by adding them up.\n\nSigned-off-by: Junio C Hamano \n---\n diff.c | 7 ++++++-\n 1 files changed, 6 insertions(+), 1 deletions(-)\n\ndiff --git a/diff.c b/diff.c\nindex dd374d4..bcc323f 100644\n--- a/diff.c\n+++ b/diff.c\n@@ -1016,7 +1016,10 @@ static long gather_dirstat(struct diffstat_dir *dir, unsigned long changed, cons\n \t\t\tthis = gather_dirstat(dir, changed, f->name, newbaselen);\n \t\t\tsources++;\n \t\t} else {\n-\t\t\tthis = f->added + f->deleted;\n+\t\t\tif (f->is_unmerged || f->is_binary)\n+\t\t\t\tthis = 0;\n+\t\t\telse\n+\t\t\t\tthis = f->added + f->deleted;\n \t\t\tdir->files++;\n \t\t\tdir->nr--;\n \t\t\tsources += 2;\n@@ -1053,6 +1056,8 @@ static void show_dirstat(struct diffstat_t *data, struct diff_options *options)\n \t/* Calculate total changes */\n \tchanged = 0;\n \tfor (i = 0; i < data->nr; i++) {\n+\t\tif (data->files[i]->is_binary || data->files[i]->is_unmerged)\n+\t\t\tcontinue;\n \t\tchanged += data->files[i]->added;\n \t\tchanged += data->files[i]->deleted;\n \t}\n"},{"id":"69845","messageId":"alpine.LNX.1.00.0802242055330.19024@iabervon.org","threadId":"12297","inReplyTo":"7v8x1ataiu.fsf@gitster.siamese.dyndns.org","subject":"Re: Instituting feature and infrastructure enhancement proposal window?","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2008-02-25T03:25:37Z","receivedAt":"2008-02-25T03:25:37Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Sun, 24 Feb 2008, Junio C Hamano wrote:\n\n> If this proposal is accepted favorably by the list and is\n> implemented, a release cycle will look like this:\n> \n> * A release from 'master' is made (e.g. v1.5.4 gets released on\n> Feb 1st).\n> \n> * The release is merged to 'maint'.\n> \n> * Fix-ups to v1.5.4 start flowing and get applied to 'maint',\n> and merged to 'master'. At some point, the first maintenance\n> release is made (e.g. v1.5.4.1 was released on Feb 10th).\n> \n> * The topics that have been cooking in 'next' may be rebased to\n> v1.5.4, and 'next' is rebuilt on top of 'master' with them\n> (e.g. this happened on Feb 17th for this cycle).\n\nI'd actually like to have topics that don't make a release reverted in \n'next' and reapplied in 'pu'. That way, from the release to the rebuild of \n'next', 'next' and 'master' have identical trees, and it's therefore \ntrivial to rebase off of 'next'. Topics that were moved out to 'pu' in \nthis period would presumably be merged back into the rebased 'next' early.\n\nOr maybe, when 'next' closes, anything not in 'master' moves out to 'pu' \nuntil the rebuild.\n\n> * New topics start appearing in 'next', cook and graduate to\n> 'master' as before.\n> \n> * The window closes. We pick what topics we should have in the\n> new release.\n> \n> * We continue as before, but with the understanding that some\n> topics in 'next' won't graduate before the new release.\n> \n> * Tag -rc1. 'next' really closes and we go into feature\n> freeze.\n> \n> * RC cycle continues. Perhaps one or two RCs every week, as before.\n> \n> * The new release is made (hopefully within 3 months since the\n> beginning of the cycle).\n\nSo what would be the 'pu' policy through this? I think one of the reasons \nthat the kernel manages to do well with a short cycle is that stuff sits \nin -mm for some time, in general, before hitting mainline. This both means \nthat people can get their code exposure without hurrying it into the merge \nwindow and that code can cook as long as necessary before starting to \nimpact end users.\n\nIn any case, I like the short cycle idea.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"}]}