Status file (Was: JAMES v2.4 Road Map)

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

Hi Danny,

I extracted the status file related sentences from the previous message.
I think that the "in-progress" issues in JIRA already have the 
informations you would like to add to the status file:

https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&pid=10411&status=3

In fact I would prefer to use JIRA for tasks, for roadmaps, and for 
tracking.

Furthermore I also use the "Assignment" also for issues I'm not 
currently working on, but I think I should be contacted before anyone 
else approach the same problem:
https://issues.apache.org/jira/secure/IssueNavigator.jspa?assigneeSelect=specificuser&sorter/field=priority&mode=hide&reset=true&resolution=-1&assignee=bago&pid=10411&sorter/order=DESC
You can see that I have DSN support, memory efficient retrieval, remote 
delivery service and more: I worked on all of this, I probably have 
almost working code for each one, but I'm not ready to discuss about all 
the complications of committing them to trunk.

If we can agree on a standard workflow/usage of JIRA I would prefer it 
over a status file to be committed in svn. Often I update JIRA when I 
have no other access than http and I can't commit so I use that spare 
time to update/reorganize JIRA.

I would be happy to be able to have a more clear roadmap about the next 
release and I could update the current trunk roadmap:
https://issues.apache.org/jira/browse/JAMES?report=com.atlassian.jira.plugin.system.project:roadmap-panel
to remove some of the "UNRESOLVED" issues that we already know won't be 
part of the next release.
E.g: there is no effort on the IPV6 side, so we could remove the ipv6 
issues from that roadmap.

I often asked people to review that list and to say what they think 
should be removed, what they think is a must, what they think is an option.

Briefly: I'm +1 to increase the usage of JIRA also for our 
roadmap/status tracking. -0 on the introduction of a status file in svn.

Stefano

Danny Angus wrote:
 > Stefano Bagnara wrote:
>> I'm happy enough with what JIRA roadmaps give us.
>> I don't know what exactly you mean with "status file" but I would not
>> like having more pieces to mantain.
> 
> the STATUS file is a mechanism used by Apache projects to record what
> work is planned and who is doing it.
> It allows the project cope with both a rapid cycle of defect fixes and
> minor enhancements, and with a longer cycle of major refactorings.
> 
>> It is already boring enough to
>> manually update the changelog in our website at each release.
> 
> Yes that is a painful task, but this is not the same thing, it isn't
> about what has changed but about everyone being able to record what
> they are working on and what state it is in.
> It can make planning releases much easier.
> [...]
>> I think that Norman and I did exactly a proper plan and almost a proper
>> timetable because we put on the table tasks that we was willing to do.
> 
> Right, and thats the right thing to do. If everyone adds their own
> thing to a list (the status file?) we can see what everyone is capable
> of achieving, and outline the contents of planned releases without
> having to comit to dates.
> Releases need to be roughly planned for major and minor cycles to
> prevent major changes from blocking defect fixes.
> 
>> I would be happy to start discussing a bigger/better roadmap: anyone
>> should start writing what they will be willing to work on and when. THen
>> we can see how to solve the puzzle (and what can be part of James and
>> what not).
> 
> I think I will propose the use of the status file, and we can see what
> we think once we've tried it, unless it gets shot down by the veto
> brigade ;-).
> 
>> I personally don't have a fixed roadmap: it depends on my mood and
>> sometimes on what features my clients are willing to pay me for ;-) but
>> I always try to keep trunk consistent and to commit things only when I
>> know I can finish it.
> 
> Thats the right approach, and (if you don't mind me saying so) one of
> several reasons that your contributions have been such a sucess, which
> in turn has encouraged others to become more involved.
> 
> d.



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

Re: Status file (Was: JAMES v2.4 Road Map)

[Danny Angus <da...@gmail.com>]

Stefano,

In many ways I agree with you, but I still believe that som summary
information reported in a status file, along with a record of the
decisions needed, made and outstanding, will help *you* to do the
things you want to without frightening everyone else ;-)

> If we can agree on a standard workflow/usage of JIRA I would prefer it
> over a status file to be committed in svn. Often I update JIRA when I
> have no other access than http and I can't commit so I use that spare
> time to update/reorganize JIRA.

I don't think the two things are really the same, and I don't think
you would be expected to replace your use of JIRA with the status
file, which is more (IMO) of a summary of what the plan is, than a
detailed record of every task.


> Briefly: I'm +1 to increase the usage of JIRA also for our
> roadmap/status tracking. -0 on the introduction of a status file in svn.

Ok, I'll take this on board.

d

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