All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@redhat.com>
To: Tom Gundersen <teg@jklm.no>
Cc: Chris Mason <chris.mason@fusionio.com>,
	Duncan <1i5t5.duncan@cox.net>,
	linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: Question: btrfs-progs releases?
Date: Sat, 17 Aug 2013 22:50:51 -0500	[thread overview]
Message-ID: <5210449B.7000302@redhat.com> (raw)
In-Reply-To: <CAG-2HqWDqjS2Er8FvwwgTkfMjoouwvjQeipHy_+ia7iTTfT==w@mail.gmail.com>

On 8/17/13 10:25 PM, Tom Gundersen wrote:
> On Sat, Aug 17, 2013 at 7:59 PM, Chris Mason <chris.mason@fusionio.com> wrote:
>> The problem with the progs release is I keep finding more things I want
>> to add.  My local git tree has about a dozen commits that I feel are
>> important enough for v1.0.  I just have to cut it, the distros and
>> others are completely correct in asking for an official release.
> 
> I know this feeling too well.
> 
> In order to just "get something out", it might make sense to just do
> some time-based releases every now and again (and maybe call them 0.X,
> rather than 1.0 until you are happy). Even the occasional (maybe after
> each kernel release) git tag (without actually creating tarballs etc)
> would be very helpful, as at least we would have a common reference
> point for bug reports and similar (and after all, numbers are cheap
> ;-)).
> 
> From your point of view, having frequent releases will also (I
> suppose) be helpful as it will make sure your users/testers are using
> the most recent version (at least in Arch, whatever you tag we will
> ship within a few days) and hence you won't have to ask them to
> rebuild from git to make sure the bug hasn't already been fixed.
> 
>> In terms of the quality of the commits, I only put things into the
>> master branch of the git tree that I have fully confidence in.
> 
> Thanks for the info Chris, this is useful to know. I'll keep pushing
> git snapshots then (but as I said, tags would be better).

>From my perspective, I don't want to push git snapshots; I'll fix one bug
and add another.

We desperately need btrfs-progs stabilization and release.

-Eric

  reply	other threads:[~2013-08-18  3:50 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAG-2HqVFdRjnK1LHnLDPm8frw1MtG2k44N=n4hhdv9kpdf4VoQ@mail.gmail. com>
2013-08-17  5:02 ` Question: btrfs-progs releases? Duncan
2013-08-17 11:59   ` Chris Mason
2013-08-18  3:25     ` Tom Gundersen
2013-08-18  3:50       ` Eric Sandeen [this message]
2013-08-20  0:50         ` Chris Mason
2013-08-17  3:19 Tom Gundersen

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=5210449B.7000302@redhat.com \
    --to=sandeen@redhat.com \
    --cc=1i5t5.duncan@cox.net \
    --cc=chris.mason@fusionio.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=teg@jklm.no \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.