[llvm-dev] Git move survey

Mehdi Amini via llvm-dev llvm-dev at lists.llvm.org
Wed Aug 17 14:18:24 PDT 2016


Hi,

> On Aug 17, 2016, at 2:05 PM, Tanya Lattner via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
>> 
>> On Aug 4, 2016, at 6:58 AM, Renato Golin <renato.golin at linaro.org <mailto:renato.golin at linaro.org>> wrote:
>> 
>> Hi Tanya,
>> 
>> Do you have an idea on how we'll put up this survey online?
> 
> I can put it in Google Forms/Docs (or you can if you prefer). Survey monkey is also an option but its about the same I think but more costly.. so lets go with free and easy. 
> 
>> 
>> The other thread on the foundation list had some good proposals, but I
>> don't know how we'll make sure we follow all of them when we actually
>> publish it.
>> 
>> I'd like to have some process going before early Sep, so we can just
>> "put it up" as soon as all the proposals are finished.
>> 
>> Some questions...
>> 
>> Q1. How do we choose the questions / format?
>> 
>> Starting from the other thread would be good, but we may need a review
>> process to make sure everyone think it's a fair questionnaire (or the
>> exercise won't have the desired effect).
> 
> I do think its been reviewed quite a bit, but if you want to give anyone else a chance to review then ok.
> 
>> 
>> Q2. Where do we host it?
>> 
>> This is mostly independent and a bit irrelevant, but it could make a
>> difference to answer the question above.
> 
> Google Forms/Docs should work.
> 
>> 
>> Q3. Do we fix a date, or make it depend on the proposals?
>> 
>> If the former, we may run with incomplete proposals. If the latter, we
>> may run it too late. A mix of both will be the answer, but I
>> personally think we need to set a limit date (early Sep).
> 
> I’m not sure I follow. Are you talking about the one repo versus many discussion? Otherwise, why wouldn’t there be one GIT proposal document that describes GITHUB versus SVN (pros and cons) and then people can give feedback?

I think the survey should be regarding question based-off a single document putting side-by-side the options that we came-up with on the mailing-list.
Indeed I don’t plan to write a document describing a “mono-repo” proposal to counter the submodules one, but I plan instead to unify it with the existing one (submodules…) along with the possible variants/options in a single document.
I plan to include examples of workflow today and after for each scenario, side-by-side. I hope to have it up for public review by the end of the month.


> http://llvm.org/docs/Proposals/GitHubSubMod.html <http://llvm.org/docs/Proposals/GitHubSubMod.html>
> 
> I also don’t think this is a process that needs to be rushed. It will take awhile to publicize the survey and give people a chance to comment. Its more reasonable to give until Dec (1 month after the dev meeting BoF) give time for feedback. But thats just my opinion. 

I’d regret not having the results of the survey for the BoF as these data seem critical to drive the discussion.


> 
>> 
>> Q4. How do we present the results?
>> 
>> I volunteer to do the analysis and conclusions, but I think that the
>> bulk of the results should be made public at some point. If we decide
>> to have private text boxes, we must keep them out, but everything else
>> should be public.
> 
> I would just make a note that the feedback may be made public and whoever is filling it out should be responsible for making sure its not releasing sensitive information. Everything should be anonymized of course.
> 
>> 
>> I also think we should have a session at the US LLVM to present the
>> results and maybe have a final decision there.
> 
> I would use the BoF as a way to discuss in person but I wouldn’t put pressure to make a decision during it. It will probably become more clear when you start getting feedback.

Right, I don’t think the BoF will much productive without the feedback on the proposal.

— 
Mehdi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160817/4ff21b58/attachment.html>


More information about the llvm-dev mailing list