From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Kaushal Modi Newsgroups: gmane.emacs.devel Subject: Re: Next release from master Date: Tue, 9 Feb 2016 21:34:57 -0500 Message-ID: References: <8qegda3kfg.fsf@fencepost.gnu.org> <83h9i695n5.fsf@gnu.org> <87si118q6e.fsf@gnus.org> <877fid5u3e.fsf@gmx.us> <87bn7pwgaj.fsf@wanadoo.es> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11c2b0ea0976cd052b614ab5 X-Trace: ger.gmane.org 1455071746 15742 80.91.229.3 (10 Feb 2016 02:35:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 10 Feb 2016 02:35:46 +0000 (UTC) Cc: Emacs developers To: =?UTF-8?Q?=C3=93scar_Fuentes?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Feb 10 03:35:46 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aTKd7-0003To-FK for ged-emacs-devel@m.gmane.org; Wed, 10 Feb 2016 03:35:45 +0100 Original-Received: from localhost ([::1]:34707 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aTKd6-0000SO-Iz for ged-emacs-devel@m.gmane.org; Tue, 09 Feb 2016 21:35:44 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51235) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aTKd1-0000Pg-Mi for emacs-devel@gnu.org; Tue, 09 Feb 2016 21:35:40 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aTKd0-0004hL-Eg for emacs-devel@gnu.org; Tue, 09 Feb 2016 21:35:39 -0500 Original-Received: from mail-ob0-x22e.google.com ([2607:f8b0:4003:c01::22e]:34308) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aTKd0-0004hD-0V for emacs-devel@gnu.org; Tue, 09 Feb 2016 21:35:38 -0500 Original-Received: by mail-ob0-x22e.google.com with SMTP id wb13so9278201obb.1 for ; Tue, 09 Feb 2016 18:35:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=gJdurOw9iAlwIEtksBcZApSMQhJ5BsDy7RO0L6Z+OHo=; b=SkYKwiXr340OEUHxiDmppUs1hzb5Q2q8Kq3T/GIF5le4HEmGS1+45ciZRTGsWksvq3 6XVpfi+KcEUoSkQtKnl6GQO0f8jaJkFe5oS46vM9bE37NnqRntnj4rKmL3iTJhvMgskj XPgxqDO1uiro5Lr1TS0ayAdWiaQiB+jhukyJUrSGhblHjq8SW7K9lpJmqFTpvhJCk/mt dULM6gT6b2u6CRQgi+9ehQVGKljXaWFI+EIl/FzkevoWeDmM3IAlBvHU3rOgIKwETeVW enSCE4Ndp13VAlaV8XQoorhv3XkcTs24qK8MSMAM7TMIWkxbbqWuSiWUkxW/O5el8jc/ /Yfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=gJdurOw9iAlwIEtksBcZApSMQhJ5BsDy7RO0L6Z+OHo=; b=eRhdAuelzsXCbEjotWujOqg993piO8B5m8r0DHK7A9LXydfxQ2gEg0L7cfNPV6ZV3W E1+cyv7qdN5b9gxI+Zn1Zw4OJjv1k3DEDy9LrWgOdsc0EOtUg4Cd3nkn1GJaop2xUHau 9JCT5plx621FPQqP9xOhHJfS7ztMKGV0sYtGOIQxGa+gce7Q2HHM6V16ade/7f7M3vv2 +vP3bqUtqQaw3huSH73LJUNJtX/SKfzudvcNuMhwzHMCU3VeCrhkqpkBHVx/ty1VGXEE s/GiLoqUcxAHd8bTUO4Kxik3IaoQ76etB6ZctUfmT2nZCCby8GPjBAKbfCuwIynCjKTn SZwQ== X-Gm-Message-State: AG10YOTfyEnEopXVm8jHMhZJEhhVHfzF1c256IBwQvo6E6jAtGfmxNuvsWEiew8fhHL7rMUx/RDCFY2kewLiXw== X-Received: by 10.182.241.134 with SMTP id wi6mr33063857obc.81.1455071737507; Tue, 09 Feb 2016 18:35:37 -0800 (PST) Original-Received: by 10.202.201.73 with HTTP; Tue, 9 Feb 2016 18:34:57 -0800 (PST) In-Reply-To: <87bn7pwgaj.fsf@wanadoo.es> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2607:f8b0:4003:c01::22e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:199661 Archived-At: --001a11c2b0ea0976cd052b614ab5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Feb 9, 2016 at 7:38 PM, =C3=93scar Fuentes 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- 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 --001a11c2b0ea0976cd052b614ab5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Tue, Feb 9, 2016 at 7:38 PM, =C3=93scar Fuentes <ofv@wanadoo.es> wrote:
What does "to be tested" mean here? Does it mean that the featu= re 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 i= s just an example, I haven't needed to do that yet).=C2=A0
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 contributi= ons, and also because of the feedback for new additions received on this li= st. But it is possible that some new addition breaks some arcane inbuilt/ex= ternal package I/someone else might be using. It's for that purpose tha= t the more people use the dev builds as their DD, the better.
Now if there were a separate branch for each new feature, it wo= uld cause the following problems:
- Necessity to keep builds read= y 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 (th= at's probably what Rasmus referred too).
- This results in fr= equent need to juggle between the feature branch builds, master build and l= ocal merged build.

=C2=A0
Or is "testing" on t= he sense
of "let's see if the feature is interesting enough for definitive<= br> 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"?
<= div>
Testing of a feature for its definitive inclusion can st= ill be done on the master branch (like we did for the multiple dir-locals.e= l feature). As more people would be testing the same master branch build (i= nstead of people being split between master branch and XYZ feature branch),= we would get a better collection of opinions and feedback about that featu= re.

I am not a software developer. So these viewpo= ints should be taken as from someone who simply likes to build and try out = the latest emacs builds :)=C2=A0


--
Kaushal Modi
--001a11c2b0ea0976cd052b614ab5--