Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ooo-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of dennis.hamilton@acm.org
 designates 75.98.160.130 as permitted sender)
Reply-To: <dennis.hamilton@acm.org>
From: "Dennis E. Hamilton" <dennis.hamilton@acm.org>
To: <ooo-dev@incubator.apache.org>
Subject: [Identifying Contributors][DISCUSS] (was RE: [Issues] [DISCUSS] Can
 we track Issues Somehow? ... )
Date: Mon, 15 Aug 2011 13:07:19 -0700
Organization: NuovoDoc
Message-ID: <00ef01cc5b86$f0cbb8d0$d2632a70$@acm.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: Acxbha2aTasqbvigTTqwS6rDDRXaGw==
Content-Language: en-us

With regard to the migration of issues, are we going to manage to =
preserve the identity of those who posted and commented on issues?

I know there is some connection among issue creators, patch creators, =
and the source-code histories that are somehow tied into particular =
identification schemes, along with those for previous wiki contributors, =
folks having @openoffice.org addresses, etc.

I've been wondering how we might crack that nut and have a way to =
preserve the identifications that exist while foreclosing their =
continuing usage as we move to ASF-hosted infrastructure and in-project =
sites.

 - Dennis

MUSINGS/THOUGHT-STARTERS, ETC.

I am an user on a system that did some merges and expansions.  They had =
to cope with conflicts among IDs.  They did it by adding suffixes to =
colliding IDs from all identifier domains but one.  If there was no =
collision, there was no modification necessary.

At Apache, one place where collision becomes tricky is when folks had =
short names that might now (or in future) collide with names in the =
Apache user name/ID domain.  That might not be so serious as it first =
appears if we think in terms of e-mail uniqueness (so name@apache.org =
and name@openoffice.org are distinct, for example), rather than simple =
user name/ID values.  But it is desirable to differentiate short names =
when they are the link to the distinguishing identity information, and =
to avoid issuance of duplicates in any place where colliding legacy use =
of short names occurs.

Also, with regard to name@oo.o, I think it would be good to preserve the =
forwarding service but not allow new sign-ups.  I don't know if we =
should allow folks to update the forwarded-to e-mail address =
indefinitely or even for a short time.  My inclination is to allow it, =
possibly with an option to declare that they are abandoning the address.


-----Original Message-----
From: Rob Weir [mailto:apache@robweir.com]=20
Sent: Monday, August 15, 2011 11:41
To: ooo-dev@incubator.apache.org
Subject: Re: [Issues] [DISCUSS] Can we track Issues Somehow? (was RE: =
Speaking of JIRA, Where's Ours?)

[ ... ]

Weird is fine.   You'll have company.  As I said before, 185 OOo
Bugzilla issues have been added or modified month-to-date.  Once we
migrate over, our goal would be to preserve the same issue ID's, at
the same URL's.  So to the average user (or even the average project
member) they will not notice the difference.

Or, if you have issues about the migration itself, then just report
them on the list.  It would be a refreshing break from reading 39
emails about fundraising, or 37 emails about whether email topic tags
are best stored on the wiki or on a web page.  We could start a trend,
put the "source" back in "open source".

-Rob

>  - Dennis
>
> -----Original Message-----
> From: Rob Weir [mailto:apache@robweir.com]
> Sent: Monday, August 15, 2011 06:10
> To: ooo-dev@incubator.apache.org
> Subject: Re: [Issues] [DISCUSS] Can we track Issues Somehow? (was RE: =
Speaking of JIRA, Where's Ours?)
>
> On Mon, Aug 15, 2011 at 12:52 AM, Dennis E. Hamilton
> <dennis.hamilton@acm.org> wrote:
>> My question is essentially whether there is a choice we could make =
for an issue tracker now that gives us an important tool for managing =
existing project issues without impairing our ability to migrate the =
OpenOffice.org bugzilla when we are ready to do that.
>>
>
> Why not use the existing OOo Bugzilla?    I see that others have
> opened or modifed 185 issues in OOo Bugzilla in just August 2011.
>
> http://openoffice.org/bugzilla/
>
> That is the general theme of the migration, right?  Use existing
> support forums until we cut over to their migrated versions.  We're
> not setting up temporary user forums.  Use existing doc wiki until we
> cut over to migrated doc wiki.  We're not setting up a temporary doc
> wiki.  Use the existing language projects until we migrate them to
> Apache.  We're not setting up temporary language projects.  Etc, Etc.,
> Etc.
>
> Why wouldn't the same be true of reporting defects?
>
>> I don't understand such systems well enough to make a recommendation. =
 I am asking if anyone else has knowledge of one or more approaches that =
would achieve that.
>>
>> If not, we get to wait until the OpenOffice.org bugzilla is migrated, =
however that is resolved.
>>
>
> Why wait?
>
>> I don't find wikis an easier alternative.  If I had, I would not have =
raised this question.  I think I was clear enough on what I consider the =
advantages of issue trackers.
>>
>>  - Dennis
>>
>> SIDE COMMENTARY
>>
>> Someone suggested posting patches to the list for various things, and =
I was relating to that with regard to posting patches to an issue =
tracker where they stay visible.  I don't have any patches in mind.
>>
>> I enter bugs in bugzilla reluctantly.  I do it when I have to.  =
Perhaps that has to do with how the bugzillas I've used are configured.  =
My attention on LibreOffice was an accidental choice because I wanted to =
follow the action there at a time when I became more interested in =
interoperability with existing implementations and OpenOffice.org was =
already in some sort of doldrums.  It is gratifying to get results on =
bugs I have reported to LibreOffice.  I am able to provide support in an =
immediate way there, and I will continue with that satisfying activity =
also.
>>
>> When there is an Apache code base and a way to make similar =
contributions here, I will do that here too.  I'm not waiting.
>>
>> -----Original Message-----
>> From: Rob Weir [mailto:apache@robweir.com]
>> Sent: Sunday, August 14, 2011 06:03
>> To: ooo-dev@incubator.apache.org
>> Subject: Re: [Issues] [DISCUSS] Can we track Issues Somehow? (was RE: =
Speaking of JIRA, Where's Ours?)
>>
>> On Sat, Aug 13, 2011 at 11:11 PM, Dennis E. Hamilton
>> <dennis.hamilton@acm.org> wrote:
>>> A tracked issue keeps things in one place, it provides a record of =
open work items and the actions on it are apparently posted to the list. =
 So it is much easier to follow the ones you care about, review them, =
and so on.  It is also a safer place to post patches, feature requests, =
and so on where they can sit until we are actually ready to do something =
with them.  The record of progressing action is simply different than =
tracking wiki pages.
>>>
>>
>> You were originally asking about issues related to migration.  I =
don't
>> expect that will include many patches, feature requests (at least not
>> outside of the list discussions).
>>
>> If you have other issues of a more general nature, why not just stick
>> them in the existing Bugzilla?  Nothing there will be lost.  It might
>> be locked to updates for a day or two during the actual migration.
>> But up to that point all issues entered there are slated to be
>> eventually migrated to an Apache host.
>>
>>> I miss having one.  We're going to need one, it would be good to =
figure out how to remove the roadblock involved in worrying how to =
preserve the OpenOffice.org bugzilla if possible.
>>>
>>
>> That part's easy, at least conceptually.  Someone steps up and =
volunteers.
>>
>>> I also have no idea how many issues we are missing from public =
contributors because there is no one to place them.
>>>
>>
>> Don't you think the public would be more familiar with the OOo
>> Bugzilla tracker that has been around for years than any new,
>> temporary issue tracker that we might set up?  If you want, we could
>> post a link to the OOo BZ from our home page, for the benefit of =
those
>> who are newly involved with the project.  Post-migration, the URL
>> should be the same.
>>
>>> What I do instead, for specifics to the implementations, is post =
bugs on LibreOffice and use their user list.
>>>
>>
>> So you can do the same for OpenOffice, right?  Or is there some
>> problem I'm not seeing with this?
>>
>>> But we have plenty of work items around the migration here, and if =
we had an issue tracker, I would hope that is more inviting for folks =
taking on something they see as immediately within their grasp.
>>>
>>
>> I still think for migration-related issues, the mailing list and the
>> wiki are the best places.  Adding a third place to store such
>> information will just scatter the information more than concentrate
>> it.  If we had used an issue tracker consistently from the start it
>> might have been different.  But we didn't.
>>
>>>  - Dennis
>>>
>>> -----Original Message-----
>>> From: Rob Weir [mailto:apache@robweir.com]
>>> Sent: Saturday, August 13, 2011 18:45
>>> To: ooo-dev@incubator.apache.org
>>> Subject: Re: [Issues] [DISCUSS] Can we track Issues Somehow? (was =
RE: Speaking of JIRA, Where's Ours?)
>>>
>>> On Sat, Aug 13, 2011 at 1:27 PM, Dennis E. Hamilton
>>> <dennis.hamilton@acm.org> wrote:
>>>> It's been two months since the podling started and we still don't =
have issue tracking.
>>>>
>>>> 1. We need something for recording and tracking issues now, =
including ones that are involved in the migrations we're struggling =
with.
>>>>
>>>
>>> Do we?  I mean, do we need something more than discussing them in
>>> clearly-labeled threads on the mailing list?  Or tracking plans on =
the
>>> wiki, as we are doing already?
>>>
>>>> 2. We don't want to foreclose how we end up finally migrating the =
OpenOffice.org bug tracker and all of the history that represents.
>>>>
>>>> I don't know enough to see how to have (1) and (2) both.  Can we =
choose one quickly for transitional use, and then merge the OO.o bugs =
with it or merge it with the OO.o bugs, whichever works?
>>>>
>>>> It looks like three choices have been proposed:
>>>>
>>>>  1. Apache JIRA
>>>>  2. Apache bug-tracker
>>>>  3. Google Code issue tracker (available on Apache Extras)
>>>>
>>>
>>> I started tracking some items on the wiki, as a short term approach.
>>> Since there appears to be a great deal of enthusiasm for using the
>>> wiki, how about start that way?  If we're dealing with a dozen or 2
>>> issues or fewer, then setting up a JIRA or BZ issue is overkill.
>>> Remember, we're already tracking planning activities related to the
>>> migration on the wiki.  It isn't clear that trying to tease action
>>> items out of the plans on the wiki and then placing them in JIRA =
does
>>> anything for us.
>>>
>>> Also, we should avoid the seductive illusion that activity is a
>>> substitute for progress.  Having volunteers move forward on the code
>>> check-ins and on the real Bugzilla migration would be progress.
>>> Churning on issue tracking would not.
>>>
>>>> I'm all for ease-of-use.  How can we have a working issue tracker =
off of the critical path around migrating the OpenOffice.org bug tracker =
without getting in the way of that more complex effort?  Do we have to =
choose one for the migrated bug tracking now or can we resolve that =
later?
>>>>
>>>
>>> Easiest way to avoid the more complex effort is to use the simplest
>>> tool that accomplishes the task.  The simplest tool right now is the
>>> mailing list.  Wiki is 2nd.
>>>
>>>>  - Dennis
>>>>
>>>> -----Original Message-----
>>>> From: Greg Stein [mailto:gstein@gmail.com]
>>>> Sent: Thursday, June 30, 2011 16:05
>>>> To: ooo-dev@incubator.apache.org
>>>> Subject: Re: Speaking of JIRA, Where's Ours?
>>>>
>>>> On Thu, Jun 30, 2011 at 12:54, Rob Weir <apache@robweir.com> wrote:
>>>>> On Thu, Jun 30, 2011 at 12:12 PM, Alexandro Colorado =
<jza@openoffice.org> wrote:
>>>> [ ... ]
>>>>>>
>>>>>> I can argually say that both suck, the issue tracker that I have =
seen
>>>>>> easiest is the one provided by google code.
>>>>>>
>>>>>> The problem with that tracker is that I am not sure is doable for =
larger
>>>>>> projects.
>>>>
>>>> The Chromium project uses Google Code's tracker[1]. They're over
>>>> 88,000 bugs now and going.
>>>>
>>>>>> The biggest hump of using an issue tracker is locating the right =
people
>>>>>> (subcomponent) to get the issue to, or asigning a developer to =
it. whcih
>>>>>> most times is not aparent. The previous OOo (Collabnet) supported =
templates
>>>>>> which fill out your issue tracker in order to submit the issues =
faster.
>>>>>> However I found not many people really used it.
>>>>>>
>>>>>
>>>>> There are two audiences (at least) for the tracker:
>>>>>
>>>>> 1) Project members, who know their way around, know the sub =
components, etc.
>>>>>
>>>>> 2) Users, or other who submit a defect report rarely. They need an
>>>>> easy way to enter a bug report and check its status later.
>>>>
>>>> Totally agree. And that was the basis of my design for the Google =
Code
>>>> tracker. I wanted it real easy for the users to submit a bug, and
>>>> possibly attach stuff. They only need a short description, and then
>>>> details. Users know *nothing* about subcomponents, assignees,
>>>> milestones, whatever. The developers would then triage the new bugs
>>>> and apply the correct tags.
>>>>
>>>> Jason Robbins built the tracker using those key principles, and I
>>>> think it turned out very well. Of course, I'm biased. But still :-)
>>>>
>>>> If we wanted to use it, then we could fire up a project on
>>>> apache-extras.org and use it. We can use its API to import all the =
old
>>>> bugs.
>>>>
>>>>>...
>>>>> And what if we didn't assign developers at all?  What if instead =
we
>>>>> had project volunteers claim what issues they want to work on and
>>>>> self-assign them?
>>>>
>>>> I'd prefer this approach. It is generally best to view the bugs as
>>>> owned by the community. That you don't have "one developer" =
assigned
>>>> to a component. And that anybody can grab a bug and start working.
>>>>
>>>>>...
>>>>
>>>> Cheers,
>>>> -g
>>>>
>>>> [1] http://code.google.com/p/chromium/issues/list
>>>>
>>>>
>>>
>>>
>>
>>
>
>