Git code hosting beta (launchpadblog) [LWN.net]

Git code hosting beta (launchpadblog)

Posted May 6, 2015 17:26 UTC (Wed) by jspaleta (subscriber, #50639)
In reply to: Git code hosting beta (launchpadblog) by josh
Parent article: Git code hosting beta (launchpadblog)

What would be really great is if this feature gives Debian a reason to take a hard look at possibly spinning up a Debian launchpad instance using the launchpad code source. Not just the CodeHosting component, but for the Soyuk build component and other things. I think there is a lot of value in Launchpad code that Debian could benefit from, but they'd need to be able to run their own instance.

to post comments

Git code hosting beta (launchpadblog)

Posted May 6, 2015 21:12 UTC (Wed) by ballombe (subscriber, #9523) [Link] (19 responses)

FWIW, alioth.debian.org has hosted git repositories for years.

Git code hosting beta (launchpadblog)

Posted May 6, 2015 21:32 UTC (Wed) by jspaleta (subscriber, #50639) [Link] (18 responses)

I know that.
I'm saying that git support might be a big enough new feature for Debian to another look at hosting their own instance of launchpad..kick the tires a bit. As a set of modules collectively, launchpad with git support, might marginally useful enough to host an instance of. The ppa concept, the integrated code review stuff, the blueprints, all of that stuff together could be useful to Debian beyond what they have now.

Or not. I'm saying, its a big enough feature enhancement to take a look and assess and maybe even bring up a toy instance and poke it with a stick.

Git code hosting beta (launchpadblog)

Posted May 7, 2015 4:40 UTC (Thu) by raof (subscriber, #57409) [Link] (17 responses)

Few things could make me happier as the maintainer of a couple of Debian packages than Debian spinning up a Launchpad instance (one of them, ddebs, seems to be imminent. YAY!).

Solely because I curse the Debian BTS everytime I need to interact with it.

Git code hosting beta (launchpadblog)

Posted May 7, 2015 7:55 UTC (Thu) by pabs (subscriber, #43278) [Link] (16 responses)

What about the Debian BTS causes you to curse?

Personally I find it better that any other centralised BTS. Launchpad is almost as good but you still have to register an account to use it.

Git code hosting beta (launchpadblog)

Posted May 7, 2015 11:22 UTC (Thu) by mbunkus (subscriber, #87248) [Link] (6 responses)

Yestday a Debian developer forwarded a bug to me (a non-Debian developer). I simply replied to that email with some information regarding the issue at hand.

Then I received… three? emails from the Debian Bug Tracking System: a rather verbose help message how to use the email interface, a kind of welcome message and the »results of your commands« mail listing all of my reply lines and stating each time that the command wasn't understood.

No big surprise there, I didn't use commands, I just wrote a paragraph of text. I didn't _want_ to interact with a bug tracking system, just to give the sender some more information.

Now you might say »well then you shouldn't have CCed control@bugs.debian.org«. You may have a point there. But am I, as a non-DD, supposed to know such things? Anyway, no harm done; I just thought it fitting the »curse at the Debian BTS every time I use it« theme :)

Git code hosting beta (launchpadblog)

Posted May 7, 2015 20:07 UTC (Thu) by epa (subscriber, #39769) [Link] (4 responses)

Sane bug tracking systems will process your reply and make it a comment on the bug. This works well enough in small groups, though out on the Internet it needs careful implementation to avoid autoreply loops and spam. Github seem to have managed it.

Certainly the idea of sending 'commands' over an email interface is absurdly retro these days. Surely anyone with the technical chops to be doing automated bug tracker work is able to send authenticated POST requests over https instead.

Git code hosting beta (launchpadblog)

Posted May 7, 2015 22:50 UTC (Thu) by andresfreund (subscriber, #69562) [Link]

The debian BTS does that. In fact, it's pretty much the only write access.

Git code hosting beta (launchpadblog)

Posted May 8, 2015 5:03 UTC (Fri) by mathstuf (subscriber, #69389) [Link] (2 responses)

Github really needs an option to send my own comments as email. Issues end up having holes poked in them in mutt and there is no easy way to get a list of all issues I've opened but are neglected (other than the web interface; the only API endpoint for it is by searching or scraping).

Git code hosting beta (launchpadblog)

Posted May 8, 2015 20:33 UTC (Fri) by peter-b (guest, #66996) [Link] (1 responses)

You could use the GitHub web service API to pull out a list of all your issues as JSON...

Git code hosting beta (launchpadblog)

Posted May 8, 2015 21:10 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

The only explicit endpoint that was available was equivalent to the "issues that are assigned to me". To get the github.com/issues list, you need to use the search API (which does not support disjunctions). I contacted them about it and they said it'd be nice, but for now, you're stuck with searching.

Git code hosting beta (launchpadblog)

Posted May 9, 2015 20:08 UTC (Sat) by robbe (guest, #16131) [Link]

It seems CC-ing (instead of BCC-ing) control@bugs.debian.org was an error of the Debian developer, not something that you should have know.

Git code hosting beta (launchpadblog)

Posted May 7, 2015 23:28 UTC (Thu) by raof (subscriber, #57409) [Link] (8 responses)

What I dislike about the BTS is its entirely arcane mechanism for making changes. Each and every time I need to change the status of a bug in some way I need to refer to the online doc, and I don't think I've *ever* got it completely correct, even rigourously consulting the documentation.

On the other hand, the Launchpad email interface offers pretty much the same features, but doesn't have the control@, bug-nnn@, bug-whatever-the-other-addresses-are@ split and usually ends up doing what I wanted. And for complex tasks there's a nice web UI.

I happen to think that requiring an account is a positive - if you're not invested enough in reporting the bug to make an account, it's probably better that you don't report the bug. We have no shortage of bug reports.

We should *additionally* have an entirely hands-off crash reporting mechanism - errors.ubuntu.com is pretty close to this, and I'm pretty sure Fedora has similar infrastructure now.

Git code hosting beta (launchpadblog)

Posted May 8, 2015 0:40 UTC (Fri) by josh (subscriber, #17465) [Link]

Personally, I use the "bts" command-line tool, which knows all the syntax.

Git code hosting beta (launchpadblog)

Posted May 8, 2015 16:30 UTC (Fri) by Wol (subscriber, #4433) [Link] (3 responses)

> I happen to think that requiring an account is a positive - if you're not invested enough in reporting the bug to make an account, it's probably better that you don't report the bug. We have no shortage of bug reports.

Which then annoys the people who actually make heavy use of a lot of systems. I have, what, eight e-mail folders for software I am seriously enough interested in to want to track the dev list. That's a LOT of reading. Do I then need another 20, 30 logins to bug-tracking systems for software that I may use extensively but am not seriously interested in?

Yes I know there's a spam problem etc etc, but it would be nice to be able to send an anonymous bug report, and know that there's a decent chance some developer will at least triage it and maybe promote it to "real bug", or point you at the relevant help or somesuch.

I don't expect much response from a drive-by bug report, but I really don't like software that puts hoop after hoop in front of you when you are trying to report a problem ...

Cheers,
Wol

Git code hosting beta (launchpadblog)

Posted May 8, 2015 18:53 UTC (Fri) by cesarb (subscriber, #6266) [Link]

> Do I then need another 20, 30 logins to bug-tracking systems for software that I may use extensively but am not seriously interested in?

We need to develop one universal login that can be used to access everyone's bug trackers. (See: https://xkcd.com/927/)

Git code hosting beta (launchpadblog)

Posted May 9, 2015 16:50 UTC (Sat) by flussence (guest, #85566) [Link]

> Do I then need another 20, 30 logins to bug-tracking systems for software that I may use extensively but am not seriously interested in?

For better or worse, sites like GitHub have alleviated that problem. I'm about 99% more likely to go report a found bug if the project it's in is on a site I don't have to do a register-email-login dance on.

(Honourable mention goes to the dnssec-validator project, which tried to allow anonymous bug reporting on their trac site. They had a captcha which didn't actually work. I couldn't be bothered reporting *that* bug.)

Git code hosting beta (launchpadblog)

Posted May 29, 2015 7:32 UTC (Fri) by pabs (subscriber, #43278) [Link]

New bug reports are never spam in the Debian bug tracker, spammers never figured out how to put "Package: foo" at the top of the mail.

Git code hosting beta (launchpadblog)

Posted May 8, 2015 19:35 UTC (Fri) by bfields (subscriber, #19510) [Link]

I happen to think that requiring an account is a positive - if you're not invested enough in reporting the bug to make an account, it's probably better that you don't report the bug. We have no shortage of bug reports.

I'd rather get the reports. I can use filtering and such to keep my initial time investment low if necessary. Lots of problems are very difficult to reproduce so will only be spotted and fixed if we can get reports from the widest possible population.

Git code hosting beta (launchpadblog)

Posted May 29, 2015 7:28 UTC (Fri) by pabs (subscriber, #43278) [Link]

I need to look up how to change bugs whenever I modify bugs on Launchpad, that is just because I don't use it very often though.

Git code hosting beta (launchpadblog)

Posted May 29, 2015 7:31 UTC (Fri) by pabs (subscriber, #43278) [Link]

Hands-off crash reporting is the wrong way to do it as automatic crash reports automatically have private data in them that shouldn't be uploaded anywhere.