Stefano Bagnara wrote: > > > 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.
So I see :) > > 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 never thought either was the case. Your reply was simply the most recent on the thread when I replied. My reply was directed at everyone. We need everyone to agree to give "Danny's idea a try". > > 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. Well I just looked at the http://moinmoin.wikiwikiweb.de/HelpOnAccessControlLists and it seems that it wouldn't be hard to access control a status page. Personally, I think this would be easier to update and therefore more likely to be updated. As we don't have single sign-on there would be an extra step when adding/removing committers to add them to a james-committer group which has the rights to update uch a page. The URL for such a page should be added as a child entry to http://james.apache.org/server/index.html under "Project". > > 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. When someone gets the votes in they record the vote in the status file. What was voted on exactly as written in the proposal and what the results were in summary (x +0, y -0, z +1). We don't have to wade though the lists. Its crystal clear. The minuses maybe dismayed about the result if a vote is passed, but that's democracy for you. > > It really shouldn't be this painful. > > No it isn't. Perhaps you meant "No it shouldn't" because it sure is painful right now. > 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." The ones driving our direction and putting in the most effort will always be making the most updates, its a record of our activity. It will need time to prove or disprove its worth. Like Danny, I think its a small worthwhile additional effort. Lets see. > 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. This is Apache. No individual owns anything. This doesn't stop people caring deeply about the projects they are involved in and their contributions and strongly expressing their care. We all do. > 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 > ----- In my view adding specific tasks already present in JIRA is overkill as JIRA already does a fine job of this. I guess we could automagically update the status page with a who is assigned to what task list, but why bother? Its all in JIRA. There should always be a single source of information. For concrete tasks this is JIRA. If others think this is useful information to be included in the status page (I don't) it should be dynamically harvested from the true source, JIRA. For non-specific tasks I would be minded to making them specific in JIRA, for instance making "fix bugs for 2.3.1" a JIRA task. I don't see the need to surface this detail in the status file, but if others do, again, it should be dynamically harvested from JIRA. > 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. Yes, this is true. The status page should only be concerned with the dynamic aspects. > > WDYT? --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
