The effort is appreciated, but where does it list that the Ubuntu developer submitted a patch to fix the problem? I thought the complaint wasn't that they weren't tracking bug reports, but more importantly, that they weren't submitting their changes, or any bug fixes upstream.
To me it's one thing to submit a bug report upstream, it's something entirely different to note the bug and submit a patch upstream.
Posted Oct 1, 2008 18:56 UTC (Wed) by dlang (✭ supporter ✭, #313)
[Link]
why do you expect ubunto to submit a patch for every bug they report?
RedHat doesn't supply a patch for every bug that they report to the kernel. sometimes they do, but I wouldn't even say that it's the majority of the time.
taking that attitude that you shouldn't submit bug reports unless you also submit patches is a great way to kill off bug reports, by driving your users away.
nothing in the GPL (or any other opensource license) requires you to create patches, let alone require you to create patches based on problems that people you provided the opensource software to ran into.
they require that you release changes that you do make, and it's strongly encouraged that you push those changes upstream, but if a distro is distributing software and there is a bug in the upstream code I don't see any reason why all the different distros should be expected to create a patch before submitting the bug. in fact I see the idea of them doing so as a massive duplication of effort. if the bug is in the upstream package the bug reports should go to the upstream package where the experts there can look at all the reports from all the different distros and fix the problem once instead of having programmers at the distros who are not familiar with the codebase all scrambling to produce a patch to submit upstream
the fact that launchpad is only a one-direction link is probably as much a limitation of the upstream bug managers as it is of launchpad. none of the upstream bug managers have hooks in them to feed data into launchpad, so they would be reduced to screen-scraping websites (and if they are lucky e-mails) to find changes to pull them back into launchpad.
I think the fact that they can do the one-direction links a big step forward from the common situation with other distros. hopefully the various bug management tools can start creating api's so that they can notify each other about updates. this is a good first step.
Ubuntu debuts its Upstream Report
Posted Oct 1, 2008 19:22 UTC (Wed) by gmb (guest, #54452)
[Link]
the fact that launchpad is only a one-direction link is probably as
much a limitation of the upstream bug managers as it is of launchpad.
none of the upstream bug managers have hooks in them to feed data into
launchpad, so they would be reduced to screen-scraping websites (and
if they are lucky e-mails) to find changes to pull them back into
launchpad.
We on the Launchpad Bugs Team have been aware of this problem for a while. One of the stated aims of Launchpad is to provide a means by which free software projects can intercommunicate, whether or not they use Launchpad for their hosting or bug tracking or translations, etc.
To help resolve this and make the communications between Launchpad and upstream bug trackers two-way, we've recently released plugins for two of the major OSS bug trackers, Bugzilla and Trac. The plugins, which work on Bugzilla 3.0 and above and Trac 0.10 and above, add an XML-RPC API to the upstream bug trackers that install them. Launchpad auto-detects the plugins and can then use that API to:
Synchronise comments both ways between LP and the upstream tracker
(so comments on the upstream tracker get imported into Launchpad and
replies to those comments in Launchpad get forwarded back upstream).
Tell the upstream tracker which Launchpad bug links to one of its
bugs (the upstream tracker will then display a link to the Launchpad
bug)
Push bugs up to the upstream tracker (this currently isn't enabled;
we want to be absolutely sure that the plugins work as they should
before we start pushing bugs upstream).
Automatically import bugs from the upstream tracker (again, this
isn't currently enabled for the same reason as the previous entry).
Also, the plugin API makes Launchpad <-> upstream communications a lot more efficient than they are at the moment.
Some upstreams (bugs.xine-project.org, twistedmatrix.com/trac to name two) have already installed the plugins, but we're eager to find more projects willing to help us test them (whilst at the same time hopefully benefiting themselves by making it easier for their users to inform them of bugs via Launchpad).
You can find information about the plugins on the Launchpad help wiki:
Posted Oct 1, 2008 20:50 UTC (Wed) by JoeBuck (subscriber, #2330)
[Link]
For FSF sites, including bugzilla.gcc.org, links to Launchpad aren't allowed as long as it is non-free software. So please delay implementing that feature until Launchpad is free. If you do it anyway, the GCC web team will have to take any links to Launchpad out again, since we agreed to implement the FSF's linking policy. That policy isn't my preference, and I can't speak for any other projects; Gnome tends to take a looser view, but you'd need to ask them if this is OK. Other projects are likely to object as well.
Alternatively, just make Launchpad free software and all these problems go away.
please don't violate rules of upstream sites
Posted Oct 1, 2008 20:57 UTC (Wed) by dlang (✭ supporter ✭, #313)
[Link]
as I read the message you would have to install the module in your bugtracker system.
but even if this wasn't the case, how do you justify telling another project not to develop or implement any feature?
Absurd rules of upstream sites
Posted Oct 1, 2008 21:39 UTC (Wed) by tseaver (subscriber, #1544)
[Link]
Such a policy is ridiculous and absurd on its face, because it is contrary to the the fundamental principle of free software, which is that users share information about, and fixes and improvements to the software they use. Must links to CVE entries, for instance, must be blocked as well? How would that help the users running the vulnerable-but-free software about which the CVE had been created?
What about bugs originating in systems where the bug tracker is free software, but which happen to be running on a non-free OS? (How would you know? Why would you care?) To take the point further: should GCC ignore bugs from Mac users, who happen not to run a free OS?
Talk about cutting off your nose to spite your face!
Absurd rules of upstream sites
Posted Oct 1, 2008 22:55 UTC (Wed) by JoeBuck (subscriber, #2330)
[Link]
GCC has, from the beginning, supported proprietary operating systems, and it's the primary compiler used on the Mac, though Apple seems to be planning a switch to LLVM.
The policy I was talking about only affects links: an FSF site isn't supposed to link to a page that promotes proprietary software.
Absurd rules of upstream sites
Posted Oct 2, 2008 1:42 UTC (Thu) by tseaver (subscriber, #1544)
[Link]
> The policy I was talking about only affects links: an FSF site isn't
> supposed to link to a page that promotes proprietary software.
Let's get specific. Here is a Launchpad bug page for Zope (the bug is assigned to me):
In what way does that page "promote proprietary software"? Its entire purpose is to help improve a piece of *free* software (Zope); the only mentions of Launchpad are the home page link (the logo at the top), and a "Help us improve Launchpad" link at the very bottom.
The report contains valuable information, including a patch, about a bug in an application I help maintain. Rejecting a link to this page because LP happens to be closed would be a ludicrously irresponsible policy. Making the report and patch inaccessible to the maintainers of a putative upstream application which applied such a policy would be a disservice both to the maintainers and to the users of the software.
Note that I *do* wish LP were opened up, as I believe its value would be increased. I *don't* think rejecting a link to a bugreport in LP would be sane: it would actively harm the free software ecosystem.
Absurd rules of upstream sites
Posted Oct 2, 2008 17:41 UTC (Thu) by JoeBuck (subscriber, #2330)
[Link]
Launchpad is itself proprietary software. I didn't make the rule, I'm just telling you what the rule is. Directing someone to Launchpad is seen by the FSF as promoting Launchpad.
Canonical has promised to free Launchpad, and when they do, this issue will be moot.
please don't violate rules of upstream sites
Posted Oct 1, 2008 22:24 UTC (Wed) by gmb (guest, #54452)
[Link]
For FSF sites, including bugzilla.gcc.org, links to Launchpad aren't allowed as long as it is non-free software. So please delay implementing that feature until Launchpad is free.
I'm sorry, perhaps I wasn't clear in my original post. For this functionality to work with a Bugzilla or Trac instance, that maintainers of that instance need to install the requisite Launchapd API plugin. Without the plugin, the API isn't available. Since we can assume that bugzilla.gcc.org won't install the plugin (at least until Launchpad is released as free software), this isn't a problem.
Alternatively, just make Launchpad free software and all these problems go away.
We're working on it ;)
please don't violate rules of upstream sites
Posted Oct 1, 2008 22:49 UTC (Wed) by jspaleta (subscriber, #50639)
[Link]
Do you have a publicly communicated roadmap later than Aug 28, 2008?
The last thing I read in launchpad's bug tracker is that the roadmap has not been approved.. and I can't seem to find a blueprint or anything describing the roadmap.
If you have an approved roadmap or blueprint or whatever you want to call it....publish it... and provide a link here please.
-jef
please don't violate rules of upstream sites
Posted Oct 2, 2008 7:59 UTC (Thu) by epa (subscriber, #39769)
[Link]
What does it mean for a website to be free software? I cannot make a
change to the code for bugzilla.gcc.org and start running it on the site.
I can download a tarball of the Bugzilla source code, but the
bugzilla.gcc.org site remains unmodifiable by me; it is no more free
software than Linux running on a TiVo.
The only people who have the freedom to change bugzilla.gcc.org for their
own requirements are the site's maintainers. And indeed the maintainers of
the Launchpad site have freedom to change their own code, run modified
versions, and even share it with others if they choose to. They currently
choose not to share it, but nothing in RMS's philosophy forces you to
distribute your code to others - just that if you do distribute it, the
others must have the same rights you do. If I made my own private version
of Apache with a few changes, and ran it only on my own website without
giving a copy to anybody else, would the FSF policy forbid linking to that?
What about linking to a website that uses a couple of CGI scripts? Must
those scripts be published somewhere first?
If the policy is only to link to websites implemented using free software
which is also available for public download, that is consistent, but
extremely strict even by FSF standards. Surely even the FSF's own site
uses some scripts and configuration files they have not made public.
Presumably it would rule out linking to a Bugzilla page that happens to be
hosted on AIX or on Linux running inside a non-free virtual machine like an
IBM mainframe.
What does it mean for a website to be free software?
Posted Oct 2, 2008 21:46 UTC (Thu) by grantingram (guest, #18390)
[Link]
What does it mean for a website to be free software?
I think that is an excellent question! I've never quite understood the objection to Launchpad - as far I can see it is a web site. Though admittedly I only report bugs in it.
I generally don't demand the source code to websites that I read (like LWN for example!) but perhaps there is a point where the website becomes complex and intermingled enough with your own data that one should... I'm not sure where or how I would draw the line though.
What does it mean for a website to be free software?
Posted Oct 3, 2008 9:22 UTC (Fri) by hppnq (guest, #14462)
[Link]
Take a look at the GNU APGLv3.
It is meant to address the issue that software (not so much data) can be
"locked up" in a
website.
What does it mean for a website to be free software?
Posted Oct 3, 2008 9:27 UTC (Fri) by hppnq (guest, #14462)
[Link]
What's in an acronym: AGPLv3 of course.
please don't violate rules of upstream sites
Posted Oct 9, 2008 20:07 UTC (Thu) by oak (guest, #2786)
[Link]
News at FUD.com: RMS "Tivo"s FSF bugzilla; users can get the sources to
it, but they cannot install their modified sources/binaries there! :-)
please don't violate rules of upstream sites
Posted Oct 9, 2008 11:21 UTC (Thu) by azrael (guest, #53640)
[Link]
"For FSF sites, including bugzilla.gcc.org, links to Launchpad aren't allowed as long as it is non-free software."
Man, I've heard that FSF is paranoid but that is just plain retarded.
I think they should also not link to Google, cause that's not free software too.
Ubuntu debuts its Upstream Report
Posted Oct 1, 2008 20:55 UTC (Wed) by JoeBuck (subscriber, #2330)
[Link]
"why do you expect [Ubuntu] to submit a patch for every bug they report?"
The expectation is that they (and all distros) will submit a patch upstream for every bug that they fix, as well as to communicate with upstream about any confirmed bug that upstream doesn't know about. The situation to avoid is where a distro (any distro) fixes bugs for its own users and doesn't work to get them upstream so that others benefit as well. Upstream might disagree with a given fix, of course.
Sometimes this can't happen immediately, but if all distros do this, then all distros benefit.
Ubuntu debuts its Upstream Report
Posted Oct 1, 2008 20:58 UTC (Wed) by dlang (✭ supporter ✭, #313)
[Link]
that's not what people are saying.
they are complaining the ubuntu is making bug reports without also sending patches to fix them, they aren't claiming that ubuntu is making fixes and refusing to submit them.
Ubuntu debuts its Upstream Report
Posted Oct 1, 2008 21:18 UTC (Wed) by nevyn (subscriber, #33129)
[Link]
No, they have said that Canonical/Ubuntu doesn't participate in upstream development. This says nothing about the number of bugs they send upstream, or how much development they do for themselves. I've heard that they do quite a bit of work on their packages and never bother pushing it even to debian -- but that is a side argument.
Personally I wouldn't care much if they did 10x the development they pushed upstream, locally, and 100x the bugs than they did fixes ... as long as they did their "fair share" of the upstream work, and generally stopped taking credit for the work Red Hat, IBM and Novell are doing for them.
This is mainly an economics argument, in that if they keep getting all the credit/mindshare and thus. a sizable number of the users ... development will freezeup as Red Hat/Novell will not be able to afford to spend money they aren't making back.
Ubuntu debuts its Upstream Report
Posted Oct 1, 2008 22:04 UTC (Wed) by kragil (guest, #34373)
[Link]
??? Logic ??? I really fail to see your reasoning.
Canonical isn't making money. They loose lots of money .. (on a pretty consistent basis so far)
So up until now Ubuntu is essentially a charity organisation that sends out CDs to everyone and develops a _very_ popular distro.
RH and Novell (mostly due to the help from MS though) are making lots of money on the other hand. So it is only fair that they do more development.
That is how the system should work IMNSHO.
Ubuntu debuts its Upstream Report
Posted Oct 1, 2008 22:45 UTC (Wed) by jspaleta (subscriber, #50639)
[Link]
Let's connect some dots....
Ubuntu is popular....
Canonical controls the core infrastructure that makes it possible for Ubuntu to be popular....
That infrastructure that Ubuntu relies on is not currently replicable without Canonical as it is closed source....
Canonical is not profitable, nor do we know for sure if its on a path to profitability....
Draw your own conclusions about the sustainability of what Canonical's approach to managing community interactions. The situation with translation handling continues to be a hallmark example. Ubuntu specific improvements such as translations are bound up in that closed infrastructure and are not flowing into upstream projects as smoothly:
And that's just upstream translations, which arguably is one of the lowest hanging fruit of community and upstream interaction that Ubuntu's popularity could be leveraged to help with. It stands to reason that Ubuntu's wide popularity translates into an army of volunteer translators across a multitude of languages.
But those volunteer efforts are not flowing easily into upstream projects because launchpad is specifically designed to aggregate contributions and not to redistribute them back to upstream. If Canonical was actually interested in helping create a conduit between community effort and the upstream projects this problem would have been solved as part of launchpad's design...years ago. Canonical has created this problem by deliberately designing launchpad to try to be a central service to everybody's workflow. To make use of downstream translations, upstream projects have to pull from launchpad and thus rely specifically on Canonical. Canonical could have designed launchpad to work with upstream projects directly and push translations into upstream's processing.
What if launchpad had been originally developed with upstream coordination in mind? What if launchpad were open to contribution from day one? Would the Rosetta component have functioned like transifex does now?
If Canonical was an actual charitable organization, they'd have no compelling reason to keep launchpad closed and Ubuntu community volunteers like their translators would be free to build the tools and the workflows they need without having to worry about Canonical's service based business model.
Speaking of charitable organizations...isn't there a Ubuntu Foundation on the books...does that organization do anything day-to-day month-to-month or was it just a PR stunt?
-jef
Ubuntu debuts its Upstream Report
Posted Oct 1, 2008 22:55 UTC (Wed) by hppnq (guest, #14462)
[Link]
Let's connect some dots....
Let's not. Let's ask for a release of the LWN site source code, so someone could say implement a reasonable comment filter.
Ubuntu debuts its Upstream Report
Posted Oct 1, 2008 23:00 UTC (Wed) by dlang (✭ supporter ✭, #313)
[Link]
there is a greasemonkey script that lets you do exactly that.
Ubuntu debuts its Upstream Report
Posted Oct 2, 2008 6:05 UTC (Thu) by madscientist (subscriber, #16861)
[Link]
Not that I don't appreciate the effort that went into that GM script, but it is in no way a replacement.
Just as an example: I regularly use at least 3 different computers, with 3 different installations of FireFox, separate bookmarks, cookies, etc.
Ubuntu debuts its Upstream Report
Posted Oct 2, 2008 8:56 UTC (Thu) by hppnq (guest, #14462)
[Link]
To be honest I do not always pass my own filter. ;-)
To this long time Red Hat user, the continuous Ubuntu bashing here is just
becoming a bit boring, and frankly, it is looking pathetic. Talking a lot
about what could be done distracts from the important stuff that is actually
being done. People are of course free to determine whether something is
important to them or not, and it is mainly the lack of respect for this
important foundation of free software that annoys me.
For people who remember the discussions about the test bed Red Hat created
with Fedora and the way Novell is dealing with Microsoft, the whining about
Canonical or Ubuntu not contributing enough to the community is a very bad
joke.
More on topic: to me it seems that the correct tooling is essential for
getting the work done, so I welcome this very interesting contribution by
Ubuntu.
Ubuntu debuts its Upstream Report
Posted Oct 2, 2008 2:27 UTC (Thu) by nevyn (subscriber, #33129)
[Link]
Canonical isn't making money.
Not true.
They loose lots of money .. (on a pretty consistent basis so far)
Possibly true, although as a private company only they know.
So up until now Ubuntu is essentially a charity organisation that sends out CDs to everyone
So you agree, they are spending money ... just not on development.
and develops a _very_ popular distro.
I think we've established that they mostly market a distro. ... and as to how popular it is, well popcon vs. smolt stats. are pretty close. So let's just say "one of the popular" distros.
So you're argument (or "logic" as you say) is that it's fine for them not to participate, even though they are one of the popular distributions, because they are spending that money on PR/marketing ... but it wouldn't be fine for Red Hat or Novell to just stop paying developers to participate upstream and instead just spend that money on PR/marketing?
Or maybe you're just saying it's fine if noone grows the pie but just spends all their money on trying to grab as big a slice of the current pie as possible?
That's fine, I guess, you can have that opinion ... but given that I actually like Linux, and want to see it improve faster (and I'd kind of prefer having a job) personally I'll choose option B. Which is pointing out how Canonical are hurting the community and need to change. As did Greg, probably for the same reasons.
Ubuntu debuts its Upstream Report
Posted Oct 2, 2008 4:13 UTC (Thu) by dlang (✭ supporter ✭, #313)
[Link]
if you don't think that marketing a distro, especially to people who have trouble with existing distros isn't growing the pie then you are being blind.
it's not a zero-sum game, ubuntu's gain doesn't directly cause RedHat loss
Ubuntu debuts its Upstream Report
Posted Oct 2, 2008 4:39 UTC (Thu) by jspaleta (subscriber, #50639)
[Link]
" Canonical isn't making money.
Not true.
They loose lots of money .. (on a pretty consistent basis so far)
Possibly true, although as a private company only they know."
As of May 22, 2008 Mark was quoted in an interview as saying that Canonical was "not close" to breaking even. I can't imagine a more qualified opinion on the matter than Shuttleworth.
This interview is also interesting to note that because Mark talks about the future of software as "unlicensed" software. That is a bit of an odd way of describing FOSS if that was his intent. Everywhere else I see the phrase "unlicensed software" used it is used in the context of some sort of licensing violation. I'm pretty sure that Mark doesn't mean to imply that the future of software is going to be the use software in violation of the license that it is offered under.
-jef
Ubuntu debuts its Upstream Report
Posted Oct 2, 2008 8:21 UTC (Thu) by jschrod (subscriber, #1646)
[Link]
> > and develops a _very_ popular distro.
> I think we've established that they mostly market a distro.
Who established that? you? Then you're part of a vocal group of people, but where others (me included) take objection to that opinion. Ubuntu develops a popular distribution by integrating different packages for a target audience of computer non-experts desktop users better than their competitors. This integration and smoothing work is *not* just marketing -- and it doesn't matter that you and others want to debase that important work that's part of our Linux eco-system.
For the record, I am not involved in Ubuntu and don't even use it. (I installed it once in a VM and recognized after a few weeks that it's not my style of distro.) But I've met many people who started to use Linux because of Ubuntu -- they tried RH and SUSE before, and Ubuntu was the first Linux distro that »did things right« for them. And just because of those newbies starting to use Linux, Ubuntu is a Good Thing(tm).
Ubuntu debuts its Upstream Report
Posted Oct 2, 2008 16:12 UTC (Thu) by dberkholz (subscriber, #23346)
[Link]
why do you expect ubunto to submit a patch for every bug they report?
How does tracking a useful metric imply that it's expected to reach 100%? Keeping track of one additional piece of data could make a big step toward disproving the common thought that Ubuntu doesn't contribute enough upstream.
Ubuntu debuts its Upstream Report
Posted Oct 2, 2008 16:31 UTC (Thu) by dlang (✭ supporter ✭, #313)
[Link]
Ok, I misread the question.
I read it as an attack based on the fact that a ubuntu bug gets linked against an upstream bug without submitting a patch.
if it was intended to only be a request to document if such a patch was generated then it's a very different story.
however I would expect that the percentage of linked bugs where a patch is provided would be _very_ low. I think this is very reasonable, ubuntu (or any other distro) may produce a patch, but most of the time they shouldn't.