Git Mailing List Archive on lore.kernel.org
 help / color / Atom feed
From: Felipe Contreras <felipe.contreras@gmail.com>
To: John Szakmeister <john@szakmeister.net>,
	Felipe Contreras <felipe.contreras@gmail.com>
Cc: Krzysztof Mazur <krzysiek@podlesie.net>, git@vger.kernel.org
Subject: Re: [PATCH v3] Add core.mode configuration
Date: Wed, 16 Oct 2013 14:57:18 -0500
Message-ID: <525eef9ea46bd_3983c19e7c61@nysa.notmuch> (raw)
In-Reply-To: <CAEBDL5UaowCZggHijoqPF2UP5B6Y6Bkr9eP+A-Z3-x71W1Oi6Q@mail.gmail.com>

John Szakmeister wrote:
> 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

  reply index

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-12  7:04 Felipe Contreras
2013-10-14 20:59 ` Krzysztof Mazur
2013-10-14 21:35   ` Felipe Contreras
2013-10-15 12:35     ` Krzysztof Mazur
2013-10-15 12:32       ` Felipe Contreras
2013-10-15 13:33         ` Krzysztof Mazur
2013-10-15 13:29           ` Felipe Contreras
2013-10-15 14:51             ` Krzysztof Mazur
2013-10-15 16:59               ` John Szakmeister
2013-10-16  3:55                 ` Felipe Contreras
2013-10-16  7:09                   ` Krzysztof Mazur
2013-10-16 19:31                     ` Felipe Contreras
2013-10-16 10:54                   ` John Szakmeister
2013-10-16 15:11                     ` John Szakmeister
2013-10-16 19:57                       ` Felipe Contreras [this message]
2013-10-16 19:32                     ` Felipe Contreras
2013-10-16 22:02                       ` Philip Oakley
2013-10-16 23:06                         ` Jonathan Nieder
2013-10-17 19:48                           ` Philip Oakley
2013-10-17 21:08                           ` Felipe Contreras
2013-10-15 18:51               ` Felipe Contreras
2013-10-15 22:01                 ` Krzysztof Mazur
2013-10-16  4:03                   ` Felipe Contreras
2013-10-16  6:34                     ` Krzysztof Mazur
2013-10-16 19:28                       ` Felipe Contreras

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=525eef9ea46bd_3983c19e7c61@nysa.notmuch \
    --to=felipe.contreras@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=john@szakmeister.net \
    --cc=krzysiek@podlesie.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Git Mailing List Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/git/0 git/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 git git/ https://lore.kernel.org/git \
		git@vger.kernel.org
	public-inbox-index git

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.git


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git