← Back to team overview

ius-community team mailing list archive

Re: Possible change from LaunchPad bugs to GitHib issues

 

We have been giving this some additional thought. Do we need to create the LaunchPad bugs as is, or just recreate some of the functionality provided in those bugs. As I see it, these bugs do the following:

- announce when IUS is aware of a new version upstream
- announce when a given package is going be available in the testing repos
- announce when a given package is going be available in the stable repos
- provide a historic account when a given version went into testing and stable repos

We could continue just creating github issues like we do with LaunchPad bugs. We also got looking into using git/github releases. While github releases does not take into account our work flow (two weeks in testing), we might have figured out a decent work around.

We started doing some testing with python34u-pip[0]. Let say python34u-pip 7.0.4 got released. We would do the work within the spec file, tag the release as 7.0.4, mark it is a pre-release and add the date when it went into the testing repos. Once it comes time to push it to the stable repos, we would unmark it as a pre-release and add the date when it went into the stable repos. If you are watching the repo in question, you will get email notification when its ready for testing and when it goes into the stable repos. This work flow hits almost all of the functionality of the LaunchPad bugs. Also, we have Version Tracker[1] to note when IUS is aware of a new version.

Unless we hear feed back saying this process is broken and a terrible idea (or has a better idea), we will proceed with this practice. Let us know what you think.

-Ben and the rest of the IUS covedev team


[0] https://github.com/iuscommunity-pkg/python34u-pip/releases
[1] https://versiontracker.iuscommunity.org/packages/



On 06/04/2015 01:20 PM, Ben Harper wrote:
We have been giving Github issues a go for several months and so far
things are working out well.  We are looking to finally stop using
LaunchPad for bugs/issues/tickets, but we would like some feedback
regarding how we currently use LaunchPad bugs.

Currently, we have automation that create bugs for each new version of
our packages.  Then we will update those bugs when the packages will be
available for the testing and stable repos.  The following bug is an
example:

https://bugs.launchpad.net/ius/+bug/1357284

We are wonder if this practice needs to continue.  Do these types of
bugs/issues/tickets provide value?  Do you find them useful?


-Ben and the rest of the IUS covedev team



On 02/04/2015 02:21 PM, BJ Dierkes wrote:
Makes sense.  To that point… what ever the end-result is… getting off
of LaunchPad completely and onto GitHub is a +10000 no doubt.

---
BJ Dierkes
Data Folk Labs, LLC

[w] http://datafolklabs.com
[e] team@xxxxxxxxxxxxxxxx

On February 4, 2015 at 2:08:39 PM, Carl George
(carl.george@xxxxxxxxxxxxx) wrote:

One of the reasons we are considering this change is because users
were already opening Github issues under the relevant repos.  This
isn't a case of us changing just to change, rather we are adapting to
what our users have naturally started doing.  It is feasible because
it is already happening.

In addition, I know many users don't have Launchpad accounts, and
don't desire to create one.  The point we are discussing is whether we
should actively encourage users to use Github issues over Launchpad bugs.

I think a general "support" repo to open issues against is fine, for
unique situations where an issue/request doesn't apply to just one (or
any) packages.  But I it makes perfect sense to me that a bug with
php56u should be opened under the php56u repo.

Of course, we would put explicit instructions (including a link to the
issue dashboard) on iuscommunity.org, as well as the readme of the
"support" repo.

Carl George
Rackspace GNU/Linux Engineer
From: BJ Dierkes [derks@xxxxxxxxxxxxxxxx]
Sent: Wednesday, February 04, 2015 11:55 AM
To: Carl George; Ben Harper; ius-community@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Ius-community] Possible change from LaunchPad bugs to
GitHib issues

Ideally, I think the best solution would be:

  * Turn *off* issues/wiki/etc on all of the iuscommunity-pkg/XXX repos.
  * Every repo would have a README.md that would include a link to
"iuscommunity/support” (or whatever its called)
  * All issues, package related or otherwise, would go through
“iuscommunity/support”


I just think that having issues spread out across dozens/hundreds of
repos will make things more complicated.  It’s easier to manage to
have a singular link.  “To report issues go HERE” rather than “to
reports issues for pkg-XXX go HERE-XXX but to report issues for
pkg-YYY go HERE-YYY"… Really, all the repos under iuscommunity-pkg are
internal use.  End-user’s don’t need to care where the data lives for
‘php54u’ … the easier it is to engage people, the more likely it is
they will engage.

Again, its a design issue with this use-case of GitHub so kinda just
duct-taping it up to work for us.  All that said, I’m not involved
with the day-to-day anymore so it might make more sense to manage
issues individually across all the repos.

But that just like, my opinion man. ;)

---
BJ Dierkes
Data Folk Labs, LLC

[w] http://datafolklabs.com
[e] team@xxxxxxxxxxxxxxxx


On February 4, 2015 at 11:44:10 AM, Ben Harper
(ben.harper@xxxxxxxxxxxxx) wrote:

BJ, that is a good point. Having a straight forward way for community
members to submit issues is important. I think there might be a few
creative solutions that might make it workable.

The initial iuscommunity/wishlist was created as a starting point for
testing. The README.md needs updating and would need detailed
information about the preferred location to submit an issue. If you
have a bug for php54 then submit it to the php54 repo. If you have a
package request, general question or not sure where to file an issue,
the iuscommunity/wishlist repo (or other name) can be used. The down
side to for using that repo for catch all is GitHub does have a way to
move an issue to a different repo. Looks like github-issues-import[0]
could be a work around for this problem, although not the most elegant
approach.

-Ben



[0] https://github.com/IQAndreas/github-issues-import


On 02/03/2015 04:01 PM, BJ Dierkes wrote:
Yep… you can view them… but there are no end-user controls to say…
create an issue, etc. It’s just a high level overview that links you
to the individual project/repo. Not really a feasible option
unfortunately.

---
BJ Dierkes
Data Folk Labs, LLC

[w] http://datafolklabs.com
[e] team@xxxxxxxxxxxxxxxx
[m] 210.367.2599

On February 3, 2015 at 3:51:32 PM, Carl George
(carl.george@xxxxxxxxxxxxx) wrote:

The Github issue dashboard does allow you to view issues at the
organization level, or even multiple organzations.

https://github.com/issues?q=is%3Aopen+user%3Aiuscommunity+user%3Aiuscommunity-pkg


The search syntax is documented here.

https://help.github.com/articles/searching-issues/

Carl George
Rackspace GNU/Linux Engineer
From: Ius-community
[ius-community-bounces+carl.george=rackspace.com@xxxxxxxxxxxxxxxxxxx]
on behalf of BJ Dierkes [derks@xxxxxxxxxxxxxxxx]
Sent: Tuesday, February 03, 2015 03:30 PM
To: Ben Harper; ius-community@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Ius-community] Possible change from LaunchPad bugs to
GitHib issues

Ness and I had this same dilemma back in the day. Super annoying in
this use case that GitHub doesn’t have issue tracking at the
organization level. What we don’t want is managing bugs/feature
requests across 300 repos for every package. Need everything in one
place, however I don’t think that “wishlist” is the best terminology.
I think we should have a single project for managing all interaction
with community including bugs, feature requests, wishlist items, etc.
Those should all be tags/labels under the same project.

I would suggest “iuscommunity/support” which covers all that pretty
generically…. or something similar.

---
BJ Dierkes
Data Folk Labs, LLC

[w] http://datafolklabs.com
[e] team@xxxxxxxxxxxxxxxx


On February 3, 2015 at 10:29:57 AM, Ben Harper
(ben.harper@xxxxxxxxxxxxx) wrote:

Greetings,

The ius-coredevs have been debating if IUS should switch from using
LaunchPad bugs to GitHib issues. We have really been enjoying GitHib
for source control and GitHib does a good job integrating issues with
source control and pull requests. Unfortunately, Github does not have a
native way to submit an issue for an entire organization for things like
new package requests. We are currently testing a dedicated repo for new
package requests[0] and are looking for feedback. Please let us know if
you have any thoughts about moving away from LaunchPad bugs and to
GitHib issues.

-Ben and the rest of the IUS covedev team


[0] https://github.com/iuscommunity/wishlist

_______________________________________________
Mailing list: https://launchpad.net/~ius-community
Post to : ius-community@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~ius-community
More help : https://help.launchpad.net/ListHelp





_______________________________________________
Mailing list: https://launchpad.net/~ius-community
Post to     : ius-community@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~ius-community
More help   : https://help.launchpad.net/ListHelp



Follow ups

References