[Sugar-devel] About comments in pull requests and tickets

[Walter Bender]

If we do stick with Trac, maybe we can make a GCI task to clean up the
spam users in Trac? I had a miserable experience trying to add a new
user last night to Trac waiting for the server to send the entire user
list several times in the process. It took > 10 minutes for each step
in the process.

-walter

On Fri, Jan 9, 2015 at 9:42 AM, Gonzalo Odiard <godiard at sugarlabs.org> wrote:
> In the process to review a patch, recently Quozl added this comment:
>
> "Really a pity all this discussion gets lost in each pull request when it
> should really go on the ticket. ;-)" [1]
>
> Sam replied:
> "Re: we should use tickets more... I don't get enough emails to remember
> that we have a bug tracker (hint: why dosn't tarc email?). I also feel that
> tarc is not as sleek and usable as GitHub. Maybe you should lead by example,
> email the mailing list or create a ticket. Hopefully your bug ticket won't
> be forgotten in the static-feeling, talking-to-a-brick-wall site that
> bugs.sl.o is (hint: I always feels like your talking to yourself on tarc,
> there is no real form of conversation)." [2]
>
> I want bring this conversation here, to try to involve more players in the
> community,
> and find a good strategy.
>
> Personally, I recognize our trac implementation have problems (more below)
> but I can't count how many times the comments in a old ticket have saved me
> hours of work or helped me avoid the same errors.
> The tickets have been a invaluable resource by example to run GCI,
> even when didn't have the resources to solve the for a long time,
> are a good resource to guide volunteers to collaborate.
> The bug database is permanent and searchable, the pull request are difficult
> to find, more when there are more than one for a single commit.
>
> Then, from my point of view, GitHub is ok to make comments about the code,
> but there are issues we need keep record. Why we do that?
> What is the best strategy to solve the problem? How can we reproduce the
> bug?
> At a time, we didn't merged code to solve errors if we didn't have a bug
> associated.
>
> About trac problems, would be good to solve:
> * We have hundred of spam users, we need clean them.
> * I don't know why, but I see a lot of ticket editions by logged users
> waiting for moderation. I suppose is a configuration to deal with spam, but
> I am not sure.
> * Trac and Git integration can be improved, right now, we use a GitHub
> service
> to add a comment and close a ticket when a "Fixes #NNNN" string is in the
> header.
> But the configuration page for that ticket say:
> "This service is deprecated. To integrate GitHub with Trac, follow the
> instructions at: http://github.com/aaugustin/trac-github
> If you're currently relying on this service, please consider upgrading to
> trac-github. It uses a standard webhook to provide the same features and
> it's
> more actively maintained."
> Maybe we can add another key to save a comment in trac from a GitHub
> comment,
> when is something we want keep record?
>
> Another alternative is configure github to send emails o sugar-devel
> with the pr updates. I don't know if will be too much spam.
> Or configure trac to send a email to sugar-devel when a bug is created,
> to avoid the sensation of talking with a wall, like Sam said.
>
> What you think? Other ideas? Anybody volunteer to improve trac
> configuration?
> I can help with admin permissions in github and trac.
>
> --
> Gonzalo Odiard
>
> SugarLabs - Software for children learning
>
> [1]
> https://github.com/sugarlabs/sugar-toolkit-gtk3/pull/188#issuecomment-69104257
> [2]
> https://github.com/sugarlabs/sugar-toolkit-gtk3/pull/190#issuecomment-69159430
>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>



-- 
Walter Bender
Sugar Labs
http://www.sugarlabs.org