[Pulp-dev] PUP Process: "obvious consensus"

[Brian Bouterse]

The voting ended on August 11th with a final vote count of eight +1s and no
-1 votes. I've gone ahead and merged the revisions. Thank you for
everyone's comments, participation, and patience throughout this process.

Now that the revisions are merged, you can see the whole document here:
https://github.com/pulp/pups/blob/master/pup-0001.md

Thanks,
Brian


On Fri, Aug 11, 2017 at 9:11 AM, Michael Hrivnak <mhrivnak at redhat.com>
wrote:

> +1
>
> On Fri, Aug 11, 2017 at 4:54 AM, Ina Panova <ipanova at redhat.com> wrote:
>
>> +1.
>> Thanks Brian for all your effort and commitment.
>>
>>
>>
>> --------
>> Regards,
>>
>> Ina Panova
>> Software Engineer| Pulp| Red Hat Inc.
>>
>> "Do not go where the path may lead,
>>  go instead where there is no path and leave a trail."
>>
>> On Thu, Aug 10, 2017 at 9:58 PM, Daniel Alley <dalley at redhat.com> wrote:
>>
>>> +1
>>>
>>> On Thu, Aug 10, 2017 at 3:04 PM, Dennis Kliban <dkliban at redhat.com>
>>> wrote:
>>>
>>>> +1
>>>>
>>>> On Thu, Aug 10, 2017 at 9:21 AM, David Davis <daviddavis at redhat.com>
>>>> wrote:
>>>>
>>>>> +1. I think this is worth trying out.
>>>>>
>>>>>
>>>>> David
>>>>>
>>>>> On Thu, Aug 10, 2017 at 8:54 AM, Austin Macdonald <amacdona at redhat.com
>>>>> > wrote:
>>>>>
>>>>>> +1
>>>>>>
>>>>>> Thank you Brian!
>>>>>>
>>>>>> On Thu, Aug 10, 2017 at 5:33 AM, Brian Bouterse <bbouters at redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>> A small language clarification was pushed based on feedback via
>>>>>>> comment:  https://github.com/bmbouter/pu
>>>>>>> ps/commit/f5b7282b2d2e369b90f149e4cc25226bb093171b
>>>>>>>
>>>>>>> Voting is open for the PUP1 revisions. Normally the voting window is
>>>>>>> longer, but this topic has been discussed for a long time. The core team
>>>>>>> earlier this week decided a shorter voting window was appropriate in this
>>>>>>> case. Voting will close at midnight UTC on Friday Aug 11th. Please raise
>>>>>>> any concerns around this process. Otherwise, please send in votes via this
>>>>>>> thread. I'll cast mine now.
>>>>>>>
>>>>>>> +1 to passing the pup1 revisions.
>>>>>>>
>>>>>>> Thanks to everyone who has contributed comments and energy into this
>>>>>>> topic.
>>>>>>>
>>>>>>> -Brian
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Aug 7, 2017 at 10:15 AM, Brian Bouterse <bbouters at redhat.com
>>>>>>> > wrote:
>>>>>>>
>>>>>>>> After some in-person convo, the core team wants to open PUP1
>>>>>>>> revision voting on Wednesday and close it at midnight UTC on Friday Aug
>>>>>>>> 11th. We will pass/not-pass according this the voting outlined in PUP1
>>>>>>>> itself (a variation on self-hosting [0]). We also want to ask that any
>>>>>>>> comments on the PUP1 revisions by posted before midnight UTC tomorrow Aug
>>>>>>>> 8th.
>>>>>>>>
>>>>>>>> [0]: https://en.wikipedia.org/wiki/Self-hosting
>>>>>>>>
>>>>>>>> -Brian
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Jul 31, 2017 at 9:24 AM, Brian Bouterse <
>>>>>>>> bbouters at redhat.com> wrote:
>>>>>>>>
>>>>>>>>> I've pushed a new commit [3] to the PR. It includes the following
>>>>>>>>> changes. Please review and comment. If there are any major/blocking
>>>>>>>>> concerns about adopting this please raise them. Once the PUP1 revisions are
>>>>>>>>> resolved, PUP2 can also be accepted based on the votes it had previously.
>>>>>>>>>
>>>>>>>>> * Adjusts the +1 approvals to come from anywhere, not just core
>>>>>>>>> devs
>>>>>>>>> * Explicitly allows for votes to be recast
>>>>>>>>> * Explains two examples where votes are recast. One is based on
>>>>>>>>> many other -1 votes being cast. The other is when concerns are addressed
>>>>>>>>> and a -1 vote is recast.
>>>>>>>>>
>>>>>>>>> [3]: https://github.com/pulp/pups/pull/5/commits/959c67f5a4d16a26
>>>>>>>>> e1d97ea6fe4aa570066db768
>>>>>>>>>
>>>>>>>>> -Brian
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, Jun 27, 2017 at 3:33 PM, Brian Bouterse <
>>>>>>>>> bbouters at redhat.com> wrote:
>>>>>>>>>
>>>>>>>>>> From the discussion on the call last week, I've made some
>>>>>>>>>> revisions [2] to explore the idea of having a lazy consensus model.
>>>>>>>>>> Comments, ideas, concerns are welcome either on the PR or via this thread.
>>>>>>>>>>
>>>>>>>>>> As @mhrivnak pointed out, the adoption of a lazy consensus model
>>>>>>>>>> is meaningfully different than the language we have in pup1 today which
>>>>>>>>>> uses "obvious consensus". I want to be up front about that change [2]. If
>>>>>>>>>> anyone significantly disagrees with this direction, or has concerns, please
>>>>>>>>>> raise them.
>>>>>>>>>>
>>>>>>>>>> [2]: https://github.com/pulp/pups/pull/5/
>>>>>>>>>>
>>>>>>>>>> -Brian
>>>>>>>>>>
>>>>>>>>>> On Mon, Jun 19, 2017 at 1:48 PM, Brian Bouterse <
>>>>>>>>>> bbouters at redhat.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> After some in-person discussion, we will have a call to discuss
>>>>>>>>>>> ideas and options regarding the pup1 process. We will use this etherpad [0]
>>>>>>>>>>> for notes, and we will recap the information to the list also. In
>>>>>>>>>>> preparation, please continue to share ideas, perspectives and concerns via
>>>>>>>>>>> this list.
>>>>>>>>>>>
>>>>>>>>>>> When: June 22nd, 1pm UTC. See this in your local timezone here
>>>>>>>>>>> [1]. The call will last no longer than 1 hour.
>>>>>>>>>>>
>>>>>>>>>>> How to connect:
>>>>>>>>>>> video chat:    https://bluejeans.com/697488960
>>>>>>>>>>> phone only: + 800 451 8679   Enter Meeting ID: 697488960
>>>>>>>>>>>
>>>>>>>>>>> [0]: http://pad-katello.rhcloud.com/p/Pulp_PUP_Process_Revisited
>>>>>>>>>>> [1]: http://bit.ly/2rJqegX
>>>>>>>>>>>
>>>>>>>>>>> -Brian
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Jun 19, 2017 at 9:23 AM, Michael Hrivnak <
>>>>>>>>>>> mhrivnak at redhat.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Back to where we started, having digested the discussion here
>>>>>>>>>>>> and references cited, it seems clear that we have a system based on
>>>>>>>>>>>> consensus, and that there is strong desire for decisions about process to
>>>>>>>>>>>> continue being made with consensus. In terms of "obvious consensus", I'll
>>>>>>>>>>>> propose that if any core member thinks it has not been reached, it has
>>>>>>>>>>>> (perhaps by definition) not been reached.
>>>>>>>>>>>>
>>>>>>>>>>>> PUP0001 simply states in that case, "If obvious consensus is
>>>>>>>>>>>> not reached, then the core devs decide." We don't need to over-complicate
>>>>>>>>>>>> this. We've had reasonable success for many years at making process changes
>>>>>>>>>>>> and agreeing on them. The PUP system should be a tool that helps us define
>>>>>>>>>>>> a proposal as best we can, while providing a focal point for discussion. It
>>>>>>>>>>>> should not unduly impede our ability to make decisions.
>>>>>>>>>>>>
>>>>>>>>>>>> So in a case where consensus is not obvious, can we talk it out
>>>>>>>>>>>> among the core devs, particularly those with reservations, and make it our
>>>>>>>>>>>> collective responsibility to find a path forward? Do we need to define it
>>>>>>>>>>>> in more detail than that?
>>>>>>>>>>>>
>>>>>>>>>>>> On Fri, Jun 16, 2017 at 9:22 AM, David Davis <
>>>>>>>>>>>> daviddavis at redhat.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> I like centos model but personally I’m not a fan of the lazy
>>>>>>>>>>>>> consensus option (X=0). Instead, I like the idea of having X be greater
>>>>>>>>>>>>> than 1 (preferably 2). I feel like if there’s at least two people driving a
>>>>>>>>>>>>> change (i.e. X=2) then if one person leaves the project, we’ll still have
>>>>>>>>>>>>> someone who is able and motivated to take on the maintenance and evolution
>>>>>>>>>>>>> of the change. That said, I am happy to test out the model where X=0.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> David
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Thu, Jun 15, 2017 at 3:20 PM, Brian Bouterse <
>>>>>>>>>>>>> bbouters at redhat.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> I asked about some of these governance questions to a group
>>>>>>>>>>>>>> of community managers from several open source projects that I meet with
>>>>>>>>>>>>>> weekly. They said that if you don't have a BDFL (Pulp does not) the other
>>>>>>>>>>>>>> very popular model is the lazy consensus model. I think lazy consensus is
>>>>>>>>>>>>>> the spirit of pup1. I asked for some examples and they pointed me at the
>>>>>>>>>>>>>> CentOS governance model [0][1].
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Also @daviddavis and I were talking and codifying the problem
>>>>>>>>>>>>>> as what value should X be if X are the number of +1s required to pass a
>>>>>>>>>>>>>> decision with zero -1 votes (vetos)? The CentOS governance model sets X = 0
>>>>>>>>>>>>>> by stating "There is no minimum +1 vote requirement". I'm also advocating
>>>>>>>>>>>>>> for X=0 for the reasons I wrote in my earlier email. Practically speaking,
>>>>>>>>>>>>>> I don't think an X=1, or X=2 will prevent many proposals that would have
>>>>>>>>>>>>>> also passed with X=0.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Regardless of the X value, we should continue the discussion
>>>>>>>>>>>>>> so we can arrive at a decision on both pup1 and pup3. Thanks for continuing
>>>>>>>>>>>>>> the convo.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> [0]: https://www.centos.org/about/g
>>>>>>>>>>>>>> overnance/appendix-glossary/#consensus-decision-making
>>>>>>>>>>>>>> [1]: https://www.centos.org/about/governance/voting/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -Brian
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Tue, Jun 13, 2017 at 11:46 AM, Ina Panova <
>>>>>>>>>>>>>> ipanova at redhat.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> And if we would remove all 'shades of grey' and go back just
>>>>>>>>>>>>>>> to +1 and -1 where people would need to make their mind up *clearly* which
>>>>>>>>>>>>>>> would lead stronger arguments of doing or not doing this.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --------
>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Ina Panova
>>>>>>>>>>>>>>> Software Engineer| Pulp| Red Hat Inc.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> "Do not go where the path may lead,
>>>>>>>>>>>>>>>  go instead where there is no path and leave a trail."
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Tue, Jun 13, 2017 at 5:30 PM, David Davis <
>>>>>>>>>>>>>>> daviddavis at redhat.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> In this model of where only -1 votes stop the PUP from
>>>>>>>>>>>>>>>> passing, wouldn’t it mean that there needn't be any consensus at all? In
>>>>>>>>>>>>>>>> other words we could effectively strike the language about consensus from
>>>>>>>>>>>>>>>> PUP-1. This model makes me worried that people other than those casting -1
>>>>>>>>>>>>>>>> won’t bother to vote or participate since only -1 votes matter.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I personally like the idea of having at least 30% that are
>>>>>>>>>>>>>>>> +1 or +0. This means that enough -0 votes can still block the vote, and
>>>>>>>>>>>>>>>> also +0 votes goes towards helping the PUP pass. Thus +0 and -0 would both
>>>>>>>>>>>>>>>> matter. I think this is a good compromise between the extremes of "broad
>>>>>>>>>>>>>>>> buy-in" and "default to change."
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> David
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Tue, Jun 13, 2017 at 10:36 AM, Brian Bouterse <
>>>>>>>>>>>>>>>> bbouters at redhat.com> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> We should (I thought we did) adopt a process that favors
>>>>>>>>>>>>>>>>> change and does not have a "broad buy-in requirement". Any change that
>>>>>>>>>>>>>>>>> doesn't harm the project should be allowed without broad buy-in. This
>>>>>>>>>>>>>>>>> empowers even a single individual to enact change. This makes Pulp better
>>>>>>>>>>>>>>>>> because:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> * Everyone is empowered. A single individual can have a
>>>>>>>>>>>>>>>>> meaningful impact.
>>>>>>>>>>>>>>>>> * Anyone can stop an idea that will negatively affect the
>>>>>>>>>>>>>>>>> project or community via veto.
>>>>>>>>>>>>>>>>> * We avoid the tyranny of the majority [0] or
>>>>>>>>>>>>>>>>> supermajority.
>>>>>>>>>>>>>>>>> * It avoids politics. If we start averaging, or counting
>>>>>>>>>>>>>>>>> votes for/against in an offsetting way, there will be politics. Counting
>>>>>>>>>>>>>>>>> votes for/against will create inequality because influential project
>>>>>>>>>>>>>>>>> members will likely see their ideas adopted but others won't. Having a
>>>>>>>>>>>>>>>>> "default to change and any core dev can veto" approach creates equality.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Regarding how "obvious consensus" works with the
>>>>>>>>>>>>>>>>> "veto-or-it-passes" model, if there are zero -1 votes cast, that means no
>>>>>>>>>>>>>>>>> one wanted to stop the process. If no wants to stop it, and at least one is
>>>>>>>>>>>>>>>>> for it, then the most sensible thing to do is to pass it. Since someone
>>>>>>>>>>>>>>>>> took time to write the PUP there is obviously someone giving it a +1. If
>>>>>>>>>>>>>>>>> one person really wants to go to place X for dinner (aka a +1), and there
>>>>>>>>>>>>>>>>> are no counterproposals (aka a -1 with a suggestion) or strong preferences
>>>>>>>>>>>>>>>>> against (aka -0 or +0) then the group will probably go to place X for
>>>>>>>>>>>>>>>>> dinner by way of "obvious consensus".
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> In summary, adopting a "default to accept or reject with
>>>>>>>>>>>>>>>>> even a single veto" system creates an equal system. A system where, a
>>>>>>>>>>>>>>>>> single individual can make a difference, and anyone can stop a bad idea
>>>>>>>>>>>>>>>>> from occurring. To @mhrivnak's point about a change not meeting a broad
>>>>>>>>>>>>>>>>> range of needs, I expect -1's to be cast in those cases, so this system is
>>>>>>>>>>>>>>>>> still very safe in terms of protecting the projects needs and interests.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> [0]: https://en.wikipedia.org/wiki/Tyranny_of_the_majority
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> -Brian
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Mon, Jun 12, 2017 at 7:53 PM, David Davis <
>>>>>>>>>>>>>>>>> daviddavis at redhat.com> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Not sure this is true. I actually abstained from voting
>>>>>>>>>>>>>>>>>> on PUP-3 because I was somewhere between a +0 and a -0.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> David
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Mon, Jun 12, 2017 at 11:43 AM, Ina Panova <
>>>>>>>>>>>>>>>>>> ipanova at redhat.com> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Having at least one  +1 is not impartial approach just
>>>>>>>>>>>>>>>>>>> because the developer who , as you said, found the time for the research
>>>>>>>>>>>>>>>>>>> and writing down the proposal obviously will vote as +1 :)
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> --------
>>>>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Ina Panova
>>>>>>>>>>>>>>>>>>> Software Engineer| Pulp| Red Hat Inc.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> "Do not go where the path may lead,
>>>>>>>>>>>>>>>>>>>  go instead where there is no path and leave a trail."
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Mon, Jun 12, 2017 at 5:35 PM, Austin Macdonald <
>>>>>>>>>>>>>>>>>>> amacdona at redhat.com> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> This reminds me of the concept of a "Do-ocracy".
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> If developers take the time to research and write up a
>>>>>>>>>>>>>>>>>>>> proposal, they have "done". It seems completely reasonable to default to
>>>>>>>>>>>>>>>>>>>> the opinion of the people that cared enough to do the work. If it isn't the
>>>>>>>>>>>>>>>>>>>> right decision, then someone must actively block it, simple as that.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I think the rule should be "PUP passes if we have at
>>>>>>>>>>>>>>>>>>>> least one +1 and no -1s".
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>>>> Pulp-dev mailing list
>>>>>>>>>>>>>>>>>>>> Pulp-dev at redhat.com
>>>>>>>>>>>>>>>>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>>> Pulp-dev mailing list
>>>>>>>>>>>>>>>>>>> Pulp-dev at redhat.com
>>>>>>>>>>>>>>>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>> Pulp-dev mailing list
>>>>>>>>>>>>>>>>>> Pulp-dev at redhat.com
>>>>>>>>>>>>>>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> Pulp-dev mailing list
>>>>>>>>>>>>> Pulp-dev at redhat.com
>>>>>>>>>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>>
>>>>>>>>>>>> Michael Hrivnak
>>>>>>>>>>>>
>>>>>>>>>>>> Principal Software Engineer, RHCE
>>>>>>>>>>>>
>>>>>>>>>>>> Red Hat
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Pulp-dev mailing list
>>>>>>> Pulp-dev at redhat.com
>>>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Pulp-dev mailing list
>>>>>> Pulp-dev at redhat.com
>>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Pulp-dev mailing list
>>>>> Pulp-dev at redhat.com
>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Pulp-dev mailing list
>>>> Pulp-dev at redhat.com
>>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Pulp-dev mailing list
>>> Pulp-dev at redhat.com
>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>
>>>
>>
>> _______________________________________________
>> Pulp-dev mailing list
>> Pulp-dev at redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>
>>
>
>
> --
>
> Michael Hrivnak
>
> Principal Software Engineer, RHCE
>
> Red Hat
>
> _______________________________________________
> Pulp-dev mailing list
> Pulp-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20170817/b7870da8/attachment.htm>