3:04 p.m.
Hello there,
Shakthi has recently encountered a situation where I think upstream of
his package is pretty non-responsive, that we can call it dead
upstream.
I went to see on sourceforge to see how many of the EDA tools's
development were pretty much dead. I was surprise to see my bright
ideas unachieved.
So the question is
As a community driven and non-profit opensource EDA leader, what should we do ?
I would like to hear from you how you would like to contribute to
solve this situation.
As far as I'm concerned, I would rather want to take over the upstream
responsibilities and little by little migrate the code/features to an
active upstream of existing opensource EDA software. In other words,
improve the existing supported opensource EDA tools.
It will also be very interesting for new developers who don't actually
know what to contribute to the opensource community.
Kind regards,
Chitlesh
3:09 p.m.
On Sat, Oct 31, 2009 at 9:04 PM, Chitlesh GOORAH
<chitlesh(a)fedoraproject.org> wrote:
Shakthi has recently encountered a situation where I think upstream
of
his package is pretty non-responsive, that we can call it dead
upstream.
Is it some secret crime site investigation of not revealing the dead victim?
--
A
3:14 p.m.
On Sat, Oct 31, 2009 at 9:09 PM, Aanjhan R < hidden > wrote:
On Sat, Oct 31, 2009 at 9:04 PM, Chitlesh GOORAH
<chitlesh(a)fedoraproject.org> wrote:
> Shakthi has recently encountered a situation where I think upstream of
> his package is pretty non-responsive, that we can call it dead
> upstream.
Is it some secret crime site investigation of not revealing the dead victim?
--
A
No it's not. However not naming the victim can help to deduce unbiased
solutions/procedures how to solve this problem.
By the way, its https://fedorahosted.org/fedora-electronic-lab/ticket/57
Chitlesh
3:15 p.m.
Hi,
--- On Sun, Nov 1, 2009 at 1:34 AM, Chitlesh GOORAH
<chitlesh(a)fedoraproject.org> wrote:
| Shakthi has recently encountered a situation where I think upstream of
| his package is pretty non-responsive, that we can call it dead
| upstream.
\--
Actually, I got one reply yesterday, but, I have been pushing this way
too far, and way too long! One of the authors forgot to "Reply all",
unfortunately.
I have sent some queries, and hopefully will get some answers. It is
good code, just that it has been unmaintained for many years.
---
| As far as I'm concerned, I would rather want to take over the upstream
| responsibilities and little by little migrate the code/features to an
| active upstream of existing opensource EDA software. In other words,
| improve the existing supported opensource EDA tools.
\--
Do you want to put these tasks as low priority, or do you want these
to be taken by any new-comers who can use it as a learning exercise?
Is it possible for you to prioritise the tickets?
Let me know,
SK
--
Shakthi Kannan
http://www.shakthimaan.com
3:28 p.m.
On Sat, Oct 31, 2009 at 9:15 PM, Shakthi Kannan < hidden > wrote:
Do you want to put these tasks as low priority, or do you want these
to be taken by any new-comers who can use it as a learning exercise?
Is it possible for you to prioritise the tickets?
Actually anyone has the right to prioritise any ticket.
As for this dead upstream discussion, I won't encourage forking if
there is an upstream. However, if there is no upstream then I think it
would be best to migrate the code/features to another EDA tools whose
development is active. Of course, this would entail first discussing
with both upstream. Such discussions can be carried out here on this
mailing list.
Indeed such tasks can be done by new-comers. We need to have something
to track such progress, which comes to another question I'm unable to
answer:
Do we need a wiki or should we stick with our ticket based system ?
Currently we have a wiki on FedoraProject.org and another one on
https://fedorahosted.org/fedora-electronic-lab. We are not using both.
Chitlesh
3:38 p.m.
Hi,
--- On Sun, Nov 1, 2009 at 1:58 AM, Chitlesh GOORAH
<chitlesh(a)fedoraproject.org> wrote:
| Do we need a wiki or should we stick with our ticket based system ?
\--
We can use both, IMO. Ticket based system is simple and serves the
needs to keep track of work.
---
| Currently we have a wiki on FedoraProject.org and another one on
| https://fedorahosted.org/fedora-electronic-lab. We are not using both.
\--
For the wiki:
* CSS work is required to motivate people to use it, and put
project/tools documentation.
* The documentation should be made usable offline, by exporting it to
pdf or some other format.
Or, if we want to use LaTeX for all our documentation, we will need to
revision its sources, and make .pdf versions available for users to
download and use. The following needs to be completed for it?
https://fedorahosted.org/fedora-electronic-lab/ticket/25
For the ticket-based system:
* Some nice CSS changes will be helpful.
SK
--
Shakthi Kannan
http://www.shakthimaan.com
4:12 p.m.
On Sat, Oct 31, 2009 at 9:38 PM, Shakthi Kannan wrote:
For the wiki:
* CSS work is required to motivate people to use it, and put
project/tools documentation.
Which CSS work ? You mean theme trac ? If you have a theme in mind, we
can package it and ask Fedora Infrastructure to set it up.
* The documentation should be made usable offline, by exporting it
to
pdf or some other format.
Yes this has been an issue for quite a long time now.
This is my opinion but I would certainly like to hear yours.
There is upstream documentation and FEL specific documentation. Our
objective should be to have less FEL specific documentation and
migrate any documentation to their upstream sources.
That said, upstream documentation should be a manpage, tutorials and
examples. These go to %doc in the FEL packaging.
FEL specific documentation should be where to find the examples,
whether docs are in main package or -doc package, which variable which
needs to set up and how interoperability between tools of different
upstream work. I was thinking of a yelp based help similar to the
gnome help.
It is fairly easy to write a script to create such a yelp
infrastructure. The latter will then be called directly from the
Electronics menu on the gnome menu.
I've drafted a piece here,
https://fedorahosted.org/fedora-electronic-lab/browser/documentation
As for the upstream documentation, if someone finds a tutorial (not
from upstream) about a tool we need to contact upstream to put it
among the sources. Another question comes up. Wouldn't it be nice to
have a similar latex template of all EDA software ?
Or, if we want to use LaTeX for all our documentation, we will need
to
revision its sources, and make .pdf versions available for users to
download and use.
Here we can use the fel git repo. I've already all the versions of FEL
flyer and release notes sources there.
The following needs to be completed for it?
https://fedorahosted.org/fedora-electronic-lab/ticket/25
I'm reviewing a nice application
https://bugzilla.redhat.com/show_bug.cgi?id=526844
For the ticket-based system:
* Some nice CSS changes will be helpful.
I'm not a CSS expert. I can't help you there. However we can propose
mockups to the Fedora Websites team to create CSS for us. If you have
something in mind please propose :)
Actually other Fedora spins consider FEL as a model, so please propose
your ideas :)
Chitlesh
12:29 a.m.
Hi,
--- On Sun, Nov 1, 2009 at 2:42 AM, Chitlesh GOORAH
<chitlesh(a)fedoraproject.org> wrote:
| Which CSS work ? You mean theme trac ? If you have a theme in mind, we
| can package it and ask Fedora Infrastructure to set it up.
\--
Let me discuss with some CSS designers on this.
---
| It is fairly easy to write a script to create such a yelp
| infrastructure. The latter will then be called directly from the
| Electronics menu on the gnome menu.
\--
IMO, we should have documentation independent of desktop environments.
Whatever examples packages provided by a package is fine. By,
documentation, what I meant were user tutorials/experiences/HOWTOs
that people (unlike packagers) can edit on a wiki, for example.
Ideally, yes, we would like these to be included in -doc for each package.
SK
--
Shakthi Kannan
http://www.shakthimaan.com
2 a.m.
On Sun, Nov 1, 2009 at 6:29 AM, Shakthi Kannan < hidden > wrote:
IMO, we should have documentation independent of desktop
environments.
Whatever examples packages provided by a package is fine. By,
documentation, what I meant were user tutorials/experiences/HOWTOs
that people (unlike packagers) can edit on a wiki, for example.
Aanjhaan and I started a wiki page in the past at
https://fedorahosted.org/fedora-electronic-lab/wiki/HowTo
Let's use this fel-hosted wiki for user tutorials/experiences/HOWTOs.
Chitlesh
12:50 p.m.
Hi,
--- On Sun, Nov 1, 2009 at 2:42 AM, Chitlesh GOORAH
| It is fairly easy to write a script to create such a yelp
| infrastructure. The latter will then be called directly from the
| Electronics menu on the gnome menu.
\--
Just want to discuss this further as our list of packages is growing day-by-day:
1. Whatever documentation made for a particular software can be pushed
upstream, so we keep track of only one set of sources. We will do
documentation in LaTeX or DocBook, so we abstract content with
presentation, and it will greatly help us in the long run.
2. In Yelp, we can provide links to all relevant installed package
documentation? If that can be done, it will only be linking to the
respective files? or else we will need something similar in the lines
of .desktop files that can simply pin-point to where the doc/, man/,
info/ pages for each software/tool that is shipped, and are
independent of desktop environments.
3. We will also need to provide documentation on suggested workflows
with various tools that are shipped, so people can follow it.
Feedback welcome,
SK
--
Shakthi Kannan
http://www.shakthimaan.com
5255
days inactive
5289
days old
electronic-lab@lists.fedoraproject.org
9 comments
3 participants
participants (3)
-
Aanjhan R -
Chitlesh GOORAH -
Shakthi Kannan