Re: Github staging and works in progress

On 7/14/2015 1:10 PM, Henry Gomersall wrote:
> As was raised during PR #102 on github, Jan's preference so far has
> been to have PRs that are complete and ready.
>
> I posit that allowing discussion and updates on specific
> implementation is a great feature of github and we should have a
> convention to allow for this, such that a solution can evolve with
> input inside a PR.
>
> @jck's suggestion of doing what neovim do seems like a great idea to
> me:
>
> Prefixing the title with one of the following tags:
>
> |[WIP] - Work In Progress: the PR will change, so while there is no
> immediate need for review, the submitter still might appreciate it.
> [RFC] - Request For Comment: the PR needs reviewing and/or comments.
> [RDY] - Ready: the PR has been reviewed by at least one other person
> and has no outstanding issues. |
>
> Only when the tag is changed to [RDY] is it deemed to be ready for
> inclusion.

If we agree on this (it sounds reasonable) we need
to update the development guide - stamp it official :)

http://dev.myhdl.org/guide.html#creating-changes

>
> It would be great if github had a collaborative staging area, but
> this seems like a good solution to me.
>
> On a similar vein, I've sometimes failed to get useful feedback on
> specific implementations that are distinctly a work in progress, but
>  need feedback to proceed. Specifically, issue #68 in which I have
> half of a complete implementation for that particular problem. It's
> distinctly not PR ready, but is a WIP. I'm somewhat disinclined to
> sink any more time into it without some further constructive
> feedback, which I attempted to garner without much success.

In my opinion this is an effect of limited resources and
distributed development.  An OP needs to be patient and
persistent with issues.  For example, we had some off in
the weeds conversations on IRC, so naturally this task
faded into the background.

>
> I feel there is quite a bit that could be done very easily to make
> contributors feel more welcome. A mechanism for better and more
> patient code collaboration for WIPs would go a long way to this end.
> Perhaps if Jan doesn't wish to be involved with this, a second mirror
> repository on github could take on that role.

A second mirror is not needed, when we first started
discussing this issue fetching from each others forks
worked fine and isn't too difficult.  I think the
process outlined in the developer guide is reasonable
first communicated (issues, IRC, gitter, mailing-list),
and git provides reasonable collaboration.  Adding the
tags could also be useful (I think it will also have
some unforeseen downsides, e.g. staleness, who decides
when a WIP is dead).

http://dev.myhdl.org/guide.html#first-step-communicate

Regards,
Chris


------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/