Thread: [Plib-devel] Portability - policy suggestion
Brought to you by:
sjbaker
Menu
▾
▴
plib-devel
|
From: Alex P. <ale...@ie...> - 2005-01-16 04:36:51
|
Steve, maybe we could have a policy that, for every apparently-supported target architecture, at least one of the developers with write access must be able to build and run code on that architecture. If that is not the case, either none of the relevant contributors meets the project's criteria for write access or (more likely) they need to be added ... |
|
From: Steve B. <sjb...@ai...> - 2005-01-16 06:20:54
|
Alex Perry wrote: > Steve, maybe we could have a policy that, for every apparently-supported > target architecture, at least one of the developers with write access > must be able to build and run code on that architecture. I have never yet refused a request for developer privilages. If someone wants to do that, they only have to ask. I believe I gave one of the BSD guy's access only a week or two ago. ---------------------------- Steve Baker ------------------------- HomeEmail: <sjb...@ai...> WorkEmail: <sj...@li...> HomePage : http://www.sjbaker.org Projects : http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net http://prettypoly.sf.net -----BEGIN GEEK CODE BLOCK----- GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M- V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++ -----END GEEK CODE BLOCK----- |
|
From: Frederic B. <fre...@fr...> - 2005-01-16 09:41:25
|
Steve Baker a =E9crit : > Alex Perry wrote: > >> Steve, maybe we could have a policy that, for every apparently-support= ed >> target architecture, at least one of the developers with write access >> must be able to build and run code on that architecture. > > > I have never yet refused a request for developer privilages. If someon= e > wants to do that, they only have to ask. I believe I gave one of the B= SD > guy's access only a week or two ago. It could help to use a central patch submission repository like the one=20 provided by sourceforge, so patches are not lost in the bulk of the=20 list. I see the 'Patches' option is not enabled for the Plib project but=20 it is available to project admin. As an example, here is the patch=20 submission form from the fgsd project : http://sourceforge.net/tracker/?func=3Dadd&group_id=3D45131&atid=3D441962 A list of categories could help too, beginning with the list of=20 currently supported OS, and an assigned maintainer that could refer to=20 the list just *before* a release if he follow the list loosely. -Fred |
|
From: Frederic B. <fre...@fr...> - 2005-01-16 09:51:15
|
Frederic Bouvier a =E9crit : > Steve Baker a =E9crit : > >> Alex Perry wrote: >> >>> Steve, maybe we could have a policy that, for every=20 >>> apparently-supported >>> target architecture, at least one of the developers with write access >>> must be able to build and run code on that architecture. >> >> >> >> I have never yet refused a request for developer privilages. If someo= ne >> wants to do that, they only have to ask. I believe I gave one of the=20 >> BSD >> guy's access only a week or two ago. > > > It could help to use a central patch submission repository like the=20 > one provided by sourceforge, so patches are not lost in the bulk of=20 > the list. I see the 'Patches' option is not enabled for the Plib=20 > project but it is available to project admin. As an example, here is=20 > the patch submission form from the fgsd project : > http://sourceforge.net/tracker/?func=3Dadd&group_id=3D45131&atid=3D4419= 62 > > A list of categories could help too, beginning with the list of=20 > currently supported OS, and an assigned maintainer that could refer to=20 > the list just *before* a release if he follow the list loosely. May I also suggest that any new ( or already registered ) developer be=20 assigned a specific task/category so that it is clear who is doing what=20 and no one wait the other do the job. I am volunteering to maintain the windows build. My sourceforge account=20 is 'fredb'. Regards, -Fred |
|
From: Bert D. <dri...@pl...> - 2005-01-16 16:17:23
|
On Sat, 15 Jan 2005, Alex Perry wrote:
> Steve, maybe we could have a policy that, for every apparently-supported
> target architecture, at least one of the developers with write access
> must be able to build and run code on that architecture. If that is not
> the case, either none of the relevant contributors meets the project's
> criteria for write access or (more likely) they need to be added ...
Hrrrm, with 20/20 hindsight it is obvious that I screwed this one up.
Let me share what I did.
I reviewed all patches Martin had pointed me to, applied the good ones
one by one on my development machine, and reported the ones I would not
take ownership of to this list. After applying a patch, I do a build in
the development tree to verify that the problem has gone before I commit
it (for a build problem, that's verifying that the build proceeds, for a
crash, it's running the appropriate test code, etc).
If I don't have a perfect explanation for why something fixes it, I even
go as far as temporarily backing out the change in a scratch build tree
to check that the problem comes back without the fix.
When I'm done, I go back and do a cvs -q diff over the whole tree. I
obviously borked this step (probably by not running it over the entire
tree), as the uncommitted patch was happily staring at me when I diffed
it this morning.
I usually catch such goofs by building a test straight from anon-cvs,
but that day anon-cvs was a bit backlogged so I couldn't do it at home.
I did a test build at $ORKPLACE under FreeBSD 4.10 the next day, and as
fate would have it, the 4.10 has both
/usr/include/{sys,machine}/soundcard.h, so the patch isn't required
there.
Anyway, I apologize for the goof. If you can think of procedural changes
to prevent reoccurance I'm all ears.
For what it's worth, just applying all patches that are available isn't
the answer. Patch trackers, like the one on Sourceforge, only work when
patches that are below par get rejected immediately. I've payed dearly
for keeping patches because they "contain good ideas" -- they linger and
realistically, if the submitter doesn't find the time to do them right,
what is the chance that you as a maintainer will?
Cheers,
-- Bert
--
Bert Driehuis -- dri...@pl... -- +31-20-3116119
If the only tool you've got is an axe, every problem looks like fun!
|
|
From: Martin S. <Mar...@un...> - 2005-01-16 18:39:04
|
Bert Driehuis wrote:
> On Sat, 15 Jan 2005, Alex Perry wrote:
>> Steve, maybe we could have a policy that, for every apparently-supported
>> target architecture, at least one of the developers with write access
>> must be able to build and run code on that architecture. If that is not
>> the case, either none of the relevant contributors meets the project's
>> criteria for write access or (more likely) they need to be added ...
> Hrrrm, with 20/20 hindsight it is obvious that I screwed this one up.
> Let me share what I did.
> I reviewed all patches Martin had pointed me to, applied the good ones
> one by one on my development machine, and reported the ones I would not
> take ownership of to this list. After applying a patch, I do a build in
> the development tree to verify that the problem has gone before I commit
> it (for a build problem, that's verifying that the build proceeds, for a
> crash, it's running the appropriate test code, etc).
> If I don't have a perfect explanation for why something fixes it, I even
> go as far as temporarily backing out the change in a scratch build tree
> to check that the problem comes back without the fix.
> When I'm done, I go back and do a cvs -q diff over the whole tree. I
> obviously borked this step (probably by not running it over the entire
> tree), as the uncommitted patch was happily staring at me when I diffed
> it this morning.
> I usually catch such goofs by building a test straight from anon-cvs,
> but that day anon-cvs was a bit backlogged so I couldn't do it at home.
> I did a test build at $ORKPLACE under FreeBSD 4.10 the next day, and as
> fate would have it, the 4.10 has both
> /usr/include/{sys,machine}/soundcard.h, so the patch isn't required
> there.
> Anyway, I apologize for the goof. If you can think of procedural changes
> to prevent reoccurance I'm all ears.
> For what it's worth, just applying all patches that are available isn't
> the answer. Patch trackers, like the one on Sourceforge, only work when
> patches that are below par get rejected immediately. I've payed dearly
> for keeping patches because they "contain good ideas" -- they linger and
> realistically, if the submitter doesn't find the time to do them right,
> what is the chance that you as a maintainer will?
> Cheers,
> -- Bert
> --
> Bert Driehuis -- dri...@pl... -- +31-20-3116119
> If the only tool you've got is an axe, every problem looks like fun!
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> https://lists.sourceforge.net/lists/listinfo/plib-devel
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------
|
|
From: Martin S. <Mar...@un...> - 2005-01-16 18:45:29
|
I'm sorry, folks, for the unbaken posting. Here's the complete one: Bert Driehuis wrote: > Hrrrm, with 20/20 hindsight it is obvious that I screwed this one up. There's no problem about doing something wrong - we are human beings and everyone is at fault sometime. It's just that the timing was very bad. Steven announced he'd go for a release on the 11th, you added one patch on the 12th, I repeated that one patch was still missing on the 13th, including a copy of the patch (and everyone ignored it), Steven did the release on the 15th - and we recieve your comment on the 16th. Maybe with so many so loosely coupled contributors such a tight timing is probably not the best way to go, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -------------------------------------------------------------------------- |
|
From: Steve B. <sjb...@ai...> - 2005-01-16 19:43:59
|
Martin Spott wrote: > Maybe with so many so loosely coupled contributors such a tight timing > is probably not the best way to go, Well, it's not the end of the world - we can just make another release within a week or two. Once we've gotten the thing to the point where it's basically releasable, doing a new version is a 10 minute job - and version numbers are a very cheap commodity. ---------------------------- Steve Baker ------------------------- HomeEmail: <sjb...@ai...> WorkEmail: <sj...@li...> HomePage : http://www.sjbaker.org Projects : http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net http://prettypoly.sf.net -----BEGIN GEEK CODE BLOCK----- GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M- V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++ -----END GEEK CODE BLOCK----- |
|
From: Martin S. <Mar...@un...> - 2005-01-16 21:02:28
|
Steve Baker wrote: > Well, it's not the end of the world - [...] You don't have any idea on how much people depend on PLIB releases ;-)) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -------------------------------------------------------------------------- |
|
From: Martin S. <Mar...@un...> - 2005-02-05 17:38:52
|
Steve Baker wrote: > Once we've gotten the thing to the point where it's basically releasable, > doing a new version is a 10 minute job - and version numbers are a very > cheap commodity. Would anyone consider reviewing the patches as proposed by Paolo Leoncini ? I think improving the 3DS loader is always a "good thing" (TM :-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -------------------------------------------------------------------------- |
|
From: Steve B. <sjb...@ai...> - 2005-02-05 18:39:43
|
Martin Spott wrote: > Steve Baker wrote: > > >>Once we've gotten the thing to the point where it's basically releasable, >>doing a new version is a 10 minute job - and version numbers are a very >>cheap commodity. > > > Would anyone consider reviewing the patches as proposed by Paolo > Leoncini ? > I think improving the 3DS loader is always a "good thing" (TM :-) Yeah - those are good changes - I've just been too busy to do anything about them. ---------------------------- Steve Baker ------------------------- HomeEmail: <sjb...@ai...> WorkEmail: <sj...@li...> HomePage : http://www.sjbaker.org Projects : http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net http://prettypoly.sf.net -----BEGIN GEEK CODE BLOCK----- GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M- V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++ -----END GEEK CODE BLOCK----- |
|
From: Martin S. <Mar...@un...> - 2005-02-27 12:34:11
|
Steve Baker wrote: > Martin Spott wrote: >> Would anyone consider reviewing the patches as proposed by Paolo >> Leoncini ? >> I think improving the 3DS loader is always a "good thing" (TM :-) > > Yeah - those are good changes - I've just been too busy to do anything > about them. Any progress in the meantime ? BTW, I made a copy of these patches available here: ftp://ftp.uni-duisburg.de/FlightGear/Devel/lepa069/ .... in case the original source might go lost, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -------------------------------------------------------------------------- |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X