3:10 p.m.
I just installed mantis (mantis-1.0.8-1.fc7.noarch et al.). I turned
my browser to http://localhost/mantis/ and got:
Forbidden
You don't have permission to access /mantis/ on this server.
Apache/2.2.4 (Fedora) Server at localhost Port 80
And similarly for http://localhost/mantis.
So I go look at the configuration file, and it says to read a file
called README.Fedora. When I finally tracked that down, it said to
point your browser at https://localhost/mantis/admin/install.php. I
did so. After some gabble about certificates, I got:
Forbidden
You don't have permission to access /mantis/admin/install.php on this server.
Apache/2.2.4 (Fedora) Server at localhost Port 443
Now what?
--
Charles Curley /"\ ASCII Ribbon Campaign
Looking for fine software \ / Respect for open standards
and/or writing? X No HTML/RTF in email
http://www.charlescurley.com / \ No M$ Word docs in email
Key fingerprint = CE5C 6645 A45A 64E4 94C0 809C FFF6 4C48 4ECD DFDB
9:23 p.m.
On Thu, 2007-08-23 at 14:10 -0600, Charles Curley wrote:
I just installed mantis (mantis-1.0.8-1.fc7.noarch et al.). I turned
my browser to http://localhost/mantis/ and got:
Forbidden
You don't have permission to access /mantis/ on this server.
Apache/2.2.4 (Fedora) Server at localhost Port 80
And similarly for http://localhost/mantis.
So I go look at the configuration file, and it says to read a file
called README.Fedora. When I finally tracked that down, it said to
point your browser at https://localhost/mantis/admin/install.php. I
did so. After some gabble about certificates, I got:
Forbidden
You don't have permission to access /mantis/admin/install.php on this server.
Apache/2.2.4 (Fedora) Server at localhost Port 443
Now what?
You might want to look at the recent threads I've had with Scott over
Apache and Drupal. It might be the same kinds of issues (symlinks to
things in /usr/share/program-name, SELinux contexts, Linux permissions,
Apache allow-from/deny rules, etc.).
--
[tim@bigblack ~]$ uname -ipr
2.6.22.1-41.fc7 i686 i386
Using FC 4, 5, 6 & 7, plus CentOS 5. Today, it's FC7.
Don't send private replies to my address, the mailbox is ignored.
I read messages from the public lists.
2:49 p.m.
On Fri, Aug 24, 2007 at 11:53:11AM +0930, Tim wrote:
On Thu, 2007-08-23 at 14:10 -0600, Charles Curley wrote:
> I just installed mantis (mantis-1.0.8-1.fc7.noarch et al.). I turned
>
> Now what?
You might want to look at the recent threads I've had with Scott over
Apache and Drupal. It might be the same kinds of issues (symlinks to
things in /usr/share/program-name, SELinux contexts, Linux permissions,
Apache allow-from/deny rules, etc.).
No joy. SELinux is not an issue. File permissions all look good: files
are readable by other, direcotries readable and executable by other. I
set the perms to wide open:
Alias /mantis /usr/share/mantis
<Directory /usr/share/mantis>
# As passwords will be sent over the line do not allow plaintext
# communication
SSLRequireSSL
Options None
# Do not change this unless the default administrator
# login was removed; see documentation for details
Order Allow,Deny
Allow from all
php_flag "register_globals" "off"
SetEnv MANTIS_CONFIG /etc/mantis/config_inc.php
</Directory>
And I remembered to restart apache when I did so.
I did not muck with symlinks. Tha alias above should have done it
without. I have a similar alias for local docs:
# Allow access to local system documentation from localhost
Alias /doc/ /usr/share/doc/
<Location /doc>
order deny,allow
deny from all
allow from foo bar localhost .localdomain
Options Indexes FollowSymLinks
</Location>
I tried copying the Options line into the mantis alias; no joy.
--
Charles Curley /"\ ASCII Ribbon Campaign
Looking for fine software \ / Respect for open standards
and/or writing? X No HTML/RTF in email
http://www.charlescurley.com / \ No M$ Word docs in email
Key fingerprint = CE5C 6645 A45A 64E4 94C0 809C FFF6 4C48 4ECD DFDB
4:06 p.m.
On Sat, Aug 25, 2007 at 01:49:51PM -0600, Charles Curley wrote:
On Fri, Aug 24, 2007 at 11:53:11AM +0930, Tim wrote:
> On Thu, 2007-08-23 at 14:10 -0600, Charles Curley wrote:
> > I just installed mantis (mantis-1.0.8-1.fc7.noarch et al.). I turned
It took me under an hour to install from tarball and set up several
accounts, projects, etc.
--
Charles Curley /"\ ASCII Ribbon Campaign
Looking for fine software \ / Respect for open standards
and/or writing? X No HTML/RTF in email
http://www.charlescurley.com / \ No M$ Word docs in email
Key fingerprint = CE5C 6645 A45A 64E4 94C0 809C FFF6 4C48 4ECD DFDB
4:13 p.m.
On Sat, Aug 25, 2007 at 03:06:08PM -0600, Charles Curley wrote:
On Sat, Aug 25, 2007 at 01:49:51PM -0600, Charles Curley wrote:
> On Fri, Aug 24, 2007 at 11:53:11AM +0930, Tim wrote:
> > On Thu, 2007-08-23 at 14:10 -0600, Charles Curley wrote:
> > > I just installed mantis (mantis-1.0.8-1.fc7.noarch et al.). I turned
>
It took me under an hour to install from tarball and set up several
accounts, projects, etc.
Oh, and in the process of doing so I found out that the RPM is missing
a dependency: php-mysql, which pulls in php-pdo.
--
Charles Curley /"\ ASCII Ribbon Campaign
Looking for fine software \ / Respect for open standards
and/or writing? X No HTML/RTF in email
http://www.charlescurley.com / \ No M$ Word docs in email
Key fingerprint = CE5C 6645 A45A 64E4 94C0 809C FFF6 4C48 4ECD DFDB
4:39 p.m.
Charles Curley wrote:
On Sat, Aug 25, 2007 at 03:06:08PM -0600, Charles Curley wrote:
> On Sat, Aug 25, 2007 at 01:49:51PM -0600, Charles Curley wrote:
>> On Fri, Aug 24, 2007 at 11:53:11AM +0930, Tim wrote:
>>> On Thu, 2007-08-23 at 14:10 -0600, Charles Curley wrote:
>>>> I just installed mantis (mantis-1.0.8-1.fc7.noarch et al.). I turned
> It took me under an hour to install from tarball and set up several
> accounts, projects, etc.
Oh, and in the process of doing so I found out that the RPM is missing
a dependency: php-mysql, which pulls in php-pdo.
Do file a bug report.
Rahul
6:22 a.m.
On Sun, Aug 26, 2007 at 03:09:58AM +0530, Rahul Sundaram wrote:
Charles Curley wrote:
>On Sat, Aug 25, 2007 at 03:06:08PM -0600, Charles Curley wrote:
>>On Sat, Aug 25, 2007 at 01:49:51PM -0600, Charles Curley wrote:
>>>On Fri, Aug 24, 2007 at 11:53:11AM +0930, Tim wrote:
>>>>On Thu, 2007-08-23 at 14:10 -0600, Charles Curley wrote:
>>>>>I just installed mantis (mantis-1.0.8-1.fc7.noarch et al.). I turned
>>It took me under an hour to install from tarball and set up several
>>accounts, projects, etc.
>
>Oh, and in the process of doing so I found out that the RPM is missing
>a dependency: php-mysql, which pulls in php-pdo.
Do file a bug report.
No, Rahul, I will not follow a bug report, for two reasons.
* If the maintainer is not already aware of the problem from reading
this thread, then he doesn't give enough of a damn for me to spend
any more time on it.
* The package is so pathetically broken (see earlier in this thread)
that the lack of the php-mysql package is irrelevant, another reason
to believe that the maintainer doesn't give a damn.
--
Charles Curley /"\ ASCII Ribbon Campaign
Looking for fine software \ / Respect for open standards
and/or writing? X No HTML/RTF in email
http://www.charlescurley.com / \ No M$ Word docs in email
Key fingerprint = CE5C 6645 A45A 64E4 94C0 809C FFF6 4C48 4ECD DFDB
6:25 a.m.
Charles Curley wrote:
No, Rahul, I will not follow a bug report, for two reasons.
* If the maintainer is not already aware of the problem from reading
this thread, then he doesn't give enough of a damn for me to spend
any more time on it.
You aren't expecting every maintainer to subscribe to user lists and
follow all the threads here. Do you? Very very few people have the time
to do this and mailing lists are not a good place to keep track of bugs
which is why bugzilla exists.
* The package is so pathetically broken (see earlier in this thread)
that the lack of the php-mysql package is irrelevant, another reason
to believe that the maintainer doesn't give a damn.
Not everyone hits the same problems. I wouldn't assume anything without
even sending any feedback.
Rahul
10:56 a.m.
On Sun, Aug 26, 2007 at 04:55:31PM +0530, Rahul Sundaram wrote:
Charles Curley wrote:
>
>No, Rahul, I will not follow a bug report, for two reasons.
>
>* If the maintainer is not already aware of the problem from reading
> this thread, then he doesn't give enough of a damn for me to spend
> any more time on it.
You aren't expecting every maintainer to subscribe to user lists and
follow all the threads here. Do you? Very very few people have the time
to do this and mailing lists are not a good place to keep track of bugs
which is why bugzilla exists.
Yes, as a matter of fact, I do expect them to subscribe to this
list. Not because they are maintainers per se, but because presumably
they are users as well. It would be a bit difficult to maintain a
package without using Fedora. Of course I could be wrong, which would
explain the state of the Mantis package.
As for following every single thread, that's a straw man argument. It
isn't hard to write a filter to make emails with certain key words
(e.g. "mantis") jump out at you.
>
>* The package is so pathetically broken (see earlier in this thread)
> that the lack of the php-mysql package is irrelevant, another reason
> to believe that the maintainer doesn't give a damn.
Not everyone hits the same problems. I wouldn't assume anything without
even sending any feedback.
The fact that I haven't seen any message to the effect of "Yeah, I saw
that, try this" and only one general "try this list of things to look
at" suggests that nobody has the RPM working.
Has anyone got the Mantis RPM working? Or have folks done what I did:
give up on it and use the upstream tarball?
And another thought, Rahul: maintainers can ignore bugzilla entries
same as they can emails. I've had one bug (189120) oustanding since
2006-04-17, and no-one has yet taken ownership, never mind actually
done anything about it.
--
Charles Curley /"\ ASCII Ribbon Campaign
Looking for fine software \ / Respect for open standards
and/or writing? X No HTML/RTF in email
http://www.charlescurley.com / \ No M$ Word docs in email
Key fingerprint = CE5C 6645 A45A 64E4 94C0 809C FFF6 4C48 4ECD DFDB
11:28 a.m.
Charles Curley wrote:
Yes, as a matter of fact, I do expect them to subscribe to this
list. Not because they are maintainers per se, but because presumably
they are users as well. It would be a bit difficult to maintain a
package without using Fedora.
So let me tell you. You have the wrong expectations. Many maintainers as
well as end users are not going to subscribe to this list for various
reasons. Lack of time. Preference to other ways of getting help like
forums etc.
As for following every single thread, that's a straw man
argument. It
isn't hard to write a filter to make emails with certain key words
(e.g. "mantis") jump out at you.
That assumes everyone chooses a good subject and sticks to the topic.
Not happening in this list.
Has anyone got the Mantis RPM working? Or have folks done what I
did:
give up on it and use the upstream tarball?
If noone reports back any feedback, you can't expect anything to change.
And another thought, Rahul: maintainers can ignore bugzilla entries
same as they can emails. I've had one bug (189120) oustanding since
2006-04-17, and no-one has yet taken ownership, never mind actually
done anything about it.
This isn't a commercial product and there isn't any guarantee of
response however the feedback on bugzilla does reach the maintainers
directly and is way more easier to keep track of. File a bug report
instead of expecting everyone to deal with bug reports in a end user's
mailing list.
Rahul
12:40 p.m.
Charles Curley wrote:
> You aren't expecting every maintainer to subscribe to user
lists
> and follow all the threads here. Do you? Very very few people have
> the time to do this and mailing lists are not a good place to keep
> track of bugs which is why bugzilla exists.
Yes, as a matter of fact, I do expect them to subscribe to this
list. Not because they are maintainers per se, but because
presumably they are users as well. It would be a bit difficult to
maintain a package without using Fedora. Of course I could be wrong,
which would explain the state of the Mantis package.
But not all users will gain from reading the messages on this list.
Certainly most folks capable of maintaining packages would get bored
reading the many questions by folks that are new users, especially if
they don't have time to help out with answering those questions.
You may well know what the package to maintainer ratio is in Fedora.
If not, it's rather large, with nearly 4700 source packages in the
distro and a little other 400 maintainers. I don't think it's all
that unreasonable to ask that users help out by reporting bugs to
bugzilla.
I do understand your hesitation of the package seems so full of bugs
that it's pointless. However, if that doesn't get bugzilla'd, then
other maintainers may not find out for a while that something is
horribly awry in the mantis package and that someone needs some help
(or a smack with the cluestick). So, a bugzilla may be the most
helpful thing you could do for a terribly broken package, even if it
just says that there are numerous problems (listing them briefly) with
the package and the whole things needs work.
As for following every single thread, that's a straw man
argument.
It isn't hard to write a filter to make emails with certain key
words (e.g. "mantis") jump out at you.
Bugzilla has the advantage that it mails the maintain automatically
and that the conversations there are more easily searchable on various
fields.
I think you should view it as a plus that some maintainers do take the
time to follow this list, not as a negative that all of them don't.
And always keep in mind that since the OS and all the work to create
it are given to you for free, it's not that much to ask for you to
report problems in the place that's most accommodating to the
maintainer. (And I'm not saying that you don't report things to
bugzilla personally. I know from my own little travels in bugzilla
that isn't true. :)
The fact that I haven't seen any message to the effect of
"Yeah, I
saw that, try this" and only one general "try this list of things to
look at" suggests that nobody has the RPM working.
Or that no one on this list has tried to use it. How many users are
installing bug trackers? I think that it's a low number of the folks
on this list. I haven't seen anyone mentioning Trac here either, but
that doesn't make me think it's broken too. :)
Has anyone got the Mantis RPM working? Or have folks done what I
did: give up on it and use the upstream tarball?
I'd read your mails and thought about trying to take a look at getting
the rpm to see what might be broken with it. I do detest mantis as a
user. I've hated having to interact with it every time I've reported
a bug to an upstream that used it. So I figured I'd wait and see if
someone else helped you out before putting myself through some likely
pain. ;-)
And another thought, Rahul: maintainers can ignore bugzilla entries
same as they can emails. I've had one bug (189120) oustanding since
2006-04-17, and no-one has yet taken ownership, never mind actually
done anything about it.
That is certainly true. Just because someone maintains a package
doesn't mean that they do it well. Having things in bugzilla though
makes it easier to find those lax maintainers and give them the help
(or kick) that they need. Other folks can run reports on bugzilla to
find which maintainers have been unresponsive to bugs. Then, if it's
appropriate, there's the AWOL maintainer process for those folks that
just stop responding to bugs/updates/needed changes in their packages.
(In the case of the above bug, it's also possible that it was fixed in
a newer gnome release and it just didn't get closed properly. It may
also have gotten lost in the forest of desktop bugs. It's assigned to
Ray Strode who isn't someone I'd consider a lax maintainer. He does a
lot of work with upstream gnome projects and within the Fedora desktop
team. So I'd guess the lack of response there is due to the latter.)
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dawn, n.:
The time when men of reason go to bed.
-- Ambrose Bierce, "The Devil's Dictionary"
2:19 p.m.
On Sun, 2007-08-26 at 13:40 -0400, Todd Zullinger wrote:
Charles Curley wrote:
>> You aren't expecting every maintainer to subscribe to user lists
>> and follow all the threads here. Do you? Very very few people have
>> the time to do this and mailing lists are not a good place to keep
>> track of bugs which is why bugzilla exists.
>
> Yes, as a matter of fact, I do expect them to subscribe to this
> list. Not because they are maintainers per se, but because
> presumably they are users as well. It would be a bit difficult to
> maintain a package without using Fedora. Of course I could be wrong,
> which would explain the state of the Mantis package.
But not all users will gain from reading the messages on this list.
Certainly most folks capable of maintaining packages would get bored
reading the many questions by folks that are new users, especially if
they don't have time to help out with answering those questions.
You may well know what the package to maintainer ratio is in Fedora.
If not, it's rather large, with nearly 4700 source packages in the
distro and a little other 400 maintainers. I don't think it's all
that unreasonable to ask that users help out by reporting bugs to
bugzilla.
I do understand your hesitation of the package seems so full of bugs
that it's pointless. However, if that doesn't get bugzilla'd, then
other maintainers may not find out for a while that something is
horribly awry in the mantis package and that someone needs some help
(or a smack with the cluestick). So, a bugzilla may be the most
helpful thing you could do for a terribly broken package, even if it
just says that there are numerous problems (listing them briefly) with
the package and the whole things needs work.
I agree that bugzilla should work but
it has never worked for me. I file
bugzillas and nothing much happens. By the time we get through all the
requests for further info a new distribution is out and it makes no
difference.
I will admit some bugzilla reports are resolved but I have never been
that lucky.
I will go further and explain in what situation it is useless to
bugzilla. When you problem is more or less unique to your system. If a
large fraction on users are having the same problem that your chances of
getting an answer are better.
--
=======================================================================
The world needs more people like us and fewer like them.
=======================================================================
Aaron Konstam telephone: (210) 656-0355 e-mail: akonstam(a)sbcglobal.net
1:35 p.m.
Aaron Konstam wrote:
I agree that bugzilla should work but it has never worked for me. I
file bugzillas and nothing much happens. By the time we get through
all the requests for further info a new distribution is out and it
makes no difference.
Perhaps it doesn't end with an updated package for the version you
reported the problem in, but it often means that the bug is fixed so
future version won't have the same problem. That is making a
difference and anything you do to help that process is surely
appreciated by many users and maintainers (even if many of the users
never notice the fixes to bugs they never had the joy of stumbling
upon :).
I will admit some bugzilla reports are resolved but I have never
been that lucky.
You must not have been clicking your heels the proper amount of times
then. You do click your heels when you report a bug, don't you? ;-)
I will go further and explain in what situation it is useless to
bugzilla. When you problem is more or less unique to your system. If
a large fraction on users are having the same problem that your
chances of getting an answer are better.
Yes, it's very difficult for an maintainer or developer to fix a bug
that they cannot reproduce. There's nothing specific about bugzilla
in that problem. It'd be just as difficult of the bug reports went to
a mailing list. :)
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I never forget a face, but in your case I'll be glad to make an
exception.
-- Groucho Marx
3:59 p.m.
On Sun, Aug 26, 2007 at 02:35:01PM -0400, Todd Zullinger wrote:
Aaron Konstam wrote:
> I agree that bugzilla should work but it has never worked for me. I
> file bugzillas and nothing much happens. By the time we get through
> all the requests for further info a new distribution is out and it
> makes no difference.
Perhaps it doesn't end with an updated package for the version you
reported the problem in, but it often means that the bug is fixed so
future version won't have the same problem.
Then the maintainer should close the report and specify the
resolution. That way the reporter knows what's happened. If Aaron's
going to go to the effort of preparing a good bug report, answering
questions, performing experiments, etc. he at least deserves that
courtesy.
You and Rahul seem to want to make things as easy as possible for the
maintainers. I think that's a fine idea. But it's a two way street:
the maintainers can acknowledged reports, work with the reporters, and
resolve the bugs. A "Won't fix" with an explanation of why is better
than leaving it hanging.
> I will go further and explain in what situation it is useless
to
> bugzilla. When you problem is more or less unique to your system. If
> a large fraction on users are having the same problem that your
> chances of getting an answer are better.
Yes, it's very difficult for an maintainer or developer to fix a bug
that they cannot reproduce. There's nothing specific about bugzilla
in that problem. It'd be just as difficult of the bug reports went to
a mailing list. :)
Then the maintainer should try to reproduce it, and if he can't,
report that fact, and ask the reporter for help in reproducing it. If
all else fails, put a sheepish expression on your face, resolve it as
"can't reproduce", and close it. Then at least Aaron will know what
happened to his problem.
--
Charles Curley /"\ ASCII Ribbon Campaign
Looking for fine software \ / Respect for open standards
and/or writing? X No HTML/RTF in email
http://www.charlescurley.com / \ No M$ Word docs in email
Key fingerprint = CE5C 6645 A45A 64E4 94C0 809C FFF6 4C48 4ECD DFDB
3:50 p.m.
Charles Curley wrote:
On Sun, Aug 26, 2007 at 02:35:01PM -0400, Todd Zullinger wrote:
> Perhaps it doesn't end with an updated package for the version you
> reported the problem in, but it often means that the bug is fixed
> so future version won't have the same problem.
Then the maintainer should close the report and specify the
resolution. That way the reporter knows what's happened. If Aaron's
going to go to the effort of preparing a good bug report, answering
questions, performing experiments, etc. he at least deserves that
courtesy.
I don't know the details of the reports Aaron was talking about. He
did say that there was a lengthy exchange asking for info, which leads
me to believe that the maintainer tried to get the needed info.
But yes, I agree that bug reports should be acknowledged and closed
with some reason, even it's "can't reproduce" or something.
You and Rahul seem to want to make things as easy as possible for
the maintainers. I think that's a fine idea. But it's a two way
street: the maintainers can acknowledged reports, work with the
reporters, and resolve the bugs. A "Won't fix" with an explanation
of why is better than leaving it hanging.
Of course. I hope I didn't give the impression that reports should be
ignored. What I do think it worth noting is the sheer number of
reports and the limit on hours per day. Most maintainers aren't paid
to work on Fedora packages, so it seems quite reasonable to expect
that a user wanting a bug fixed be patient and understanding if their
bug doesn't get the attention they would like.
I only recently started to maintain a few packages so I don't have
piles of bug reports to deal with as some maintainers do. I certainly
intend to reply to every bug report that is filed on any of my
packages, but I know that other maintainers with heavier workloads may
not be able to do that. What can really help in those cases are
volunteers to do some triaging of bugs to weed out duplicates and ask
for more info from reports that lack enough detail to enable proper
debugging[1].
Basically, since this is a mostly volunteer effort, I get a little
defensive when anyone has too many expectations from the volunteers.
(I'm not saying that you do, so please don't take that personally. :)
[1] http://fedoraproject.org/wiki/BugZappers
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Things in our country run in spite of government, not by aid of it.
-- Will Rogers
5:44 p.m.
On Sun, Aug 26, 2007 at 04:50:17PM -0400, Todd Zullinger wrote:
Charles Curley wrote:
> On Sun, Aug 26, 2007 at 02:35:01PM -0400, Todd Zullinger wrote:
I don't know the details of the reports Aaron was talking about. He
did say that there was a lengthy exchange asking for info, which leads
me to believe that the maintainer tried to get the needed info.
But yes, I agree that bug reports should be acknowledged and closed
with some reason, even it's "can't reproduce" or something.
Fair enough.
> You and Rahul seem to want to make things as easy as possible for
> the maintainers. I think that's a fine idea. But it's a two way
> street: the maintainers can acknowledged reports, work with the
> reporters, and resolve the bugs. A "Won't fix" with an explanation
> of why is better than leaving it hanging.
Of course. I hope I didn't give the impression that reports should be
ignored. What I do think it worth noting is the sheer number of
reports and the limit on hours per day. Most maintainers aren't paid
to work on Fedora packages, so it seems quite reasonable to expect
that a user wanting a bug fixed be patient and understanding if their
bug doesn't get the attention they would like.
I only recently started to maintain a few packages so I don't have
piles of bug reports to deal with as some maintainers do.
I have had such piles, although not with Fedora. My advice: learn how
to triage them, and how to move them along. Do not get behind; it will
kill you. It's also rude to the reporter.
I certainly intend to reply to every bug report that is filed on any
of my packages,
I appreciate that; I hope the good intentions last. As you are a
volunteer (so I take it), don't take on more than you can chew, and
leave yourself some slack. That's advice I've been giving volunteers
and paid employees for damn near half a century now, and its good
advice.
but I know that other maintainers with heavier workloads may
not be able to do that. What can really help in those cases are
volunteers to do some triaging of bugs to weed out duplicates and ask
for more info from reports that lack enough detail to enable proper
debugging[1].
OK, I've worked as a paid professional on the receiving end of bug
systems similar to bugzilla. Sorry, but from that experience I'm
skeptical of the bug zappers. I think it is part of the maintainer's
job to do that stuff. I'm glad to see it proposed and I hope it
prospers. The work definitely needs to be done!
Is there a document anywhere that details what a maintainer should
expect from bugzilla and reporters, how to go about using the system,
etc. For example, a document that gives circumstances under which one
would mark a bug as "will not fix", and steps to take prior to doing
so. An ops manual, if you will, for bugzilla?
Yeah, I know: this is FOSS: Read the Source.
Basically, since this is a mostly volunteer effort, I get a little
defensive when anyone has too many expectations from the volunteers.
(I'm not saying that you do, so please don't take that personally. :)
Understandable, and not taken personally.
[1] http://fedoraproject.org/wiki/BugZappers
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Things in our country run in spite of government, not by aid of it.
-- Will Rogers
--
fedora-list mailing list
fedora-list(a)redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
--
Charles Curley /"\ ASCII Ribbon Campaign
Looking for fine software \ / Respect for open standards
and/or writing? X No HTML/RTF in email
http://www.charlescurley.com / \ No M$ Word docs in email
Key fingerprint = CE5C 6645 A45A 64E4 94C0 809C FFF6 4C48 4ECD DFDB
1:20 p.m.
Charles Curley wrote:
> I only recently started to maintain a few packages so I don't
have
> piles of bug reports to deal with as some maintainers do.
I have had such piles, although not with Fedora. My advice: learn
how to triage them, and how to move them along. Do not get behind;
it will kill you. It's also rude to the reporter.
Very true. Sometimes reality and other factors step in and keep that
truth from being followed. :)
> I certainly intend to reply to every bug report that is filed on
> any of my packages,
I appreciate that; I hope the good intentions last. As you are a
volunteer (so I take it), don't take on more than you can chew, and
leave yourself some slack. That's advice I've been giving volunteers
and paid employees for damn near half a century now, and its good
advice.
Indeed it's good advice. I've volunteered in a few places over the
years and have watched many people join, push hard, burn out, and
disappear. A lot of people can sprint, few can run marathons.
I'm particularly good at not taking on too much (some would say I'm a
little too good at it ;).
OK, I've worked as a paid professional on the receiving end of
bug
systems similar to bugzilla. Sorry, but from that experience I'm
skeptical of the bug zappers. I think it is part of the maintainer's
job to do that stuff. I'm glad to see it proposed and I hope it
prospers. The work definitely needs to be done!
I see it as much like a good secretary, who acts as a filter. That
way the boss only has to deal with the important things without
weeding out duplicate information and other useless info.
Is there a document anywhere that details what a maintainer should
expect from bugzilla and reporters, how to go about using the
system, etc. For example, a document that gives circumstances under
which one would mark a bug as "will not fix", and steps to take
prior to doing so. An ops manual, if you will, for bugzilla?
I'm sure there are various pieces of this on the Fedora wiki and in
the mailing list archives. I don't have any links off the top of my
head. In bugzilla itself, the various states a bug can be in are
described at https://bugzilla.redhat.com/page.cgi?id=bug_status.html
I've seen discussion about a maintainer responsibility document, but I
don't think anything solid exists yet.
To bring this discussion back to the topic of mantis a bit, I
installed the package last night and got it working (in a little over
the 20-30 minutes that the mantis docs say it should take). I don't
think that the package is hopelessly broken, but there are a few
things that could definitely be fixed up to provide a better user
experience. Here are some notes of what I ran into, some of which I
think are what bit you (mostly the Apache Allow/Deny rules):
1) php-mysql missing -- should this be required? It seems that
technically it isn't, but it makes for an unusable default. At the
least, the php-mysql package should be noted in the README.Fedora
file. The package changelog indicates that the dependency was
removed a long time ago (version 0.19.2-1) because the package can
be used with PostgreSQL as well.
2) Apache rules use "Allow from localhost", but seem to fail with the
default hosts file that specifies localhost.localdomain as the
canonical hostname. Using allow from 127.0.0.1 worked out better
for me, and seems to be what the other web app packages I have
installed use.
3) mantis 1.0.8 has a bug that keeps the initial db creation from
working. See http://www.mantisbt.org/bugs/view.php?id=8256 for a
report and patch. This should get added to the Fedora package
until a 1.0.9 release is made upstream.
4) SELinux generated an error when trying to send a password reminder:
type=AVC msg=audit(1188186921.311:669): avc: denied { read } for pid=3974
comm="sh" name="sendmail.postfix" dev=sda2 ino=216037
scontext=user_u:system_r:httpd_t:s0 tcontext=system_u:object_r:sendmail_exec_t:s0
tclass=file
I disabled SELinux before using the package much further, so I
don't know if there are other SELinux issues lurking. It may only
occur with Postfix, I don't know.
Aside from that, I had a seemingly usable[1] mantis install in a
reasonable amount of time. With the Apache allow/deny rules setup it
is probably a little more secure than just unpacking the upstream
tarball in /var/www/html. But that security definitely caused me the
most hassle in working out why I was getting access denied errors. I
didn't think Apache was that strict with the hostnames used.
I reported these issues at:
https://bugzilla.redhat.com/show_bug.cgi?id=257561
Please feel free to add anything that I missed. :)
[1] For some definition of usable (I'm not a mantis lover myself.)
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From there to here, from here to there, funny things are everywhere.
-- Dr. Seuss, One Fish Two Fish, Red Fish Blue Fish
11:18 p.m.
On Mon, 2007-08-27 at 14:20 -0400, Todd Zullinger wrote:
2) Apache rules use "Allow from localhost", but seem to
fail with the
default hosts file that specifies localhost.localdomain as the
canonical hostname. Using allow from 127.0.0.1 worked out better
for me, and seems to be what the other web app packages I have
installed use.
I'm not a user of Mantis, but I do use Apache a lot. I've never had any
problems with it using "localhost". The normal /etc/hosts file lists
the Linuxism "localhost.localdomain" and has the standard 'localhost"
as
an alias, that's good enough for Apache. You'd have to have some real
name resolution problems for that to fail.
Having said that, using allow or deny with a hostname/domain-name does
mean that every access has to have a name lookup done (results are
cached, though). Whereas using an IP (with or without netmask
wildcarding) avoids that step, but means you can't easily apply such
rules to hosts that change IPs dynamically.
--
[tim@bigblack ~]$ uname -ipr
2.6.22.1-41.fc7 i686 i386
Using FC 4, 5, 6 & 7, plus CentOS 5. Today, it's FC7.
Don't send private replies to my address, the mailbox is ignored.
I read messages from the public lists.
11:47 p.m.
Tim wrote:
On Mon, 2007-08-27 at 14:20 -0400, Todd Zullinger wrote:
> 2) Apache rules use "Allow from localhost", but seem to fail with
> the default hosts file that specifies localhost.localdomain as the
> canonical hostname. Using allow from 127.0.0.1 worked out better
> for me, and seems to be what the other web app packages I have
> installed use.
I'm not a user of Mantis, but I do use Apache a lot. I've never had
any problems with it using "localhost". The normal /etc/hosts file
lists the Linuxism "localhost.localdomain" and has the standard
'localhost" as an alias, that's good enough for Apache. You'd have
to have some real name resolution problems for that to fail.
I'm not sure what I've got wrong then. If I change /etc/hosts to:
127.0.0.1 localhost localhost.localdomain
it works. If localhost.localdomain is the canonical name in
/etc/hosts, I get denied.
I added a localhost.localdomain zone to my local DNS and things still
wouldn't work. (I'd previously only had a localhost zone.)
Commenting out the localhost entry in /etc/hosts didn't work either.
Care to test this out and let me know if it's just me (and Charles)
with this problem? I created /etc/httpd/conf.d/test.conf with the
following content:
Alias /tmp /tmp
<Directory /tmp>
Options Indexes
Order deny,allow
Deny from all
#Allow from 127.0.0.1
#Allow from localhost
#Allow from localhost.
#Allow from localhost.localdomain
</Directory>
In /etc/hosts:
127.0.0.1 localhost.localdomain localhost
I am able to browse to http://localhost/tmp/ with either the 127.0.0.1
or localhost.localdomain allow lines uncommented. Neither the
localhost nor localhost. allowed me to access the URL.
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The average woman would rather be beautiful than smart because the
average man can see better than he can think.
7:21 a.m.
On Tue, 2007-08-28 at 00:47 -0400, Todd Zullinger wrote:
I'm not sure what I've got wrong then. If I change
/etc/hosts to:
127.0.0.1 localhost localhost.localdomain
it works. If localhost.localdomain is the canonical name in
/etc/hosts, I get denied.
Using your examples, I found the same. I've not done this with FC7's
Apache before, but I've certainly used localhost without any problems,
with Apache on prior Fedora releases. I keep forgetting that the server
is still on FC4.
There's something screwy, here. With that line, if I try to find the IP
for either name, I should be told it. And I am, either will resolve.
If I try to find the name for that IP, I'll be told the first one.
Apache acts like it's doing a double lookup (names to IPs and back
again).
The expected behaviour:
Set Apache to allow from localhost.
Try browsing http://localhost/ from localhost.localdomain.
The check should find out the IP for the localhost.localdomain and see
if it's the same IP for localhost.
I added a localhost.localdomain zone to my local DNS and things
still
wouldn't work. (I'd previously only had a localhost zone.)
I've got both, I've had them that way since my nameserver was set up on
FC4.
I don't know if IPv6 muddies the waters...
[root@bigblack conf]# host localhost
localhost has address 127.0.0.1
localhost has IPv6 address ::1
[root@bigblack conf]# host localhost.localdomain
localhost.localdomain has address 127.0.0.1
Commenting out the localhost entry in /etc/hosts didn't work
either.
Care to test this out and let me know if it's just me (and Charles)
with this problem? I created /etc/httpd/conf.d/test.conf with the
following content:
Alias /tmp /tmp
<Directory /tmp>
Options Indexes
Order deny,allow
Deny from all
#Allow from 127.0.0.1
#Allow from localhost
#Allow from localhost.
#Allow from localhost.localdomain
</Directory>
In /etc/hosts:
127.0.0.1 localhost.localdomain localhost
I am able to browse to http://localhost/tmp/ with either the 127.0.0.1
or localhost.localdomain allow lines uncommented. Neither the
localhost nor localhost. allowed me to access the URL.
Confirmed.
Personally, I've always avoided using localhost. About the only time I
do is when browsing the CUPS configuration server. Otherwise, I
normally use the name of the machine to browse to, and IPs in the Apache
restrictions.
--
[tim@bigblack ~]$ uname -ipr
2.6.22.1-41.fc7 i686 i386
Using FC 4, 5, 6 & 7, plus CentOS 5. Today, it's FC7.
Don't send private replies to my address, the mailbox is ignored.
I read messages from the public lists.
12:11 a.m.
Tim wrote:
On Tue, 2007-08-28 at 00:47 -0400, Todd Zullinger wrote:
> I'm not sure what I've got wrong then. If I change /etc/hosts to:
>
> 127.0.0.1 localhost localhost.localdomain
>
> it works. If localhost.localdomain is the canonical name in
> /etc/hosts, I get denied.
Using your examples, I found the same.
Thank you much for checking this. :)
I've not done this with FC7's Apache before, but I've
certainly used
localhost without any problems, with Apache on prior Fedora
releases. I keep forgetting that the server is still on FC4.
Yeah, I don't use the "allow from" with a name anywhere that I can
recall, so I'd never run into this. I'll have to try it on some older
Apache servers to see if it behaves differently. It sure seems like a
bug somewhere.
RFC1912 (the text of which can be found in the caching-nameserver rpm
docs as rfc1912.txt, or at http://www.ietf.org/rfc/rfc1912.txt), says
this about localhost:
The "localhost" address is a "special" address which always refers
to
the local host. It should contain the following line:
localhost. IN A 127.0.0.1
The "127.0" file should contain the line:
1 PTR localhost.
There has been some extensive discussion about whether or not to
append the local domain to it. The conclusion is that "localhost."
would be the best solution. The reasons given include:
"localhost" by itself is used and expected to work in some
systems.
Translating 127.0.0.1 into "localhost.dom.ain" can cause some
software to connect back to the loopback interface when it didn't
want to because "localhost" is not equal to
"localhost.dom.ain".
Now, I may very well be overlooking other relevant RFC's, but the
above reads to me like the default /etc/hosts entry which sets
127.0.0.1 to localhost.localdomain is causing the sort of problems
that they're warning about. I don't know. Maybe Apache tightened up
some of the rules used to process names used in "allow from"
directives.
> I added a localhost.localdomain zone to my local DNS and things
> still wouldn't work. (I'd previously only had a localhost zone.)
I've got both, I've had them that way since my nameserver was set up
on FC4.
I hadn't changed mine since sometime in 2001. So I figured times must
have changed and I updated my zone info. :)
I don't know if IPv6 muddies the waters...
I have IPv6 disabled here, with neither any zones configured in DNS
nor entries in /etc/hosts. Funny enough, one of the mantis
maintainers wondered if that might have some affect on things as well.
Thanks again for taking the time to test this out and confirm that it
breaks for you as well as it does for Charles and me.
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Be who you are and say what you feel because those who mind don't
matter and those who matter don't mind.
-- Dr Seuss, "Oh the Places You'll Go"
4:49 p.m.
On Sun, Aug 26, 2007 at 01:40:57PM -0400, Todd Zullinger wrote:
You may well know what the package to maintainer ratio is in Fedora.
If not, it's rather large, with nearly 4700 source packages in the
distro and a little other 400 maintainers. I don't think it's all
that unreasonable to ask that users help out by reporting bugs to
bugzilla.
I do understand your hesitation of the package seems so full of bugs
that it's pointless. However, if that doesn't get bugzilla'd, then
other maintainers may not find out for a while that something is
horribly awry in the mantis package and that someone needs some help
(or a smack with the cluestick). So, a bugzilla may be the most
helpful thing you could do for a terribly broken package, even if it
just says that there are numerous problems (listing them briefly)
with the package and the whole things needs work.
Todd, the whole open source bazaar is a multi-lateral trade area, as
the term bazaar suggests. Most of us are not in this out of the
kindness or our hearts, but because we want to get something done. I
went to install the Mantis RPM because I wanted to get something
done. I hit a problem. Instead of tossing the RPM and installing the
tarball, I asked on the list. I made a good faith effort to look at
the suggestions I got, and none of those panned out. I decided I had
done my due dilligence for the community, and have now installed the
tarball.
It may not be unreasonable to ask, but I just determined that in this
instance the answer was "no".
> As for following every single thread, that's a straw man
argument.
> It isn't hard to write a filter to make emails with certain key
> words (e.g. "mantis") jump out at you.
Bugzilla has the advantage that it mails the maintain automatically
and that the conversations there are more easily searchable on various
fields.
I think you should view it as a plus that some maintainers do take the
time to follow this list, not as a negative that all of them don't.
And always keep in mind that since the OS and all the work to create
it are given to you for free, it's not that much to ask for you to
report problems in the place that's most accommodating to the
maintainer. (And I'm not saying that you don't report things to
bugzilla personally. I know from my own little travels in bugzilla
that isn't true. :)
Thanks for the parenthetical acknowledgement. Everyone has to
determine for themselves what contributions they will make to the
community. I doubt very much I know all of yours, and you may not know
all of mine. Nor do we need any central Soviet telling us, "Comrade
Zullinger, you haven't written enough lines of free software this
week. Back to your terminal!" So if you don't mind, I will determine
whether something is "that much to ask" of me.
I'd read your mails and thought about trying to take a look at getting
the rpm to see what might be broken with it. I do detest mantis as a
user. I've hated having to interact with it every time I've reported
a bug to an upstream that used it. So I figured I'd wait and see if
someone else helped you out before putting myself through some likely
pain. ;-)
Thanks for the thought. No-one has to do anything on this list, except
maybe the paid employees whose duties encompass such things.
> And another thought, Rahul: maintainers can ignore bugzilla entries
> same as they can emails. I've had one bug (189120) oustanding since
> 2006-04-17, and no-one has yet taken ownership, never mind actually
> done anything about it.
That is certainly true. Just because someone maintains a package
doesn't mean that they do it well. Having things in bugzilla though
makes it easier to find those lax maintainers and give them the help
(or kick) that they need. Other folks can run reports on bugzilla to
find which maintainers have been unresponsive to bugs. Then, if it's
appropriate, there's the AWOL maintainer process for those folks that
just stop responding to bugs/updates/needed changes in their packages.
That's a good point.
(In the case of the above bug, it's also possible that it was fixed in
a newer gnome release and it just didn't get closed properly.
Nope, hasn't been fixed as far as I know. Sorry, I thought that was
implied when I described the bug as "outstanding" rather than "still
open".
It may also have gotten lost in the forest of desktop bugs.
It's
assigned to Ray Strode who isn't someone I'd consider a lax
maintainer. He does a lot of work with upstream gnome projects and
within the Fedora desktop team. So I'd guess the lack of response
there is due to the latter.
As you say, probably an upstream bug. Given the likely nature of the
problem, I doubt it's a packaging issue. Speaking of "too much to
ask", could Mr. Strode enter the upstream issue number or URL and mark
the bug appropriately?
He hasn't even taken ownership, so I have no reason to believe he has
reported it upstream.
)
--
Charles Curley /"\ ASCII Ribbon Campaign
Looking for fine software \ / Respect for open standards
and/or writing? X No HTML/RTF in email
http://www.charlescurley.com / \ No M$ Word docs in email
Key fingerprint = CE5C 6645 A45A 64E4 94C0 809C FFF6 4C48 4ECD DFDB
4:36 p.m.
Charles Curley wrote:
Todd, the whole open source bazaar is a multi-lateral trade area, as
the term bazaar suggests. Most of us are not in this out of the
kindness or our hearts, but because we want to get something done.
I'm immediately suspect of anyone that claims to do anything purely
for altruistic reasons. I think there's always a benefit to the giver
as well. But that's a bit of a philosophical tangent. :)
I went to install the Mantis RPM because I wanted to get something
done. I hit a problem. Instead of tossing the RPM and installing the
tarball, I asked on the list. I made a good faith effort to look at
the suggestions I got, and none of those panned out. I decided I had
done my due dilligence for the community, and have now installed the
tarball.
It may not be unreasonable to ask, but I just determined that in
this instance the answer was "no".
Fair enough.
I sincerely hope I didn't come across as shitting on you for not
reporting it to bugzilla.
> I think you should view it as a plus that some maintainers do
take
> the time to follow this list, not as a negative that all of them
> don't. And always keep in mind that since the OS and all the work
> to create it are given to you for free, it's not that much to ask
> for you to report problems in the place that's most accommodating
> to the maintainer. (And I'm not saying that you don't report
> things to bugzilla personally. I know from my own little travels
> in bugzilla that isn't true. :)
Thanks for the parenthetical acknowledgement. Everyone has to
determine for themselves what contributions they will make to the
community. I doubt very much I know all of yours, and you may not
know all of mine. Nor do we need any central Soviet telling us,
"Comrade Zullinger, you haven't written enough lines of free
software this week. Back to your terminal!"
Hehe. I try to bail quickly from places that bark orders at me.
So if you don't mind, I will determine whether something is
"that
much to ask" of me.
Nope, I don't mind at all (in fact, I'd prefer that you determine
that). I hope I didn't give the wrong impression in my replies. The
thing that spurred me to write is the part about expecting maintainers
to be subscribed here. That's similar to expecting all users to
report all bugs to bugzilla (perhaps a little worse IMHO, since the
signal to noise ratio here is much lower than it is in bugzilla :).
And since there are more users than maintainers here, the side of the
maintainers is in more need of stating now and again.
Thanks for the thought. No-one has to do anything on this list,
except maybe the paid employees whose duties encompass such things.
Indeed. I'm curious about it now and if other tasks don't fill my
time and distract me, I may well poke into the mantis package a bit.
If it's really fubar'd, it should be fixed or removed. It'd be far
better to have you not find the package than to find it and waste an
hour or more before just installing the tarball.
I know nothing about mantis though, so I wonder if it could be the
sort of package like mailman, where there is a lot that needs to be
done after installing the package before it will work? If so, there
should be a fedora specific readme somewhere that explains such steps.
> (In the case of the above bug, it's also possible that it was
fixed in
> a newer gnome release and it just didn't get closed properly.
Nope, hasn't been fixed as far as I know. Sorry, I thought that was
implied when I described the bug as "outstanding" rather than "still
open".
I just didn't guess that you were being so specific with your wording
(you damn writers ;). If it's still an issue with new versions, then
the report could be updated to note that it still applies to f7.
Otherwise it may end up getting closed when someone comes along and
auto-closes bugs from older releases*. And changing the release
version along with a comment something like "Ping! This is still a
problem, any news?" may reach Ray at a moment when he can reply or
look into it. (And to be clear, that's just a suggestion, I'm not
saying you need to do this. :)
* I do think that if and when such bugs are closed, they generate a
message to the reporter (and others on the CC list) that if they
still apply to a current release, to reopen and change the release.
As you say, probably an upstream bug. Given the likely nature of the
problem, I doubt it's a packaging issue. Speaking of "too much to
ask", could Mr. Strode enter the upstream issue number or URL and
mark the bug appropriately?
Perhaps. It may already be in the gnome bugzilla. It'd just take
someone to search there and tag the rh bugzilla appropriately. Ray
may or may not have time to do that (I don't know him personally.)
I think that generally, if a bug is likely to be an upstream bug (not
a distro-specific or packaging bug), that it should be reported
upstream directly. That way it can be addressed and fixed upstream
for all distros to pick up when an update occurs. Who knows, maybe
the bug you reported has been fixed by another distro maintainer and
no one has yet reported it upstream so we can all get the fix.
He hasn't even taken ownership, so I have no reason to believe
he
has reported it upstream.
Sometimes this can be caused by bugs getting reassigned as teams at
RedHat change members. I'm not saying the bug shouldn't get
acknowledged or anything, just offering a possibly reasonable
explanation for why it's gone so long without even being assigned.
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I am in shape. Round is a shape.
6:17 p.m.
New subject: Bugzilla and management thereof
On Sun, Aug 26, 2007 at 05:36:10PM -0400, Todd Zullinger wrote:
Charles Curley wrote:
Fair enough.
I sincerely hope I didn't come across as shitting on you for not
reporting it to bugzilla.
You didn't. Others in other fora have been less polite. I was reacting
to them and took it out on you. Sorry about that.
> "Comrade Zullinger, you haven't written enough lines of
free
> software this week. Back to your terminal!"
Hehe. I try to bail quickly from places that bark orders at me.
Good. We need more people who will do that.
> So if you don't mind, I will determine whether something is "that
> much to ask" of me.
Nope, I don't mind at all (in fact, I'd prefer that you determine
that). I hope I didn't give the wrong impression in my replies. The
thing that spurred me to write is the part about expecting maintainers
to be subscribed here. That's similar to expecting all users to
report all bugs to bugzilla (perhaps a little worse IMHO, since the
signal to noise ratio here is much lower than it is in bugzilla :).
It didn't occur to me that someone who maintained one or more packages
for Fedora wouldn't also use it, and so wouldn't be on this
list. Really.
And since there are more users than maintainers here, the side of the
maintainers is in more need of stating now and again.
Yup. Which side you are getting to learn.
> Thanks for the thought. No-one has to do anything on this list,
> except maybe the paid employees whose duties encompass such things.
Indeed. I'm curious about it now and if other tasks don't fill my
time and distract me, I may well poke into the mantis package a bit.
If it's really fubar'd, it should be fixed or removed. It'd be far
better to have you not find the package than to find it and waste an
hour or more before just installing the tarball.
I know nothing about mantis though, so I wonder if it could be the
sort of package like mailman, where there is a lot that needs to be
done after installing the package before it will work? If so, there
should be a fedora specific readme somewhere that explains such steps.
There is a Fedora specific README which outlines a short process to go
through. I followed it, to no avail.
(Such documents should be mentioned in the description field of the
spec so installers know they exist, but that's another tirade!)
>> (In the case of the above bug, it's also possible that it was fixed in
>> a newer gnome release and it just didn't get closed properly.
>
> Nope, hasn't been fixed as far as I know. Sorry, I thought that was
> implied when I described the bug as "outstanding" rather than "still
> open".
I just didn't guess that you were being so specific with your wording
(you damn writers ;). If it's still an issue with new versions, then
the report could be updated to note that it still applies to f7.
Otherwise it may end up getting closed when someone comes along and
auto-closes bugs from older releases*. And changing the release
version along with a comment something like "Ping! This is still a
problem, any news?" may reach Ray at a moment when he can reply or
look into it. (And to be clear, that's just a suggestion, I'm not
saying you need to do this. :)
Good point.
* I do think that if and when such bugs are closed, they generate a
message to the reporter (and others on the CC list) that if they
still apply to a current release, to reopen and change the release.
I believe bugzilla sends an email, but don't recall the contents. I
have reopened bugs under such circumstances but don't remember if they
were in RH's bugzilla or elsewhere.
> As you say, probably an upstream bug. Given the likely nature of the
> problem, I doubt it's a packaging issue. Speaking of "too much to
> ask", could Mr. Strode enter the upstream issue number or URL and
> mark the bug appropriately?
Perhaps. It may already be in the gnome bugzilla. It'd just take
someone to search there and tag the rh bugzilla appropriately. Ray
may or may not have time to do that (I don't know him personally.)
Ah, I was assuming that if Ray decided it was an upstream bug he'd
file in their bugzilla (and search prior to filing, etc.). In that
case, he'd know the number.
I think that generally, if a bug is likely to be an upstream bug (not
a distro-specific or packaging bug), that it should be reported
upstream directly. That way it can be addressed and fixed upstream
for all distros to pick up when an update occurs. Who knows, maybe
the bug you reported has been fixed by another distro maintainer and
no one has yet reported it upstream so we can all get the fix.
I had understood that Fedora preferred such bugs to be filed in RH's
bugzilla and if necessary the maintainer would file upstream. I don't
recall where I got that, and it may have changed since I did.
I would think the packager, especially a person who is both
maintaining a package and actively contributing to the upstream
project, would be in a better position to determine whether to report
upstream than an end user.
> He hasn't even taken ownership, so I have no reason to believe he
> has reported it upstream.
Sometimes this can be caused by bugs getting reassigned as teams at
RedHat change members. I'm not saying the bug shouldn't get
acknowledged or anything, just offering a possibly reasonable
explanation for why it's gone so long without even being assigned.
When someone owning bugs leaves a team, he (or his manager)
mass-assigns his bugs to a special management account specifically for
the purpose. When someone new comes in or someone else is assigned a
package to maintain, management then assigns that person bugs from the
special account. Been there, done that.
I know there are other ways bugs can slip through the cracks. I've
probably committed a few of them myself. Good management processes
minimize that sort of thing.
--
Charles Curley /"\ ASCII Ribbon Campaign
Looking for fine software \ / Respect for open standards
and/or writing? X No HTML/RTF in email
http://www.charlescurley.com / \ No M$ Word docs in email
Key fingerprint = CE5C 6645 A45A 64E4 94C0 809C FFF6 4C48 4ECD DFDB
6:40 p.m.
Charles Curley:
> And another thought, Rahul: maintainers can ignore bugzilla
entries
> same as they can emails. I've had one bug (189120) oustanding since
> 2006-04-17, and no-one has yet taken ownership, never mind actually
> done anything about it.
Todd Zullinger:
That is certainly true. Just because someone maintains a package
doesn't mean that they do it well. Having things in bugzilla though
makes it easier to find those lax maintainers and give them the help
(or kick) that they need. Other folks can run reports on bugzilla to
find which maintainers have been unresponsive to bugs. Then, if it's
appropriate, there's the AWOL maintainer process for those folks that
just stop responding to bugs/updates/needed changes in their
packages.
Third parties do read bugzilla entries, sometimes trying to solve their
own problems, rather than use the mailing lists (full of other stuff,
that they're not interested in). You'll even see patches supplied, from
time to time, as well as other solutions.
--
[tim@bigblack ~]$ uname -ipr
2.6.22.1-41.fc7 i686 i386
Using FC 4, 5, 6 & 7, plus CentOS 5. Today, it's FC7.
Don't send private replies to my address, the mailbox is ignored.
I read messages from the public lists.
2:25 p.m.
On Sun, 2007-08-26 at 05:22 -0600, Charles Curley wrote:
On Sun, Aug 26, 2007 at 03:09:58AM +0530, Rahul Sundaram wrote:
> Charles Curley wrote:
> >On Sat, Aug 25, 2007 at 03:06:08PM -0600, Charles Curley wrote:
> >>On Sat, Aug 25, 2007 at 01:49:51PM -0600, Charles Curley wrote:
> >>>On Fri, Aug 24, 2007 at 11:53:11AM +0930, Tim wrote:
> >>>>On Thu, 2007-08-23 at 14:10 -0600, Charles Curley wrote:
> >>>>>I just installed mantis (mantis-1.0.8-1.fc7.noarch et al.). I
turned
> >>It took me under an hour to install from tarball and set up several
> >>accounts, projects, etc.
> >
> >Oh, and in the process of doing so I found out that the RPM is missing
> >a dependency: php-mysql, which pulls in php-pdo.
>
> Do file a bug report.
No, Rahul, I will not follow a bug report, for two reasons.
* If the maintainer is not already aware of the problem from reading
this thread, then he doesn't give enough of a damn for me to spend
any more time on it.
* The package is so pathetically broken (see earlier in this thread)
that the lack of the php-mysql package is irrelevant, another reason
to believe that the maintainer doesn't give a damn.
Your signature says that you do fine software and writing? I find this
a bit hard to
believe given your comments above.
Regards,
Les H
12:10 a.m.
On Sat, 2007-08-25 at 13:49 -0600, Charles Curley wrote:
<Directory /usr/share/mantis>
# As passwords will be sent over the line do not allow plaintext
# communication
SSLRequireSSL
Have you got SSL set up? The above requirement refuses non HTTPS access
to this directory (i.e. HTTP won't work, it'll have to be HTTPS). So
you'll need to have HTTPS access working, which is a separate
configuration.
e.g. Does <https://localhost.localdomain/> work? (Ignoring Mantis, for
the moment.)
You can expect a warning about the certificate not being trustworthy, as
it's not signed by any endorsed body. But after that step (the warning,
and temporarily accepting it), can you get a webpage?
--
[tim@bigblack ~]$ uname -ipr
2.6.22.1-41.fc7 i686 i386
Using FC 4, 5, 6 & 7, plus CentOS 5. Today, it's FC7.
Don't send private replies to my address, the mailbox is ignored.
I read messages from the public lists.
6136
days inactive
6142
days old
26 comments
6 participants
participants (6)
-
Aaron Konstam -
Charles Curley -
Howard Howell -
Rahul Sundaram -
Tim -
Todd Zullinger