git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Let's make our cycles shorter

From
Junio C Hamano <gitster@pobox.com>
Date
Mar 31, 2011, 22:35 UTC
Message-ID
<7vvcyyhq9q.fsf@alter.siamese.dyndns.org>
In-Reply-To
<7v62qzhqp4.fsf@alter.siamese.dyndns.org>

I've been aiming for 6-8 week cycles but the 1.7.5 cycle ended up being way longer than that. I just tagged a -rc0 and it will be mirroring out, and today's "What's cooking" has annotations on topics in flight that I expect to be in the -rc1.

This message is primarily meant to be a reminder to myself and also to clarify my intentions. I'd like one cycle of ours to look roughly like this:

 - 1.7.5 is released.
 - Week 1: post release clean-up.  People are strongly encouraged to give
   the highest priority to the regression fixes for the most recent
   release.
 - Week 2: new features, restructuring, non-regression bugfixes start to
   flow in and graduate in preparation for 1.7.6.  Some may graduate from
   'next' before 1.7.5 to master, some may be newly queued through 'pu' to
   'next'.
 - Week N: 1.7.6-rc0 is tagged.  Examine topics in 'next' that are still
   not in 'master' and decide which way they should go, either included in
   1.7.6-rc1 or wait until the next cycle.
 - Week N+1: 1.7.6-rc1 is tagged with (a subset of) candidate topics we
   decided previous week.
   At this point, people are again strongly encouraged to give the highest
   priority to the regression fixes for the upcoming release.
 - Week N+2: 1.7.6-rc2 is tagged.
 - Week X: 1.7.6 is released.

Historically we have done at least two rc releases, and often three, so I would expect X is at least N+3 but possibly N+4. Since I want to have at most an 8-week cycle, it would mean N=4 or 5, so we have three to four weeks to concentrate the real development for the next release.

We are at "Week N" for this cycle as of today.

This of course does not mean that people are forbidden from working on or discussing anything but regression fixes during the rc and post-release period. It may take longer than a month to stabilize for a large-ish topic to be properly reviewed, discussed and guinea-pigged in 'next'.

So during Weeks N thru X, there may appear new topics in flight and I may end up queueing them in 'pu' or even move some of them to 'next', with an understanding that they will not be part of the current cycle, but are queued merely to make it easier for people interested in the new topic to try out and discuss ideas for the next cycle. Also handling these new topics during the rc period will receive much lower priority and time from me.

I hope all the above sound sensible.  Thanks.
Previous: Junio C HamanoNext: Sebastien Douche
Message 2 of 13 in “What's cooking in git.git (Mar 2011, #06; Thu, 31)”
  1. Junio C HamanoMar 31, 2011
  2. Let's make our cycles shorterJunio C Hamano, Mar 31, 2011
  3. Sebastien DoucheApr 25, 2011
  4. Junio C HamanoApr 25, 2011
  5. Sebastien DoucheJun 13, 2011
  6. git diff -D: omit the preimage of deletesMichael J Gruber, Apr 1, 2011
  7. Junio C HamanoApr 1, 2011
  8. Junio C HamanoApr 3, 2011
  9. Junio C HamanoApr 3, 2011
  10. Michael J GruberApr 3, 2011
  11. Jeff KingApr 1, 2011
  12. Junio C HamanoApr 1, 2011
  13. Jeff KingApr 1, 2011

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.