On Wed, Jul 21, 2010 at 9:23 AM, Jonathan Underwood
wrote:
> On 21 July 2010 12:12, Adam Williamson wrote:
>> Thanks, but afaics that thread doesn't really answer any of my
>> questions, it's just a bunch of yum technicalities about how the
>> implementation of having two packages actually works.
On Wed, Jul 21, 2010 at 10:45 AM, Chris Adams wrote:
> I just want to see changes in a backwards-compatible way whenever it is
> practical. I understand that that is not always the case, but I don't
> see anything here that indicates systemd and the long-standing
> chkconfig/service interfaces ca
On Wed, Jul 21, 2010 at 9:45 AM, Lennart Poettering
wrote:
> We can add similar code to chkconfig too: something that warns the admin
> when a native systemd unit file exists, and then redirects the command
> properly. It is now on my todo list, but not even near the top of the
> list.
Is there
2010/7/21 "Jóhann B. Guðmundsson" :
> There is an RFE for the same compatibility from chkconfig #616857 as in
> chkconfig will try to use systemd native files first and spill out a
> deprecation warning or just spill out deprecation warning hinting users (
> Written in C patches welcome ) and #6127
2010/7/21 "Jóhann B. Guðmundsson" :
> Admins will need to know that they have to use chkconfig for services that
> do not have a native systemd $service file. ( legacy for services )
>
> And as the general rule goes "native configuration breaks legacy
> configuration" so if a native systemd $servic
On Tue, Jul 20, 2010 at 4:02 PM, David Malcolm wrote:
> I'm planning to do a partial mass-rebuild for Python 2.7.
Please, when you hit build failures, and you will if you can
provide a link to a failure report that is easily searchable(if not
sorted by) primary package owner. That will help
On Mon, Jul 12, 2010 at 1:25 PM, Przemek Klosowski
wrote:
> If you kill all of them you'd get rid of the ones you suggested for a
> legit AutoQA tests.
Yes I would. And I'm okay with that. Since there been no work done to
identify any scripts yet there's no real work lost.
I agree about the ugli
On Mon, Jul 12, 2010 at 12:33 PM, Przemek Klosowski
wrote:
> Every file outside of this 'core examples' set could print the message
> "This example's functionality may depend on the specific configuration
> of matplotlib and other packages". Even better, could it be in some sort
> of try/catch blo
On Mon, Jul 12, 2010 at 11:34 AM, Przemek Klosowski
wrote:
> It doesn't look good when the application-provided examples crash. I see
> that it's a complex issue between the upstream and packagers, but I
> think the policy should be "it either runs or gives a clear message that
> it's unsupported"
On Sun, Jul 11, 2010 at 5:17 AM, Michel Alexandre Salim
wrote:
> The signal-to-noise ratio in Bugzilla has definitely dropped since
> ABRT is introduced. Newer versions do require some text to be inserted
> before it will submit the bug report, but perhaps it has to be
> modified further to requir
On Sat, Jul 10, 2010 at 12:29 PM, Carl Gaudreault
wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=531464#c29
I appreciate the effort to be more explicit in your reasoning by
adding an additional comment in response to this out-of-ticket
dicussion.
That being said. I really really think that
On Fri, Jul 9, 2010 at 3:34 PM, Carl Gaudreault
wrote:
>>So It seems Carl G. has been closing several bugs across multiple
>>components without comment recently. Hmm. Not cool.
>
> -jef
>
> I gave the reason why i closed it.
Are you saying that you comment in 27 requesting the report file a
r
On Fri, Jul 9, 2010 at 2:49 PM, Matt McCutchen wrote:
> On Fri, 2010-07-09 at 23:27 +0200, Andreas Tunek wrote:
>> I get Empathy crashes all the time, duplicates of
>> https://bugzilla.redhat.com/show_bug.cgi?id=531464, but this bug is in
>> WONTFIX status. Anyone know why?
>
> Look at the history
On Thu, Jul 8, 2010 at 4:02 PM, David Malcolm wrote:
> Hope this is helpful
> Dave
Is there any hints on expected gotchas that we can look out for.
Deprecations or API changes of significant merit?
-jef
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman
On Wed, Jun 9, 2010 at 8:31 AM, Adam Miller
wrote:
> Did we really need to
> take some raw numbers that Luke was kind enough to put together and make it
> into some sort of QA methods holy war?
The lesson here is that for data mining to make sense there must a
consensus understanding of the quest
On Mon, Jun 7, 2010 at 4:18 PM, Michael Cronenworth wrote:
> Due to bug 493565[1], fuse needs to be updated. This bug has been around for
> a very long time, and no one can seem to reach the fuse maintainer. I see
> this bug daily on one system and I'm tired of it. Can anyone help?
Has the AWOL
On Wed, Jun 2, 2010 at 3:45 PM, Adam Williamson wrote:
> It's a bit intangible and not entirely predicated on whether we're using
> the keyword or flag setup, I think. Currently when we're considering
> bugs we use a search that excludes closed bugs,
In either case, I would suggest that it may be
On Wed, Jun 2, 2010 at 2:07 PM, Adam Williamson wrote:
> Ah. It's a shame it wasn't put up for consideration as a release
> blocker. Obviously the rather peremptory response from Jakub didn't help
> with that...
Would the flag concept for blocker status that Jesse was championing
recently have he
On Wed, Jun 2, 2010 at 10:43 AM, Michael Cronenworth wrote:
> Lennart Poettering wrote:
> If you can make everyone move away from sysv to something else, then by
> all means I'll do my best to aid in patches, but I don't have much
> confidence since everything that has been said about systemd has
On Wed, Jun 2, 2010 at 9:11 AM, Chris Adams wrote:
> That would require systemd to be installed though, since otherwise
> /etc/systemd doesn't exist (or every package that wants to drop a file
> in there has to own it).
>
> I guess the directory could be added to chkconfig or even filesystem.
Tha
On Wed, Jun 2, 2010 at 8:37 AM, Lennart Poettering wrote:
> Handling this with systemd is very easy: you can just drop in a file in
> /etc/init.d/foo *AND* /etc/systemd/system/foo.service from the same
> package. And then, if something that is not systemd is booted it will
> only see the init scri
On Wed, Jun 2, 2010 at 5:21 AM, Patrice Dumas wrote:
> That being said, it seems that the new init system, systemd is already in
> the pipe. Doing a policy for an obsolete technology may be some time
> lost. Maybe even better would be preparing a policy for systemd scripts
> than doing a policy fo
Backstory. I voluntarily adopted python-xlib when it was orphaned by
its original maintainer as it is part of istanbul's depchain.
The client side windows work that went into gtk has played havoc with
how istanbul makes use of python-xlib in the F12 timeframe. Thanks to
some other people, who und
On Wed, May 26, 2010 at 5:55 AM, Lennart Poettering
wrote:
> Well, that depends on configuration.
> In systemd you can choose individually for each unit whether you want to
> allow it to continue run processes on shut down, whether you want the
> main process killed, the process group to be kille
On Wed, May 26, 2010 at 5:55 AM, Lennart Poettering
wrote:
> In systemd you can choose individually for each unit whether you want to
> allow it to continue run processes on shut down, whether you want the
> main process killed, the process group to be killed or the cgroup to be
> killed.
So in
On Tue, May 25, 2010 at 9:09 AM, Jesse Keating wrote:
> Right now, it's not about speed. Speed is one thing, and somewhat
> important. But doing it right is also important. Make it right, then
> make it fast, because if you try to make it fast first, you'll often be
> doing it wrong.
He offere
On Tue, May 25, 2010 at 7:45 AM, Lennart Poettering
wrote:
> Please, judge systemd on technical grounds, don't judge it on political,
> or emotional grounds.
"I'll publish the numbers of a 100% socket-activated boot soon."
I would love to have the necessary data to have an informed public
discus
On Thu, May 20, 2010 at 7:44 AM, Kevin Fenzi wrote:
> http://tinyurl.com/22resfg
>
> Currently I see 77 bugs on this list, I'm sure maintainers who haven't
> been able to fix things yet would love provenpackgers to step in and
> help out. :)
Awesome. Lets see if I can earn my security bugfix meri
On Tue, May 18, 2010 at 3:00 PM, Rahul Sundaram wrote:
> While I understand the decision behind enabling updates-testing repo by
> default, I think it should be turned off much earlier, perhaps during
> the beta release phase. Due to the workflow I follow, one of the
> problems of having it ena
On Tue, May 11, 2010 at 3:10 PM, Przemek Klosowski
wrote:
> This probably means at least a rudimentary application testing rig
> and a discipline that identifies and deals with distressed packages.
Does the ongoing work with AutoQA provide the solution you are looking for?
http://fedoraproject.o
On Tue, May 11, 2010 at 2:14 PM, Till Maas wrote:
> I use the non-responsive process or active nagging quite a lot, since I
> often stumble upon such packages (it already happend twice to youtube-dl
> that the current maintainer did not have enough time). Thankfully the
> start of the non-responsi
On Tue, May 11, 2010 at 1:47 AM, Chen Lei wrote:
> It seems a lot of trivial packages in fedora are unmaintained for a long
I dispute your claim that there are "a lot."
Yes we are going to have things fall through the cracks. But I've seen
no analysis and no tools which would help us identify th
On Tue, May 11, 2010 at 10:57 AM, Jon Ciesla wrote:
> Well, no, not if there's an easy way to find the existing stuff. Is
> there a way to extract this info from Bugzilla? I'd stick that query in
> my bookmarks and peek at it every couple days.
Indeed. I'd like to use my proven powers for good
On Tue, May 11, 2010 at 8:46 AM, Kevin Fenzi wrote:
> It's unfortunate that these two big packages didn't make it into the
> base repo, but such is life. ;(
As this is the first time we've done the early branching... I
certainly expect mistakes right around the time of the branch freeze
and for
On Mon, May 10, 2010 at 10:14 PM, James Antill wrote:
> 6.2M wesnoth-1.8.1-1.fc13.x86_64.rpm
> 12M hanazono-fonts-20100222-2.fc13.noarch.rpm
> 48M xmoto-0.5.3-1.fc13.x86_64.rpm
> 260M wesnoth-data-1.8.1-1.fc13.noarch.rpm
> 318M openarena-0.8.5-1.fc13.noarch.rpm
>
> ...the last being particularly
On Mon, May 10, 2010 at 10:36 AM, drago01 wrote:
> Fix what is broken and not break everything else so that you can
> pretend that it isn't.
Think of that opening remark as a modern twitter-friendly version of
"A Modest Proposal" given in the very same spirit of Jonathon Swift's
original.
-jef
-
On Mon, May 10, 2010 at 2:48 AM, Adam Williamson wrote:
> That's the wrong argument. We all know why we _can't_ make it just work,
> but that doesn't excuse us.
You are right. The answer is clearly to export US legal rules to the
rest of the world so we can have an equally unfriendly playing fiel
On Thu, May 6, 2010 at 3:01 PM, Rudolf Kastl wrote:
> one of the questions raised in the meeting posted by mcepl was... "why
> dont those people leave if they are unhappy". simple... they put alot
> sweat blood and tears into a project, and they have friends... with
> the development crowd and wit
On Wed, May 5, 2010 at 2:12 PM, Orcan Ogetbil wrote:
> An anonymous database is easy to ignore by packagers. I fear that that
> might turn to something as useless as pulseaudio.
The little jab at pulseaudio is extremely inappropriate and absolutely
non-constructive to the discussion at a hand. S
On Wed, May 5, 2010 at 1:34 PM, Orcan Ogetbil wrote:
> I understand. But please respect what others are thinking. I do see a
> problem in abrt that it wastes my time.
It's not possible for you to simply ignore the abrt bugs? I filter
the [abrt] ticket email into a separate folder for example so
On Wed, May 5, 2010 at 12:47 PM, Orcan Ogetbil wrote:
> Can we just disable abrt on Fedora until it figures how to file bugs
> upstream? What is the procedure to propose this? Does this have to go
> through FESCo?
that's a bit drastic. I don't want abrt disabled on my packages. I'm
willing to mak
On Wed, May 5, 2010 at 9:54 AM, Frank Ch. Eigler wrote:
> Good point. Clearly though one can't delay the setting of the final
> release behaviors too long, or else *those* won't get tested.
I'm not arguing about what that point should be. I'm just saying that
this glib debugging stuff should syn
On Wed, May 5, 2010 at 9:28 AM, Eric Sandeen wrote:
> Agreed, I'm tired of (insert random benchmarking site) saying "OH NOES!
> Fedora got SLOWER AGAIN!" when it's really a lot of debug going on.
>
> Stating something like this clearly on login & install would be nice,
> not just for this MALLOC_P
On Tue, May 4, 2010 at 9:50 AM, Jesse Keating wrote:
> If the breakage was more of a functional break and not a dep break,
> that's where automated testing comes in, and we grow the automated
> functional testing of updates so that if an update comes along we can
> detect the breakage and alert bo
On Tue, May 4, 2010 at 8:45 AM, Jesse Keating wrote:
> So I'd love to have multi-level policy, but in my opinion it should get
> harder and harder to push an update as the release gets older, not
> easier.
In general I'm in agreement with this. But at the same time I'm
concerned that the policy
On Mon, May 3, 2010 at 1:06 PM, Thomas Janssen
wrote:
> To make sense it should be on by default.
Good luck with that. I strongly suggest that any usage which only
makes sense with "on by default" is not a usage you can rely on as a
strawman.
The popularity application idea would be a compellin
On Mon, May 3, 2010 at 12:19 PM, yersinia wrote:
> Sure, I can try. If one software is used many time from many user, directly
> or indirectly, and it have not such many problems (e.g bug open on bugzilla
> for example ), well this could guide to the decision of the goodness of the
> software a
On Mon, May 3, 2010 at 12:03 PM, Thomas Janssen
wrote:
> - Superb information for us packagers if and how much (of course not
> the correct value) users use the software i package
It may or may not be superb information...but you haven't told me how
collecting this information is helpful to the u
On Sun, May 2, 2010 at 7:25 AM, yersinia wrote:
> Look interesting from a QA point of view.
How exactly is this interesting from a QA pov in Fedora? Smolt
profiles I can understand being useful for QA because it gives us some
ability to look for commonalities when troubleshooting hardware
proble
On Mon, May 3, 2010 at 10:00 AM, Chris Adams wrote:
> Thanks a lot Kevin; you showed a lot of class trying to stir up the same
> arguments that you stirred up before. Maybe the reason you lost votes
> is that a lot of people just don't agree with you; pouting about that
> won't help anything.
Th
On Mon, May 3, 2010 at 3:07 AM, Alex Hudson wrote:
> I think it's a bit disingenuous to talk about prevailing opinion of the
> mailing list otherwise; to me a lot of the discussion looks an awful lot
> like a vocal minority,
Be careful about meeting subjective opinion with differing subjective op
On Thu, Apr 29, 2010 at 9:58 AM, Christopher Aillon wrote:
> Anyway, it's unfortunate that this really isn't done more often. I
> really think that as a project, we'd be doing a lot better if we
> mandated upstream review before applying patches to any package if you
> aren't an upstream maintain
On Thu, Apr 29, 2010 at 10:24 AM, Christopher Aillon wrote:
> But, I'll re-iterate what Jan told you earlier in the thread that we've
> been working on it with upstream and have been for a while, and it's a
> HUGE undertaking. We've already made significant progress and have
> gotten quite a bit
On Mon, Apr 26, 2010 at 10:09 PM, Luming Yu wrote:
> God must have fixed the problem for us. :-)
> or some mysterious things happened with the web site
> offering the mysterious video, which sometimes working, sometimes
> not working
It's most likely a connectivity problem associated with ho
On Sun, Apr 25, 2010 at 12:10 AM, Christoph Wickert
wrote:
> I'm upstreaming reports from 'lazy idiots' too and some of them get
> fixed. In fact the percentage of the ones that get fixed is not
> different from the 'active' reporters cause usually the backtrace
> contains all necessary data for t
On Sun, Apr 25, 2010 at 5:41 PM, Luming Yu wrote:
> Hmm,... tried ff 3.6.4, not working...
Just fyi, the flash video in question works fine for me in a fully
updated 64bit F13 beta using the 64bit flash using the tarball from
the adobe website
libflashplayer-10.0.45.2.linux-x86_64.so.tar.gz
I d
On Thu, Apr 22, 2010 at 2:53 PM, Seth Vidal wrote:
> Run "echo 'n' | yum --skip-broken update"
>
> for me and save the output.
It's really unexciting output.
Output below:
Loaded plugins: downloadonly, presto, refresh-packagekit
Setting up Update Process
Resolving Dependencies
--> Running tran
On Thu, Apr 22, 2010 at 11:09 AM, Jim Meyering wrote:
> I hope it's just me...
> but I was very dismayed to find that today's F13 update (which pulled
> in a lot of changes) hosed my laptop.
I have two 64bit F13 laptops... fully updated with updates-testing
except for gnome-icon-theme-extras whic
I'm assuming everyone here has heard of Lernid, the little classroom
ui that Jono Bacon original put together.
I got lernid trunk up and running on Fedora 13. All the prerequisites
are in place. it connects to the Ubuntu events.
My understanding is that lernid just needs a hardcoded url from whi
On Tue, Apr 20, 2010 at 10:02 AM, drago01 wrote:
> It is just a game ...
> Ever tried to run compiz on software? (hint: desktop effects will tell
> you to come back once you are using a 3D driver).
Ah...see here's the thing... this application doesn't actually tell
you anything...its just fails
On Tue, Apr 20, 2010 at 9:32 AM, drago01 wrote:
> Clutter is not targeting mesa's software rastersizer ... so clutter
> upstream do not really care if it works without any hardware support
> or not.
Which is all fine for an optional component gnome-shell which
explicitly states it targets hardwa
On Tue, Apr 20, 2010 at 9:18 AM, Mark Bidewell wrote:
> I have been dealing with this issue in the context of Ubuntu Lucid,
> however since it can be reproduced under F13 Beta I thought it would
> be wise to raise it here. In some cases, gnome-games do not properly
> fall back to software renderi
On Wed, Apr 14, 2010 at 11:53 AM, Karel Klic wrote:
> Please file a RFE in Bugzilla, and include the filename mask(s) marking
> the files you want to exclude. I think it will be something like:
> /usr/lib/python2.6/site-packages/scipy/*/examples/*.py
do you want that in Fedora bugzilla against ab
On Wed, Apr 14, 2010 at 11:53 AM, Karel Klic wrote:
> Please file a RFE in Bugzilla, and include the filename mask(s) marking
> the files you want to exclude. I think it will be something like:
> /usr/lib/python2.6/site-packages/scipy/*/examples/*.py
For the moment... im talking about things down
On Wed, Apr 14, 2010 at 6:09 AM, Jon Ciesla wrote:
> I agree, and thought Seth made his point well. I typically consider the
> set of things in Fedora I need to worry about to be the set of bugs
> assigned to me, plus the ones I've files, plus any FTFFS or broken deps
> I'm aware of. If somethin
So I'm maintaining matplotlib and scipy.. which effectively allows
"scientists" to pretend they are "programmers"
So matplotlib includes a large selection of examples to read over as
documentation. Some of these example do some crazy complicated things
which make use of matplotlib and wont work ou
2010/4/12 Devrim GÜNDÜZ :
> It is my bad. I should have noticed it before pushing update...
No worries. I doubt it was maliciously intended.
However, this is the 3rd different issue with basemap in the same week
where another maintainer's actions updating one of the dependency
packages have cause
On Fri, Apr 9, 2010 at 4:20 PM, Matt McCutchen wrote:
> There's another possible explanation for that policy: users who don't
> participate in testing know that any update with an ID went to stable
> and won't be distracted by references to IDs of testing updates in
> various forums. But actually
On Fri, Apr 9, 2010 at 4:09 PM, Matt McCutchen wrote:
> Better comparison: Bugzilla does not allow the content of an attachment
> to be edited once it is submitted. Instead, people submit a new
> attachment and obsolete the old one.
Yes and koji keeps builds around to even when they aren't in a
On Fri, Apr 9, 2010 at 4:05 PM, Matt McCutchen wrote:
> It confuses the people who put in the effort to test your packages. I
> updated to NetworkManager-0.8.0-4.git20100325.fc12.x86_64 and hit bugs
> 576925 and 578141. I wanted to leave negative feedback on the update,
> but I could not find on
On Fri, Apr 9, 2010 at 4:05 PM, Matt McCutchen wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=573510#c2
>
> How hard is it to use Bodhi properly?
And then at the bottom of the bug report... there's newer
packages...and newer links.
There's no value in commenting on testing packages that ar
On Fri, Apr 9, 2010 at 3:57 PM, Matt McCutchen wrote:
> The comparison to bugs is not valid. A bug is the same bug until it is
> fixed. An update consisting of different packages is a different
> update.
What? We don't tag testing-updates with an ID. Testing packages...are
implicitly in flux..
On Fri, Apr 9, 2010 at 3:10 PM, Matt McCutchen wrote:
> Thoughts? Am I missing something?
When someone is publishing updates and putting them into testing
specifically to address known bugs... and they get the fix wrong in
some way... I think its perfectly acceptable to reuse the same update
no
Here's the notice that I'm taking ownership of orphaned inkscape in EPEL 4/5.
-jef
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Wed, Apr 7, 2010 at 8:50 AM, Orion Poplawski wrote:
> Looks like the geos update for F-12 bumped the soname:
> python-basemap-0:0.99.2-6.fc12.i686
Sigh thanks for the heads up. I'll push a rebuild now.
-jef"Not to be picky, but it sure would be nice if there was some way
I could get a he
On Tue, Apr 6, 2010 at 2:49 PM, Adam Williamson wrote:
> That seems strange, it should use dracut, not mkinitrd at all? Is this
> an F13 system?
dracut package provides /sbin/mkinitrd
and you'll see that new-kernel-pkg gets called with --mkinitrd as well
as --dracut in the kernel scriptlet for b
On Fri, Apr 2, 2010 at 7:54 AM, David Malcolm wrote:
> Doing so now and forcing a rebuild _might_ help isolate the change. I
> don't know if that's a good idea at this stage for F-13, though.
>
> Hope this is helpful; I haven't had enough coffee yet today so I may be
> missing something.
It look
On Thu, Apr 1, 2010 at 11:03 PM, Jussi Lehtola
wrote:
> A Python package BuildRequiring numpy does not need to mean anything.
> All of my packages on the list BuildRequires numpy simply because the
> install scripts have a dummy check in them for checking that all
> necessary runtime modules are i
On Thu, Apr 1, 2010 at 10:44 PM, Thomas Spura
wrote:
> Are you sure, packages like gnuplot-py *have* to get rebuild?
> Your first programm that causes troubles 'python-basemap' is not noarch.
> A compiled programm needs a rebuild, but a programm with just python
> files in it?
Apologies, see the
On Thu, Apr 1, 2010 at 12:48 PM, Jeff Spaleta wrote:
> It was sorted! By build date! Oldest builds at the top. I'm working
> on narrowing the list to just things that buildrequire...I'll
> alpanumeric sort that one.
Here is a revised list, sorted for package name, of pac
On Thu, Apr 1, 2010 at 12:41 PM, John Reiser wrote:
>> Here are the packages that might be affected according to repoquery
>> run on my 32bit box with build timestamps prior to numpy 1.4.0.
> <>
>
> Please sort the list. Yes, many mail user agents do offer text Search,
> but mostly that works
On Thu, Apr 1, 2010 at 11:41 AM, Jeff Spaleta wrote:
> Here are the packages that might be affected according to repoquery
> run on my 32bit box with build timestamps prior to numpy 1.4.0.
Let me stress the "might" That was a first rough cut at a list. Its
really anything th
Found this today with python-basemap. Numpy 1.4.0 introduced some ABI
changes. Anything that compiles against numpy and hasn't been rebuilt
since Numpy 1.40 was introduced in late January may need to be rebuilt
in F-13 and rawhide.
Just a friendly heads up.
I'm fixing python-basemap now and then
On Wed, Mar 31, 2010 at 6:35 PM, Orion Poplawski wrote:
> This is why I actually really enjoyed the brief period that bugzilla
> automatically searched closed bugs, though I can see why that isn't
> sustainable. Perhaps it could automatically search closed bugs for
> supported releases?
Or perha
On Wed, Mar 31, 2010 at 12:30 PM, Juha Tuomala wrote:
> Because it's a database of release's bugs, not a todo list?
Bugzilla has multiple uses. The upstream project goes to some length
describing it as a flexible tool. We in fact use it for multiple
purposes. We use it for package review tickets
On Wed, Mar 31, 2010 at 8:29 AM, Juha Tuomala wrote:
>
>
>
> On Wed, 31 Mar 2010, Jeff Spaleta wrote:
>>
>> Are you saying that we should all clone every report that we all would
>> normally close as fixed rawhide?
>
> Are you saying, that everyone facin
On Wed, Mar 31, 2010 at 8:15 AM, Juha Tuomala wrote:
> that's why there is 'clone' functionality. Use it.
Are you saying that we should all clone every report that we all would
normally close as fixed rawhide?
-jef
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.
On Wed, Mar 31, 2010 at 4:49 AM, Rahul Sundaram wrote:
> That's just your perception and I don't see any consensus on that. The
> bug is fixed and fixed only in the development branch and this is a
> fairly common thing to do for upstream projects as well as
> distributions. because the fix is to
On Tue, Mar 30, 2010 at 3:33 PM, Adam Williamson wrote:
> I don't think there's ever an absolute answer to this question.
> Sometimes it makes more sense for the original reporter to report
> upstream - in which case the maintainer should politely ask them to;
> sometimes it makes more sense for t
101 - 189 of 189 matches
Mail list logo
