[lm-sensors] project status and future

[lm-sensors] project status and future

[Rudolf Marek]

Hello all,

In this holiday time most of us is resting and maybe thinking about the future plans
for a new year. Maybe you want to do something for other people, to help, to support,
simply to create something that will help other people. Well as you will read further
here is your chance ;)

Executive summary is bellow the article ;)

I would like to write here few notes and visions about lm-sensors project. Let me begin
with current state. The project is managed by Jean Delvare, who also maintains the kernel
part of the project. He is doing his job very well and I would like to thank him very much for this effort.

He always tries hard to go through every single byte of C source and find out if code will work in all cases as
expected. Well this review work is very hard and takes a lot of time in magintude of hours just to review
single patch. He also manages the stack of patches that he accepted and  pushes them to kernel. Of course
he must keep everything in sync. As the project leader he must resolve all issues that are in question,
architectural and implemntation specific. This also takes some time to think out.

He is doing his work very well but he is quite overloaded, so please dont blame him for not reviewing your work
for some time or dont expect that you will receive polite answer to some obvious question. He is only a human
and after 8 hours in regular job is quite difficult not to be tired. You might thing there is a weekend too.
Well there is but even developers want to have a social life :), and rememeber there should be some time
that is devoted to actual coding and thoughts about the future plans. This all is hard to do when you dont
have time, because you must solve all other issues - but  not for different project but for this project.

This was just a first part, the patches. We have also different work. We call them "support questions". Maybe
this is why you are on the list. You came with question but you left yourself subscribed.

Handling the user questions is mainly my "job" I'm trying to help them as much I can, sometimes I win, sometimes
not. We have also a support system on our pages but it is quite unfonfortable for our needs. The answers are written
by me or Jean, and it takes tenth of minutes to reply single one.

Time is my enemy too. I'm finishing university -> master thesis, have already part time jobs... So I cant spend
so much time for this project as I want. Things will go better like round end of February but I'm having hard time now.
I had to stop my theora optimization work because I simply dont have more free time left.

Well this is the end of "active" team. We have some hidden staff, that helps us run the list and website.
I would like to thank Philip Edelbrock and Axel Thimm (iirc) for their efforts.

We have here also past developers of the project and they do help when
they can, but as we all are busy with other stuff and by defintion of past developers lm-sensors is now not
their main project. I would like to thank them for a help too, most notably to Mark Hoffman and Mark Studebaker.

And then we have you and next like 150 of others on the list. Well I know that some of you is trying to help, when
it comes to some work you preiously did. Yeah it is good, but as you can see it is simply not enough.

We have some visions and plans for a future but we cant turn them into reality because we are burried with "must do"
work then will never ever stop to come.

We need your help with our work so we can go for future!

And the future plans that are PITA for now:

1) new support system, - (it died previously and never has been finished)
2) new userspace library - new config file system and all stuff around.
3) wiki like pages, so other people can contribute to sensors know-how -> it should "concentrate" our wisdom
   and wisdom from mailing list.
Pi) configuration file repository - this can hide in wiki as first step.
4) patches that were not included in mainline simply because Jean did not have time to handle them :(
5) and many others ...(multiplexed bus handling, driver cleanup, decode-dimms update... etc etc)
(hope I did not forget something)


Well thats it. If you have some free time and willing to help with someting mentioned here, please reply to
this mail and we can discuss further. I also would like to hear what you wish to change and how we should
change...

Executive summary:

Please join us and help to maintain/create even better project!

We need help with:
1) with this new projects
2) with the support
3) With the reviews

Thank you all for staying with us on ML.

Regards
Rudolf

PS: sorry for the long email and my english, this was written just with one and half pass and it came directly from
my mind.

[lm-sensors] project status and future

[Michael Renzmann]

Hi.

On Sun, 2005-12-25 at 23:33 +0100, Rudolf Marek wrote:
> And the future plans that are PITA for now:
> 
> 1) new support system, - (it died previously and never has been finished)
> 2) new userspace library - new config file system and all stuff around.
> 3) wiki like pages, so other people can contribute to sensors know-how -> it should "concentrate" our wisdom
>    and wisdom from mailing list.
> Pi) configuration file repository - this can hide in wiki as first step.
> 4) patches that were not included in mainline simply because Jean did not have time to handle them :(
> 5) and many others ...(multiplexed bus handling, driver cleanup, decode-dimms update... etc etc)
> (hope I did not forget something)

I want to suggest a tool that covers several of these items. But first a
few words on the background:

I'm working on the MadWifi project [1], a Linux driver for Atheros-based
WLAN cards. Our project used to be hosted on sf.net, but aside from the
CVS and the mailing lists we didn't make use of the other tools they
provide (such as the bug/wishlist/patch trackers), due to a decision of
the original maintainer. Everything was managed via the mailing lists,
which made it very hard to keep track on the current state of an issue,
for example. Submitted patches and good bug reports got virtually lost,
things like that. Long story short: the situation was a mess.

At that time we decided to make use of Trac [2], a tool for managing
small projects. It integrates a powerful Wiki engine (based on
MoinMoin), an issue tracker, a web-based frontend to the (Subversion)
code repository and "milestone" management. It's not feature-overloaded,
making it easy to use for administrators as well as users.

The only possible down-side of Trac: it requires making use of
Subversion rather than CVS. For us that was no problem, since we already
planned to do this switch anyway, but it might be a hurdle for other
projects. 

We're working with Trac for about two months now, and it's a great tool.
It helped us to free up resources, keeping better oversight on
outstanding issues / patches / requests and making it easier to maintain
the documentation. We don't want to miss it anymore, and it was worth
all the related hazzle of moving to a new server and a new scm.


Some words on how we handle some of the above mentioned items in our
project:

All our documentation is kept in the Wiki. This includes a "best of
mailing list posts" as part of the FAQs, user-contributed recipes,
configuration examples, and so on. Where appropriate we can attach files
to a wiki page (it's easier to click on a download link rather than
copy'n'paste provided examples to a local file).
Most of the wiki is opened for contribution from users. This is used to
extend the available documentation, getting rid of typos/errors in the
documentation and so on. We have good experiences with this so far, no
serious case of abuse.

Similar to lm-sensors we provide mailing lists for support requests as
well as an IRC channel for support and socialising. Interesting
information gets "ported" over to the wiki, most of the time as addition
to the FAQ. 

Bug reports, feature requests and contributed patches are kept as
tickets. Tickets can be manually or automatically assigned to one of
those with an user account (which we give away for developers and
continuing supporters). Each ticket can be assigned to one of the
defined milestones, and from the milestone view it's possible to tell
what amount of work is left until a milestone is reached.
The tickets allows to easily tell who is working on an issue, what the
current state of the issue is and what happened to a submitted patch. 


Bottom line: I think Trac is a valuable tool, and might be a good choice
for the lm-sensors project as well.

[1] http://madwifi.org
[2] http://www.edgewall.com/trac/

Bye, Mike

[lm-sensors] project status and future

[Volker Kuhlmann]

> I would like to write here few notes and visions about lm-sensors project.

Let me add some ;)

I found that the fancontrol script works impressively well for
controlling the CPU fan, although it needed tweaking (the code, not just
the config params). It doesn't adjust well enough to the sorts of fans
existing "out there". It's also not integrated into a service startup
script.

There ought to be a general desktop suitable GUI to the sensors
monitored values, with proper reaction when they're found to be out of
range. The good news is, there is a framework for that already:
http://sourceforge.net/projects/powersave Powersave already keeps tabs
on resources, and is capable to optimise in various directions
(performance, noise, battery) and react if necessary (suspend box when
battery flat). It has a daemon part, and a KDE panel GUI part, and some
other GUI part. In other words, it's a monitor and control construction
with Joe-Average-capable interface. Sounds perfect to me for adding
lm_sensors into.

Volker

-- 
Volker Kuhlmann			is possibly list0570 with the domain in header
http://volker.dnsalias.net/		Please do not CC list postings to me.

[lm-sensors] project status and future

[Philip Edelbrock]

Rudolf Marek wrote:

> [...]
> Well this is the end of "active" team. We have some hidden staff, that helps us run the list and website.
> I would like to thank Philip Edelbrock and Axel Thimm (iirc) for their efforts.

Thanks!  I've been very proud of being involved since its inception when 
I posted to the LKML and recruited Frodo. :')

> And the future plans that are PITA for now:
> 
> 1) new support system, - (it died previously and never has been finished)
[...]
> 3) wiki like pages, so other people can contribute to sensors know-how -> it should "concentrate" our wisdom
>    and wisdom from mailing list.
> Pi) configuration file repository - this can hide in wiki as first step.

I've receintly been toying with Trac and importing a legacy bug database 
into it for another project.  It's a bug tracker and wiki.  You've 
probably used it before?

http://www.edgewall.com/trac/

What do you guys think of this?


Phil

[lm-sensors] project status and future

[Henrique de Moraes Holschuh]

On Wed, 28 Dec 2005, Philip Edelbrock wrote:
> http://www.edgewall.com/trac/
> 
> What do you guys think of this?

It certainly seems to be working just fine for madwifi.org...

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

[lm-sensors] project status and future

[Michael Renzmann]

Hi.

On Wed, 2005-12-28 at 11:07 -0800, Philip Edelbrock wrote:
> I've receintly been toying with Trac and importing a legacy bug database 
> into it for another project.  It's a bug tracker and wiki.  You've 
> probably used it before?
> 
> http://www.edgewall.com/trac/
> 
> What do you guys think of this?

As mentioned in my posting, I really like Trac. I already told it to
Rudolf in IRC, but nevertheless: I'd be happy to help in case there are
any questions/problems in case you guys want to try Trac for lm_sensors.

Bye, Mike

[lm-sensors] project status and future

[Jean Delvare]

Hi Michael, Phil, all,

> On Wed, 2005-12-28 at 11:07 -0800, Philip Edelbrock wrote:
> > I've receintly been toying with Trac and importing a legacy bug database 
> > into it for another project.  It's a bug tracker and wiki.  You've 
> > probably used it before?
> > 
> > http://www.edgewall.com/trac/
> > 
> > What do you guys think of this?
> 
> As mentioned in my posting, I really like Trac. I already told it to
> Rudolf in IRC, but nevertheless: I'd be happy to help in case there are
> any questions/problems in case you guys want to try Trac for lm_sensors.

Well, if several of you guys have had a good experience with trac,
let's go with this. We do need a replacement for the current ticket
system which fits our needs so badly now (although I don't question the
fact it was helpful at the time it was implemented, some 7 years ago or
so; the number and nature of users was quite different back then.)

We had plans to go with bugzilla some times ago but we never actually
did it, so as long as someone actually does something, it's fine with
me. The faster we have a replacement and can get rid of the old system,
the better.

Phil, can you change the old ticket system code so that no new tickets
can be created there? This will motivate all of us to get the new
system setup fast, I think. And the old system is sucking too much of my
time and Ruik's too. We can handle the support requests more
efficiently on the mailing list in the meantime (we already do anyway.)

Then, everyone interested in trac can help setting it up. Michael, Phil
and others, please get in touch and decide who will do what, and where
the application will be hosted. It can be either at Phil's server
(which was hosting the older ticket system) or at Axel Thimm's facility
(which hosts the mailing list already). I'd rather avoid having a third
location for lm-sensors' stuff so as to not confuse people (starting
with ourselves).

Let's do it! As a general comment, please don't wait for my approval to
do things like this. Any of you may have much better ideas than I do -
and more importantly, more time to implement them. Just because I have
been handling a large part of the lm_sensors project on my own for some
times now doesn't mean my opinion matters more than any of yours. What
matters is that the work gets done, so anyone contributing something
useful in one way or another is right be definition. And I *really*
would like to see more people contributing to the project, not less.

And BTW: thanks Rudolf for the nice words :)

Thanks,
-- 
Jean Delvare

[lm-sensors] project status and future

[Rudolf Marek]

> Then, everyone interested in trac can help setting it up. Michael, Phil
> and others, please get in touch and decide who will do what, and where
> the application will be hosted. It can be either at Phil's server
> (which was hosting the older ticket system) or at Axel Thimm's facility
> (which hosts the mailing list already). I'd rather avoid having a third
> location for lm-sensors' stuff so as to not confuse people (starting
> with ourselves).

I guess Phul and Michael knows better the workflow and configuration of trac, so
I can help with the content filling itself. (convert some pages we already have, create new
docs ideas etc etc.)

However as I already written I cannot guarantee any schedule for this until
end of February. (But hey I will do my best)

> Let's do it! As a general comment, please don't wait for my approval to
> do things like this. Any of you may have much better ideas than I do -
> and more importantly, more time to implement them. Just because I have
> been handling a large part of the lm_sensors project on my own for some
> times now doesn't mean my opinion matters more than any of yours. What
> matters is that the work gets done, so anyone contributing something
> useful in one way or another is right be definition. And I *really*
> would like to see more people contributing to the project, not less.
> 
> And BTW: thanks Rudolf for the nice words :)

Well you deserve them for the hard work ;)

Regards
Rudolf

[lm-sensors] project status and future

[Philip Edelbrock]

Jean Delvare wrote:
> Hi Michael, Phil, all,
> 
> 
>>On Wed, 2005-12-28 at 11:07 -0800, Philip Edelbrock wrote:
>>
>>>I've receintly been toying with Trac and importing a legacy bug database 
>>>into it for another project.  It's a bug tracker and wiki.  You've 
>>>probably used it before?
>>>
>>>http://www.edgewall.com/trac/
>>>
>>>What do you guys think of this?
>>
>>As mentioned in my posting, I really like Trac. I already told it to
>>Rudolf in IRC, but nevertheless: I'd be happy to help in case there are
>>any questions/problems in case you guys want to try Trac for lm_sensors.
> 
> 
> Well, if several of you guys have had a good experience with trac,
> let's go with this. We do need a replacement for the current ticket
> system which fits our needs so badly now (although I don't question the
> fact it was helpful at the time it was implemented, some 7 years ago or
> so; the number and nature of users was quite different back then.)

Glad we managed to get as much use out of it as we did!  It is 
definitely past it's expected lifetime.

> Phil, can you change the old ticket system code so that no new tickets
> can be created there? 

OK.

> Then, everyone interested in trac can help setting it up. Michael, Phil
> and others, please get in touch and decide who will do what, and where
> the application will be hosted. It can be either at Phil's server
> (which was hosting the older ticket system) or at Axel Thimm's facility
> (which hosts the mailing list already). I'd rather avoid having a third
> location for lm-sensors' stuff so as to not confuse people (starting
> with ourselves).

I will see how hard it will be to implement on my server, unless 
somebody has a better home in mind.


Phil

[lm-sensors] project status and future

[Michael Renzmann]

Hi all.

On Thu, 2005-12-29 at 23:49 +0100, Rudolf Marek wrote:
> I guess Phul and Michael knows better the workflow and configuration of trac, so
> I can help with the content filling itself. (convert some pages we already have, create new
> docs ideas etc etc.)

I've started to port over content from the old, static website to the
wiki of the lm_sensors Trac. Almost all of the easier pages are already
ported, some are still missing (which are listed at
http://lm-sensors.org/trac/ticket/1 ).

Some of the remaining pages, most notably the "supported devices" and
"new drivers" ones, use tables with cells that span more than one row
and/or column. This type of table can be better rendered when support
for "restructured text" is enabled, see:
http://lm-sensors.org/trac/wiki/WikiRestructuredText - any chance we get
this on the lm_sensors Trac installation?

Something else that I've found while working: it seems there is a
problem regarding the graphics. Pages that have graphics embedded - such
as http://lm-sensors.org/trac/wiki/HardwareHacking - don't show all the
graphics at all. Reloading the page will enable the graphics that were
hidden in the first try, and hide those that were visible. Strange
thing.


By the way: Rudolf found a nice converter which is a great help when
converting HTML to Trac-wiki-markup:
http://diberri.dyndns.org/html2wiki.html .

Bye, Mike

[lm-sensors] project status and future

[Rudolf Marek]

Hi all,

I just added the FAQ, feel free to fix it. (several fixme is left there)

I tried to create the Configuration specific part of wiki.
First shot is linked from main page.

We agreed with Jean:

1) upload files via wiki (no svn module)
2) Directories for manufacturers, subdirectiories with model specific pages

http://www.lm-sensors.org/trac/wiki/Configurations/Asus
http://www.lm-sensors.org/trac/wiki/Configurations/Asus/TX97-E

I also hacked up some quick guide how to setup such pages. Anyone here please feel free to enhance it.

The "Identify flow diagram" can wait it is needed to rebuild that anyway.

The only missing thing is the Supported & New drivers pages. They should look like they had to (as Jean wishes)
So lets wait to switch that feature on.

Also someone with trac admin please update the logo ;)

Thanks

regards
Rudolf

[lm-sensors] project status and future

[Axel Thimm]

Hi,

didn't we want to use mediawiki instead of trac's embedded wiki?

http://lm-sensors.org/wiki/

vs

http://lm-sensors.org/trac/wiki/

I'm fine with both, but usually people are happier with mediawiki. It
is more mature as a wiki and offers more features.

As wikispamming is just around the corner, we need to restrain freely
editing and have some wiki operators (e.g. people that acknowledge
other people's wiki accounts).

On Mon, Jan 02, 2006 at 11:19:07PM +0100, Rudolf Marek wrote:
> Hi all,
> 
> I just added the FAQ, feel free to fix it. (several fixme is left there)
> 
> I tried to create the Configuration specific part of wiki.
> First shot is linked from main page.
> 
> We agreed with Jean:
> 
> 1) upload files via wiki (no svn module)
> 2) Directories for manufacturers, subdirectiories with model specific pages
> 
> http://www.lm-sensors.org/trac/wiki/Configurations/Asus
> http://www.lm-sensors.org/trac/wiki/Configurations/Asus/TX97-E
> 
> I also hacked up some quick guide how to setup such pages. Anyone here please feel free to enhance it.
> 
> The "Identify flow diagram" can wait it is needed to rebuild that anyway.
> 
> The only missing thing is the Supported & New drivers pages. They should look like they had to (as Jean wishes)
> So lets wait to switch that feature on.
> 
> Also someone with trac admin please update the logo ;)
> 
> Thanks
> 
> regards
> Rudolf
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20060102/80fb723f/attachment.bin

[lm-sensors] project status and future

[Michael Renzmann]

Hi.

On Mon, 2006-01-02 at 23:38 +0100, Axel Thimm wrote:
> didn't we want to use mediawiki instead of trac's embedded wiki?
> 
> http://lm-sensors.org/wiki/
> 
> vs
> 
> http://lm-sensors.org/trac/wiki/

I'd say no. While mediawiki might be more powerful regarding the markup
it uses, we will loose one of the features of Trac: the possibility to
easily link between tickets, wiki, changeset comments, and other Trac
objects.

Trac uses the Wiki markup nearly everywhere where someone can enter text
(the tickets for example), and if we decided to use Mediawiki for the
main wiki, users would be forced to cope with two different wiki markup
dialects.

Bottom line: personally I'd strongly vote for the Trac-internal wiki
rather than Mediawiki in this case.

> As wikispamming is just around the corner, we need to restrain freely
> editing 

madwifi.org runs Trac for about three months now. We had no incident of
Wiki spam so far, and only one or two incidents of minor vandalism
(someone thought it would be funny to remove parts of a newbie
documentation).

We allow changes to anonymous users, with the exception of only a few
pages. One of them is a page where I publish my public GPG key.
Everything else can be edited freely.

I have a bot running in our IRC channel that announces
added/deleted/changed wiki pages and tickets, as well as new Subversion
commits. That way it's easy to have a quick look on the changes, which
can then be reverted if necessary.

> and have some wiki operators (e.g. people that acknowledge
> other people's wiki accounts).

Accounts for Trac (which includes the Wiki) will have to be created in
two (three) steps:
1. adding the account credentials to a htpasswd file
2. adding the corresponding permissions to the user via trac-admin
(permission add ...)

3. (optional) The user has to log in and fill in the fields on the
"Settings" page to create a valid session. Without this session his name
won't occur in the drop-down list of the "(re)assign to" field of
tickets.

> > Also someone with trac admin please update the logo ;)

See:
http://lm-sensors.org/trac/wiki/TracInterfaceCustomization#ProjectLogoandIcon

Needs to be done by someone with shell access to the server, write
access to the trac.ini and, depending on the way Trac is installed (as
CGI or using mod_python), the rigths to restart Apache.

Bye, Mike

[lm-sensors] project status and future

[Axel Thimm]

Hi,

On Tue, Jan 03, 2006 at 08:25:25AM +0100, Michael Renzmann wrote:
> On Mon, 2006-01-02 at 23:38 +0100, Axel Thimm wrote:
> > didn't we want to use mediawiki instead of trac's embedded wiki?
> > 
> > http://lm-sensors.org/wiki/
> > 
> > vs
> > 
> > http://lm-sensors.org/trac/wiki/
> 
> I'd say no. While mediawiki might be more powerful regarding the markup
> it uses, we will loose one of the features of Trac: the possibility to
> easily link between tickets, wiki, changeset comments, and other Trac
> objects.

Is it really that helpful? At ivtvdriver.org nobody really misses
that, while there are quite a few users that are mediawiki experts and
have taken the load off the developers' shoulders. After all one of
the ideas of a wiki is to make it easier for users to contribute to
documentation.

> Trac uses the Wiki markup nearly everywhere where someone can enter text
> (the tickets for example), and if we decided to use Mediawiki for the
> main wiki, users would be forced to cope with two different wiki markup
> dialects.

At least tickets and any items that will be sent in notifier channels
(a commit/notify list) should not contain markup. This makes it very
hard to the ASCII MUA user (i.e. all od us? ;).

> Bottom line: personally I'd strongly vote for the Trac-internal wiki
> rather than Mediawiki in this case.

Well, as I said I personally prefer mediawiki, but I'm not insisting :)
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20060103/fb057afb/attachment.bin

[lm-sensors] project status and future

[Michael Renzmann]

Hi.

On Tue, 2006-01-03 at 15:05 +0100, Axel Thimm wrote:
> > I'd say no. While mediawiki might be more powerful regarding the markup
> > it uses, we will loose one of the features of Trac: the possibility to
> > easily link between tickets, wiki, changeset comments, and other Trac
> > objects.
> Is it really that helpful?

I'm quite used to it now, yes. It's a lot easier to refer to a fixed
ticket by just mentioning "#123" rather than by
"http://madwifi.org/ticket/123" in a commit message, for example.

> > Bottom line: personally I'd strongly vote for the Trac-internal wiki
> > rather than Mediawiki in this case.
> Well, as I said I personally prefer mediawiki, but I'm not insisting :)

I also won't insist. Let the majority decide that. :)

Bye, Mike

[lm-sensors] project status and future

[Jim Cromie]

hi Axel and friends,  (were all friends here ;-)

just hopping on this thread since the activists are here ;-)

Could someone with access add a few more URLs to the email footer ?
http://lm-sensors.org/trac/   & FAQ
http://lm-sensors.org/wiki/   & FAQ


+$0.02 - everyone knows that the 2nd line is an email addy,
and dont need the 1st line to tell them that.
Lets use it for something more informative ;-)


Yes, right here, just below this..    \|/

>_______________________________________________
>lm-sensors mailing list
>lm-sensors at lm-sensors.org
>http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
>
>  
>

[lm-sensors] project status and future

[Rudolf Marek]

Hello all,

>>>I'd say no. While mediawiki might be more powerful regarding the markup
>>>it uses, we will loose one of the features of Trac: the possibility to
>>>easily link between tickets, wiki, changeset comments, and other Trac
>>>objects.
>>
>>Is it really that helpful?

Well sometimes I guess it could be...

> I also won't insist. Let the majority decide that. :)

As far I know trac wiki markup is the subset of media wiki so we can switch to mediawiki when there is
something we will need. Until now we found nothing what could not be handled with the trac wiki.

I'm for the trac wiki right now.

Axel,
can please you enable that extended features as Mike requested (and fix the logo)

I'm also observing the disappearing of pictures on every second page reload, can you please fix it too?

Thanks
Regards
Rudolf

[lm-sensors] project status and future

[Axel Thimm]

On Fri, Jan 06, 2006 at 09:01:52PM +0100, Rudolf Marek wrote:
> Hello all,
> 
> >>>I'd say no. While mediawiki might be more powerful regarding the markup
> >>>it uses, we will loose one of the features of Trac: the possibility to
> >>>easily link between tickets, wiki, changeset comments, and other Trac
> >>>objects.
> >>
> >>Is it really that helpful?
> 
> Well sometimes I guess it could be...
> 
> > I also won't insist. Let the majority decide that. :)
> 
> As far I know trac wiki markup is the subset of media wiki so we can switch to mediawiki when there is
> something we will need. Until now we found nothing what could not be handled with the trac wiki.
> 
> I'm for the trac wiki right now.
> 
> Axel,
> can please you enable that extended features as Mike requested (and fix the logo)

I added logo (& favicon), but which extended features are you
referring to?

> I'm also observing the disappearing of pictures on every second page
> reload, can you please fix it too?

Trying to, I contacted upstream for fixing this bug.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20060106/bd85e02e/attachment-0001.bin

[lm-sensors] project status and future

[Philip Edelbrock]

Rudolf Marek wrote:
> I'm also observing the disappearing of pictures on every second page reload, can you please fix it too?
> 

Ah, are you using Safari?  (Or another KHMTL browser?)  I see the 
disappearing images/stylesheets too.  Same thing on the ivtv site.  I 
suspect that it might be because the images/stylesheet are marked as not 
cachable and expire even before the page renders, but I'm not sure.


Phil

[lm-sensors] project status and future

[Axel Thimm]

On Fri, Jan 06, 2006 at 01:42:07PM -0800, Philip Edelbrock wrote:
> 
> 
> Rudolf Marek wrote:
> > I'm also observing the disappearing of pictures on every second
> > page reload, can you please fix it too?
> 
> Ah, are you using Safari?  (Or another KHMTL browser?)  I see the
> disappearing images/stylesheets too.  Same thing on the ivtv site.
> I suspect that it might be because the images/stylesheet are marked
> as not cachable and expire even before the page renders, but I'm not
> sure.

I think it's independent of the browser, I see it with firefox, too (at
least the logo flipping on and off).

I think this is a regression in 0.9.2, because I hadn't seen this
before. Mike has contact to a trac guy and I also contacted the trac
list to get this fixed.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20060106/2dd2d987/attachment.bin

[lm-sensors] project status and future

[Jean Delvare]

Hi Axel,

> > can please you enable that extended features as Mike requested (and fix the logo)
> 
> I added logo (& favicon), but which extended features are you
> referring to?

Quoting Michael Renzmann a few days ago:

<< Some of the remaining pages, most notably the "supported devices" and
"new drivers" ones, use tables with cells that span more than one row
and/or column. This type of table can be better rendered when support
for "restructured text" is enabled, see:
http://lm-sensors.org/trac/wiki/WikiRestructuredText - any chance we get
this on the lm_sensors Trac installation? >>

I think that's what Rudolf was referring to here.

-- 
Jean Delvare