On 16/03/13 12:36, Ryan Ollos wrote:
On Sat, Mar 16, 2013 at 1:44 AM, Greg Stein <[email protected]> wrote:
How about leaving some TODO markers in the page via commit? Maybe
somebody will follow up on that commit, and actually make the changes.
Joe filled this ticket and he's primarily a designer rather than a
developer. It doesn't make sense for him to checkout and edit the codebase
in order to ask for something to be implemented.
Why should the marker be within a ticket, instead of the codebase
itself? Again, if somebody goes to fix this, then they have
double-work: make some commits, and make some ticket changes.
Maybe you don't think that an issue tracker should exist at all? You
continue to suggest that we not use the issue tracker for anything as far
as I can tell. You seem to feel that Subversion and the mailing list are
entirely adequate, and an issue tracker would then be used for what? I
disagree, and I can't speak for others, but I get the impression that I'm
not alone in disagreeing.
The ticket system is entirely divorced from the codebase. Consider:
community members can spend the next month handling tickets. Does that
accomplish anything? Nope. Alternative: work within the actual
product, making changes/notes as they are discovered.
I'd suggest that we aim to improve the integration of the ticket system
with the code base and correct the flaws here, rather than giving up and
not using the ticket system.
I'm not going to repeat any of my arguments of why I think the ticket
system is better and more valuable than a mailing list, but you can read
them in (1) if you like.
On Sat, Mar 16, 2013 at 1:40 AM, Greg Stein <[email protected]> wrote:
This is better discussed on the mailing list, rather than moving the
discussion over to a ticket.
The majority of the community is on the dev@ list. By placing this
question into a ticket, you're dividing the set of people who may want
to discuss this item. You're also attempting to flow the discussion
into the ticket, rather than here on the dev@ list, where the larger
community resides.
We are building an issue tracker and we'd like users to use that issue
tracker. Discussing issues may be the first interaction they have with
Bloodhound and it would be nice to expose them to our product.
I'm willing to change how we do things for Bloodhound if there is *a
consensus among the community* that things should be done differently. I'd
like to hear if others agree with the viewpoint of our mentor. I
respectfully disagree.
(1)
http://markmail.org/search/?q=bloodhound%20#query:bloodhound%20list%3Aorg.apache.incubator.bloodhound-dev%20order%3Adate-backward+page:2+mid:3uuwhkztmtipdchw+state:results
I have to agree with Ryan to a large extent. I don't see it as a
particular hardship to be using the issue tracker to track our work and
share it out. Using svn for this purpose seems like a poor substitute
and could certainly be considered as being more difficult to use when we
want note that a piece of work is to be done, see whether the work is in
progress or if the work can be done by someone else. The idea that
switching context is a particular hardship is a bit strange as there is
already a switch of context to commit work.
Where I agree with our mentors is that we are getting too much
commenting on issues in the issue tracker if we assume that the larger
developer audience is on the dev mailing list.
So, I suggest that we
* continue to raise tickets for all our work,
* redirect discussion and request for clarifications to the dev
mailing list as much as possible,
* continue to use ticket comments to record revision numbers for that
ticket - note that it can be appropriate to list multiple revisions
in a single comment depending on the period over which work is done
Cheers,
Gary
