From: Kaushal Modi <kaushal.modi@gmail.com>
To: "Óscar Fuentes" <ofv@wanadoo.es>
Cc: Emacs developers <emacs-devel@gnu.org>
Subject: Re: Next release from master
Date: Tue, 9 Feb 2016 21:34:57 -0500 [thread overview]
Message-ID: <CAFyQvY0mxYR32j9YVXf+KJ7MWekkFuBQe-owPFj_QM2HW5vXwg@mail.gmail.com> (raw)
In-Reply-To: <87bn7pwgaj.fsf@wanadoo.es>
[-- Attachment #1: Type: text/plain, Size: 2406 bytes --]
On Tue, Feb 9, 2016 at 7:38 PM, Óscar Fuentes <ofv@wanadoo.es> wrote:
> What does "to be tested" mean here? Does it mean that the feature was
> not thoroughly tested by the developer yet?
>
I use the dev builds of emacs as my daily driver. I keep the emacs-25 and
master builds ready at all times. For now, I am using emacs-25 as my daily
driver, mainly to test it thoroughly before its public release. But if some
bug creeps in that thwarts my day-job work, then I can report that and
switch to using the master branch build till the bug gets fixed (this is
just an example, I haven't needed to do that yet).
I am able to use the emacs-25/master builds as my daily driver because the
developers are doing a great job of verifying their contributions, and also
because of the feedback for new additions received on this list. But it is
possible that some new addition breaks some arcane inbuilt/external package
I/someone else might be using. It's for that purpose that the more people
use the dev builds as their DD, the better.
Now if there were a separate branch for each new feature, it would cause
the following problems:
- Necessity to keep builds ready for different features to try in addition
to the master/emacs-<VER> branch
- If I stay on a feature branch for too long, I will miss out the fixes,
etc on the master branch. To prevent that, I might need to manually merge
that feature in the master branch locally and then build (that's probably
what Rasmus referred too).
- This results in frequent need to juggle between the feature branch
builds, master build and local merged build.
> Or is "testing" on the sense
> of "let's see if the feature is interesting enough for definitive
> inclusion into Emacs but now it is all over the place and removing it
> would be a lot of work so it is here to stay"?
>
Testing of a feature for its definitive inclusion can still be done on the
master branch (like we did for the multiple dir-locals.el feature). As more
people would be testing the same master branch build (instead of people
being split between master branch and XYZ feature branch), we would get a
better collection of opinions and feedback about that feature.
I am not a software developer. So these viewpoints should be taken as from
someone who simply likes to build and try out the latest emacs builds :)
--
Kaushal Modi
[-- Attachment #2: Type: text/html, Size: 3130 bytes --]
next prev parent reply other threads:[~2016-02-10 2:34 UTC|newest]
Thread overview: 120+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-12 7:09 emacs-25 merge pushed, please confirm John Wiegley
2016-01-12 11:12 ` Alex Bennée
2016-01-12 16:19 ` John Wiegley
2016-01-17 23:04 ` Next release from master Stefan Monnier
2016-01-17 23:10 ` John Wiegley
2016-01-18 9:06 ` Michael Albinus
2016-01-18 15:55 ` Eli Zaretskii
2016-01-18 20:06 ` Michael Albinus
2016-01-18 20:25 ` Eli Zaretskii
2016-01-18 15:55 ` Eli Zaretskii
2016-01-18 21:13 ` John Wiegley
2016-01-18 21:31 ` Daniel Colascione
2016-01-18 21:43 ` John Wiegley
2016-01-18 21:45 ` Daniel Colascione
2016-01-18 21:51 ` John Wiegley
2016-01-18 22:15 ` Stefan Monnier
2016-01-18 22:18 ` John Wiegley
2016-01-19 3:36 ` Eli Zaretskii
2016-01-18 15:54 ` Eli Zaretskii
2016-01-21 17:35 ` Glenn Morris
2016-01-21 17:58 ` Eli Zaretskii
2016-02-04 17:39 ` Glenn Morris
2016-02-04 20:31 ` John Wiegley
2016-02-08 13:41 ` Stefan Monnier
2016-02-08 15:54 ` John Wiegley
2016-02-08 16:47 ` Dmitry Gutov
2016-02-09 14:55 ` John Wiegley
2016-02-09 15:15 ` Dmitry Gutov
2016-02-09 14:57 ` Stefan Monnier
2016-02-09 22:38 ` Lars Ingebrigtsen
2016-02-09 23:42 ` Rasmus
2016-02-10 0:09 ` Kaushal Modi
2016-02-10 0:38 ` Óscar Fuentes
2016-02-10 2:04 ` Lars Ingebrigtsen
2016-02-10 2:42 ` Óscar Fuentes
2016-02-10 3:00 ` Lars Ingebrigtsen
2016-02-10 3:43 ` Óscar Fuentes
2016-02-10 4:01 ` Lars Ingebrigtsen
2016-02-10 3:28 ` Alexis
2016-02-10 3:33 ` Dmitry Gutov
2016-02-10 4:02 ` Óscar Fuentes
2016-02-10 4:13 ` Dmitry Gutov
2016-02-10 4:51 ` Alexis
2016-02-10 5:28 ` Dmitry Gutov
2016-02-10 18:10 ` Eli Zaretskii
2016-02-10 4:58 ` Óscar Fuentes
2016-02-10 5:07 ` Lars Ingebrigtsen
2016-02-10 5:16 ` Dmitry Gutov
2016-02-10 18:09 ` Eli Zaretskii
2016-02-10 18:09 ` Eli Zaretskii
2016-02-10 5:08 ` Alexis
2016-02-10 5:10 ` Dmitry Gutov
2016-02-10 18:08 ` Eli Zaretskii
2016-02-10 18:03 ` Eli Zaretskii
2016-02-10 4:04 ` Alexis
2016-02-10 4:23 ` Dmitry Gutov
2016-02-10 18:07 ` Eli Zaretskii
2016-02-10 17:58 ` Eli Zaretskii
2016-02-11 17:21 ` Paul Eggert
2016-02-11 18:11 ` John Wiegley
2016-02-10 17:56 ` Eli Zaretskii
2016-02-11 3:35 ` Daniel Colascione
2016-02-11 3:55 ` Óscar Fuentes
2016-02-11 15:24 ` John Wiegley
2016-02-11 16:07 ` Mark Oteiza
2016-02-11 16:20 ` Óscar Fuentes
2016-02-11 16:59 ` Teemu Likonen
2016-02-11 19:33 ` Daniel Colascione
2016-02-10 2:34 ` Kaushal Modi [this message]
2016-02-10 3:24 ` Óscar Fuentes
2016-02-10 21:46 ` Rasmus
2016-02-10 16:40 ` John Wiegley
2016-02-10 17:18 ` Dmitry Gutov
2016-02-10 16:41 ` John Wiegley
2016-02-10 17:07 ` Dmitry Gutov
2016-02-10 18:06 ` Óscar Fuentes
2016-02-11 3:47 ` Daniel Colascione
2016-01-22 1:01 ` John Wiegley
2016-01-22 1:28 ` Dmitry Gutov
2016-01-22 1:42 ` Paul Eggert
2016-01-22 3:50 ` Xue Fuqiao
2016-01-22 1:46 ` John Wiegley
2016-01-22 1:48 ` Dmitry Gutov
2016-01-22 1:56 ` John Wiegley
2016-01-22 7:32 ` Eli Zaretskii
2016-01-22 7:38 ` John Wiegley
2016-01-22 14:59 ` Barry Fishman
2016-01-22 17:45 ` John Wiegley
2016-01-22 21:27 ` Barry Fishman
2016-01-23 1:47 ` John Wiegley
2016-01-25 10:38 ` Alex Bennée
2016-01-25 15:56 ` Eli Zaretskii
2016-01-23 5:17 ` Stefan Monnier
2016-01-23 17:09 ` Barry Fishman
2016-01-23 20:06 ` John Wiegley
2016-01-24 4:26 ` Stefan Monnier
2016-01-24 14:11 ` Eli Zaretskii
2016-01-24 18:04 ` Stefan Monnier
2016-01-24 18:35 ` Eli Zaretskii
2016-01-25 2:20 ` Stefan Monnier
2016-01-22 7:26 ` Eli Zaretskii
2016-01-22 8:10 ` Michael Albinus
2016-01-22 8:25 ` Eli Zaretskii
2016-01-22 8:58 ` Nicolas Petton
2016-01-22 9:02 ` Michael Albinus
2016-01-22 17:42 ` John Wiegley
2016-01-22 19:02 ` Michael Albinus
2016-01-22 19:16 ` Alan Mackenzie
2016-01-22 21:22 ` Eli Zaretskii
2016-01-22 7:11 ` Eli Zaretskii
2016-01-23 5:25 ` Stefan Monnier
-- strict thread matches above, loose matches on Subject: below --
2016-02-11 16:28 Angelo Graziosi
2016-02-11 17:09 ` John Wiegley
2016-02-11 17:26 ` Paul Eggert
2016-02-11 17:27 ` Angelo Graziosi
2016-02-11 21:08 ` Eli Zaretskii
2016-02-11 21:04 ` Eli Zaretskii
2016-02-11 19:36 ` Stefan Monnier
2016-02-11 19:40 ` John Wiegley
2016-02-12 12:34 ` Richard Stallman
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAFyQvY0mxYR32j9YVXf+KJ7MWekkFuBQe-owPFj_QM2HW5vXwg@mail.gmail.com \
--to=kaushal.modi@gmail.com \
--cc=emacs-devel@gnu.org \
--cc=ofv@wanadoo.es \
/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.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).