New issue tracker
H Xu
core, plugins) are more and more, I think it's time to move our issue
tracker(e.g. a bugzilla based one).
What do you think?
Hong
--
Sent from my mobile device
Trey Hunner
> github's issue tracker is good. however, our components(website, doc,
> core, plugins) are more and more, I think it's time to move our issue
> tracker(e.g. a bugzilla based one).
>
> What do you think?
Before we consider switching issue trackers we should try to agree how
we should use issue trackers in general. It sounds like you'd like to
integrate our multiple issue trackers into a single one. If that's
the case, we could use the current EditorConfig core issue tracker as
our tracker with tags for our different components.
I haven't yet had a problem with our separate issue trackers. I think
the main problem we've had so far was due to splitting up our code
bases.
I've researched issue trackers for a few other projects over the last
year and my most recent conclusion was that the most commonly used
issue trackers provide the nearly the same functionality and all can
be effective tools when used properly. I'm not strictly opposed to
switching issue trackers, but I do like the integration with our
repository and the similar interface between the issue tracker and the
rest of our project pages.
--
Trey Hunner
H Xu
> On Sun, Nov 20, 2011 at 02:53, H Xu <xuh...@gmail.com> wrote:
>> github's issue tracker is good. however, our components(website, doc,
>> core, plugins) are more and more, I think it's time to move our issue
>> tracker(e.g. a bugzilla based one).
>>
>> What do you think?
>
> Before we consider switching issue trackers we should try to agree how
> we should use issue trackers in general. It sounds like you'd like to
> integrate our multiple issue trackers into a single one. If that's
> the case, we could use the current EditorConfig core issue tracker as
> our tracker with tags for our different components.
So let's use tags.
>
> I haven't yet had a problem with our separate issue trackers. I think
> the main problem we've had so far was due to splitting up our code
> bases.
Thus could we merge them?
>
> I've researched issue trackers for a few other projects over the last
> year and my most recent conclusion was that the most commonly used
> issue trackers provide the nearly the same functionality and all can
> be effective tools when used properly. I'm not strictly opposed to
> switching issue trackers, but I do like the integration with our
> repository and the similar interface between the issue tracker and the
> rest of our project pages.
So let's do not switch now.
Hong
Trey Hunner
> On 11/21/11, Trey Hunner <treyh...@gmail.com> wrote:
>> On Sun, Nov 20, 2011 at 02:53, H Xu <xuh...@gmail.com> wrote:
>>> github's issue tracker is good. however, our components(website, doc,
>>> core, plugins) are more and more, I think it's time to move our issue
>>> tracker(e.g. a bugzilla based one).
>>>
>>> What do you think?
>>
>> Before we consider switching issue trackers we should try to agree how
>> we should use issue trackers in general. It sounds like you'd like to
>> integrate our multiple issue trackers into a single one. If that's
>> the case, we could use the current EditorConfig core issue tracker as
>> our tracker with tags for our different components.
>
> So let's use tags.
>>
>> I haven't yet had a problem with our separate issue trackers. I think
>> the main problem we've had so far was due to splitting up our code
>> bases.
>
> Thus could we merge them?
I think we should merge the EditorConfig core and EditorConfig website
trackers and use the "website" tag. The file format, the core code,
and the website are all tightly linked. I will work on merging this
now.
I'm not sure if we should merge the EditorConfig Vim, Emacs, and Gedit
plugin issue trackers into this main issue tracker though. Do you
think we should merge all of these or keep these separate from the
main EditorConfig issue tracker?
--
Trey Hunner
H Xu
I agree to merge plugin issue trackers into the main issue tracker. Thus
things could be simpler.
Hong
Trey Hunner
Okay. My only concern currently with doing this is that it sets a
precedent for users and developers that issue tracking for all
editor-specific EditorConfig code is handled in the main repository.
I fear that this may cause confusion of other independent developers
maintain their own EditorConfig plugins with their own issue tracker.
Do you think we should encourage plugin developers to use the main
issue tracker for plugin-specific issues?
--
Trey Hunner
H Xu
maybe we could do something like pidgin: plugins maintained by pidgin
team are put into one, while third parties are separated. Besides, our
label should be something like "plugin-vim", so reporters won't find
the editors that are not maintained by us. We could also encourage
plugin developers to use the main issue tracker, so reporters that
report many bugs would feel convenient, and we could find some
problems early.
Hong
Hong
Trey Hunner
The issue trackers are now merged into one:
https://github.com/editorconfig/editorconfig/issues
--
Trey Hunner