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

Re: [PATCH v3] Add core.mode configuration

From
Felipe Contreras <felipe.contreras@gmail.com>
Date
Oct 16, 2013, 19:57 UTC
Message-ID
<525eef9ea46bd_3983c19e7c61@nysa.notmuch>
In-Reply-To
<CAEBDL5UaowCZggHijoqPF2UP5B6Y6Bkr9eP+A-Z3-x71W1Oi6Q@mail.gmail.com>
John Szakmeister wrote:
Show 21 quoted lines
> On Wed, Oct 16, 2013 at 6:54 AM, John Szakmeister <john@szakmeister.net> wrote:
> [snip]
> > "probably a minority" -- I guess that's the part I disagree with.  I'm
> > not sure what a minority means here, but I don't think it'll be a
> > handful of people.  How big does that number get before we get
> > concerned about backlash from users if we decide to change course?
> > Or, is that simply not an issue?  Why or why not?  I have to be
> > honest, if the option was available, I'd have my developers turn it
> > on.  I'm sure a great deal of others would do so too.
> >
> > Is there some other way we can solve this?  Having an experimental
> > branch with all the 2.0 features merged and those concerned can just
> > build that version?  I see the downside of that too: it's not as easy
> > for people to try, and there is nothing preventing folks from posting
> > binaries with the new behaviors enabled.  It leads me to feeling that
> > we're stuck in some regard.  But maybe I'm being overly pessimistic
> > here, and it's really all a non-issue.  As I said earlier, it'd be
> > nice if others chimed in here.
> 
> Thinking about this a little more, we do have a proving ground.
> That's what the whole pu/next/master construct is for.
No, that's not true.

'next' doesn't contain experimental patches, it contains potentially dangerous one that might benefit from some testing before going to master, but they are certainly not experimental.

'pu' doesn't contain experimental code either, the code in 'pu' has to be feature complete. It might require a few more tunning patches, but it's not experimental, and those branches are not long lived. For example the pack-v4 patches could be merged today, and the people involved could keep working on top of that merge point, but that doesn't happen, because 'pu' is not for experimental stuff.

There is no place in the Git repository for pack-v4, because there's no place for experimental patches.

> So maybe this is a non-issue.  By the time it lands on master, we should have
> decided whether the feature is worth keeping or not.

I believe without an experimental branch, many branches would never mature to go into master, or next, or even pu.

-- 
Felipe Contreras
Previous: John SzakmeisterNext: Felipe Contreras
Message 15 of 25 in “Add core.mode configuration”
  1. Add core.mode configurationFelipe Contreras, Oct 12, 2013
  2. Krzysztof MazurOct 14, 2013
  3. Felipe ContrerasOct 14, 2013
  4. Krzysztof MazurOct 15, 2013
  5. Felipe ContrerasOct 15, 2013
  6. Krzysztof MazurOct 15, 2013
  7. Felipe ContrerasOct 15, 2013
  8. Krzysztof MazurOct 15, 2013
  9. John SzakmeisterOct 15, 2013
  10. Felipe ContrerasOct 16, 2013
  11. Krzysztof MazurOct 16, 2013
  12. Felipe ContrerasOct 16, 2013
  13. John SzakmeisterOct 16, 2013
  14. John SzakmeisterOct 16, 2013
  15. Felipe ContrerasOct 16, 2013
  16. Felipe ContrerasOct 16, 2013
  17. Philip OakleyOct 16, 2013
  18. Jonathan NiederOct 16, 2013
  19. Philip OakleyOct 17, 2013
  20. Felipe ContrerasOct 17, 2013
  21. Felipe ContrerasOct 15, 2013
  22. Krzysztof MazurOct 15, 2013
  23. Felipe ContrerasOct 16, 2013
  24. Krzysztof MazurOct 16, 2013
  25. Felipe ContrerasOct 16, 2013

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.