On 03/26/2014 04:38 PM, Steven Walling wrote:
I'd also like to suggest a somewhat radical alternative, which is not
automatically importing any Bugzilla items in to Phabricator. Let me
explain the steps here and what I think the advantages would be:
1. We set up Phabricator. All new issues shou
On 03/28/2014 05:31 PM, Luis Villa wrote:
Or to try to put it another way: it is common that old bugs are actively
harmful to developers by making the BTS less useful, particularly in
large, old projects, where change in the code makes it hard to reproduce
old bugs, or likely that they are no lon
On 03/26/2014 09:46 PM, Quim Gil wrote:
4. Projects with history in Bugzilla are created, old bugs are dealt in
Bugzilla, new ones are dealt in the new tool. Ouch, it can get messy.
5. Other scenarios?
I'm not sure if this is what you mean, so to be explicit, 4 could also
be done at a global l
On 03/26/2014 09:58 PM, Steven Walling wrote:
As for history: I'm not sure there is value in migrating all resolved
bug history, since the task status of Phabricator does not exactly match
Bugzilla anyway, and contains a lot of irrelevant information to strip
like gerrit patch links, keywords, an
On Fri, Mar 28, 2014 at 7:05 PM, Luis Villa wrote:
> I think the most important principle for a BTS is "it must be useful for
> the developers". All other principles are subordinate.
I really deeply agree with this.
A bug tracker is really just a fancy to-do list for software development.
The
On Fri, Mar 28, 2014 at 3:42 PM, Quim Gil wrote:
>
>
> On Friday, March 28, 2014, Luis Villa wrote:
>
>>
>> Bugzilla/future bug tracking system, first and foremost, has to serve the
>> developers by helping them figure out what to work on next. Old bugs can
>> make the BTS less effective at that
On Fri, Mar 28, 2014 at 3:42 PM, Quim Gil wrote:
> Have you been in a free software community where old bugs were WONTFIXed
> en masse? Because Andre and me have, and at least for me it wasn't funny.
I'm pretty sure no one is suggesting we do that. At least, that's not what
I was proposing.
-
On Friday, March 28, 2014, Luis Villa wrote:
>
> Bugzilla/future bug tracking system, first and foremost, has to serve the
> developers by helping them figure out what to work on next. Old bugs can
> make the BTS less effective at that goal, by cluttering developer queries.
>
Have you been in a
On Wed, Mar 26, 2014 at 3:34 PM, Bryan Davis wrote:
>
> A giant bug triage and resolve party does sound generally useful
> however. It sounds exhausting as well. :)
Bugzilla/future bug tracking system, first and foremost, has to serve the
developers by helping them figure out what to work on ne
James Forrester, 27/03/2014 03:28:
I think the sanest options are B0 and A0; B1 and A0 could just about
work, but B2–B5 (and A!0) seem to be non-starters in terms of user
experience from my POV.
+1
Nemo
___
teampractices mailing list
teampractices
On 26 March 2014 18:46, Quim Gil wrote:
> About a manual migration out of Bugzilla...
>
> A first questions is whether we should only migrate open report, or also
> the resolved ones. Having all your project memory in the same place is
> probably a good idea. To find duplicates easier, to deal wi
On Wed, Mar 26, 2014 at 6:46 PM, Quim Gil wrote:
> With 4707 or 22842 reports, writing the magical script is probably the
> only way forward. Once we have a script capable of migrating thousands of
> reports, we can apply it to other products / components.
I'd agree with 22,842... but not with
About a manual migration out of Bugzilla...
A first questions is whether we should only migrate open report, or also
the resolved ones. Having all your project memory in the same place is
probably a good idea. To find duplicates easier, to deal with groups of
dependent / tracked bugs that combine
On Wed, Mar 26, 2014 at 3:34 PM, Bryan Davis wrote:
> Although I completely understand the desire to dust off the cobwebs by
> doing something like this, I think Nemo has probably summed up the
> reaction of most of the community pretty well. This would likely be
> seen as "The Foundation" trying
On Wed, Mar 26, 2014 at 3:44 PM, Steven Walling wrote:
>
> On Wed, Mar 26, 2014 at 2:36 PM, Federico Leva (Nemo)
> wrote:
>>
>> Steven Walling, 26/03/2014 21:38:
>>
>>> as a group we import tickets from Bugzilla they actually think are
>>> relevant.
>>
>>
>> No.
>
>
> Nemo, it is not particularly
On Wed, Mar 26, 2014 at 2:36 PM, Federico Leva (Nemo) wrote:
> Steven Walling, 26/03/2014 21:38:
>
> as a group we import tickets from Bugzilla they actually think are
>> relevant.
>>
>
> No.
>
Nemo, it is not particularly constructive to reply this way. Since we want
to work as a group on this
Steven Walling, 26/03/2014 21:38:
as a group we import tickets from Bugzilla they actually think are relevant.
No.
Nemo
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices
On Wed, Mar 26, 2014 at 1:18 PM, Rob Lanphier wrote:
> Chad points out that we can start a fresh instance of Phabricator with
> T10, which would give us plenty of headway to import Bugzilla tickets 1
> through 67000 or so at a later date. Given how complicated a
> Bugzilla->Phabrcator migrat
On Tue, Mar 25, 2014 at 4:50 PM, Quim Gil wrote:
> If we end up going for Phabricator... it looks like the main bottleneck is
> the migration from Bugzilla (based on casual conversations with Andre and
> Chad).
>
> Going for Phabricator while keeping Bugzilla would be a half-backed
> solution tha
If we end up going for Phabricator... it looks like the main bottleneck is
the migration from Bugzilla (based on casual conversations with Andre and
Chad).
Going for Phabricator while keeping Bugzilla would be a half-backed
solution that would perpetuate the divide/duplication that we are seeing
n
20 matches
Mail list logo
