Looking for something to hack on?
Jonathan "Duke" Leto
There is a new dashboard for organizations that shows all of their issues:
https://github.com/organizations/parrot/dashboard/issues
This is a great view into the Parrot organization and makes it easy to find
stuff to hack on across all of our repos.
I dislike Trac, so I will be using Github issues for new bugs+patches going
forward. I hope others join in, but this isn't an "official" policy (whatever
that is supposed to mean in the Parrot community).
I am of the opinion that there is more noise than signal in our Trac TT's
currently. We could programmatically convert our TT's to Github issues, but
that is not a good solution either. We need to remove a lot of old and
irrelevant tickets first.
This is not a task for a new-comer, and everybody that is qualified to kill old
tickets doesn't really seem to want to do it. Why not?
Duke
--
Jonathan "Duke" Leto <jona...@leto.net>
Leto Labs LLC
209.691.DUKE // http://labs.leto.net
NOTE: Personal email is only checked twice a day at 10am/2pm PST,
please call/text for time-sensitive matters.
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
Will Coleda
Speaking for myself, burnout. I've done the task too many times for
parrot so far.
In the last day or so, I provided some advice in IRC on how to triage
these old tickets and start closing some again. Hope that helps.
My recommendation on migrating tickets is to have a way to transfer
tickets over programmatically; even if you only use it on one triaged
ticket at a time, you will save yourself much madness.
(Recommendation: mention the URL for the ticket in each system in the
other system. Create a new status for "migrated" tickets, or add an
explicit comment to the closed trac ticket along with the URL "marking
resolved just to close the ticket, for update see...")
Regards.
--
Will "Coke" Coleda
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
Peter Lobsinger
When I moved the pirc bugs out of trac and into parrot/pirc's github
issues, I looked at App::SD, which in turn uses Net::Trac, and
Net::Github. I found these two to be quite effective at migrating
simple tickets. If we do implement some ticket auto-transfer tool, I'd
recommend starting there.
I have attached the script I used to do the transfer the pirc as an
example for anyone eager to get started on this.
Andy Dougherty
> I am of the opinion that there is more noise than signal in our Trac TT's
> currently. We could programmatically convert our TT's to Github issues, but
> that is not a good solution either. We need to remove a lot of old and
> irrelevant tickets first.
>
> This is not a task for a new-comer, and everybody that is qualified to kill old
> tickets doesn't really seem to want to do it. Why not?
Speaking only for myself, I have periodically gone through first RT and
then Trac looking for open tickets that I reported, or for which I think I
have relevant expertise. What I usually find is that the issues are still
present, and there's still nothing further I can do about them. (There
are also many closed tickets, for which patches have been successfully
applied, or for which other appropriate resolutions have been found.
That's great, but since they are closed, they are not relevant to your
question.)
Again, speaking only for myself, I can't imagine that yet another ticket
migration would really make any significant difference. It's the content
of the tickets that matters most. Still, it's a volunteer project, and if
that's how someone wants to spend his or her time, I certainly don't
object.
--
Andy Dougherty doug...@lafayette.edu
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
James E Keenan
>
> Again, speaking only for myself, I can't imagine that yet another ticket
> migration would really make any significant difference. It's the content
> of the tickets that matters most. Still, it's a volunteer project, and if
> that's how someone wants to spend his or her time, I certainly don't
> object.
>
I agree almost completely with Andy Dougherty here. Suppose we were to
migrate to a Shiny New Bug Tracker (SNBT) or, better yet, a Shiny New
Bug Tracker with 'Git' Somewhere in It's Name (SNBTWGSIIN). Is there
any reason to think that the attitude of our contributors to working on
old tickets would change? Will the people who dislike being reminded of
their old tickets cease disliking that once we're using SNBTWGSIIN?
Based on my experience as a cage-cleaner in both RT and Trac, I doubt it.
Where I disagree with Andy is this: Granted we're a volunteer project,
but I would hate to see our *core* developers working on a bug tracker
migration when they could be working on ... core!
Thank you very much.
Jim Keenan
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
Jonathan "Duke" Leto
> I agree almost completely with Andy Dougherty here. Suppose we were to
> migrate to a Shiny New Bug Tracker (SNBT) or, better yet, a Shiny New Bug
Just to be clear, I am not talking about a wholesale migration. I will just
simply not use Trac for new tickets and will suggest that others do the same.
Instead, issues in the appropriate repo on Github will be created. If somebody
cares enough about a TT, it will get migrated to a Github issue.
I don't want to hear strawman arguments about how I don't care about all the
hardwork that people have put into our TTs. I have created and cagecleaned many
TT's. But the simple fact is that we, Parrot hackers, need to refactor our
community infrastructure if we hope to continue.
"Do what you have always done, get what you have always gotten".
Parrot is losing developers and quickly becoming even more irrelevant, and I
refuse to just rearrange furniture on the deck of a sinking ship.
Trac actively discourages new developers, since we have to lock it down from
Trac spam. Github actively encourages new developers via all the social
features. If we want to continue, we need to fully embrace Github.
Moritz Lenz
On 10/17/2011 06:42 PM, Jonathan "Duke" Leto wrote:
> Just to be clear, I am not talking about a wholesale migration. I will just
> simply not use Trac for new tickets and will suggest that others do the same.
So we have two bug trackers to ignor^Wtend.
> Instead, issues in the appropriate repo on Github will be created. If somebody
> cares enough about a TT, it will get migrated to a Github issue.
So we ignore the effort that people put into reporting bugs, and tell
them "if you care, do more work for us". If you ever asked yourself why
parrot doesn't have many users, think again.
That way you only encourage potential users to write hateful blog posts
about parrot, you don't encourage them to tell the developers what goes
wrong.
> I don't want to hear strawman arguments about how I don't care about all the
> hardwork that people have put into our TTs. I have created and cagecleaned many
> TT's.
How about non-strawman arguments? What do you say to users who put a lot
of effort into submitting good bug reports, and which will got lost by
the non-migration?
> But the simple fact is that we, Parrot hackers, need to refactor our
> community infrastructure if we hope to continue.
Yes, parrot needs to do things better, but it needs a plan and a
direction. A single developer dashing off and calling it a "community
refactor" isn't a plan.
> "Do what you have always done, get what you have always gotten".
>
> Parrot is losing developers and quickly becoming even more irrelevant, and I
> refuse to just rearrange furniture on the deck of a sinking ship.
Sorry, but it sounds like exactly what you are doing. You're not fixing
the deep issues with parrot (slow calling conventions, no JIT compiler,
very limited NCI, ...), you're rearranging furniture.
> Trac actively discourages new developers, since we have to lock it down from
> Trac spam. Github actively encourages new developers via all the social
> features. If we want to continue, we need to fully embrace Github.
How about fixing trac? Maybe by using github for authentication as an
option?
Jonathan, I can't tell you what to do, but so far I got the impression
that you are running towards a shiny new feature without consulting the
rest of the community, and a weak rationalization after the fact.
The reason I have a problem this time is that you place a burden on
others, either by forcing them to consider two bug trackers, or by
forcing them to migrate tickets, or by condemning the non-migrated
tickets to go unnoticed eventually.
Please think again if that's what you want, and if really considered the
costs and possible alternatives.
Cheers,
Moritz
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
Andy Lester
How about non-strawman arguments? What do you say to users who put a lot
of effort into submitting good bug reports, and which will got lost by
the non-migration?
Andrew Whitworth
>> Instead, issues in the appropriate repo on Github will be created. If somebody
>> cares enough about a TT, it will get migrated to a Github issue.
>
> So we ignore the effort that people put into reporting bugs, and tell
> them "if you care, do more work for us". If you ever asked yourself why
> parrot doesn't have many users, think again.
>
> That way you only encourage potential users to write hateful blog posts
> about parrot, you don't encourage them to tell the developers what goes
> wrong.
Exactly the opposite. I think moving to use the github bug tracker
will have a positive effect on usability. This is especially true when
you consider that our trac installation is currently closed to ticket
creation from new users because of spam problems. A big portion of
this problem is that we have so far been unable to find and install a
suitable anti-spam solution for trac.
Github is a relatively popular platform, so it's likely that many
hackers already have an account there and will be able to submit
issues to Parrot seamlessly.
This is all not to mention that the maintenance burden of keeping the
trac server running is much higher than it would be on github. trac
isn't nearly as maintenance-intensive as smolder, but it's still not
perfect. OSL does a great job, all things considered, but we are
relying on their good will a lot to keep our rag-tag assortment of
software running. For a variety of reasons which I won't list here,we
shouldn't blindly think we can rely on OSL forever to host our stuff
for free.
> How about non-strawman arguments? What do you say to users who put a lot
> of effort into submitting good bug reports, and which will got lost by
> the non-migration?
I don't think there will be a non-migration, even if dukeleto is not
motivated to mass-move tickets by himself. He wants to start using the
new issue tracker. Other people have already indicated a willingness
to help with a migration, and some people have suggested automation
tools to help. If dukeleto is using the new tracker for his own todo
list and he uses it to great effect, I think that's the kind of
experiment that would be very compelling.
I personally would like to put a little bit of effort into basic
filtering so we aren't moving over a bunch of old, obsolete, junk
tickets. I also recognize that having to put human eyes on every
single one is a burden we can hardly afford.
As something of a compromise, all tickets assigned to me will be
personally inspected before any migration, whether to github. Feel
free to send any tickets my way that you think needs a human opinion
before the bots get rolling.
> How about fixing trac? Maybe by using github for authentication as an
> option?
I wasn't aware that was an option. Is that an extension which exists
already, or something that we are going to have to put developer
effort into?
Parrot does have a lot of things to do, but we can't ignore a
particular sore point (our issue tracker and server infrastructure)
just because we need to focus attention on other things (JIT, PCC,
etc). Improvements to issue tracking may actually help improve our
long-term productivity. Again, it's an experiment that I would like to
see conducted.
--Andrew Whitworth
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
Will Coleda
> http://lists.parrot.org/mailman/listinfo/parrot-dev
>
>
If the general consensus is to switch, that's fine, but my
recommendation would be to convert /everything/, and tag any tickets
that came over from trac with a label of some kind like "needs-triage"
or "from-trac" then we have a builtin list of tickets that we know
needs to be reviewed from the old system. Once a human has laid eyes
on the ticket and decided if it's worth keeping (some may be old
roadmap requests, some may be obsolete build reports from long ago,
patches that don't apply), remove the label.
Any new tickets should be triaged rather sooner than that, so we can
use the ticket status (new/open) to indicate if something needs triage
instead of the label.
If we can get more eyeballs on tickets in github, that's fine. I don't
think it matters if we close them before or after the migration, as
long as it's done.
Andy Dougherty
> Exactly the opposite. I think moving to use the github bug tracker will
> have a positive effect on usability. This is especially true when you
> consider that our trac installation is currently closed to ticket
> creation from new users because of spam problems.
Actually, that's not true. You don't need a Trac account to create or
respond to tickets. In the very first section of docs/submissions.pod,
under "How to Submit a Bug Report", it describes how to use email to
create a bug report. No Trac account is required.
(Of course, whether or not that feature makes a makes enough of a
difference to matter is a rather different question.)