incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olemis Lang <>
Subject Re: [Apache Bloodhound] Proposals/BEP-0003 modified
Date Thu, 15 Nov 2012 16:19:28 GMT
On 11/15/12, Gary Martin <> wrote:
> On 15/11/12 12:51, Peter Koželj wrote:
>> I am a bit confused here. It was only yesterday that we where still
>> discussing the features that multiproduct should bring and today I am
>> looking at BEP that already has hints of agreed and rejected solutions

There is nothing in rejected ideas at the moment , but it is there in
order to move unwanted parts of the specification we might find along
the way .

The only thing I've done so far is to move Jure's text to Rationale
section (where it belongs) and rewrite it in such a way that we think
about generic resources first and later about specific customizations
for tickets , wiki , ... Like I said before , we need to see the big
picture here . Multi-product support is not just about tickets and
wiki ... ;)

>> and
>> other stuff and I am not even certain that we agreed on features yet.
>> Did I miss something in ML archives?

No. I'm just throwing out portions of a proposal that IMO will make
our life easier because it works in a way quite similar to a
functional multi-env setup considered as a reference . Thus the impact
on plugins will be minimal in spite of making them work OOTB under the
new conditions.

The fact is that it will be very hard to discuss such things in the ML
if there's not an initial text as a starting point .

In python-dev the PEP champion sits under a dark rock , writes his
proposal and then submits to python-dev for approval . It may be all
wrong , or may be right with some/many adjustments needed . What I've
been doing is the first part of the process . I'm trying to put all
the pieces together and see how they should work . That does not mean
that what you see in there is all ok . So far it means that I suggest
to start with something like this , because of some reasons I'll be
mentioning as I write it.

Then in the process we all enhance it considering functional
requirements , issues with DB and transactions , ... whatever .

> Hmm.. a very good question. It still represents a proposal rather than
> something that we already agree on.

It is a draft . Exactly . It will represent the community consensus
after fleshing out its contents , discuss in the ML and identify
what's ok and what is wrong (unwanted features will be moved towards
«Rejected ideas») , and we all decide that it will be Final . It's a
draft at the moment .

In python-dev this happens after discussions => vote => (BDFL | PEP
czar) decision. We'll need to figure out how will that happen in this

> It is not yet clear that the
> proposal will meet our requirements in the form that it takes.

Exactly . It's a draft . I'm just putting some pieces together , and I
may be wrong . I'm still human ;)

I've been updating the wiki page step by step in order to start
discussing early the points mentioned in there .

> I will need to study the proposal as it evolves before I go with it

Of course , we all should do that and discuss the proposal before we
emit a final decision .

> but
> it is possible we can be able to pick out parts of the proposal that we
> can agree on for early implementation. I guess we'll see how it goes.

Indeed the proposal should document the most appropriate solution to
multi-product support . The fact that it will be implemented step by
step , and there will be intermediate milestones before getting should
not be a reason in first place to reject some parts of it ... IMO

.. [1] Reference Multi-environment setup for Multi-product architecture



Blog ES:
Blog EN:

Featured article:

View raw message