> 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 worke
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 encour
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
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
On Wed, Mar 10, 2010 at 12:52 PM, 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.
>
Sorry, didn't mean to diminish yo
On Wednesday 10 March 2010 20:26:41 Jared Casper wrote:
> On Wed, Mar 10, 2010 at 12:18 PM, Alberto Maccioni
>
> wrote:
> > This:
> > http://sourceforge.net/tracker/?group_id=73743&atid=538813
> >
> > which is also linked from:
> > http://www.gpleda.org/developer.html
>
> Ah yes... unfortunatel
On Wed, Mar 10, 2010 at 12:18 PM, Alberto Maccioni
wrote:
> This:
> http://sourceforge.net/tracker/?group_id=73743&atid=538813
>
> which is also linked from:
> http://www.gpleda.org/developer.html
>
Ah yes... unfortunately, at present, "Sourceforge is where patches go
to die"*. I've had more suc
This:
http://sourceforge.net/tracker/?group_id=73743&atid=538813
which is also linked from:
http://www.gpleda.org/developer.html
2010/3/10 Ethan Swint :
> 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, b
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.
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 :
> On Wed, Mar 10, 2010 at 5:14 AM, Alberto Maccioni
> wrote:
>> the code on the
On Wed, Mar 10, 2010 at 5:14 AM, Alberto Maccioni
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
geda-user@moria.seul.org
On Tue, Mar 9, 2010 at 5:06 PM, Dan McMahill 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
> process becomes
>
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 incl
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 the
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 these seemingly likely places:
http://
> 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 these seemingly likely places:
http://www.gpleda.org/m
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 differen
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 typical
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 co
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 s
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..
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 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 o
> 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
On 9 March 2010 18:23, DJ Delorie 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 is on t
> > 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
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 pat
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 ad
On Mon, Mar 8, 2010 at 5:50 PM, DJ Delorie 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 updated
> 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
geda-user@
On Mon, Mar 8, 2010 at 5:17 PM, DJ Delorie 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) but I
> 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 f
Since I'm in the mood to share my opinions today... :)
On Mon, Mar 8, 2010 at 1:30 PM, Peter Clifton 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 completely stifle c
On Mon, 2010-03-08 at 16:41 -0500, Stephen Ecob wrote:
> On Mon, Mar 8, 2010 at 4:00 PM, DJ Delorie 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
On Mon, Mar 8, 2010 at 12:10 PM, DJ Delorie 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:
>
I like
On Mon, Mar 8, 2010 at 4:00 PM, DJ Delorie 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 (#2946254), and
shor
> 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 hid
On Mon, 2010-03-08 at 17:40 +, Kai-Martin Knaak wrote:
>
> 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 de
> 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
http://www.seul.org/cgi-bin/mailma
> * 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
http://www.seul.org/cgi-bin/mailma
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?
On Mon, Mar 8, 2010 at 9:48 AM, DJ Delorie 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, not giving fr
> 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.
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 mor
44 matches
Mail list logo
