From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mike Mattie Newsgroups: gmane.emacs.devel Subject: Turning in quality work, the goal of merging Date: Sun, 6 Jan 2008 06:54:17 -0800 Message-ID: <20080106065417.029dcfb3@reforged> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2139439016==" X-Trace: ger.gmane.org 1199631447 26960 80.91.229.12 (6 Jan 2008 14:57:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 6 Jan 2008 14:57:27 +0000 (UTC) To: emacs developers Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 06 15:57:47 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1JBWwY-0002Oi-F5 for ged-emacs-devel@m.gmane.org; Sun, 06 Jan 2008 15:57:43 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JBWwB-0007GR-LP for ged-emacs-devel@m.gmane.org; Sun, 06 Jan 2008 09:57:19 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JBWw7-0007GJ-Oa for emacs-devel@gnu.org; Sun, 06 Jan 2008 09:57:15 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JBWw2-0007FN-IQ for emacs-devel@gnu.org; Sun, 06 Jan 2008 09:57:15 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JBWw2-0007FK-CC for emacs-devel@gnu.org; Sun, 06 Jan 2008 09:57:10 -0500 Original-Received: from wa-out-1112.google.com ([209.85.146.180]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JBWw1-0003l1-OA for emacs-devel@gnu.org; Sun, 06 Jan 2008 09:57:10 -0500 Original-Received: by wa-out-1112.google.com with SMTP id k34so11866877wah.10 for ; Sun, 06 Jan 2008 06:57:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject:message-id:x-mailer:mime-version:content-type; bh=GhCmvU8HvEeKlI2EYYy7DLgo5n/T51AH25arxaZfwN4=; b=N3TBaWDhLBdN1lftUWc0x84aomQyJwCFfBjLDExP2nPfy/5Sx4lbuanikM9BiGaSf7B+Vjw51BCliLENuKxR0qlNmv21+aQVsRxnCfwbjtcFCYWWwpLpsVlZXXr/xFfyzvjEWVo79LCHmna/yjrD2NxiCGMSeJ6TzaOzcOsygTg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:x-mailer:mime-version:content-type; b=eF8quwrprPRlNUgrE7AIqBoSth8i8ojRfEqIvGqfgRB418p0KIj0QYE1Zdan9a4oI5T7e/vwwvss/tzDAgZL1Ghi+BYz5L90mTWr07OrwPc+rsmCh8NyFIEiBiuKqwGXRAEUluTpoiwILGhOKo5oCZ7FTnlVtUojlAa9vro/dX0= Original-Received: by 10.115.94.1 with SMTP id w1mr3272426wal.85.1199631428817; Sun, 06 Jan 2008 06:57:08 -0800 (PST) Original-Received: from reforged ( [71.217.198.62]) by mx.google.com with ESMTPS id m17sm33008048waf.41.2008.01.06.06.57.07 (version=SSLv3 cipher=OTHER); Sun, 06 Jan 2008 06:57:08 -0800 (PST) X-Mailer: Claws Mail 3.0.2 (GTK+ 2.12.1; i686-pc-linux-gnu) X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 2) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:86330 Archived-At: --===============2139439016== Content-Type: multipart/signed; boundary="Sig_/LHmQB2UVZJtL7HXMGP1J2oC"; protocol="application/pgp-signature"; micalg=PGP-SHA1 --Sig_/LHmQB2UVZJtL7HXMGP1J2oC Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hello, -> Intro I would like to add some relevant ideas to the discussion of merging which = has devolved into tools. I tried to shy away from the discussion but it's hard when you are being di= scussed in the third person. I am the third person in that I am very likely younger than most of= the people on this list.=20 Having said that age is irrelevant to the issue, the only real difference b= eing the music I enjoy. Everything else is the same, an unpopular foreign war and lots of = anti-war lyrics. Oh yeah, bottled water, that's new :) -> Meat Much of the debate so far has devolved into trying to explain one tool in t= erms of another, without much discussion of what the goals, or criteria for merging is. What would be useful IMHO is to articulate what it is to turn in quality wo= rk for review and inclusion in a code-base. With a high standard for quality clearly fixe= d there is opportunity for Emacs to innovate beyond the current tools if necessary and= take the lead in excellence for no other reason than our own desire to benefit from = that excellence. So here is a sketch of what a programmer who happens to be a bit younger th= inks of merging. Quality in merging is preparing the work you have done for review and integ= ration. Not a single tool out there supports the developer before he publishes his changes. My ideal scenario is to first conceive an idea. I will hack away at it from= several different angles until a development plan forms in my mind. A development plan and a = merge plan are the same thing: a sequence of steps that incrementally construct the desire= d changes. A good interface for supporting this would have something like the speedbar= on the side of a development window. In this side-window I would create and maintain my= plan. Each of the steps in the plan would be a change-log entry in progress. It would = describe succinctly and completely the purpose of each change-set, significant desig= n and implementation properties such as algorithms I have chosen, vital knowledge discovered whi= le exploring the problem domain, and impact on the existing code-base. While I am developing the code essentially ad-hoc (as is all development un= less you have solved that problem before) I am committing changes. The changelog for these chang= es is essentially irrelevant to the merge and largely useless because it is likely a long seq= uence of "fixed this", "spelling fixes", "added function foo". What I need in a tool is a facility to clean up my ad-hoc change history in= to the merge plan that is also serving as a tool to keep my eye on the ball. Say I have decid= ed on a three step plan to add a feature. I notice that other parts of the code-base have to b= e changed as well, or will benefit from using some of my code. My first step is to introduce as much of my code as possible as dead-code a= nd make sure nothing is affected AFAICT. The second step is to make any modifications necessary = to the existing code-base that aren't intrinsically linked to new features, and verify that= I haven't introduced regressions. My third step is to add my new feature. I think any merge should have this as the basic plan as it mitigates risk t= o the existing code at each step, and takes care to ensure that it places the least burden poss= ible on the reviewers. Each of these steps needs to be testable in my working-copy to check that e= ach step compiles, does not have regressions, and missing pieces. When it looks like my new code is ready to merge I run into a big problem t= hat existing tools don't even address much less resolve. My goal is to merge in three steps: M= 1, M2, M3. If I have a function "foo" that needs to go in step 1 or M1 I have a proble= m. The changes to function foo are scattered throughout the chronology of my revision hist= ory. What I need to do is re-order my revision history to organize it properly. A interface for doing such a thing would ideally have my plan in one window= , and my change history in another. I would like to be able to sort the changes into the me= rge plan by selecting a change and "attaching" it to one of my merges. M1 (changelog text) |-> change |-> change M2 |-> change |-> change If I attach my introduction of function foo into step M1, it is also going = to show up in M2, and M3. Now later in the chronology of my revisions I have various fixe= s for function foo. I want to attach those changes to M1, and have it automatically adjust the = diffs for M2, M3, The only tool that is even close to something like this is darcs with it's = theory of commutation of patches. Now when you consider the possibility of code moving around it = gets really hairy and you might assume it is impossible. It is not, at least with Emacs. It i= s theoretically possible that Emacs can track the movement of code, where tracking is being= able to for a given region of code, identify it's location in any given revision starti= ng from where it was introduced. In fact Emacs could even track copy and paste in theory. Assuming that my hypothetical tool has allowed me to re-organize my change = history into my merge plan I can now commit a coherent planned merge sequence. Even bett= er I was able to incrementally develop my merge plan and merge change-logs while I was de= veloping instead of trying to write it down at one sitting, largely from memory and tedious = review. Now that I have finished the private development phase I need to get review= . At this point I need to commit on a branch, as any multiple change commit does to r= emain atomic. This introduces two new kinds of changes that I need to organize into my pr= epared merge. First is various fixes and changes I will get from review. Assuming I have = my tool for re-organizing my revisions this is no problem. To actually merge though= I need to re-base against the latest revision. Rebasing introduces M0, changes that reconcile my merge sequence of M1,M2,M= 3 against the head. This stage is not something I want to expose for review, it is th= e tool's internal representation of rebase. It is special in that it doesn't have th= e benefit of being able to track the movement of code as Emacs can in my working repo= sitory. Assuming I have successfully passed review and rebased, I need to commit. A= t this point I need to deal with the project's version control system. A key point= is that which VCS system in use is *entirely* random. I may work on a dozen differe= nt projects and each one has chosen their own VCS for their own reasons. If the hypothetical tool I have outlined above is built into the VCS it's n= early useless since integrating my changes into their code should not be predicat= ed on the necessity of convincing them to switch their entire project over to the mythical *one true VCS to rule them all*. Even assuming that the current debate results in switching to a new VCS that doesn't help any of the Emacs developers on all the other projects they are involved in. Questions: 1. Do the Emacs developers consider the above description to be a good stan= dard or goal for merging practices. 2. What is the existing standard for merging ? Is it compatible, better, or= worse than what I have described. (I am all ears for the lessons learned by a proje= ct at rev 23) 3. Can existing tools be used to implement this work-flow ? 4. Can new tools be built to facilitate this work-flow with any given VCS s= ystem ? ie can vc be hacked towards this direction if the Emacs developers so de= sire ? In closing I will use any tool that let's me reach a higher standard of qua= lity than I could without it, and I never get to choose the tools unless it's my project, or my machine. If something cool does emerge from this debate I ho= pe it runs in Emacs because that's the only thing I can count on. Everything e= lse was determined by historical accident and fiat long before I even laid eyes on the project. One request: If this does spark ideas for new vc features please start anot= her topic. It would be very nice if this thread continues, to remain a discussi= on of defining quality merging. Tools help but are not the mechanism, not the = goal. humbly, Mike Mattie --Sig_/LHmQB2UVZJtL7HXMGP1J2oC Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFHgOuZdfRchrkBInkRAgjYAJ90du3UXbsXlKoq1dGDH48xifp8FACguiP3 4GEr+6a/8dvoTIG8qt03NpY= =1Udi -----END PGP SIGNATURE----- --Sig_/LHmQB2UVZJtL7HXMGP1J2oC-- --===============2139439016== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel --===============2139439016==--