About STATUS file (was: Next 2.x release)

[Stefano Bagnara <ap...@bago.org>]

Steve Brewin wrote:
> Danny Angus wrote:
> 
> Can we not just give Danny's idea a try? We really need to find a way to cut
> out all of this noise.

That's what Im doing :-)
I already updated the STATUS when I wrote that message.

> Quite honestly, I can't be arsed to wade though threads to determine who
> said what to who and when.

I happy that you are on the listeners of that file. I wrote that message 
to understand who was interested in it apart Danny. It was not indended 
as an insult to Danny or any refusal to do that from me.

> I don't care whether its the status file or a wiki page (which should only
> editable by committers). I do care that we have a clear and visible
> direction recorded that has been decided by committer votes.

Ok, I'm interested understanding this opinions, because I would work 
better on a wiki page for this kind of things. That's another reason for 
my message.

> I hate to think of the time people have wasted in these and similar
> discussions that might more productively have been spent in moving James
> forward. Its true that to move forward we need a consensus on goals. Once
> achieved, we use the status file to publish them.

The hard part, unfortunately, is not recording it, but having a real 
consensus. I'm having real problem creating a consensus around something 
to collaborate upon for a goal, and when I think I did it I understand 
that I'm probably on the wrong line.

> It really shouldn't be this painful.

No it isn't.
Maybe I'll change my confidence on the role of the STATUS file when 
others but me and Danny will update it and when it will "mean" something 
to me, too!

Danny said about me "arguing" about the branches status:
"people who are driving out decisions will have more record keeping to 
do, thats just life I'm afraid."
I want to make it clear that I'm not lead/owner of any branch now, and I 
fill the PMC driven that decisions about branches, not me.

I have no problems updating the STATUS for things I think I 
understand/know/overview of, but I really would like to see more people 
involved in this because it seems to me that someone think that I'm 
doing what I want on James, and this is not really the case: most time I 
do what james needs, and what the PMC agreed, and this is much different 
from what I would like to do on James.

What about adding to the STATUS a per-committer space where anyone 
update (and add a "last-udpated" date) the personal goals?
------
Stefano Bagnara:
     - Committed to fix bugs for 2.3.1
     - Trying to keep updated james website, JIRA mantenaince
     - Trying to coordinate efforts for next-major
     - Working on the following list of issues for *next-major*:
       JAMES-52 8bitmime capabilities missing
       JAMES-595 artifacts names james => james-server
       JAMES-675 Add search-domain configurability to DNSServer
       JAMES-676 disable override of default resolver/cache in DNSServer
     - Optional mid-term issues:
       JAMES-134 JAMES-241 JAMES-288 Read/write streaming of data to db
       JAMES-491 SpoolManager refactorings
     - In the long term:
       JAMES-520 Create a RemoteDelivery service
       full DSN support
-----
You,
-----
Steve Brewin:
     - Currently busy, not active on code.
     - Partecipate on organizational and mentoring issues
-----
Maybe we should limit the list to the short term (releasable in 2.3.1, 
next-minor or next-major) efforts.

I would remove generic data like "Project Mission", "Assets", "PMC 
Members", "Committers" because all of this is already recorded in 
different places and the file would start to be too big.

WDYT?

Stefano

> Cheers
> 
> Steve
> 
>> On 11/7/06, Stefano Bagnara <ap...@bago.org> wrote:
>>
>>> Don't know what others think, but I have a few workflow
>> problems working
>>> on the STATUS file (I would prefer, for example, a wiki page).
>>> I would like to hear what other committers think about
>> this, as I would
>>> not like to be the only one updating it: I'm not the owner
>> of any open
>>> branch, but I just updated it to include some of them.
>> It is a matter of having a controlled record of what decisions we've
>> made, people who are driving out decisions will have more record
>> keeping to do, thats just life I'm afraid. And updating the STATUS
>> file isn't really much more difficult than updating a wiki page or
>> sending an email.
>>
>>> I personally don't need a status file because I spend
>> already so much
>>> time on this project that it is more probable I forgot my
>> name than the
>>> status of the project, and I currently feel I'm updating it to make
>>> Danny happy...
>> No, you should be doing it to record the fact that *other people* have
>> endorsed what you are doing, This is a collaboration and it is
>> important to record our consensus, especially important to people in
>> your position who might be accused of doing too much too quickly
>> without the support of the group. The STATUS file is there to back you
>> up.
>>
>>
>>> I really have problems deciding what to write there and what to not
>>> write there. I would write there every message I wrote in
>> the "roadmaps"
>>> threads but this would make it unreadable... so I don't
>> write much...
>>
>> No, just key facts, what version, when. If you *want to* you can add
>> *short* descriptions of what is planned for the versions, and record
>> VOTES which people might question. You're finding that it is hard to
>> keep reminding people that they have agreed to something. The STATUS
>> file should help stop that.
>>
>>
>>> That said I will update it when you'll write "this should be in the
>>> status file" ;-) . And maybe you can do this for a while so I learn.
>> I hope you will learn that it can benefit you by being your sword and
>> shield as well ;-)
>> And if it really doesn't help us with some of this stuff, well we can
>> stop using it again.
>>
>> d.



---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: About STATUS file (was: Next 2.x release)

[Bernd Fondermann <be...@googlemail.com>]

On 11/8/06, Stefano Bagnara <ap...@bago.org> wrote:
> What about adding to the STATUS a per-committer space where anyone
> update (and add a "last-udpated" date) the personal goals?
> ------
> Stefano Bagnara:
>      - Committed to fix bugs for 2.3.1
>      - Trying to keep updated james website, JIRA mantenaince
>      - Trying to coordinate efforts for next-major
>      - Working on the following list of issues for *next-major*:

Don't like. This only keeps others from doing this, even if the person
signed here is not doing it at all.

>        JAMES-52 8bitmime capabilities missing
>        JAMES-595 artifacts names james => james-server
>        JAMES-675 Add search-domain configurability to DNSServer
>        JAMES-676 disable override of default resolver/cache in DNSServer
>      - Optional mid-term issues:
>        JAMES-134 JAMES-241 JAMES-288 Read/write streaming of data to db
>        JAMES-491 SpoolManager refactorings
>      - In the long term:
>        JAMES-520 Create a RemoteDelivery service
>        full DSN support

I would like better if we keep JIRA for all this information because
it is intended to do exactly that.

> Steve Brewin:
>      - Currently busy, not active on code.
>      - Partecipate on organizational and mentoring issues
> -----

Such information is already proven on a daily basis by activity on
mailing lists etc. and likely to become outdated.

> I would remove generic data like "Project Mission", "Assets", "PMC
> Members", "Committers" because all of this is already recorded in
> different places and the file would start to be too big.

+1

  Bernd

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: About STATUS file

[Norman Maurer <nm...@byteaction.de>]

Bernd Fondermann schrieb:
> On 11/8/06, Stefano Bagnara <ap...@bago.org> wrote:
>> What about adding to the STATUS a per-committer space where anyone
>> update (and add a "last-udpated" date) the personal goals?
>> ------
>> Stefano Bagnara:
>>      - Committed to fix bugs for 2.3.1
>>      - Trying to keep updated james website, JIRA mantenaince
>>      - Trying to coordinate efforts for next-major
>>      - Working on the following list of issues for *next-major*:
>
> Don't like. This only keeps others from doing this, even if the person
> signed here is not doing it at all.
I don't agree.. If the person don't have time he should just remove the
issue from the status file..
>
>>        JAMES-52 8bitmime capabilities missing
>>        JAMES-595 artifacts names james => james-server
>>        JAMES-675 Add search-domain configurability to DNSServer
>>        JAMES-676 disable override of default resolver/cache in DNSServer
>>      - Optional mid-term issues:
>>        JAMES-134 JAMES-241 JAMES-288 Read/write streaming of data to db
>>        JAMES-491 SpoolManager refactorings
>>      - In the long term:
>>        JAMES-520 Create a RemoteDelivery service
>>        full DSN support
>
> I would like better if we keep JIRA for all this information because
> it is intended to do exactly that.
Agree .. Maybe we should just add the link to jira ?
>
>> Steve Brewin:
>>      - Currently busy, not active on code.
>>      - Partecipate on organizational and mentoring issues
>> -----
>
> Such information is already proven on a daily basis by activity on
> mailing lists etc. and likely to become outdated.
I like Stefanos idea.. It whould also be usefull if the commiter add a
comment if he is unreachable etc. Like holidays etc..
>
>> I would remove generic data like "Project Mission", "Assets", "PMC
>> Members", "Committers" because all of this is already recorded in
>> different places and the file would start to be too big.
>
> +1
+1
>
>  Bernd

bye
Norman


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org