Having a post-commit hook that calls out to something on fido that updates bookmarks after pull requests get merged would be helpful.<div><br></div><div>Of course it would be nice if bitbucket added a UI for this but I'm not holding my breath.<span></span><br><br>On Friday, September 11, 2015, Kacper Kowalik <<a href="mailto:xarthisius.kk@gmail.com">xarthisius.kk@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 09/11/2015 10:29 AM, Matthew Turk wrote:<br>
> Hi Britton,<br>
><br>
> I've thought through a bit more, and I'm coming around to having multiple<br>
> heads. If each one had a feature name, and we didn't get too many (i.e., a<br>
> h-yt-dra haha) then perhaps this would be a fine situation. Avoiding PRs<br>
> between repos means consolidating code review, which is a positive thing,<br>
> as well. By focusing on *features* rather than the blanked "experimental"<br>
> we would be in a better situation to deal with situations like this, we<br>
> could still do feature work, and also preserve stability.<br>
<br>
Hi all,<br>
is there something we could do code-wise to make such workflow more<br>
user-friendly? What are the main "pain" points?<br>
<br>
The idea of cursed-based UI for issuing / viewing / editting PRs has<br>
been on my mind for quite sometime, but I haven't had enough motivation<br>
to do it...<br>
<br>
One semi-related thing I'd like to mention/remind of: there's no need<br>
for making "fork of forks" of yt repo. Assuming you want to<br>
collaborately work on already issued PR, you can easily pull it:<br>
<br>
hg bbprs -p PRNUMBER<br>
<br>
Then add your changes and issue PR with them back to somebody's fork:<br>
<br>
hg bbnewpr -t "PR title" -d "PR description" -r tip -n somebody/yt<br>
<br>
All this ^^ and other goodies are available in hgbb[1]<br>
Cheers,<br>
Kacper<br>
<br>
[1] <a href="https://bitbucket.org/MatthewTurk/hgbb" target="_blank">https://bitbucket.org/MatthewTurk/hgbb</a><br>
<br>
> -Matt<br>
><br>
> On Thu, Sep 10, 2015 at 1:52 PM, Britton Smith <<a href="javascript:;" onclick="_e(event, 'cvml', 'brittonsmith@gmail.com')">brittonsmith@gmail.com</a>><br>
> wrote:<br>
><br>
>> Hi everyone,<br>
>><br>
>> I had some ideas for improving the yt development process that I<br>
>> wanted to run by everyone. This can be discussed further at our<br>
>> upcoming team meeting and if people are in favor, I will issue a pull<br>
>> request to the relevant YTEP.<br>
>><br>
>> STATEMENT OF PROBLEM<br>
>> Currently, development proceeds roughly as follows. The two main<br>
>> active branches within the central yt repository are *yt* and *stable*.<br>
>> The tip of *stable* is the latest release and the *yt* branch is the de<br>
>> facto "development version" of the code. Until recently, we have not<br>
>> been very good at regularly scheduled minor releases and so the *stable*<br>
>> branch sits for quite some time with many bugs that are fixed within<br>
>> the development branch. This effectively makes *stable* unusable and<br>
>> pushes most users to the *yt* branch.<br>
>><br>
>> When new features are developed, pull requests are issued to the<br>
>> single head of the *yt* branch. Because this is the version most people<br>
>> are actually using, the current policy is to not allow PR with new<br>
>> functionality to be accepted until they are 100% ready (full<br>
>> functionality, tests, docs, etc). As we have already seen, this makes<br>
>> collaborative development very cumbersome, as it requires people to<br>
>> create forks of the fork from which the PR originates. They then must<br>
>> issue PRs to that fork after which time the original PR is updated.<br>
>> The current volume render refactor is the perfect example of this.<br>
>><br>
>> PROPOSED SOLUTION<br>
>> Before I lay out the proposed solution, I want to list a number of<br>
>> recent developments that I think will make this possible:<br>
>> 1. Nathan's new script for backporting changes now keeps *stable* and *yt*<br>
>> synced on bugfixes.<br>
>> 2. We have returned to doing minor releases containing only bugfixes,<br>
>> thanks again to Nathan's hard work. This and point 1 means that<br>
>> users are once again safe to be on *stable*, and now *should* be there<br>
>> most of the time.<br>
>> 3. Bitbucket now supports bookmarks, meaning that PRs can be issued to<br>
>> specific bookmarks instead of to branches or heads named only by the<br>
>> changeset hash.<br>
>> 4. The weekly PR triage hangouts are making it easier to process PRs<br>
>> and also providing a place to strategize getting larger PRs<br>
>> accepted. Thanks to Hilary for keeping this going.<br>
>><br>
>> With the above in mind, I propose the following:<br>
>> 1. Create a "development" bookmark to sit at the tip of the *yt*<br>
>> branch. All PRs containing relatively small new features are<br>
>> issued to this. The requirements for acceptance remain the same:<br>
>> PRs accepted to "development" must contain all intended<br>
>> functionality and be fully documented. This allows the<br>
>> "development" bookmark to be defined explicitly as everything that<br>
>> will be included in the next major release.<br>
>> 2. Large new features should have a corresponding YTEP that has been<br>
>> accepted. After the YTEP has been accepted, a PR should be issued<br>
>> to the *yt* branch. After some initial discussion, this PR is pulled<br>
>> into the main yt repo with a bookmark named after the feature.<br>
>> Once this has happened, developers can now issue new PRs<br>
>> specifically to this bookmark. This is effectively what we have<br>
>> now with the volume render work in the "experimental" bookmark,<br>
>> only we would rename the bookmark to something like "vr-refactor".<br>
>> As with PRs issued directly to "development", only after the new<br>
>> feature is 100% ready shall it be merged into the "development"<br>
>> bookmark.<br>
>> 3. We continue to make use of the PR triage hangouts to establish when<br>
>> large features are ready to be merged.<br>
>><br>
>> I believe this will have the following benefits:<br>
>> 1. Large, new features can be developed collaboratively without the<br>
>> need for forks of forks of forks.<br>
>> 2. New, underdevelopment features are more accessible to the larger<br>
>> community by simply updating to named bookmarks from the main repo<br>
>> (no need for "just pull these changes from my fork").<br>
>> 3. The "development" branch is preserved as a place only for<br>
>> ready-to-be-released features (i.e., polished and documented).<br>
>><br>
>><br>
>> All told, this is really just a small tweak on our current process.<br>
>> Please comment with any thoughts, or even a +/-1 if your feelings can<br>
>> be summed up thusly.<br>
>><br>
>> Britton<br>
>><br>
>> _______________________________________________<br>
>> yt-dev mailing list<br>
>> <a href="javascript:;" onclick="_e(event, 'cvml', 'yt-dev@lists.spacepope.org')">yt-dev@lists.spacepope.org</a><br>
>> <a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
>><br>
>><br>
><br>
><br>
><br>
> _______________________________________________<br>
> yt-dev mailing list<br>
> <a href="javascript:;" onclick="_e(event, 'cvml', 'yt-dev@lists.spacepope.org')">yt-dev@lists.spacepope.org</a><br>
> <a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
><br>
<br>
<br>
</blockquote></div>