At 2017-05-16 22:46:00, hyperledger-fabric-request@... wrote:
>Send Hyperledger-fabric mailing list submissions to
>	hyperledger-fabric@...
>
>To subscribe or unsubscribe via the World Wide Web, visit
>	https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric
>or, via email, send a message with subject or body 'help' to
>	hyperledger-fabric-request@...
>
>You can reach the person managing the list at
>	hyperledger-fabric-owner@...
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of Hyperledger-fabric digest..."
>
>
>Today's Topics:
>
>   1. suspicious code in multichain.NewChannelConfig (Sorin Manolache)
>   2. Post 1.0 feature work (Troy Ronda)
>   3. Re: Post 1.0 feature work (Baohua Yang)
>   4. Re: Post 1.0 feature work (Troy Ronda)
>   5. Re: Branching Model Final Thread (David Huseby)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Tue, 16 May 2017 15:52:34 +0200
>From: Sorin Manolache <sorinm@...>
>To: hyperledger-fabric <hyperledger-fabric@...>
>Subject: [Hyperledger-fabric] suspicious code in
>	multichain.NewChannelConfig
>Message-ID: <2d97d972-9900-9317-04eb-f07497ad03fd@...>
>Content-Type: text/plain; charset=utf-8; format=flowed
>
>Hello,
>
>multichain.NewChannelConfig contains the lines below:
>
>for key, value := range systemChannelGroup.Values {
>	channelGroup.Values[key] = value
>	if key == config.ConsortiumKey {
>		// Do not set the consortium name, we do this later
>		continue
>	}
>}
>
>I think the if-condition has no effect. Shouldn't it precede the assignment?
>
>Best regards,
>Sorin
>
>
>------------------------------
>
>Message: 2
>Date: Tue, 16 May 2017 14:20:17 +0000
>From: Troy Ronda <troy@...>
>To: "hyperledger-fabric@..."
>	<hyperledger-fabric@...>
>Subject: [Hyperledger-fabric] Post 1.0 feature work
>Message-ID:
>	<MWHPR10MB156529FA3599420D6F5A890DB0E60@...>
>	
>Content-Type: text/plain; charset="iso-8859-1"
>
>Hi all,
>
>
>Last week I sent a note proposing new feature development for Fabric (targeting post 1.0 GA). What is the best way to get going on post 1.0 development in our community? E.g., could I please request a branch for post 1.0 efforts?
>
>
>Thanks,
>
>Troy Ronda
>
>SecureKey Technologies
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL: <http://lists.hyperledger.org/pipermail/hyperledger-fabric/attachments/20170516/558fb0a4/attachment-0001.html>
>
>------------------------------
>
>Message: 3
>Date: Tue, 16 May 2017 22:25:38 +0800
>From: Baohua Yang <yangbaohua@...>
>To: Troy Ronda <troy@...>
>Cc: "hyperledger-fabric@..."
>	<hyperledger-fabric@...>
>Subject: Re: [Hyperledger-fabric] Post 1.0 feature work
>Message-ID:
>	<CACbo-EBRK4pnemq=dj9VVB17=Wj28BvEVazeu12OJ2SLziPe9A@...>
>Content-Type: text/plain; charset="utf-8"
>
>Why not open a jira issue and post the link here to collect comments?
>
>I think there are many people interested to discuss the post-1.0 features,
>as remaining in the original proposal, like Tcert, BFT, orderer privacy.
>
>On Tue, May 16, 2017 at 10:20 PM, Troy Ronda <troy@...> wrote:
>
>> Hi all,
>>
>>
>> Last week I sent a note proposing new feature development for Fabric
>> (targeting post 1.0 GA). What is the best way to get going on post
>> 1.0 development in our community? E.g., could I please request a branch
>> for post 1.0 efforts?
>>
>>
>> Thanks,
>>
>> Troy Ronda
>>
>> SecureKey Technologies
>>
>>
>> _______________________________________________
>> Hyperledger-fabric mailing list
>> Hyperledger-fabric@...
>> https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric
>>
>>
>
>
>-- 
>Best wishes!
>
>Baohua Yang
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL: <http://lists.hyperledger.org/pipermail/hyperledger-fabric/attachments/20170516/de90166d/attachment-0001.html>
>
>------------------------------
>
>Message: 4
>Date: Tue, 16 May 2017 14:33:33 +0000
>From: Troy Ronda <troy@...>
>To: Baohua Yang <yangbaohua@...>
>Cc: "hyperledger-fabric@..."
>	<hyperledger-fabric@...>
>Subject: Re: [Hyperledger-fabric] Post 1.0 feature work
>Message-ID:
>	<MWHPR10MB15652A54CD6CAE32B1BE70D8B0E60@...>
>	
>Content-Type: text/plain; charset="iso-8859-1"
>
>Hi Baohua - Thanks for the idea. As a result, I created FAB-3951 (https://jira.hyperledger.org/browse/FAB-3951).
>
>________________________________
>From: Baohua Yang <yangbaohua@...>
>Sent: May 16, 2017 10:25 AM
>To: Troy Ronda
>Cc: hyperledger-fabric@...
>Subject: Re: [Hyperledger-fabric] Post 1.0 feature work
>
>Why not open a jira issue and post the link here to collect comments?
>
>I think there are many people interested to discuss the post-1.0 features, as remaining in the original proposal, like Tcert, BFT, orderer privacy.
>
>On Tue, May 16, 2017 at 10:20 PM, Troy Ronda <troy@...<mailto:troy@...>> wrote:
>
>Hi all,
>
>
>Last week I sent a note proposing new feature development for Fabric (targeting post 1.0 GA). What is the best way to get going on post 1.0 development in our community? E.g., could I please request a branch for post 1.0 efforts?
>
>
>Thanks,
>
>Troy Ronda
>
>SecureKey Technologies
>
>_______________________________________________
>Hyperledger-fabric mailing list
>Hyperledger-fabric@...<mailto:Hyperledger-fabric@...>
>https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric
>
>
>
>
>--
>Best wishes!
>
>Baohua Yang
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL: <http://lists.hyperledger.org/pipermail/hyperledger-fabric/attachments/20170516/1f470c51/attachment-0001.html>
>
>------------------------------
>
>Message: 5
>Date: Tue, 16 May 2017 07:45:57 -0700
>From: David Huseby <dhuseby@...>
>To: Christopher Ferris <chris.ferris@...>
>Cc: hyperledger-fabric <hyperledger-fabric@...>
>Subject: Re: [Hyperledger-fabric] Branching Model Final Thread
>Message-ID:
>	<CAGrvdA16PqLMnYSmHMtZmY8VzOxZtF_c_jYpe4Qe4apw5J+s0A@...>
>Content-Type: text/plain; charset="utf-8"
>
>Thanks for the feedback, I plan to read through this later today and answer
>in full soon.
>
>Dave
>
>---
>David Huseby
>Security Maven, Hyperledger
>The Linux Foundation
>+1-206-234-2392 <+12062342392>
>dhuseby@...
>Skype: dwhuseby
>
>On Tue, May 16, 2017 at 4:44 AM, Christopher Ferris <chris.ferris@...>
>wrote:
>
>> Thanks, Greg.
>>
>> I like the idea of having automated promotion. I think that this is
>> consistent with Dave's desired auto-revert of a failed merge verify.
>>
>> Cheers,
>>
>> Chris
>>
>> On Mon, May 15, 2017 at 10:41 PM, Gregory Haskins <
>> gregory.haskins@...> wrote:
>>
>>> On Sat, May 13, 2017 at 11:20 AM, Christopher Ferris
>>> <chris.ferris@...> wrote:
>>> > I tend to share Greg's concerns about handling feature branches. As for
>>> > branch merging, I think we could probably make a case for permitting
>>> > maintainers to submit these. What we would need, though, is some form of
>>> > review and concurrence process.
>>>
>>> Yeah, and Gerrit is a little weak in this regard, or so we learned on
>>> the last go-round.  We would need to investigate and understand the
>>> behavior better.
>>>
>>> >
>>> > My other concern goes beyond Greg's concern about integrating with the
>>> main
>>> > development branch - is that the current modularity of the code base,
>>> while
>>> > enabling plug points for certain functions - is not at a level of
>>> maturity
>>> > that a feature's development would not overlap another's and we'd have
>>> > significant challenges dealing with this, as opposed to small
>>> incremental
>>> > changes on features developed behind a feature flag which we could
>>> disable
>>> > on a given release if the function were incomplete.
>>>
>>> All good points.
>>>
>>> >
>>> > I will say that I do favor a model where the default branch exposed via
>>> GH
>>> > is always the latest stable release, as opposed to the current model
>>> where
>>> > it is always the HEAD of master (our only branch) which is often
>>> unstable.
>>>
>>> I am definitely in favor of something different than what we do today.
>>> My problem isn't so much that I think that master must be a "release"
>>> as much as it is related to the way the current model throws things
>>> more or less "over the wall" and hopes for the best.  By that, I mean,
>>> contributors submit CRs, and those CRs run the gauntlet of tests but
>>> only w.r.t. the tree on which the submitter was based on at the time
>>> they submitted the patch.  Gerrit does a minimal amount of monitoring
>>> between the CR and HEAD over the lifetime of the CR, catching things
>>> like egregious git merge-conflicts with other CRs that have already
>>> been merged.  However, it won't catch more subtle issues such as a
>>> dependent configuration change that is merged ahead of the CR until
>>> _after_ the CR is merged.  This is bad.
>>>
>>> What I would love to see instead is that hitting "Submit" on a CR is
>>> just an early stage of the pipeline rather than the output of the
>>> process.  Consider it "the human approval" gate, but that the change
>>> must pass more gates before it becomes "active".  Furthermore, those
>>> gates are able to provide clear and obvious feedback to maintainers
>>> and contributors alike when something is wrong.  Today, once the CR is
>>> "submitted", we _do_ run the -merge job on it, but there are two
>>> problems: 1) it's too late because the change is already visible to
>>> the world, and 2) failures generally go unnoticed unless you happen to
>>> carefully watch for V-1s on CRs that are already merged.  I know that,
>>> sadly, I don't as carefully as is warranted.  I don't suspect many
>>> others do either.  Most of the time, I would say the -merge failure
>>> ends up being flaky CI (which is a different topic).  However,
>>> sometimes it really is a bad merge and you get this trainwreck effect
>>> where all new CRs that are rebased on top are failing through no fault
>>> of their own.  This is not to mention the poor souls just working with
>>> the tree directly.
>>>
>>> How this is all implemented could vary significantly.  Perhaps this is
>>> done with branches (the "develop+master" model both Dave and Chris
>>> have been talking about).  Perhaps it's done some other way.  I've
>>> been envisioning something inspired by the CICD trend: automated
>>> promotions.  The main component here is that the "submit" button in
>>> gerrit just kicks off some rigorous testing pipeline and, if
>>> successful, it is promoted to "production".  The main difference here
>>> is "production artifact" is the creation of a git commit in a stable
>>> branch as opposed to, say, a running process.  Likewise, a failure in
>>> the pipeline could kick it back to the user to fix and try again.
>>>
>>> I am not sure what this looks like exactly, but to my earlier point:
>>> I'm pretty sure we are not ready for it quite yet ;)
>>>
>>> Anyway, a sidebar to the above is that if we really nailed what I
>>> talked about above, we might even be able to do away with the notion
>>> of "a release" as an infrequent special celebration.  If the pipeline
>>> is rigorous enough, each commit that survives the gauntlet could be
>>> considered a continuously delivered evolution of the project, stable
>>> at any point in history at the granularity of an atomic commit in that
>>> designated stable branch.  Until then, periodic, explicit, and human
>>> curated releases are fine ;)
>>>
>>> > I think we could do this either by creating a new "release" branch for
>>> each
>>> > major and minor release, against which only CVE fixes are applied
>>>
>>> I think regardless of model, we need to do this...at least after the
>>> first CVE is discovered anyway. Prior to the first CVE, a tag is
>>> likely all that is needed, depending on your model.  However, this is
>>> a minor detail
>>>
>>> > and just change the default branch to be the latest release branch;
>>> > then we would not need to do the FF merging.
>>>
>>> I'm not sure I am following the branch-change thing.
>>>
>>> >
>>> > IFF we had a release branch(es), against which the only CRs would be CVE
>>> > fixes, we could automate a process to create a JIRA that tracked the
>>> process
>>> > of also updating the develop branch as appropriate (could be cherrypick,
>>> > could be a derivative fix).
>>>
>>> That's an interesting twist to use JIRA.  I hadn't thought of it that way.
>>>
>>> > I agree with Greg that we'd want that process in
>>> > place before we cut over to that model of development.
>>>
>>> Yeah, and FWIW I will implicitly NACK any plan that doesn't include
>>> the provisions to sanely manage on day one whatever this all ends up
>>> looking like. ;)
>>>
>>> >
>>> > Note that we can and IMO should adopt more rigorous review criteria.
>>> e.g.
>>> > coverage must not be reduced by a CR, any documentation changes must
>>> also be
>>> > merged with the change such that the documentation is always correct
>>> (even
>>> > though it might need editing),
>>>
>>> Agreed.
>>>
>>> Kind Regards,
>>> -Greg
>>>
>>
>>
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL: <http://lists.hyperledger.org/pipermail/hyperledger-fabric/attachments/20170516/a818f4b2/attachment.html>
>
>------------------------------
>
>_______________________________________________
>Hyperledger-fabric mailing list
>Hyperledger-fabric@...
>https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric
>
>
>End of Hyperledger-fabric Digest, Vol 13, Issue 59
>**************************************************