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
On Sat, Oct 31, 2009 at 9:04 PM, Chitlesh GOORAH chitlesh@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
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@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
Hi,
--- On Sun, Nov 1, 2009 at 1:34 AM, Chitlesh GOORAH chitlesh@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
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
Hi,
--- On Sun, Nov 1, 2009 at 1:58 AM, Chitlesh GOORAH chitlesh@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
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?
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
Hi,
--- On Sun, Nov 1, 2009 at 2:42 AM, Chitlesh GOORAH chitlesh@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
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
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
electronic-lab@lists.fedoraproject.org
-
Aanjhan R -
Chitlesh GOORAH -
Shakthi Kannan