[SM-Discuss] Being about choice is knowing where to stop

Seth Alan Woolley seth at positivism.org
Thu May 12 15:44:18 EDT 2005


On Thu, May 12, 2005 at 02:21:24PM -0400, Sergey A. Lipnevich wrote:

> Regardless even of what we vote, people are interested in certain 
> areas and will continue to work on them, with dual 32 and 64-bit 
> platform being a good example.

Yep, and I can't stop them -- they are half way around the world, and we 
don't pay them to risk payment loss.

> 
> However, just note that in your particular example of bug 8869, the 
> feature that we had was useless for the user because it essentially 
> didn't work (I agree that feature itself is not to blame, it's the 
> spell's problem, but the whole thing didn't work in the end). 
> Moreover, I had never used this --cflags feature, or even the 
> "customize configuration" feature of sorcery, I always disable it 
> because that's one less question in the long string of cast questions. 

I never use it because I tend to add support for whatever I want 
directly into the spell or file a bug for sorcery :)

> On the other hand, I was on a number of occasions interested in what 
> exactly are CFLAGS and configure options fed into the build, but alas, 
> there's no way to know this in general, especially for non-configure 
> spells; we don't retain or manage this information. 

It's in three places: the global depends store, global defaults, and the 
local persistence store.

I'm sure a feature to gaze could be added to make these visible to the end user.

We tend to implement before user-accessible interfaces to the underlying 
system are provided in gaze.  We probably should be more careful of that 
in the future.

> Meaning, there's 
> no easy user-accessible answer to the question "what options was this 
> spell built with," as well as backup and restoration of these options 
> for troubleshooting. Or for example, we have many spells that have 
> BUILD file just for the purpose of adjusting OPTS variable, instead of 
> having a simple declarative way of doing that and reducing complexity 
> and number of files.
> 
> I think it's time to be smarter about choices we provide, that's all.

Yep, and they first start with proposals, then discussion, then 
documentation, then implementation.

> 
> Quoting Seth Alan Woolley <seth at positivism.org>:
> 
> >Sergey, I sympathize with your comments, but see:
> >
> >http://bugs.sourcemage.org/show_bug.cgi?id=8869
> >
> >Users are filing bugs on the most _obscure_ of customized hacks.
> >
> >I think we should leave the decision of what to support in the hands of
> >the developers.  Yes, it's a whole hell of a lot to support odd CFLAGS
> >like that, but we have the WONTFIX variable.  As QA Team Leader, I've
> >set a few WONTFIXes or LATERs myself.
> >
> >The last thing we want is to become the patch-hell that is gentoo
> >portage, and Andrew's put us on the correct track (like grimoire
> >FUNCTIONS allowing the spell writer to extend sorcery themselves without
> >having to patch sorcery and get a new release) in this regard.
> >
> >I think though that md5unpack (which was something I think I helped
> >introduce) isn't as important as, say, full-tree-aware dependency
> >resolution and cast ordering on partial rebuilds and updates.
> >
> >So I say, let the developer decide, and if there are conflicts, let's
> >vote up or down on it, all together, as developers.
> 

-- 
Seth Alan Woolley [seth at positivism.org], SPAM/UCE is unauthorized
Key id 00BA3AF3 = 8BE0 A72E A47E A92A 0737  F2FF 7A3F 6D3C 00BA 3AF3
Quality Assurance Team Leader; Security Team Member, Leader Emeritus
Linux so advanced, it may as well be magic http://www.sourcemage.org
Elected Coordinating Committee Member, Secretary, and Finances Chair
Pacific Green Party of Oregon - Peace - http://www.pacificgreens.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.ibiblio.org/pipermail/sm-discuss/attachments/20050512/3615a84a/attachment.bin 


More information about the SM-Discuss mailing list