_______________________________________________I'd say that not all tickets are Guidelines related (e.g. we have a label for TEI:Website and another for TEI:Build Process), so perfectly reasonable to have a ticket as a place for conversation about this that we might return to in the future. That is assuming that this is something that might have several iterations, tests, decision about which is the best way, etc. If it is a straightforward "Let's test this, oh look, it works now let's document that." then maybe a ticket is not needed.
My two pence,
James
--
Dr James Cummings, James.Cummings@newcastle.ac.uk
School of English Literature, Language, and Linguistics, Newcastle University
From: Tei-council <tei-council-bounces@lists.tei-c.org> on behalf of Elisa Beshero-Bondar <ebb8@pitt.edu>
Sent: 03 October 2018 12:10:28
To: TEI Council
Subject: Re: [Tei-council] TCW 20 Revision on Branch Practice?PS: Should I open that as a ticket? Since it's not specifically Guidelines-related, I'm not sure...figured I'd sound us out here first.
Thanks,
Elisa
On Wed, Oct 3, 2018 at 7:08 AM Elisa Beshero-Bondar <ebbondar@gmail.com> wrote:
Dear Council,I was just re-reading TCW 20 to remind myself what we advise each other on working in feature branches, and how to update them. You may remember some excitement during our Tokyo face-to-face as I first nearly bungled a branch merge and then we fixed it. This was, I think, a bit too much excitement, and lots of us do work in branches. When it comes time to update them and/or merge them back into dev, we don't always know exactly what to do, and just relying on looking stuff up is, as we saw, a little brittle and error prone. We are pretty confident we can fix anything that goes wrong, but perhaps we can minimize the excitement with a little more guidance to our future selves.
So, I'm writing this to propose some revision to this portion of TCW 20:"If you are working on a particularly complex change involving multiple files, it may be better to create a branch in which to work on your changes, and then to merge the branch when you are confident that the work is successfully completed. See any guide to git for instructions on how to approach that. Bear in mind that our Jenkins servers only build the dev branch, so you cannot depend on them to test-build your working branch."
I'd like to propose rewriting that with some more detailed steps on our TEI Technical Council preferred process for reconciling branches with dev, to help prevent future excitement. :-) I've been reading about the "best" ways to keep branches updated, and the differences, for example, between rebase and merge for keeping a branch tip updated. Rebasing is pretty dangerous in that it "rewrites history" by resequencing commits, so I am not sure we ever want to use it for updating a branch from dev, before merging it back. Do we want to always advise, then, to update a branch by merging it with dev? I'm not 100% certain of that either. What I'd like to do is (very careful) test a few approaches and work with you all to try to plot out an excitement-proof set of safe guidelines for Council members on Best Practices for Working in Branches as part of TCW 20.
What say you all?Elisa
--
Elisa Beshero-Bondar, PhD
Associate Professor of English
University of Pittsburgh at Greensburg
Humanities Division
150 Finoli Drive
Greensburg, PA 15601 USA
E-mail: ebb8@pitt.edu
--
Elisa Beshero-Bondar, PhD
Director, Center for the Digital Text | Associate Professor of English
University of Pittsburgh at Greensburg | Humanities Division
150 Finoli Drive
Greensburg, PA 15601 USA
E-mail: ebb8@pitt.edu
Development site: http://newtfire.org
Tei-council mailing list
Tei-council@lists.tei-c.org
http://lists.lists.tei-c.org/mailman/listinfo/tei-council