All, I am +1 to make Github the “repo of record” for the record. I believe it has been suggested to keep a secondary, read-only mirror of the repo on ASF which seems like a prudent, low effort backup.
Personally, I think both Confluence and Github are fairly poor wiki implementations. Therefore, I am +0 on moving the wiki to Github so long as we can maintain the content that has already been created. While some of the content in the existing wiki is a bit out of date, I think it would be a mistake to “throw the baby out with the bathwater”. So long as moving the wiki to Github doesn’t mean starting over, it makes little difference to me if it is Confluence or Github. I am no fan of JIRA. I think it is clunky, bloated, and overly complicated — particularly in its default configuration. It also requires additional registration and approval for users to interact with the project which I deeply dislike. However, as much as I dislike JIRA, my experience with Github issues has been worse. Where JIRA attempts to do too much, Github issues simply can’t do many things. In particular, we need the following features in a ticketing system which are not currently provided by Github Issues: 1. Private Tickets: We must have an avenue for security researchers, developers, and users to responsibly inform the project about security issues and track resolution. This process is necessarily confined to the reporter and security team until a resolution is found. 2. Attachments: A vital part of resolving issues are screenshots and logs. While people can gist or imgur this information, it is cumbersome. Many of these systems also purge information after some period of time — removing important information from long lived, unresolved ticket and/or reducing their historical value. I don’t know about others, but I search through ticket history a few times a week to understand the history of issues and when they have been fixed. I often look at the attachments to determine whether or not the issue I am debugging matches the ticket. 3. History Import: While less important than the previous two items, a single source to comprehend history is very useful. Our current JIRA is a rich corpus of project’s previous problems and their resolutions. Splitting that corpus across two repositories would be a step backwards in my mind. I would imagine there are additional gaps between JIRA and Github Issues functionality as Github Issues is an extremely simplistic ticking system. For these reasons, I am -1 on moving to Github Issues. Thanks, -John > [ShapeBlue]<http://www.shapeblue.com> John Burwell ShapeBlue d: +44 (20) 3603 0542 | s: +1 (571) 403-2411 <tel:+44%20(20)%203603%200542%20|%20s:%20+1%20(571)%20403-2411> e: john.burw...@shapeblue.com | t: <mailto:john.burw...@shapeblue.com%20|%20t:> | w: www.shapeblue.com<http://www.shapeblue.com> a: 53 Chandos Place, Covent Garden London WC2N 4HS UK [cid:image7b7e2d.png@57e35166.4d8951a3] Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark. This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. On Jan 3, 2016, at 2:12 PM, Sebastien Goasguen <run...@gmail.com> wrote: > > >> On Jan 3, 2016, at 4:28 PM, humbed...@gmail.com wrote: >> >> >> >> On 2016-01-03 12:25, Sebastien Goasguen <run...@gmail.com> wrote: >>> Bringing this one discuss thread to the top of the ML to get stronger >>> consensus. >>> >>> We need it if we want to request a move to GitHub. >>> >>> Note that this is not about leaving the ASF, it is about using GitHub to >>> its full potential. >>> >>> The ASF board is investigating ways for a project to use Github and still >>> maintain strong provenance of commits to keep the high quality and >>> provenance standards of ASF code. >>> >>> If we get consensus we can request to the board to be part of the >>> “trial†and move to Github. >> >> Sorry to burst any bubbles here, but there is no trial you can join at the >> moment. >> We are, as always, exploring new ways of having people collaborate and >> contribute, but at present, there are no opt-in trials for GitHub. >> >> What the future holds remains to be seen, but for now...sorry, but nope. >> If/when such an option becomes available, we will of course notify the >> various projects about this opportunity. >> > > ok thanks for the clarification. > > However let’s keep the DISCUSS going so we know what we want. With that in > hand we will have a thread to point the board to if we want to make a request. > >> With regards, >> Daniel on behalf of Infrastructure. >> >>> >>>> On Dec 21, 2015, at 11:37 AM, Sebastien Goasguen <run...@gmail.com> wrote: >>>> >>>> >>>>> On Dec 21, 2015, at 11:34 AM, Daan Hoogland <daan.hoogl...@gmail.com> >>>>> wrote: >>>>> >>>>> Sebastien, This will create a github repo under the apache organisation >>>>> right? one that we can not merge to. >>>>> >>>> >>>> Yes , that’s how I created all the docs repo and the repos for ec2stack >>>> and gstack. >>>> >>>> >>>> >>>>> On Mon, Dec 21, 2015 at 10:51 AM, Sebastien Goasguen <run...@gmail.com> >>>>> wrote: >>>>> >>>>>> BTW >>>>>> >>>>>> Anyone can ask for a new git repo which will be mirrored on github at: >>>>>> >>>>>> https://issues.apache.org/jira/servicedesk/customer/portal/1/create/8 >>>>>> >>>>>> Not sure if the link will work, but it’s available through issues. >>>>>> >>>>>>> On Dec 19, 2015, at 7:03 PM, Sebastien Goasguen <run...@gmail.com> >>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On 19 Dec 2015, at 16:28, Rene Moser <m...@renemoser.net> wrote: >>>>>>>> >>>>>>>> Hi Seb >>>>>>>> >>>>>>>>> On 12/19/2015 10:12 AM, sebgoa wrote: >>>>>>>>> >>>>>>>>> Late October I started thread [1] about moving our repo to GitHub, I >>>>>> would like to re-open this discussion. >>>>>>>>> >>>>>>>>> Now that we have stabilized master and release 4.6.0, 4.6.1, 4.6.2 and >>>>>> 4.7.0 we need to think about the next steps. >>>>>>>>> >>>>>>>>> To me Git and GitHub has become an essential tool to any software >>>>>> development, not using it to its full potential is hurting us. >>>>>>>>> >>>>>>>>> Just as an example I would like to point you to [2], this a PR I made >>>>>> to Kubernetes (a container orchestrator), it literally added 14 >>>>>> characters >>>>>> in a json file. >>>>>>>>> This was really a very minor change. >>>>>>>>> >>>>>>>>> The PR automatically triggered 3 bots which created 7 labels, it ran >>>>>> end to end testss, Jenkins jobs and triggered third part builds. >>>>>>>>> It was automatically merged. >>>>>>>> >>>>>>>> I am fine moving to github. >>>>>>>> >>>>>>>> But IMHO the git hosting is not the problem, the problem is how far do >>>>>>>> we trust the current tests and how we can them improve. >>>>>>>> >>>>>>>> Moving to github doesn't improve testing. Doing manual tests is okay >>>>>>>> and >>>>>>>> hard work, it does not speed up things. >>>>>>>> >>>>>>>> We need fully automated unit _and_ integration tests that we trust. I >>>>>>>> do >>>>>>>> not trust in mocking and simulating infrastructure. >>>>>>>> >>>>>>>> We discovered most of the major problems running cloudstack on real >>>>>>>> hardware in real world scenarios. Race conditions, unexpected VR >>>>>>>> reboots, VMs not getting IPs from DHCP, etc. >>>>>>>> >>>>>>>> Rating complexity of changes: easy_fix, minor_change, major_change >>>>>>>> >>>>>>>> Running tests according complexity: >>>>>>>> >>>>>>>> - easy_fix: just merge it. >>>>>>>> - minor_change: unit and simulator test passed >>>>>>>> - major_change: the full blown integration testing >>>>>>>> >>>>>>>> IMHO we should work on solid testing and development is fun, merging a >>>>>>>> click and releasing a breath. >>>>>>>> >>>>>>>> Just my 2 cents. >>>>>>> >>>>>>> Fully agree >>>>>>> >>>>>>> I do think moving to github would allow us to run tests on real systems >>>>>> more easily. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Regards >>>>>>>> René >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Daan >>>> >>> >>> >> ------ >> Sent via Pony Mail for dev@cloudstack.apache.org. >> View this email online at: >> https://pony-poc.apache.org/list.html?dev@cloudstack.apache.org > Find out more about ShapeBlue and our range of CloudStack related services: IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//> | CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/> | CloudStack Software Engineering<http://shapeblue.com/cloudstack-software-engineering/> CloudStack Infrastructure Support<http://shapeblue.com/cloudstack-infrastructure-support/> | CloudStack Bootcamp Training Courses<http://shapeblue.com/cloudstack-training/>
