You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Nicola Ken Barozzi <ni...@apache.org> on 2003/10/04 10:12:16 UTC
[PROPOSAL] fold incubator-site into incubator CVS ( Re: Posting and
tracking project tasks )
Noel J. Bergman wrote:
> To a certain extent, the incubator is evolving, too. If evolving procedures
> that are not being disseminated, that's one problem.
>
> I propose that a good way to address this situation will be to make active
> use of the new JIRA install, Serge and I have scheduled for next Thursday.
IMO it will just obfuscate tasks more. What we need is more simplicity,
not complexity. IMO just keeping STATUS files in the Incubator is simple
enough.
The issue is more about visibility. We have created an incubator CVS and
an incubator-site CVS, but the incubator is only the site, and will
always be like this.
Therefore I propose that we move the STATUS files of incubator CVS into
incubator-site, so that they will be included in the website, then kill
off incubator and rename incubator-site to incubator.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] fold incubator-site into incubator CVS ( Re: Posting
and tracking project tasks )
Posted by Berin Lautenbach <be...@ozemail.com.au>.
Nicola Ken Barozzi wrote:
> Since there seems to be agreement that we should have some sort of
> Mentor reporting to the PMC, it would be easy for Mentors to update the
> STATUS file at every report.
>
> Does this sound reasonable?
+1.
One is a tool, the other is the processed information. The PMC probably
only cares about the information and the Mentor/Shepherd can keep that
information in whatever way suits best, provided it is delivered in a
standard format.
The STATUS file is the minimal requirement, allowing the Mentor the
greatest possible flexibility in how they deliver that requirement.
Cheers,
Berin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] fold incubator-site into incubator CVS ( Re: Posting
and tracking project tasks )
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Noel J. Bergman wrote:
...
<snipped why issue trackers are better/>
> These all contribute to why I suggest that issue tracking is better done
> with an issue tracker. So although I had not mentioned the STATUS file in
> this context, I had given it thought. I'm interested in your response, and
> those of others, to this assessment.
What I need is that a secure document about what has been done in the
project is kept in CVS. If that document is used actively as a means to
track issues is not important.
So if a mentor wants to use an issue tracker to help keep track of
issues it's just fine, as long as the information in CVS is updated
every once in a while. When the Incubator will vote the project out, it
will be based on the contents of that file.
Since there seems to be agreement that we should have some sort of
Mentor reporting to the PMC, it would be easy for Mentors to update the
STATUS file at every report.
Does this sound reasonable?
> As for the titular topic, I have no problem with the two modules merging.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: STATUS file compared/contrasted with an issue tracker
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Noel J. Bergman wrote:
> Nicola Ken Barozzi wrote:
>
>>Noel J. Bergman wrote:
>>
>>> I agree with Nicola Ken (and you) about using the STATUS file for
>>> project status, and had originally thought to suggest that such
>>> change requests could be entered into the STATUS file, too.
>>
>> I have checked in the incubator CVS a new version of the Incubator
>> site, with a proposed new layout.
>
> Can you post a live copy to your home page or somewhere?
Ok, but the source files are also important, as they are what we will be
actively working with.
http://www.apache.org/~nicolaken/whiteboard/incubator-draft-new-site/index.html
http://cvs.apache.org/viewcvs.cgi/incubator/src/documentation/content/xdocs/projects/
BTW, IMHO that FAQ is atarting to come along nicely:
http://www.apache.org/~nicolaken/whiteboard/incubator-draft-new-site/faq.html
>>I am now stuck with exactly this issue, the STATUS files.
>>Could you give me a hand in making a version that can be
>>effectively used for identifying action items in order?
>
> Be happy to do so. Of course, you won't be getting this until about 15
> hours after you posted, but yes.
:-)
>>We could use a status.xml file that contains information about who does
>>things, todos, and changes. The less nice side is that it's XML.
>>Ideas?
>
> Well, I want to hear Roy's thoughts, because the HTTP Server project seems
> to do a lot more in STATUS than most other projects. Personally, I would
> record in the STATUS file the incubation related information. Particularly
> issues related to status of legal issues, completion of exit criteria, and
> any other information that the Incubator PMC felt was important. At the
> least, the STATUS file will naturally be polled by the PMC for each review
> cycle. If the project chooses to copy the STATUS items into an issue
> tracker so that they'll receive periodic reminders of outstanding items,
> that would be their choice, but the only official document would be the
> STATUS file.
+1
> Since you want to use XML, if the XML were defined properly,
> someone could write a tool to generate a report of all outstanding items.
> But I don't think that we want to get into the process of building yet
> another ad hoc issue tracker.
Forrest already has a todo-changes-etc DTD that outputs the items. The
upside is that the changes also produce an RSS feed.
> Or we could stick with plain text. From what I think we are saying
> (including below), the original status file could come from a template,
> customized if/as necessary by the PMC and placed into the incubator CVS
> module.
That's what I have done now, but the current STATUS files are IMHO not
suitable for the task.
In any case, I think that plaintext is needed here, so eventually I'll
have also a text version of the above-stated DTDs so we can have the
best of both worlds.
>>> The ASF has different projects doing things differently. In my
>>> opinion, one of the interesting things with Incubator is that the
>>> Incubator is going to bring out those differences, and help to
>>> illuminate best practices across the ASF, not just for new
>>> projects.
>
>>True. But some things need to be taken into account nevertheless.
>>1 - security (authentication, authorization)
>>2 - history
>>3 - backups
>>4 - change messages to the Incubator Project
>>5 - one place to have all items tracked
>>
>>CVS gives all of these, and IMHO no issue tracker can easily be made to
>>do it.
>
>
> AFAIK, a good issue tracker (bugzilla notwithstanding) will do all of the
> above.
Through SSH? Can I easily point to a doc that shows what has been done
in, let's say, 5 years from now?
> But I'm *not* saying that we should use an issue tracker for
> incubation status. For one thing, we trust CVS and we don't afford any of
> the issue trackers the same degree of trust.
Exactly, agreed.
> So what, specifically, are we talking about in terms of your item #5? The
> fact that you say "we are not talking about 200 action items, but 20" leads
> me to believe that we're in agreement, and talking about the status of items
> related to incubation. And those we agree should be recorded in the STATUS
> file.
Exactly. The STATUS files of the projects in the incubator site CVS are
about *incubation* STATUS.
>>they are free to *also* use an issue-tracker, as long as
>>the mentor reports these in CVS in a reasonabe timeframe
>
> We appear to be saying the same things, yes?
Yup :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: STATUS file compared/contrasted with an issue tracker
Posted by Berin Lautenbach <be...@ozemail.com.au>.
Nicola Ken Barozzi wrote:
> BTW, I wrote two mails about it on this list, did you miss them? I mean,
> are we still having problems with mails?
>
I seem to be getting the odd mail bounced after five days of trying?
Cheers,
Berin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: STATUS file compared/contrasted with an issue tracker
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Roy T. Fielding wrote:
> NKB wrote:
>> I have checked in the incubator CVS a new version of the Incubator
>> site, with a proposed new layout.
>>
>> I am now stuck with exactly this issue, the STATUS files.
>> Could you give me a hand in making a version that can be effectively
>> used for identifying action items in order?
>>
>> We could use a status.xml file that contains information about who
>> does things, todos, and changes. The less nice side is that it's XML.
>
> I don't mind xml, but I am somewhat concerned about placing the STATUS
> information where end-users are expected to look. A project's detailed
> status within incubator should only be of interest to the developers and
> incubator pmc.
Hmmm, you mean that we should not publish the status files on the
website? If this is the case I disagree, as it's important that on
public docs we are as transparent as possible.
> In particular, I wouldn't want people to feel the need
> to dumb-down or generalize its content for the sake of user documentation,
> as is often done with website content.
I agree on this. In fact that's why I'm trying to come up with a
"standard" status doc, that would reflect only the incubation items, and
link to the project website for more info.
> OTOH, it would be really nice
> to replace the big text checklist with a table-formatted list,
ACK
> and I'd
> like to reduce the number of redundant directories in the incubator
> module so that people won't have to search all over for relevant bits.
That's the idea, to have a single directory with all the incubator docs.
Have also a 1-1 mapping with the website, so that we know where to look
for and where to change docs.
> BTW, having to dig way down to src/documentation/content/xdocs
> just to get to the top of the website source seems a bit ridiculous.
That's the standard position, as projects usually have lots of other
artifacts. I can change it though, and having felt the same thing, will.
> Why are the site sources in both incubator and incubator-site?
I am moving the incubator stuff in only one place, ie incubator. But
it's a WIP, so I also kept the other site. The new proposed site in in
inbcubator CVS.
BTW, I wrote two mails about it on this list, did you miss them? I mean,
are we still having problems with mails?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: STATUS file compared/contrasted with an issue tracker
Posted by Berin Lautenbach <be...@ozemail.com.au>.
Noel J. Bergman wrote:
> cycle. If the project chooses to copy the STATUS items into an issue
> tracker so that they'll receive periodic reminders of outstanding items,
> that would be their choice, but the only official document would be the
> STATUS file. Since you want to use XML, if the XML were defined properly,
> someone could write a tool to generate a report of all outstanding items.
> But I don't think that we want to get into the process of building yet
> another ad hoc issue tracker.
>
> Or we could stick with plain text. From what I think we are saying
> (including below), the original status file could come from a template,
> customized if/as necessary by the PMC and placed into the incubator CVS
> module.
Apologies for coming in late on the conversation - have been away from
e-mail.
I think everyone is agreeing - but one other thought that comes to mind
that supports a text STATUS file is that it is the minimal possible
requirement.
So if we want to put a process/policy requirement in place, this is the
one that makes sense. It can be implemented using a status tracker, or
by processing an XML file - i.e. in whatever way the mentor/podling
think is best for their incubation effort. If we start saying we want
this tool or that then things start getting messy.
Doesn't mean that the Incubator can't point people to a favourite
tracker as a tool - just means it's a suggestion, not a requirement.
Cheers,
Berin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: STATUS file compared/contrasted with an issue tracker
Posted by "Noel J. Bergman" <no...@devtech.com>.
Nicola Ken Barozzi wrote:
> Noel J. Bergman wrote:
> > I agree with Nicola Ken (and you) about using the STATUS file for
project
> > status, and had originally thought to suggest that such change requests
> > could be entered into the STATUS file, too.
> I have checked in the incubator CVS a new version of the Incubator site,
> with a proposed new layout.
Can you post a live copy to your home page or somewhere?
> I am now stuck with exactly this issue, the STATUS files.
> Could you give me a hand in making a version that can be
> effectively used for identifying action items in order?
Be happy to do so. Of course, you won't be getting this until about 15
hours after you posted, but yes.
> We could use a status.xml file that contains information about who does
> things, todos, and changes. The less nice side is that it's XML.
> Ideas?
Well, I want to hear Roy's thoughts, because the HTTP Server project seems
to do a lot more in STATUS than most other projects. Personally, I would
record in the STATUS file the incubation related information. Particularly
issues related to status of legal issues, completion of exit criteria, and
any other information that the Incubator PMC felt was important. At the
least, the STATUS file will naturally be polled by the PMC for each review
cycle. If the project chooses to copy the STATUS items into an issue
tracker so that they'll receive periodic reminders of outstanding items,
that would be their choice, but the only official document would be the
STATUS file. Since you want to use XML, if the XML were defined properly,
someone could write a tool to generate a report of all outstanding items.
But I don't think that we want to get into the process of building yet
another ad hoc issue tracker.
Or we could stick with plain text. From what I think we are saying
(including below), the original status file could come from a template,
customized if/as necessary by the PMC and placed into the incubator CVS
module.
> > The ASF has different projects doing things differently. In my opinion,
one
> > of the interesting things with Incubator is that the Incubator is going
to
> > bring out those differences, and help to illuminate best practices
across
> > the ASF, not just for new projects.
> True. But some things need to be taken into account nevertheless.
> 1 - security (authentication, authorization)
> 2 - history
> 3 - backups
> 4 - change messages to the Incubator Project
> 5 - one place to have all items tracked
> CVS gives all of these, and IMHO no issue tracker can easily be made to
> do it.
AFAIK, a good issue tracker (bugzilla notwithstanding) will do all of the
above. But I'm *not* saying that we should use an issue tracker for
incubation status. For one thing, we trust CVS and we don't afford any of
the issue trackers the same degree of trust.
So what, specifically, are we talking about in terms of your item #5? The
fact that you say "we are not talking about 200 action items, but 20" leads
me to believe that we're in agreement, and talking about the status of items
related to incubation. And those we agree should be recorded in the STATUS
file.
> they are free to *also* use an issue-tracker, as long as
> the mentor reports these in CVS in a reasonabe timeframe
We appear to be saying the same things, yes?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: STATUS file compared/contrasted with an issue tracker
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Why are the site sources in both incubator and incubator-site?
Nicola Ken had indicated his plan to move the site into incubator, and to
eliminate the site module. The two top level directories would be the site/
and the projects/.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: STATUS file compared/contrasted with an issue tracker
Posted by "Roy T. Fielding" <fi...@apache.org>.
> I have checked in the incubator CVS a new version of the Incubator
> site, with a proposed new layout.
>
> I am now stuck with exactly this issue, the STATUS files.
> Could you give me a hand in making a version that can be effectively
> used for identifying action items in order?
>
> We could use a status.xml file that contains information about who
> does things, todos, and changes. The less nice side is that it's XML.
I don't mind xml, but I am somewhat concerned about placing the STATUS
information where end-users are expected to look. A project's detailed
status within incubator should only be of interest to the developers and
incubator pmc. In particular, I wouldn't want people to feel the need
to dumb-down or generalize its content for the sake of user
documentation,
as is often done with website content. OTOH, it would be really nice
to replace the big text checklist with a table-formatted list, and I'd
like to reduce the number of redundant directories in the incubator
module so that people won't have to search all over for relevant bits.
BTW, having to dig way down to src/documentation/content/xdocs
just to get to the top of the website source seems a bit ridiculous.
Why are the site sources in both incubator and incubator-site?
....Roy
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: STATUS file compared/contrasted with an issue tracker
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Noel J. Bergman wrote:
> Roy T. Fielding wrote:
...
> I agree with Nicola Ken (and you) about using the STATUS file for project
> status, and had originally thought to suggest that such change requests
> could be entered into the STATUS file, too.
I have checked in the incubator CVS a new version of the Incubator site,
with a proposed new layout.
I am now stuck with exactly this issue, the STATUS files.
Could you give me a hand in making a version that can be effectively
used for identifying action items in order?
We could use a status.xml file that contains information about who does
things, todos, and changes. The less nice side is that it's XML.
Ideas?
...
> The ASF has different projects doing things differently. In my opinion, one
> of the interesting things with Incubator is that the Incubator is going to
> bring out those differences, and help to illuminate best practices across
> the ASF, not just for new projects.
True. But some things need to be taken into account nevertheless.
1 - security (authentication, authorization)
2 - history
3 - backups
4 - change messages to the Incubator Project
5 - one place to have all items tracked
CVS gives all of these, and IMHO no issue tracker can easily be made to
do it. In any case, we are not talking about 200 action items, but 20.
And as I said, they are free to *also* use an issue-tracker, as long as
the mentor reports these in CVS in a reasonabe timeframe (ie a couple of
weeks)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: STATUS file compared/contrasted with an issue tracker
Posted by "Noel J. Bergman" <no...@devtech.com>.
Tetsuya Kitahata wrote:
> Noel J. Bergman wrote:
> > The ASF has different projects doing things differently. In my
> > opinion, one of the interesting things with Incubator is that the
> > Incubator is going to bring out those differences, and help to
> > illuminate best practices across the ASF, not just for new projects.
> Also, I am sure that the point is that those who would relate to the
> ASF should get aware of the fact that the different rules
> should be applied to differed *gradation* (STATUS?) of each projects.
You may not have realized that the STATUS file is actually a specific file
in the CVS module named STATUS. I don't agree that rules should be
different because the HTTP Server project should be about stability, and
other projects should be about rapid development. ASF software is supposed
to be something you can count on. Each package may not scale to enterprise
size, but each should strive for enterprise quality in any stable release.
Do you imagine that Tomcat, Xerces, and Axis should be anything less than
stable?
My point was not that the HTTP Server project does things differently
*because ...*. It was simply an observation that various projects do things
differently. My comment was about what is, not what should be. For
example, one rule is that the PMC is supposed to approve a release. Just
because not all projects know about or practice the rule doesn't mean that
they shouldn't.
Here in the Incubator, we are trying to teach best practices to new
projects. Since we come from different ASF projects, this nexus is where
project differences become more apparent, and where we can try to document
best practices not only for new projects, but also to disseminate to
existing ones.
I don't believe that there is any disagreement over the use of the STATUS
file. The STATUS file should be the official document regarding incubation
status for a project. AFAIK, Nicola Ken is saying the same thing, and
emphasized that he is talking about a score of items important to the PMC.
If anything, the question is what else to do in the STATUS file compared to
an issue tracker.
The HTTP Server project probably makes the fullest use of the STATUS file of
any ASF project, and I'd like to know more about their practices, since I
mostly see what goes on in Children of Jakarta projects.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: STATUS file compared/contrasted with an issue tracker
Posted by Tetsuya Kitahata <te...@apache.org>.
On Wed, 8 Oct 2003 10:39:34 -0400
"Noel J. Bergman" <no...@devtech.com> wrote:
> The ASF has different projects doing things differently. In my
> opinion, one of the interesting things with Incubator is that the
> Incubator is going to bring out those differences, and help to
> illuminate best practices across the ASF, not just for new projects.
Quite agreed. Bravo!
This is exacly what I wanted to express by my `POOR' Eng*r*ish.
Also, I am sure that the point is that those who would relate to the
ASF should get aware of the fact that the different rules
should be applied to differed *gradation* (STATUS?) of each projects.
For example, HTTP Server project is matured enough. There
would be less "new function requirements" than those of all the jakarta
sub-projects. Long History ... and all the committers (nearly equalled
to ASF members) really deserve to be respected by other OSS
communities and members. However, the rule which would be the best
to HTTP Project is not necessarily the best to Jakarta (and Java world).
Jakarta requires "SPEED", on the other hand, HTTP Project requires
"STABILITY" ... Different rules should be applied as a matter of course.
However, there would be also needed "consistency" as projects
under ASF umbrella. (Legal issues, etc.) Training ourselves to find it
out with our own eyes where exists the diverging point of "diversity"
and "consistency" would be necessary, I suspect.
Understanding "heterogeneousness" as well as "differentials"/"diversities"
and the attitude of the respects to each other would be highly
appreciated in this apache (apatchy!?) community, I am sure, and
sublimation of such heterogeneousness into "evolution" would be ultimate
destination for us. The Incubator Project would be sure to provide
such a "experimental" place for all the developers/committers/members
who DO love apache.org and who DO want to contribute to and get
involved in the societies, opensource communities :-)
Peace,
-- Tetsuya. (tetsuya@apache.org)
P.S. You may "s/Jakarta/XML/" or "s/Jakarta/WS/" ... ;-)
---------------------------------------------------------------------
Tetsuya Kitahata -- Terra-International, Inc.
E-mail: tetsuya@apache.org http://www.terra-intl.com/
Apache Software Foundation Committer: http://www.apache.org/~tetsuya/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
STATUS file compared/contrasted with an issue tracker
Posted by "Noel J. Bergman" <no...@devtech.com>.
Roy T. Fielding wrote:
> AFAIK, Jira does not authenticate that the person entering the status
> information has the authority to do so, which is what we get with the
> cvs process.
When I asked Serge, he replied that "You can control what an unauthenticated
person can do. It has very fine grained permission rules." So apparently,
it does do authentication, although we'd want to ensure that the person
claiming to be so-and-so on the issue tracker was really that person. As a
side note, I'll suggest that if we ever move to doing client auth over HTTPS
for Committers, we'd probably want the issue tracker to be capable of using
it, too. However, for the purpose I'm suggesting it be used, does it need
to authenticate?
I suppose that one interesting issue with the STATUS file is its purpose /
how to use it. The HTTPd project, since I just looked at the STATUS file
for httpd-2.0, seems to use it to record some bugs, list current project
status as a snapshot, record votes on decisions, etc. In some ways, it
appears that HTTPd uses the STATUS file as an issue tracker, and the CVS
preserves the historical record (e.g., when things are removed). Other
projects use bugzilla or (increasingly) Jira, and make far less use of the
STATUS file. What should be normative use is certainly not clear to me.
Nor to Serge when he asked me about it.
I would expect the primary use for the STATUS file in the incubator module
to be the project's incubation status.
I agree with Nicola Ken (and you) about using the STATUS file for project
status, and had originally thought to suggest that such change requests
could be entered into the STATUS file, too. However, it seems to me that an
issue tracker is better for managing for requests/action items. The project
using it can always reject the request. And I would expect, as a general
rule, that requests coming into a project will often be from people who
don't have authorization to either mandate the request or to change a STATUS
file, although in this instance, Greg certainly had both.
Is a request that a particular change be made to the web site a STATUS item
or a work item? FWIW, there was no change made even to the STATUS file
AFAIK. There was an e-mail, which was missed and/or not acted upon. An
issue tracker would not permit that to happen. The active nature of the
issue tracker is some thing that I feel provides a distinct advantage over
the STATUS file for tracking requests.
The ASF has different projects doing things differently. In my opinion, one
of the interesting things with Incubator is that the Incubator is going to
bring out those differences, and help to illuminate best practices across
the ASF, not just for new projects.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] fold incubator-site into incubator CVS ( Re: Posting and tracking project tasks )
Posted by "Roy T. Fielding" <fi...@apache.org>.
> The STATUS file is passive. Jira is active. The STATUS file requires
> the
> submitter to have CVS commit access to that module, and CVS knowledge.
> Jira
> has its own access control, and a built-in UI. The STATUS file
> requires
> human parsing to understand the priorities. Jira has a prioritization
> model. Updating the STATUS file requires a checkout/update, edit,
> commit.
> Jira would be simply filing an issue via the webapp.
AFAIK, Jira does not authenticate that the person entering the status
information has the authority to do so, which is what we get with the
cvs process.
....Roy
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: [PROPOSAL] fold incubator-site into incubator CVS ( Re: Posting and tracking project tasks )
Posted by "Noel J. Bergman" <no...@devtech.com>.
Nicola Ken Barozzi wrote:
> Noel J. Bergman wrote:
> > To a certain extent, the incubator is evolving, too. If evolving
procedures
> > that are not being disseminated, that's one problem.
>
> > I propose that a good way to address this situation will be to make
active
> > use of the new JIRA install, Serge and I have scheduled for next
Thursday.
> IMO it will just obfuscate tasks more. What we need is more simplicity,
> not complexity. IMO just keeping STATUS files in the Incubator is simple
> enough.
I had thought of that, and ended up removing the paragraph discussing the
STATUS file because of the differences. I am not trying to complicate the
process. I am proposing what I believe is at least as easy a process, and
which better facilitates active oversight through a more appropriate tool.
The STATUS file is passive. Jira is active. The STATUS file requires the
submitter to have CVS commit access to that module, and CVS knowledge. Jira
has its own access control, and a built-in UI. The STATUS file requires
human parsing to understand the priorities. Jira has a prioritization
model. Updating the STATUS file requires a checkout/update, edit, commit.
Jira would be simply filing an issue via the webapp.
There was a study long ago related to auto-pilots. The initial idea was
that the computer would fly the plane, and the human would monitor its
actions. Turns out that we are particularly poor at monitoring something
that is usually fine; we get bored, and inattentive. It works much better
when the computer is monitoring us, rather than the other way around.
Hence, the active nature of the issue tracker seems a key. It is like the
question of "If a tree falls in a forest, and no one is there to hear, does
it make a sound?" ** If an issue is added to STATUS, and action is not
immediate, will anyone remember? Will the change even be noticed? The
STATUS files are in a common module; to which list are the commit notices
posted? Lastly, I don't think that an inbox makes a good issue tracker.
With high e-mail volumes, if a message isn't acted upon and deleted, once it
scrolls off the screen, there is a tendency for it to be out of sight, out
of mind until the person has time to address the backlog. The issue
tracker, on the other hand, will continue to remind until the task is marked
as completed.
These all contribute to why I suggest that issue tracking is better done
with an issue tracker. So although I had not mentioned the STATUS file in
this context, I had given it thought. I'm interested in your response, and
those of others, to this assessment.
As for the titular topic, I have no problem with the two modules merging.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org