|
Shawn Amundson <amundson@...>
Processing markdown with Jenkins and hosting it with Apache is extremely simple, so relying on on-demand rendering provided by GitHub wouldn't be necessary. If on-demand was desired, there are other repository viewers that do the same thing that might be friendly within the context of gerrit.
A benefit of rendering from markdown (with sphinx-doc for example, but probably asciidoc and other tools as well) is that it is also trivial to generate nice LaTeX-based PDFs of sections of the documentation (for white-papers, for example). Those things could start out on etherpad to benefit from real-time collaboration and then graduate to markdown when its ready for polish/versioning/publication. That would make sense independent of the wiki.
A key criteria is which method makes contribution easier. The argument in favor of the wiki is that it doesn't involve the laborious(?) git+gerrit processes in favor of login-and-click-edit. I assume the target is thus non-developers that wouldn't already be using git+gerrit. One thought would be inline edit. But the implementation within gerrit doesn't look simple/obvious: https://gerrit-review.googlesource.com/Documentation/user-inline-edit.html.
Dokuwiki seems like a reasonable compromise as it is simple but doesn't have any lock-in problems.
-Shawn
On Wed, Aug 24, 2016 at 8:18 AM, Jon Brisbin <jbrisbin@...> wrote: We recently went through this discussion ourselves and decided that markdown or asciidoc (or both!) in GitHub was better because it automagically renders, you can link to anything you need using the built-in tools, it's searchable (hard to find good search in other wiki platforms), it's inherently source-controlled so changes to the docs are tracked, you can create PRs against the docs and review them before someone plops new content into the wiki and blasts whatever was there without much review, etc...
Just having a repo full of asciidoc would likely be sufficient. It wouldn't have to be processed into HTML and hosted. You could do that, of course, but IMO it's not really necessary since the default rendering of GitHub is sufficient for everything we need.
It beats maintaining a separate server just to run a wiki and then having to secure it, make sure it's up, keep it up to date, etc... Yuck.
jb
So we're now not going with Confluence
- I'm having a Dokuwiki instance set up with the markdown plugin
installed.
Brian
On 08/16/2016 07:49 AM, Shawn Amundson wrote:
About confluence... Since it's not markdown or wiki syntax
based, it is hard to pull information out. It is also hard to
paste text content into from terminal editors like vim (lots of
time spent re-flowing line breaks). Dokuwiki and mediawiki are
open source and don't have those problems. FWIW, when I've used
dokuwiki in the past I've thought it was pretty nice/easy as far
as wikis go.
Should we have an etherpad instance setup to fill the
real-time collaboration need, as an alternative to google docs
(for some subset of the google docs use case)?
-Shawn
--
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@linuxfoundation.org
Twitter: @brianbehlendorf _______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@lists.hyperledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric
|
|
|
Brian Behlendorf <bbehlendorf@...>
Which, to be clear, is not an alternative to wikis.
Brian On August 24, 2016 9:57:05 AM EDT, Christopher B Ferris <chrisfer@...> wrote:
+1 to Etherpad
----- Original message -----
From: Brian Behlendorf <bbehlendorf@...>
Sent by: hyperledger-fabric-bounces@...
To: Shawn Amundson <amundson@...>
Cc: hyperledger-fabric@...
Subject: Re: [Hyperledger-fabric] Wikis? (was Re: issues for fabric)
Date: Wed, Aug 24, 2016 12:24 AM
So we're now not going with Confluence - I'm having a Dokuwiki instance set up with the markdown plugin installed.
Brian
On 08/16/2016 07:49 AM, Shawn Amundson wrote:
About confluence... Since it's not markdown or wiki syntax based, it is hard to pull information out. It is also hard to paste text content into from terminal editors like vim (lots of time spent re-flowing line breaks). Dokuwiki and mediawiki are open source and don't have those problems. FWIW, when I've used dokuwiki in the past I've thought it was pretty nice/easy as far as wikis go.
Should we have an etherpad instance setup to fill the real-time collaboration need, as an alternative to google docs (for some subset of the google docs use case)?
-Shawn
On Tue, Aug 16, 2016 at 2:16 AM, Brian Behlendorf <bbehlendorf@...> wrote:
On 08/13/2016 06:48 AM, jeremysevareid wrote:
I agree that spreadsheets aren't as necessary if scope is just the build phase right now. Jira helps with that. However, spreadsheets may be worth revisiting when performance, scalability and integration testing come up.
Willing to concede the point for now.
For the IP and attribution concerns, does this apply to code only? Architecture white paper and requirements documents?
It should for completeness' sake, and if integrated with one's linuxfoundation.org identity then we'll get that for free, I think, since one will have filled that out (the equivalent of a DCO) while setting up an account. I see no need to anonymous contributions to a wiki at all, nor the architecture white paper and requirements docs. As for use cases for a wiki - right now, I could use one to track our investigation into Slack and Mailman alternatives. That's not a code-related thing, it's something where frequency of update and availability to all is more important than each commit being gerrit-reviewed. Here's an instance of Confluence running for anoth
er LF
project, OPNFV: https://wiki.opnfv.org/Note that they seem to use it for most of their community & web content. Sensing that we've talked this pretty deeply, I will ask LF IT to set up a Confluence instance running next to our Jira, and we can kick the tires. Brian
Jeremy
-------- Original message --------
From: Brian Behlendorf <bbehlendorf@linuxfoundation.org>
Date: 8/11/2016 2:10 PM (GMT-05:00)
To: jeremysevareid <jeremysevareid@...>
Cc: hyperledger-fabric@lists.hyperledger.org
Subject: Re: [Hyperledger-fabric] Wikis? (was Re: issues for fabric)
On 08/11/2016 10:56 AM, jeremysevareid wrote:
I agree on the PDF source file front.
Any preference for a spreadsheet tool? Ethercalc? Apache OpenOffice? Other?
Frankly all of them kind of suck for portability; if we're just using it to build a table of something, most wikis support tables, most in a wysiwyg way.
We're going to need one or something similar, in order to validate calcs, ledger updates, perform reconciliations, etc.
Any examples of where today we use it in the _development_process_? That would be new to me. Would we really be using e.g. Excel for "ledger updates, perform reconciliations"? I could see proper spreadsheets performing calculations as part of the documentation or white papers, perhaps.
Brian
-------- Original message --------
From: Brian Behlendorf <bbehlendorf@linuxfoundation.org>
Date: 8/11/2016 12:48 PM (GMT-05:00)
To: jeremysevareid <jeremysevareid@...>
Cc: hyperledger-fabric@lists.hyperledger.org
Subject: Re: [Hyperledger-fabric] Wikis? (was Re: issues for fabric)
On 08/10/2016 08:34 PM, jeremysevareid wrote:
Wiki, goggle docs and traditional file types like PDF, PPT and xls are already in use by the requirements and identity work groups.
Right. The goal should not be more tooling for tooling sake, but naming at least one as the preferred system of record, so that discovery, search-ability, and versioning are easier, as we do for software source code and issue tracking. Also, access to expensive proprietary tools required to edit powerpoint and excel files creates barriers to participation (not to mention those tools have very lousy version control systems if you try to operate outside Microsoft Sharepoint) The fewer attachments via email, the fewer links that are shared ad-hoc, the better the history of ideas can be traced so we can properly credit contributors and track IP, the better.
Can we consider supporting both a wiki and an agreed range of checked-in doc file types?
Sure, though the checked-in doc types should be editable. Too often PDFs are pretty pictures of information, but not really malleable or computable. So long as the source is always in a repo of some sort (and easily changeable by other committers, without having to use proprietary software) that's fine.
That could give contributors more flexibility to choose the right tool and still provide the community with interoperable files under strong controls.
E.g., an exported wiki snapshot could be checked in and reviewed as part of a tagged release. Exported Google, OpenOffice or MS docs, graphics and PDFs could as well.
I'd say anything included in a software release tarball should get the kind of formal review that Gerrit brings to the source code, since it's as important as the code itself, which also brings automatic conformance to a DCO. I'm uncomfortable with the idea that someone might contribute something important in a Google doc, and then it would end up in a package, without a DCO. Make that very uncomfortable.
Often debates about "right tools" come down to a matter of familiarity and aesthetics rather than objective metrics. Familiarity means ease of use which is important, at least for those already up to speed on that tool. But the cost of disparate tooling (where 3 different tools are used for something that 1 tool would be acceptable for) is hard to measure, and still very real.
Brian
-------- Original message --------
From: Brian Behlendorf <bbehlendorf@linuxfoundation.org>
Date: 8/10/2016 11:15 AM (GMT-05:00)
To: Shawn Amundson <amundson@...>
Cc: hyperledger-fabric@lists.hyperledger.org
Subject: Re: [Hyperledger-fabric] Wikis? (was Re: issues for fabric)
Most projects figure out that line pretty organically. The risk of limiting participation due to barriers to entry is high, and metrics hard to come by (how do you measure the people who wanted to edit but were turned off by the process). Let's see how it goes with content very core to the code (like API docs) built from markdown in the source code repository, and other content in the wiki (bootstrapping with the current content), and shift docs from one to the other as seems appropriate, or tighten write privs to the wiki worst case (e.g., we start to see a lot of spam or drive-by changes). I'll sign up to monitor wiki changes, as I hope others will.
We will still require an LF identity/account to edit the wiki, at which point we get the equiv of a DCO for their contributions. No Wikipedia-style anonymous contributions.
Google docs can be great for some forms of collaboration, but if links to those docs aren't wired into a w
iki or
other parts of the project website, they run the risk of becoming forgotten cul-de-sacs. Also, gdocs is blocked in some countries and increasingly across some corporate firewalls.
Brian
On 08/10/2016 06:58 AM, Shawn Amundson wrote:
Not sure how the project would successfully draw that line between what should be good proper docs and what should be unreviewed ad-hoc wiki docs. A new-user how-to deserves at least as much refinement/thought as API documentation. Brainstorming pages are best done in something collaborative like google docs. (wikis are non-collaborative - they neither provide pre-commit peer review nor multiple real-time editors).
From a practical legal perspective, it seems like you wouldn't want anything "real" to be written outside of the DCO process; if a great user's guide was written on the wiki by multiple authors, it seems like, regardless of quality, it could never be part of the project proper (and thus not version controlled, tagged, branched, etc.) without a big headache.
-Shawn
On Wed, Aug 10, 2016 at 12:07 AM, Brian Behlendorf <bbehlendorf@linuxfoundation.org> wrote:
Often, one benefit of a Wiki is that it provides a way to engage new developers or non-technical contributors in the development process, by making it easy to make the kind of small iterative simple improvements that often accompanies text editing, versus code development that is more about branches and pull requests and more formal reviews and processes. Many open source communities feel comfortable granting write privs to the wiki broadly, even to anonymous users, on this basis, combined with premise that version control will always let us roll back in case of mistakes or spam (I'd probably recommend that here, actually, so long as we could make it easy to follow commits to the wiki, and have unified logins). For more formal API and internal code documentation we do have a "readthedocs" section of the source
code
tree - does that use markdown? Seems like that suffices for the uses you might be thinking of. After all I can see API definitions and internal docs benefiting from more formal review than new-user how-to's or brainstorming pages. Brian
On 08/09/2016 03:13 PM, Shawn Amundson wrote:
Sounds like an opportunity to switch away from a traditional wiki and move to a markdown language (sphinx-doc or similar) backed by git+Jenkins. There are many benefits, including using the same review processes (gerrit, etc.) as we do with the rest of the source code.
-Shawn
On Mon, Aug 8, 2016 at 5:54 PM, Brian Behlendorf <bbehlendorf@...rg> wrote:
For the time being we can continue using the Github wiki, but to make the migration complete we should talk about setting up a separate wiki tool for the Hyperledger projects. Currently, the LF infrastructure team would support either a Mediawiki or a Dokuwiki instance (if I recall correctly), for which we would also get single sign-on. Does anyone here have a preferences? This would be for a project-wide wiki so may be better to discuss on hyperledger-technical-discuss@lists.hyperledger.org. Brian On 08/08/2016 03:26 PM, Kondo, Yuki wrote: Thanks, I understood that Jira will replace Github issue as well as Gerrit replaced Github Repository.
How about Github wiki? Do you have any plan to migrate wiki documents elsewhere?
Best Regards,
Yuki Kondo
Hitachi America, Ltd., Research & Development Division
Tel: (408) 986-6460 | Mail: Yuki.Kondo@...
From: Christopher B Ferris [mailto:chrisfer@...]
Sent: Monday, August 08, 2016 2:27 PM
To: Kondo, Yuki
Cc: hyperledger-fabric@...ledger.org
Subject: Re: [Hyperledger-fabric] issues for fabric
Jira issues replace the role of GitHub issues. Just a different tool - one that allows greater flexibility than GH. If you find a bug, submit a Jira issue and if you are interested, you can also submit a patch via Gerrit and reference the Jira issue in the Commit message. ----- Original message -----
From: "Kondo, Yuki" <Yuki.Kondo@...>
Sent by: hyperledger-fabric-bounces@lists.hyperledger.org
To: hyperledger-fabric <hyperledger-fabric@...rledger.org>
Cc:
Subject: Re:
[Hyperledger-fabric] issues for fabric
Date: Mon, Aug 8, 2016 4:34 PM
Hello Chris. May I ask questions?
1) Process of issue discussion and bug fix
Currently, contributors submit issue/bug to Gerrit directly and reviewers check it.
How this process will change after migration to Jira?
2) Github Wiki document
Fabric has documents which are only stored on github wiki pages.
https://github.com/hyperledger/fabric/wiki
Where can I find these documents after migration to Gerrit & Jira has been completed?
Best Regards,
Yuki Kondo |近藤 佑樹
Hitachi America, Ltd., Research & Development Division
Tel: (408) 986-6460 | Mail: Yuki.Kondo@...
From: hyperledger-fabric-bounces@lists.hyperledger.org [mailto:hyperledger-fabric-bounces@...] On Behalf Of Gabor Hosszu
Sent: Monday, August 08, 2016 12:50 PM
To: hyperledger-fabric
Subject: Re: [Hyperledger-fabric] issues for fabric
+1 For the fresh start but I also agree with Arnaud's idea that we should try not to lose any important issue that is worth moving. :)
On Mon, Aug 8, 2016 at 9:15 PM, Christopher B Ferris <chrisfer@...> wrote:
+1 what Ry said, your LF credentials should work
Cheers,
Christopher Ferris
IBM Distinguished Engineer, CTO Open Technology
IBM Cloud, Open Technologies
email: chrisfer@...
twitter: @christo4ferris
blog: https://developer.ibm.com/opentech/author/chrisfer/
phone: +1 508 667 0402
-----Ry Jones <rjones@...> wrote: -----To: bob@...
From: Ry Jones <rjones@...>
Date: 08/08/2016 03:09PM
Cc: Christopher B Ferris/Waltham/IBM@IBMUS, hyperledger-fabric <hyperledger-fabric@...rledger.org>
Subject: Re: [Hyperledger-fabric] issues for fabric
The same credentials are used across any LF-managed property except the mailing list manager, so the same credentials should work on gerrit.hyperledger.org, jenkins.hyperledger.org, and jira.hyperledger.org.
On Mon, Aug 8, 2016 at 12:02 PM, Bob Summerwill <bob@...> wrote:
What login should be used for that JIRA instance, Chris?
My hyperledger.org credentials don't seem to work. Should they?
How
many different logins are required for a Hyperledger participant to use all the infrastructure at the moment? Which are shared and which are separate? Thanks!
--
This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.
_______________________________________________
Hyperledger-fabric mailing list
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
|
|
|
Christopher B Ferris <chrisfer@...>
yes but superb for running virtual meetings that you want to preserve for posterity
----- Original message -----
From: Brian Behlendorf <bbehlendorf@...>
To: Christopher B Ferris/Waltham/IBM@IBMUS
Cc: amundson@..., hyperledger-fabric@...
Subject: Re: [Hyperledger-fabric] Wikis? (was Re: issues for fabric)
Date: Wed, Aug 24, 2016 1:39 PM
Which, to be clear, is not an alternative to wikis.
Brian
On August 24, 2016 9:57:05 AM EDT, Christopher B Ferris <chrisfer@...> wrote:
+1 to Etherpad
----- Original message -----
From: Brian Behlendorf <bbehlendorf@...>
Sent by: hyperledger-fabric-bounces@...
To: Shawn Amundson <amundson@...>
Cc: hyperledger-fabric@...
Subject: Re: [Hyperledger-fabric] Wikis? (was Re: issues for fabric)
Date: Wed, Aug 24, 2016 12:24 AM
So we're now not going with Confluence - I'm having a Dokuwiki instance set up with the markdown plugin installed.
Brian
On 08/16/2016 07:49 AM, Shawn Amundson wrote:
About confluence... Since it's not markdown or wiki syntax based, it is hard to pull information out. It is also hard to paste text content into from terminal editors like vim (lots of time spent re-flowing line breaks). Dokuwiki and mediawiki are open source and don't have those problems. FWIW, when I've used dokuwiki in the past I've thought it was pretty nice/easy as far as wikis go.
Should we have an etherpad instance setup to fill the real-time collaboration need, as an alternative to google docs (for some subset of the google docs use case)?
-Shawn
On Tue, Aug 16, 2016 at 2:16 AM, Brian Behlendorf <bbehlendorf@...> wrote:
On 08/13/2016 06:48 AM, jeremysevareid wrote:
I agree that spreadsheets aren't as necessary if scope is just the build phase right now. Jira helps with that. However, spreadsheets may be worth revisiting when performance, scalability and integration testing come up.
Willing to concede the point for now.
For the IP and attribution concerns, does this apply to code only? Architecture white paper and requirements documents?
It should for completeness' sake, and if integrated with one's linuxfoundation.org identity then we'll get that for free, I think, since one will have filled that out (the equivalent of a DCO) while setting up an account. I see no need to anonymous contributions to a wiki at all, nor the architecture white paper and requirements docs. As for use cases for a wiki - right now, I could use one to track our investigation into Slack and Mailman alternatives. That's not a code-related thing, it's something where frequency of update and availability to all is more important than each commit being gerrit-reviewed. Here's an instance of Confluence running for anoth er LF project, OPNFV: https://wiki.opnfv.org/Note that they seem to use it for most of their community & web content. Sensing that we've talked this pretty deeply, I will ask LF IT to set up a Confluence instance running next to our Jira, and we can kick the tires. Brian
Jeremy
-------- Original message --------
From: Brian Behlendorf <bbehlendorf@linuxfoundation.org>
Date: 8/11/2016 2:10 PM (GMT-05:00)
To: jeremysevareid <jeremysevareid@...>
Cc: hyperledger-fabric@lists.hyperledger.org
Subject: Re: [Hyperledger-fabric] Wikis? (was Re: issues for fabric)
On 08/11/2016 10:56 AM, jeremysevareid wrote:
I agree on the PDF source file front.
Any preference for a spreadsheet tool? Ethercalc? Apache OpenOffice? Other?
Frankly all of them kind of suck for portability; if we're just using it to build a table of something, most wikis support tables, most in a wysiwyg way.
We're going to need one or something similar, in order to validate calcs, ledger updates, perform reconciliations, etc.
Any examples of where today we use it in the _development_process_? That would be new to me. Would we really be using e.g. Excel for "ledger updates, perform reconciliations"? I could see proper spreadsheets performing calculations as part of the documentation or white papers, perhaps.
Brian
-------- Original message --------
From: Brian Behlendorf <bbehlendorf@linuxfoundation.org>
Date: 8/11/2016 12:48 PM (GMT-05:00)
To: jeremysevareid <jeremysevareid@...>
Cc: hyperledger-fabric@lists.hyperledger.org
Subject: Re: [Hyperledger-fabric] Wikis? (was Re: issues for fabric)
On 08/10/2016 08:34 PM, jeremysevareid wrote:
Wiki, goggle docs and traditional file types like PDF, PPT and xls are already in use by the requirements and identity work groups.
Right. The goal should not be more tooling for tooling sake, but naming at least one as the preferred system of record, so that discovery, search-ability, and versioning are easier, as we do for software source code and issue tracking. Also, access to expensive proprietary tools required to edit powerpoint and excel files creates barriers to participation (not to mention those tools have very lousy version control systems if you try to operate outside Microsoft Sharepoint) The fewer attachments via email, the fewer links that are shared ad-hoc, the better the history of ideas can be traced so we can properly credit contributors and track IP, the better.
Can we consider supporting both a wiki and an agreed range of checked-in doc file types?
Sure, though the checked-in doc types should be editable. Too often PDFs are pretty pictures of information, but not really malleable or computable. So long as the source is always in a repo of some sort (and easily changeable by other committers, without having to use proprietary software) that's fine.
That could give contributors more flexibility to choose the right tool and still provide the community with interoperable files under strong controls.
E.g., an exported wiki snapshot could be checked in and reviewed as part of a tagged release. Exported Google, OpenOffice or MS docs, graphics and PDFs could as well.
I'd say anything included in a software release tarball should get the kind of formal review that Gerrit brings to the source code, since it's as important as the code itself, which also brings automatic conformance to a DCO. I'm uncomfortable with the idea that someone might contribute something important in a Google doc, and then it would end up in a package, without a DCO. Make that very uncomfortable.
Often debates about "right tools" come down to a matter of familiarity and aesthetics rather than objective metrics. Familiarity means ease of use which is important, at least for those already up to speed on that tool. But the cost of disparate tooling (where 3 different tools are used for something that 1 tool would be acceptable for) is hard to measure, and still very real.
Brian
-------- Original message --------
From: Brian Behlendorf <bbehlendorf@linuxfoundation.org>
Date: 8/10/2016 11:15 AM (GMT-05:00)
To: Shawn Amundson <amundson@...>
Cc: hyperledger-fabric@lists.hyperledger.org
Subject: Re: [Hyperledger-fabric] Wikis? (was Re: issues for fabric)
Most projects figure out that line pretty organically. The risk of limiting participation due to barriers to entry is high, and metrics hard to come by (how do you measure the people who wanted to edit but were turned off by the process). Let's see how it goes with content very core to the code (like API docs) built from markdown in the source code repository, and other content in the wiki (bootstrapping with the current content), and shift docs from one to the other as seems appropriate, or tighten write privs to the wiki worst case (e.g., we start to see a lot of spam or drive-by changes). I'll sign up to monitor wiki changes, as I hope others will.
We will still require an LF identity/account to edit the wiki, at which point we get the equiv of a DCO for their contributions. No Wikipedia-style anonymous contributions.
Google docs can be great for some forms of collaboration, but if links to those docs aren't wired into a w iki or other parts of the project website, they run the risk of becoming forgotten cul-de-sacs. Also, gdocs is blocked in some countries and increasingly across some corporate firewalls.
Brian
On 08/10/2016 06:58 AM, Shawn Amundson wrote:
Not sure how the project would successfully draw that line between what should be good proper docs and what should be unreviewed ad-hoc wiki docs. A new-user how-to deserves at least as much refinement/thought as API documentation. Brainstorming pages are best done in something collaborative like google docs. (wikis are non-collaborative - they neither provide pre-commit peer review nor multiple real-time editors).
From a practical legal perspective, it seems like you wouldn't want anything "real" to be written outside of the DCO process; if a great user's guide was written on the wiki by multiple authors, it seems like, regardless of quality, it could never be part of the project proper (and thus not version controlled, tagged, branched, etc.) without a big headache.
-Shawn
On Wed, Aug 10, 2016 at 12:07 AM, Brian Behlendorf <bbehlendorf@linuxfoundation.org> wrote:
Often, one benefit of a Wiki is that it provides a way to engage new developers or non-technical contributors in the development process, by making it easy to make the kind of small iterative simple improvements that often accompanies text editing, versus code development that is more about branches and pull requests and more formal reviews and processes. Many open source communities feel comfortable granting write privs to the wiki broadly, even to anonymous users, on this basis, combined with premise that version control will always let us roll back in case of mistakes or spam (I'd probably recommend that here, actually, so long as we could make it easy to follow commits to the wiki, and have unified logins). For more formal API and internal code documentation we do have a "readthedocs" section of the source code tree - does that use markdown? Seems like that suffices for the uses you might be thinking of. After all I can see API definitions and internal docs benefiting from more formal review than new-user how-to's or brainstorming pages. Brian
On 08/09/2016 03:13 PM, Shawn Amundson wrote:
Sounds like an opportunity to switch away from a traditional wiki and move to a markdown language (sphinx-doc or similar) backed by git+Jenkins. There are many benefits, including using the same review processes (gerrit, etc.) as we do with the rest of the source code.
-Shawn
On Mon, Aug 8, 2016 at 5:54 PM, Brian Behlendorf <bbehlendorf@...rg> wrote:
For the time being we can continue using the Github wiki, but to make the migration complete we should talk about setting up a separate wiki tool for the Hyperledger projects. Currently, the LF infrastructure team would support either a Mediawiki or a Dokuwiki instance (if I recall correctly), for which we would also get single sign-on. Does anyone here have a preferences? This would be for a project-wide wiki so may be better to discuss on hyperledger-technical-discuss@lists.hyperledger.org. Brian On 08/08/2016 03:26 PM, Kondo, Yuki wrote: Thanks, I understood that Jira will replace Github issue as well as Gerrit replaced Github Repository.
How about Github wiki? Do you have any plan to migrate wiki documents elsewhere?
Best Regards,
Yuki Kondo
Hitachi America, Ltd., Research & Development Division
Tel: (408) 986-6460 | Mail: Yuki.Kondo@...
From: Christopher B Ferris [mailto:chrisfer@...]
Sent: Monday, August 08, 2016 2:27 PM
To: Kondo, Yuki
Cc: hyperledger-fabric@...ledger.org
Subject: Re: [Hyperledger-fabric] issues for fabric
Jira issues replace the role of GitHub issues. Just a different tool - one that allows greater flexibility than GH. If you find a bug, submit a Jira issue and if you are interested, you can also submit a patch via Gerrit and reference the Jira issue in the Commit message. ----- Original message -----
From: "Kondo, Yuki" <Yuki.Kondo@...>
Sent by: hyperledger-fabric-bounces@lists.hyperledger.org
To: hyperledger-fabric <hyperledger-fabric@...rledger.org>
Cc:
Subject: Re: [Hyperledger-fabric] issues for fabric
Date: Mon, Aug 8, 2016 4:34 PM
Hello Chris. May I ask questions?
1) Process of issue discussion and bug fix
Currently, contributors submit issue/bug to Gerrit directly and reviewers check it.
How this process will change after migration to Jira?
2) Github Wiki document
Fabric has documents which are only stored on github wiki pages.
https://github.com/hyperledger/fabric/wiki
Where can I find these documents after migration to Gerrit & Jira has been completed?
Best Regards,
Yuki Kondo |近藤 佑樹
Hitachi America, Ltd., Research & Development Division
Tel: (408) 986-6460 | Mail: Yuki.Kondo@...
From: hyperledger-fabric-bounces@lists.hyperledger.org [mailto:hyperledger-fabric-bounces@...] On Behalf Of Gabor Hosszu
Sent: Monday, August 08, 2016 12:50 PM
To: hyperledger-fabric
Subject: Re: [Hyperledger-fabric] issues for fabric
+1 For the fresh start but I also agree with Arnaud's idea that we should try not to lose any important issue that is worth moving. :)
On Mon, Aug 8, 2016 at 9:15 PM, Christopher B Ferris <chrisfer@...> wrote:
+1 what Ry said, your LF credentials should work
Cheers,
Christopher Ferris
IBM Distinguished Engineer, CTO Open Technology
IBM Cloud, Open Technologies
email: chrisfer@...
twitter: @christo4ferris
blog: https://developer.ibm.com/opentech/author/chrisfer/
phone: +1 508 667 0402
-----Ry Jones <rjones@...> wrote: -----To: bob@...
From: Ry Jones <rjones@...>
Date: 08/08/2016 03:09PM
Cc: Christopher B Ferris/Waltham/IBM@IBMUS, hyperledger-fabric <hyperledger-fabric@...rledger.org>
Subject: Re: [Hyperledger-fabric] issues for fabric
The same credentials are used across any LF-managed property except the mailing list manager, so the same credentials should work on gerrit.hyperledger.org, jenkins.hyperledger.org, and jira.hyperledger.org.
On Mon, Aug 8, 2016 at 12:02 PM, Bob Summerwill <bob@...> wrote:
What login should be used for that JIRA instance, Chris?
My hyperledger.org credentials don't seem to work. Should they?
How many different logins are required for a Hyperledger participant to use all the infrastructure at the moment? Which are shared and which are separate? Thanks!
--
This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.
_______________________________________________
Hyperledger-fabric mailing list
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
|
|
|
