Re: gEDA-user: test repo
On Mon, 5 Sep 2011 16:43:43 -0400 DJ Delorie wrote: > And nine women can have a baby in a month :-) -- Kovacs Levente Voice: +36705071002 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: test repo
On Mon, Sep 5, 2011 at 9:53 PM, Bert Timmerman wrote: > Hi Russell, > >> -Original Message- >> From: geda-user-boun...@moria.seul.org >> [mailto:geda-user-boun...@moria.seul.org] On Behalf Of Russell Dill >> Sent: Monday, September 05, 2011 10:21 PM >> To: gEDA user mailing list >> Cc: geda-u...@seul.org >> Subject: Re: gEDA-user: test repo >> >> >> with one checked-out version you know works, or maintain your own >> >> bugfix branch. Git head is where development happens, and >> when we're >> >> bringing in big changes, stuff breaks. >> > >> > This is why other projects like KiCAD provide a dedicated >> testing repo. >> > Debian even has four stages (experimental, unstable, >> testing and stable). >> > By the way, stuff also breaks with small changes. See the first >> > commits of the new layer selector. >> >> gEDA PCB's developer and testing community is much smaller >> than Debian's. I don't know about a size comparison to KiCAD. >> The only way bugs can be fixed is by someone finding that >> it's broken in the first place. I fear that not only would >> the developer resources be there to maintain two separate >> branches, but the testing resources wouldn't be there either. >> Out of all the people testing on git HEAD, I think only you >> managed to find the large silk bug. This model is used with >> quite a bit of success in linux kernel development with the >> linux-next tree, so who knows, maybe it does have a place. >> >> I think the only way this gets solved is the suggestion that >> someone made of someone tagging "semi-stable" versions. Bug >> fix patches could be back-ported to those and at some point >> the branch could be abandoned for a newer semi-stable >> version. The nice thing about this solution is that it can >> easily scale based on how many people are willing to help >> maintain the various semi-stable branch points and don't >> depend on the core developers doing anything. Someone with a >> big enough itch to scratch could put something up on github today. >> >> > > Some of us have been there, done just that, and for some time: > > https://github.com/fruoff/pcb-fruoff.git > > https://github.com/jaredcasper/pcb.git > > https://github.com/peter-b/geda-gaf.git > > https://github.com/bert/pcb.git > > And maybe some more I didn't notice. > (Note, clip the .git for the web interface) I don't see any branching or tagging on any of these that would indicate maintenance of stable branches. Also, if someone was doing this, it'd be nice of them to send out an announcement each time they made a new stable branch point. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: test repo
Hi Russell, > -Original Message- > From: geda-user-boun...@moria.seul.org > [mailto:geda-user-boun...@moria.seul.org] On Behalf Of Russell Dill > Sent: Monday, September 05, 2011 10:21 PM > To: gEDA user mailing list > Cc: geda-u...@seul.org > Subject: Re: gEDA-user: test repo > > >> with one checked-out version you know works, or maintain your own > >> bugfix branch. Git head is where development happens, and > when we're > >> bringing in big changes, stuff breaks. > > > > This is why other projects like KiCAD provide a dedicated > testing repo. > > Debian even has four stages (experimental, unstable, > testing and stable). > > By the way, stuff also breaks with small changes. See the first > > commits of the new layer selector. > > gEDA PCB's developer and testing community is much smaller > than Debian's. I don't know about a size comparison to KiCAD. > The only way bugs can be fixed is by someone finding that > it's broken in the first place. I fear that not only would > the developer resources be there to maintain two separate > branches, but the testing resources wouldn't be there either. > Out of all the people testing on git HEAD, I think only you > managed to find the large silk bug. This model is used with > quite a bit of success in linux kernel development with the > linux-next tree, so who knows, maybe it does have a place. > > I think the only way this gets solved is the suggestion that > someone made of someone tagging "semi-stable" versions. Bug > fix patches could be back-ported to those and at some point > the branch could be abandoned for a newer semi-stable > version. The nice thing about this solution is that it can > easily scale based on how many people are willing to help > maintain the various semi-stable branch points and don't > depend on the core developers doing anything. Someone with a > big enough itch to scratch could put something up on github today. > > Some of us have been there, done just that, and for some time: https://github.com/fruoff/pcb-fruoff.git https://github.com/jaredcasper/pcb.git https://github.com/peter-b/geda-gaf.git https://github.com/bert/pcb.git And maybe some more I didn't notice. Kind regards, Bert Timmerman. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: test repo
Bob Paddock wrote: > Outside of our group here gEDA/PCB/Et.Al. are seen as toys and hard > to use. Maybe we should all asks ourselves why? Part of the reason may be seen on youtube. Yesterday, I was surprised to see a number of geda/PCB tutorials there. I watched only a few. All of them made schematic capture look difficult and an enduring task. It was not that the commentator directly sad so, but because there were so many steps involved before a result was visible. There were major misconceptions, too. E.g., one author insists, you have to be root to change symbols in the lib... Looks like, the lesson to be learned here is: Us power users should engage and write better tutorials and make them visible. Upload videos on youtube blog about it, write articles in Make Magazine, etc. ---<)kaimartin(>--- -- Kai-Martin Knaak Email: k...@familieknaak.de http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53 increasingly unhappy with moderation of geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: test repo
> The patch-maintainer does not have to cherry pick anything. So what you're asking for is a release manager. Ok, put up some money to hire one, because we don't have anyone to do that at the moment. Meanwhile, please stop suggesting changes that require more man-power. We don't have any to spare. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: test repo
> > The fall back option is to use a release. > > It won't be an option once file format changes kick in. Always true for any new feature you want to use. Wait until there's a stable release with that feature, then migrate forward. > In 2005 Debian had 1200 maintainers for 8400 packages. Maintaining someone else's package in a distro is not the same as developing those packages in the first place. And 1200 people is WAY BIGGER than the geda developer community. > That is, on avarage every maintainer handles 6.3 packages. And nine women can have a baby in a month, but the math just isn't relevent. The raw ratio of packages to maintainers has nothing to do with how hard it is for a tiny team to manage multiple release/test repositories. > Sigh. I thought I made it clear, that I don't expect guaranteed > unbroken applications when testing. Perhaps I was not clear - it doesn't matter how much testing we do, stuff is going to break and not get found until release anyway. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: test repo
DJ Delorie wrote: > >> If additional filtering is desired: One of the "core developers" > > Again, we just don't have enough "core developers" to add any burden > to them. We need options that *reduce* the load on developers, to > encourage more participation. See the "if" in my sentence. Core developers are only required if _additional_ filtering is desired. >> This wouldn't neceessarily have to be a developer. He or she just >> has to be familiar with git and the build tools in general. > > If they have commit access to the master git, they need to be a > developer. That's kind of our definition of "developer" - you need > to know enough about what's going on, to make smart choices about > which patches to pull. All of them that have been commited by developers to the test repo and have not been seen to break anything for a reasonable amount of testing time. The patch-maintainer does not have to cherry pick anything. He does not have to review code, either. Just read the bug reports and what devs respond. In other words: He automatically commits to git-head unless a patch had been singled out as the cause of trouble. Of course, changes may depend on each other. Then patches will be held back until the blocking feature is ready for prime time. >From the viewpoint of decision making, this is the same situation as now. The developer is responsible for what he commits. Period. Only difference is that he commits to git-test rather than to git-head. > As I said before, that's our procedure - git head *is* our testing > repo. It is "unstable" in the debian sense. What I am asking for, is a repo that is already tested but not as dated as the current releases tend to be. Or more specifically: A repo that contains all patches and features that have been shown to work. >> A fixed calendar would help. I'd say two months of patching followed >> by a month of freeze would be fine. > > A fixed calendar won't work as we don't have dedicated developers. > Our roadmap is to decide on a minimum set of features and bugfixes we > want in the next release, I am not talking about fixed calendar for a release. The calendar is about the internal organization of the testing-to-head-conversion. Note, this is the szenario without the patch-maintainer. ---<)kaimartin(>--- -- Kai-Martin Knaak Email: k...@familieknaak.de http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53 increasingly unhappy with moderation of geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: test repo
DJ Delorie wrote: >> If you want real world testing, provide an environment with proper >> fall back options. > > The fall back option is to use a release. It won't be an option once file format changes kick in. >> Debian even has four stages (experimental, unstable, testing and >> stable). > > Debian has a huge development community. In 2005 Debian had 1200 maintainers for 8400 packages. That is, on avarage every maintainer handles 6.3 packages. This includes screening of bug reports push of new versions and maintainance of the build scripts. Seen from that perspective, the maintainer community of debian is not that large. > The reality is, stuff breaks for all sorts of reasons. If you expect > otherwise, you're not going to be happy unless you stick with > official releases. Sigh. I thought I made it clear, that I don't expect guaranteed unbroken applications when testing. After all, the whole point of testing is to find things that are broken. So please stop suggesting otherwise. ---<)kaimartin(>--- -- Kai-Martin Knaak Email: k...@familieknaak.de http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53 increasingly unhappy with moderation of geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: test repo
>> with one checked-out version you know >> works, or maintain your own bugfix branch. Git head is where >> development happens, and when we're bringing in big changes, stuff >> breaks. > > This is why other projects like KiCAD provide a dedicated testing repo. > Debian even has four stages (experimental, unstable, testing and stable). > By the way, stuff also breaks with small changes. See the first commits > of the new layer selector. gEDA PCB's developer and testing community is much smaller than Debian's. I don't know about a size comparison to KiCAD. The only way bugs can be fixed is by someone finding that it's broken in the first place. I fear that not only would the developer resources be there to maintain two separate branches, but the testing resources wouldn't be there either. Out of all the people testing on git HEAD, I think only you managed to find the large silk bug. This model is used with quite a bit of success in linux kernel development with the linux-next tree, so who knows, maybe it does have a place. I think the only way this gets solved is the suggestion that someone made of someone tagging "semi-stable" versions. Bug fix patches could be back-ported to those and at some point the branch could be abandoned for a newer semi-stable version. The nice thing about this solution is that it can easily scale based on how many people are willing to help maintain the various semi-stable branch points and don't depend on the core developers doing anything. Someone with a big enough itch to scratch could put something up on github today. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: test repo
> If additional filtering is desired: One of the "core developers" Again, we just don't have enough "core developers" to add any burden to them. We need options that *reduce* the load on developers, to encourage more participation. > This wouldn't neceessarily have to be a developer. He or she just > has to be familiar with git and the build tools in general. If they have commit access to the master git, they need to be a developer. That's kind of our definition of "developer" - you need to know enough about what's going on, to make smart choices about which patches to pull. > The difficult task is to determine, when a patch has seen enough > testing. This is the case whether we have a testing repo or not. > But then again -- Currently, most patches are applied directly to > git-head with no intermediate test repo. As I said before, that's our procedure - git head *is* our testing repo. > There would be a freeze period, during whitch only bug fixes but no > new features are applied to the test-repo. We can already do that with git head, and often do when a release is in the near future. > A fixed calendar would help. I'd say two months of patching followed > by a month of freeze would be fine. A fixed calendar won't work as we don't have dedicated developers. Our roadmap is to decide on a minimum set of features and bugfixes we want in the next release, and whatever else gets in during that too. For the next PCB release, my goals are the nanometer work and a working windows port. We're close. Meanwhile, P&A are working on modernizing the GTK gui, and some other things are getting attention. > A mini-release could be offered as a package ready to install on the > servers. This might draw more users into the testing boat. --> More > eyes, more bugs spotted, more quality. I don't mind releasing PCB more often than we do, but development just isn't that quick. *This* release was supposed to happen last November. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: test repo
> If you want real world testing, provide an environment with proper > fall back options. The fall back option is to use a release. > Debian even has four stages (experimental, unstable, testing and stable). Debian has a huge development community. We have a tiny one. Any suggestion that involves more work for the developers is just not going to work. > By the way, stuff also breaks with small changes. See the first > commits of the new layer selector. The reality is, stuff breaks for all sorts of reasons. If you expect otherwise, you're not going to be happy unless you stick with official releases. > Obviously, some quite severe issues had passed undetected. But many of them were found and fixed. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: test repo
Andrew Poelstra wrote: > On Mon, Sep 05, 2011 at 03:21:25AM +0200, Kai-Martin Knaak wrote: >> Proposal to tone down the impact of patches breaking important features: >> >>Add a branch "test" to git. This branch would work pretty much like >>sid/unstable repo of debian. It would receive all the new stuff so >>advanced users like me can give them a test run. >>If a patch stands the test by same time, it will be applied to git-head. >> > > My thoughts on this: > > This sounds like a good idea, but depends on developer availability > (who will move features from testing to master?) If additional filtering is desired: One of the "core developers" Else, whoever commited the patch in the first place. Or someone who takes the job as his/her task in the project. This wouldn't neceessarily have to be a developer. He or she just has to be familiar with git and the build tools in general. The difficult task is to determine, when a patch has seen enough testing. But then again -- Currently, most patches are applied directly to git-head with no intermediate test repo. At worst, a premature application by the "patch-master" would yield the same situation as we have now. > , and would probably end up being of limited usefulness. A transition like debian/testing to debian/stable would remove the necessity to move single patches. There would be a freeze period, during whitch only bug fixes but no new features are applied to the test-repo. Then the test repo is moved wholesale to git-head. This is sort of mini-release. A fixed calendar would help. I'd say two months of patching followed by a month of freeze would be fine. And again, the actual work of moving repo versions around does not necessarily have to be shouldered by devs. > My mil-to-nm changes and Peter C's rendering/cleanup changes have both > been so intrusive that any "minor" changes applied after-the-fact, would > simply not apply without those changes. So they would be stuck in testing > for as long as mil-to-nm is. This seems like no problem to me. It does not delay development in any way compared to the situation now. > So you might want to just checkout your own branch with this reverted, > and rebase any new changes against that: Sure, you can always go back in a git repo. But this needs informed bisection when the critical changes occured. Also, it requires the skill to work with git and build the application locally. A mini-release could be offered as a package ready to install on the servers. This might draw more users into the testing boat. --> More eyes, more bugs spotted, more quality. ---<)kaimartin(>--- -- Kai-Martin Knaak tel: +49-511-762-2895 Universität Hannover, Inst. für Quantenoptik fax: +49-511-762-2211 Welfengarten 1, 30167 Hannover http://www.iqo.uni-hannover.de -> not happy with moderation of geda-user mailinglist ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: test repo
> Thanks for setting up such a service, a well kept secret until now, > and let's keep this one quite as not to waken the wild hoards of > windoze users ;-) Well, I wanted a few people to try it to see if it worked, but apparently I need to ask a wider audience to get enough testers. If anyone wants to send me a nsi file (installer template) for gerbv or gaf, I'll add those to the mix. I did the pcb one manually, after using cygcheck to list the DLL dependencies. Mostly I want to have the pcb windows installer ready for our next pcb release; it's been a blocker since the last one. > 1) I can't zoom in using "Z" or "z". Hmmm > 2) No transparency (GL) supported. I suspect this just might not be supported. > 3) When loading a layout the file selector only displays the icons for the > top 1 or 2 files/directories and the remaining entries only when hovered > over (having focus). /me wonders if these are all issues with the gtk port > 4) the big font issue ... (probably solved in tomorrows snapshot) Yup. > Should windoze "users" file bug reports in LP for these nightly > windows snapshots too ? They're no different than any other git-head-build, so sure. Just make sure you specify that they're from my windows builds, and which timestamp. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: test repo
DJ Delorie wrote: > >> If this happens too often, I may have to quit using and testing the >> cutting edge version. After all, I still have to get my projects >> done. I guess, other users feel the same. > > This has always been the case. No reason not to change sub optimum habits. > If you want a stable reliable tool, use a released version, or stick If you want real world testing, provide an environment with proper fall back options. > with one checked-out version you know > works, or maintain your own bugfix branch. Git head is where > development happens, and when we're bringing in big changes, stuff > breaks. This is why other projects like KiCAD provide a dedicated testing repo. Debian even has four stages (experimental, unstable, testing and stable). By the way, stuff also breaks with small changes. See the first commits of the new layer selector. >>Add a branch "test" to git. > > We call this "remote repositories" like Peter's GL repo. This is only comparable, if there is just one such remote repo and if this repo is handled like Peter did. That is, frequent rebase to the main tree and in general a slow and steady progress. If any of these prerequisites is not met, the remote repository approach won't cut it. > I see no > need to have something else in the main repo that needs admin time > when we already have a working model for it. It is not working. See the mil-to-nm conversion. IIRC, Andrew had a test repo set up. Obviously, some quite severe issues had passed undetected. ---<)kaiamrtin(>--- -- Kai-Martin Knaak tel: +49-511-762-2895 Universität Hannover, Inst. für Quantenoptik fax: +49-511-762-2211 Welfengarten 1, 30167 Hannover http://www.iqo.uni-hannover.de -> not happy with moderation of geda-user mailinglist ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: test repo
On 5 September 2011 15:16, Peter Clifton wrote: > > First person to send me a shiny Apple laptop bought themselves that > development work ;) (Seriously). > I have one, but Objective-C and Cocoa are completely alien to me, otherwise I'd be all over it. Gareth ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: test repo
On Mon, 2011-09-05 at 15:14 +0100, Gareth Edwards wrote: > In fact, I'd go further and say that if we also had a native OS X > build (not macports/fink) we'd have a pretty killer proposition for > the open hardware community. First person to send me a shiny Apple laptop bought themselves that development work ;) (Seriously). Best wishes. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) signature.asc Description: This is a digitally signed message part ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: test repo
On 5 September 2011 14:28, Bob Paddock wrote: >> Thanks for setting up such a service, a well kept secret until now >> let's keep this one quite as not to waken the wild hoards of windoze users >> ;-) > >> Should windoze "users" file bug reports in LP for these nightly windows >> snapshots too ? > > Bugs are bugs, they need reported. > > This anti-Windows attitude is not helpful to the project, and I'm not > trying to pick on you specifically Bert. sorry if it seems that way. > Well said, Bob. If we /really/ want Eagle users to move to gEDA/gaf and PCB (and I do, because I'm sick fed up of seeing "open hardware" being developed on Eagle), the whole pipeline needs to run (and run well i.e. as close to native as we can get within reason) on Windows platforms. In fact, I'd go further and say that if we also had a native OS X build (not macports/fink) we'd have a pretty killer proposition for the open hardware community. Cheers Gareth ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: test repo
> Thanks for setting up such a service, a well kept secret until now Its been discussed before. > let's keep this one quite as not to waken the wild hoards of windoze users > ;-) > Should windoze "users" file bug reports in LP for these nightly windows > snapshots too ? Bugs are bugs, they need reported. This anti-Windows attitude is not helpful to the project, and I'm not trying to pick on you specifically Bert. sorry if it seems that way. In my personal view there seems to be a fear that a bunch of people from Windows will show up asking annoying questions. Yet I see the same questions over-and-over from new users on non-Windows systems, and no one gets annoyed with them. There are two groups of people involved in using EDA tools. Hobbyist trying to learn and have fun, and professionals that just want to get work done. Those in the professional category often have no choice but to use Windows due to IT departments or uninformed management policies. I know of at least one person that was here for a while, who is extremely knowledgeable in Analog Design, that left because of lack of Windows support. He is now quit vocal about it in other groups driving potential users, and more importantly contributors, away. In the hobbyist group we have to be aware of the Baby-Duck-Syndrome. When a Baby-Duck is born, it imprints the first moving thing it sees to be its Mother. In software the first tool a person is exposed to is the one they may stick with for a life time. Do we want to be a tool that a first time user can be productive with in a few minutes, or at least hours? No, that does not mean things get broken for current users that like Makefiles. First time users and long time users can be supported by the same tool, and constant wining about something maybe getting it broken by a change to improve usability is no more productive for the project than wining about Windows, and has driven off contributors. If it gets broken, it gets fixed. Outside of our group here gEDA/PCB/Et.Al. are seen as toys and hard to use. Maybe we should all asks ourselves why? [Which does not mean that my message here needs any kind of reply telling use why, we all know if some issue or other that needs addressed, starting an other wining sessions is not my goal with this message.] The attitude of 'Things would be so much better if the customers would all just go away' and stop complaining about real usability problems is sure to cause a long slow painful death of any project. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: test repo
Hi DJ, > -Original Message- > From: geda-user-boun...@moria.seul.org > [mailto:geda-user-boun...@moria.seul.org] On Behalf Of DJ Delorie > Sent: Monday, September 05, 2011 6:52 AM > To: gEDA user mailing list > Subject: Re: gEDA-user: test repo > > > > Maybe give a non-dev volunteer permission to make "official" > > development snapshots, similar to how Icarus Verilog has > done in the > > past. > > Go for it, I say. It's Free Software, they don't need > permission, they just need dedication. If they offer > something useful, people will use it. > > Note that I do nightly snapshots of gaf, pcb, and gerbv as > part of my "build it for windows" cron job: > http://www.delorie.com/pcb/geda-windows/ > but I only save the last three unique snapshots. > > Thanks for setting up such a service, a well kept secret until now, and let's keep this one quite as not to waken the wild hoards of windoze users ;-) I just downloaded the pcb-20110905.exe snapshot to check the GUI changes on my windoze XP box. Some minor bugs appear: 1) I can't zoom in using "Z" or "z". 2) No transparency (GL) supported. 3) When loading a layout the file selector only displays the icons for the top 1 or 2 files/directories and the remaining entries only when hovered over (having focus). 4) the big font issue ... (probably solved in tomorrows snapshot) Should windoze "users" file bug reports in LP for these nightly windows snapshots too ? Kind regards, Bert Timmerman. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: test repo
Kai-Martin Knaak writes: > But big text is still broken. Big text is now fixed. The LP bug had a proposed solution in it already, too, which you could have used. Also, you can now try this: ./configure --enable-coord64 if you think you're seeing overflow problems, or need a board bigger than about 2 meters (7 feet) across. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: test repo
On Sun, Sep 4, 2011 at 9:52 PM, DJ Delorie wrote: >> Maybe give a non-dev volunteer permission to make "official" >> development snapshots, similar to how Icarus Verilog has done in the >> past. > > Go for it, I say. It's Free Software, they don't need permission, > they just need dedication. If they offer something useful, people > will use it. > They don't need permission to make a snapshot, but they need permission to make "official" snapshots that are linked to and downloadable from the web page, acknowledged by the devs, etc. Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: test repo
> Maybe give a non-dev volunteer permission to make "official" > development snapshots, similar to how Icarus Verilog has done in the > past. Go for it, I say. It's Free Software, they don't need permission, they just need dedication. If they offer something useful, people will use it. Note that I do nightly snapshots of gaf, pcb, and gerbv as part of my "build it for windows" cron job: http://www.delorie.com/pcb/geda-windows/ but I only save the last three unique snapshots. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: test repo
On Sun, Sep 4, 2011 at 6:21 PM, Kai-Martin Knaak wrote: > back to git-head from gpleda.org . Fall back to the last relased > version of PCB would have been not so nice, because of the long > release cycle. On Sun, Sep 4, 2011 at 7:14 PM, DJ Delorie wrote: > use a released version, or stick with one checked-out version you know > works, or maintain your own bugfix branch. Git head is where > development happens, and when we're bringing in big changes, stuff > breaks. > Maybe give a non-dev volunteer permission to make "official" development snapshots, similar to how Icarus Verilog has done in the past. Those who want tested stability use the official release that is packaged by distros, those who want more bleeding edge but want to have had someone at least do a quick check that there aren't major board-breaking bugs can use the development snapshot, and those who want to tinker use git head. The difference between the snapshot and an official release is the time spent testing for bugs, dealing with which features to hold off the release for, etc. Even if a snapshot ends up with a major bug, if they happen often enough you won't loose a lot of features by going back a snapshot or two like you would going back to the last release. Just a thought. Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: test repo
On Mon, Sep 05, 2011 at 03:21:25AM +0200, Kai-Martin Knaak wrote: > Proposal to tone down the impact of patches breaking important features: > >Add a branch "test" to git. This branch would work pretty much like >sid/unstable repo of debian. It would receive all the new stuff so >advanced users like me can give them a test run. >If a patch stands the test by same time, it will be applied to git-head. > My thoughts on this: This sounds like a good idea, but depends on developer availability (who will move features from testing to master?), and would probably end up being of limited usefulness. My mil-to-nm changes and Peter C's rendering/cleanup changes have both been so intrusive that any "minor" changes applied after-the-fact, would simply not apply without those changes. So they would be stuck in testing for as long as mil-to-nm is. (To see this, run git diff 4d239d98 master --stat which gives 252 files changed, 25069 insertions(+), 13260 deletions(-) !) In the case of my metric changes, it might have been smart to tag a revision before the crazy changes, so that you would have something to compile without the breakage. As it stands, the actual conversion (i.e., the hardcoded-constant changes) should all be in commit 97b3260ec. So you might want to just checkout your own branch with this reverted, and rebase any new changes against that: git checkout -b kai_no_metric git revert 97b3260ec Then to update: git pull origin master git rebase master -- Andrew Poelstra Email: asp11 at sfu.ca OR apoelstra at wpsoftware.net "Do whatever you want. Do what you think is important. Everybody is an individual." --Ron Paul ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: test repo
> If this happens too often, I may have to quit using and testing the > cutting edge version. After all, I still have to get my projects > done. I guess, other users feel the same. This has always been the case. If you want a stable reliable tool, use a released version, or stick with one checked-out version you know works, or maintain your own bugfix branch. Git head is where development happens, and when we're bringing in big changes, stuff breaks. >Add a branch "test" to git. We call this "remote repositories" like Peter's GL repo. I see no need to have something else in the main repo that needs admin time when we already have a working model for it. The nanometer change *did* go on its own branch, too. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: test repo
For the last two (three?) years I used and tested Peters pcb+GL branch of PCB because it provided the joy of speed and transparency. If Peter would screw his version, which he rarely did, I could fall back to git-head from gpleda.org . Fall back to the last relased version of PCB would have been not so nice, because of the long release cycle. After openGL was finally included in git-head, I switched to this repo for my daily work. I was delighted to see the mil-to-nm upgrade. There were a few show stoppers. Most of them got rectified. quickly. But big text is still broken. This means, I need to fall back to some older version at least for gerber export. This kind of brokenness will probably happen more often when big changes to the GUI to the layer infrastructure and/or the file system will hit git head. If this happens too often, I may have to quit using and testing the cutting edge version. After all, I still have to get my projects done. I guess, other users feel the same. Proposal to tone down the impact of patches breaking important features: Add a branch "test" to git. This branch would work pretty much like sid/unstable repo of debian. It would receive all the new stuff so advanced users like me can give them a test run. If a patch stands the test by same time, it will be applied to git-head. ---<)kaimartin(>--- -- Kai-Martin Knaak Email: k...@familieknaak.de http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53 increasingly unhappy with moderation of geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
