On Wed, 2010-03-10 at 20:52 +, Peter TB Brett wrote:
We (Peter C I) try quite hard to keep on top of patches to gschem/libgeda
etc., y'know. Putting them in the tracker makes things a lot easier for us,
and I really encourage you to keep doing that.
I'm very bad at following stuff in
On Thursday 11 March 2010 13:55:29 Peter Clifton wrote:
On Wed, 2010-03-10 at 20:52 +, Peter TB Brett wrote:
We (Peter C I) try quite hard to keep on top of patches to
gschem/libgeda etc., y'know. Putting them in the tracker makes things a
lot easier for us, and I really encourage you
I'm very bad at following stuff in the sourceforge trackers, partly
since I _HATE_ the sourceforge site with a fiery passion.
Why not just move to LaunchPad? If it is set up and all the docs point
in that direction then all new bugs/issues will be added there. The SF
bugs just need to be worked
I submitted a patch for PCB about a month ago and it has been reviewed
these days; is this too much delay?
Probably not, but now I read that including tests would have made the
reviewing job easier and possibly shorter.
But I didn't even know of the existence of such tests: the point is
that to
I totally agree with you (as a new user interested in developing).
2010/3/10 Alberto Maccioni [1]alberto.macci...@gmail.com
I submitted a patch for PCB about a month ago and it has been
reviewed
these days; is this too much delay?
Probably not, but now I read that
On Tue, Mar 9, 2010 at 5:06 PM, Dan McMahill d...@mcmahill.net wrote:
Here's an example of a place where extra help wouldn't have needed any
knowledge of internals. Over the years there have been various bug reports
about some of the footprints that ship with pcb. For each of those, the
On Wed, Mar 10, 2010 at 5:14 AM, Alberto Maccioni
alberto.macci...@gmail.com wrote:
the code on the mailing list, but it took me several months to
discover the submit patch procedure.
What procedure did you find?
Jared
___
geda-user mailing list
I called it a procedure, but it's the fact that there is a submit
patch function; it's so obvious to any developer that it's not written
anywhere.
And I didn't notice it until very recently.
2010/3/10 Jared Casper jaredcas...@gmail.com:
On Wed, Mar 10, 2010 at 5:14 AM, Alberto Maccioni
Yes - but what is the function!?! (A,B,C; 1,2,3 please.)
On 03/10/2010 03:07 PM, Alberto Maccioni wrote:
I called it a procedure, but it's the fact that there is a submit
patch function; it's so obvious to any developer that it's not written
anywhere.
And I didn't notice it until very recently.
This:
http://sourceforge.net/tracker/?group_id=73743atid=538813
which is also linked from:
http://www.gpleda.org/developer.html
2010/3/10 Ethan Swint eswint.r...@verizon.net:
Yes - but what is the function!?! (A,B,C; 1,2,3 please.)
On 03/10/2010 03:07 PM, Alberto Maccioni wrote:
I called
On Wed, Mar 10, 2010 at 12:18 PM, Alberto Maccioni
alberto.macci...@gmail.com wrote:
This:
http://sourceforge.net/tracker/?group_id=73743atid=538813
which is also linked from:
http://www.gpleda.org/developer.html
Ah yes... unfortunately, at present, Sourceforge is where patches go
to die*.
On Wednesday 10 March 2010 20:26:41 Jared Casper wrote:
On Wed, Mar 10, 2010 at 12:18 PM, Alberto Maccioni
alberto.macci...@gmail.com wrote:
This:
http://sourceforge.net/tracker/?group_id=73743atid=538813
which is also linked from:
http://www.gpleda.org/developer.html
Ah yes...
On Wed, Mar 10, 2010 at 12:52 PM, Peter TB Brett pe...@peter-b.co.uk wrote:
We (Peter C I) try quite hard to keep on top of patches to gschem/libgeda
etc., y'know. Putting them in the tracker makes things a lot easier for us,
and I really encourage you to keep doing that.
Sorry, didn't mean
On Tue, 09 Mar 2010 21:11:08 -0500, Bob Paddock wrote:
fwiw, there is a pcb-bugs mailing list with only me as the subscriber.
Of course in all fairness, that list didn't exist yesterday ;) That
list will get all new bug reports and updates to existing reports.
Don't see it listed at any of
On Mon, 08 Mar 2010 15:10:09 -0500, DJ Delorie wrote:
I agree that PCB needs more grunt work from the (we) primary developers.
(...)
So what can we do? How can we get people with *less* experience more
involved in solving this problem?
Grow them?
Honestly. Developers don't emerge fully
On Mon, 08 Mar 2010 21:30:39 +, Peter Clifton wrote:
Some developers - like (sorry to say, I'm speaking purely for myself
here), are damned right lazy, and sometimes need a little cajoling to
get things done.
Well, that's why I brought up the subject twice on this list.
Getting
So what can we do? How can we get people with *less* experience
more involved in solving this problem?
Grow them?
That is, introduce a group of second class developers. I don't
think, this will work. The real work is to decide whether or not a
patch actually improves the code. IMHO,
On 9 March 2010 18:23, DJ Delorie d...@delorie.com wrote:
If developer cycles is the bottle neck, the only solution is to
increase the number of active developers.
That's what I'm trying to do - both reduce the bottleneck, and make it
easier to add more developers.
From my perspective, DJ
If the senior developers are fed projects and requirements, suitably
discussed and planned, they'd be more likely to work on them. We
currently work on our own desires because we know what we want, to
solve our problems.
That sounds nice, but the reality is quite different (understandably).
That sounds nice, but the reality is quite different (understandably).
Firstly, who feeds the projects and requirements to the developers?
Secondly, raising ideas for discussion often ends (quickly) in the
comment, If you want it, just develop it yourself. In practice
developers work on
On Tue, 2010-03-09 at 21:33 +0200, Duncan Drennan wrote:
If the senior developers are fed projects and requirements, suitably
discussed and planned, they'd be more likely to work on them. We
currently work on our own desires because we know what we want, to
solve our problems.
That
On Tue, 2010-03-09 at 19:20 +, Gareth Edwards wrote:
If we want to trial this model, I'm personally happy to become one of
the second-class developers as Kai-Martin put it - to do some patch
triage for gEDA tools in general, not just pcb.
Sure!
These things typically evolve anyway.. and
Am 08.03.2010 23:11, schrieb Jared Casper:
I think your email is a great response to KMK and loads better than
ignoring it, saying I'm busy, or even applying it without being
happy with it. I don't think it is inappropriate for devs to require
contributors to follow guidelines and a certain
DJ Delorie wrote:
So what can we do? How can we get people with *less* experience
more involved in solving this problem?
Grow them?
That is, introduce a group of second class developers. I don't
think, this will work. The real work is to decide whether or not a
patch actually improves the
Peter Clifton wrote:
On Tue, 2010-03-09 at 19:20 +, Gareth Edwards wrote:
If we want to trial this model, I'm personally happy to become one of
the second-class developers as Kai-Martin put it - to do some patch
triage for gEDA tools in general, not just pcb.
Sure!
These things
Duncan Drennan wrote:
If the senior developers are fed projects and requirements, suitably
discussed and planned, they'd be more likely to work on them. We
currently work on our own desires because we know what we want, to
solve our problems.
That sounds nice, but the reality is quite
As noted in a different post, I just recompiled pcb from git.
Unfortunately, neither git-head nor Peter Cliftons before_pours branch
process action scripts when printing from the command line. The main
procedure of pcb simply exports before action scripts are read. This is a
known bug since
Yes, I feel ignored by the developers. No, I am not happy about it.
I agree. Those mean developers! Why can't they spend more time on
PCB and less time with their families and jobs? They should be
ashamed of themselves, not giving free software priority over things
like food and shelter.
On Mon, Mar 8, 2010 at 9:48 AM, DJ Delorie d...@delorie.com wrote:
Yes, I feel ignored by the developers. No, I am not happy about it.
I agree. Those mean developers! Why can't they spend more time on
PCB and less time with their families and jobs? They should be
ashamed of themselves,
I agree that PCB needs more grunt work from the (we) primary
developers. At this time, I rarely have time to even work on my own
pet projects. The last couple of code sprints, I've done nothing
*but* bug/patch reviews, since I understand it's an important part of
a project.
So what can we do?
* A group of non-developers watch for bug reports, either in the
mailing list or the SF tracker.
How good are people at actually logging bugs on the SF tracker?
___
geda-user mailing list
geda-user@moria.seul.org
How good are people at actually logging bugs on the SF tracker?
I suspect our lack of attention to them has prompted them to be less
good at reporting them there.
___
geda-user mailing list
geda-user@moria.seul.org
On Mon, 2010-03-08 at 17:40 +, Kai-Martin Knaak wrote:
rant=on
I filed a bug report, I provided a patch on this list, I nagged twice on
on this about it. How come, the patch is still not applied to the source?
What should I do to get this annoying bug fixed?
Yes, I feel ignored by the
Touching hidnogui.c to remove the CRASH; statement - why is that
needed?
hidnogui was designed to be a template for new HIDs, so everything
crashes when called - that's how you know which function needs to be
implemented next. Perhaps we need two hids - hidnogui for
command-line use, and
On Mon, Mar 8, 2010 at 4:00 PM, DJ Delorie d...@delorie.com wrote:
How good are people at actually logging bugs on the SF tracker?
I suspect our lack of attention to them has prompted them to be less
good at reporting them there.
I submitted my first PCB bug report to SF last month
On Mon, Mar 8, 2010 at 12:10 PM, DJ Delorie d...@delorie.com wrote:
So what can we do? How can we get people with *less* experience more
involved in solving this problem? That opens up the labor pool so
to speak, letting the main developers work on the hard problems.
How about this idea:
On Mon, 2010-03-08 at 16:41 -0500, Stephen Ecob wrote:
On Mon, Mar 8, 2010 at 4:00 PM, DJ Delorie d...@delorie.com wrote:
How good are people at actually logging bugs on the SF tracker?
I suspect our lack of attention to them has prompted them to be less
good at reporting them there.
Since I'm in the mood to share my opinions today... :)
On Mon, Mar 8, 2010 at 1:30 PM, Peter Clifton pc...@cam.ac.uk wrote:
It might seem unfair that we're (or I am) trying to third party
contributions to a higher standard than some of PCB's existing legacy
code, but assuming it doesn't
The patch looks good to me (although I've only skimmed it). It might
warrant a definition of what a freckle is, if that term isn't use
elsewhere.
It looks OK to me (assuming a comment explaining *why* it's needed is
added) but I wonder if one of the other optimizations is creating
these
On Mon, Mar 8, 2010 at 5:17 PM, DJ Delorie d...@delorie.com wrote:
The patch looks good to me (although I've only skimmed it). It might
warrant a definition of what a freckle is, if that term isn't use
elsewhere.
It looks OK to me (assuming a comment explaining *why* it's needed is
added)
When djopt is then run, it splits the overshooting line to create a
good line plus a 0.01 thou long freckle.
Perhaps it shouldn't do that, then :-)
But keep the other code too, in case someone else does it.
___
geda-user mailing list
On Mon, Mar 8, 2010 at 5:50 PM, DJ Delorie d...@delorie.com wrote:
When djopt is then run, it splits the overshooting line to create a
good line plus a 0.01 thou long freckle.
Perhaps it shouldn't do that, then :-)
But keep the other code too, in case someone else does it.
OK, here's an
42 matches
Mail list logo
