Distro/irc20051024

distro meeting to follow Distro/irc20051010
date: October 24th, 2005
checkin time: 5:15 PDT -0700 (8:15pm EDT)
meeting time: 5:30 PDT -0700 (8:30pm EDT)
meet in irc.freenode.net #freegeek-distro
Agenda

commitments

from last meeting:
vagrant:
(dropped) hand-roll package repository scripts until a better method is devised.
set up mini-dinstall package repository for freekbox3 packages
head to portland and wake them up (probably in november)
set up a few machines to post to freegeekcolumbus's popcon (done: 3 machines)
release new simple-cdd packages (done)
hassle martin about svn (partially done)
martin(carryover):
(carryover) get tested a freekbox3 package release
(carryover) post instructions to pdx QC process.
(carryover) finish svn, add user access (either ssh or webdav)
rob:
(carryover) try submitting to skippy's popcon server (done)
michael:
(carryover) I will email the adoptionteachers list [to arrange a meeting to discuss developing user personae]
(carryover) get feedback from build teachers on user personae.
(carryover) WormRunner will talk on the list
matteo:
(carryover?) join the list discution on kde v gnome
set up a few boxes to submit to skippys popcon server
set up fg-oly changes box
ongoing items:

user-oriented-design
Prognosis (how is this project looking?) & Long-term outlook (including definition of objectives, estimation of required work, and timeline)
hosting our own popularity-contest server (http://popcon.debian.org)
Install CD: multi-profile or otherwise?
svn repository hosted at svn.freegeek.org ?
1. buildbot-like functionality
2. irc bot
3. more accounts
4. web interface sometimes stalls for 5-30 minutes
how is the meeting time/date ~~(tuesdays, 7pm, -0700)~~ (mondays, 5:30pm, -0700) for active participants?
packaging & repository
How to propose and approve changes to FreekBox3
Fork? Branch?
How can we set goals and deadlines?
new items:

(posted friday before the meeting or sooner)
new items here
late items:

(posted saturday before meeting or later) may not have time
late items here
log / summary

meeting content should get posted here. some possible useful categories below.
Present

Summary

Commitments

skippy: automate analysis of popcon data.
skippy: remove multi-profile stuff from future agendas
skippy: bring games separation to the list.
skippy: ~~paste the raw log~~ DONE
tymp: post link to rough wiki distro development page
tymp: post and hopefully attempt some xthis xthat removal suggestions
tymp: propose a wiki template for distro changes, and raise the issue of clarification process on list
vagrantc: attempt to get svn functional
vagrantc: experiment with ways to make games optional
Full Log

<skippy> <meetup>
<skippy> vagrant: status of your items from last meeting?
<vagrantc> well, i've still dropped package repository stuff.
<vagrantc> i haven't set up a mini-dinstall repository
<vagrantc> i'll be heading to portland sometime in november, most likely.
<vagrantc> i set up 3 machines to post to the popcon
<vagrantc> released a new simple-cdd package
<vagrantc> and i hassled martin a little about svn
<vagrantc> next person?
<tymp> lets tap martin if he shows up
<vagrantc> or any questions ...
<vagrantc> stillflame: your commitments? :P
<skippy> I've no questions.  If no one else does...
<tymp> i have one box at home submitting to skippy's popcon
<skippy> sweeeeeet
<tymp> questions about that for later..
<tymp> - i have questions, that is
<skippy> meho said to me earlier today that his popcon stuff would be coming together tomorrow.
<tymp> micheal is absent, meho : you here?
<tymp> skippy : how did you get away with no commitments?
<tymp> :)
<skippy> bribery and intimidation
<tymp> hehe
<skippy> next item: User Oriented Design
<{gate}> I just slept with the boss
<skippy> any new thoughts on this?
<vagrantc> i had a frustrating conversation with obnosis
<skippy> I've been thinking about it a lot in non-freekbox products I use.
<skippy> who is obnosis?
<vagrantc> i presume, an adoption teacher?
<skippy> in what way was it frustrating?
<vagrantc> basically, they said the only use of the personae approach would be to orient new teachers, and what we were doing with the distro was stupid.
<tymp> i've been reading the book, 'the inmates are running the asylum', by alan cooper.  user-oriented-design is, presumably, his brainchild.
<tymp> when i'm done, i'll write a summary.  i think that will help.
<skippy> vagrantc: that's disappointing.
<vagrantc> skippy: obnosis also wrote the multi-person persona ...
<tymp> vagrantc : there's obviously some misunderstanding.  i think the disconnect between adoptionteachers and distro is partly to blame.
<vagrantc> skippy: it honestly felt like a troll-baiting conversation that i fell into.
<vagrantc> tymp: yes, i think you are right. though i think some of it is specific to the person.
<tymp> he sounded pretty hot about it all
<tymp> is obnosis joe, whose message richard forwarded to distro?
<vagrantc> i think it is lisa kochold
<tymp> hmm
<vagrantc> tymp: based on reading the adoptionteachers archives
<skippy> was it a real objection, or was it perhaps a "turf war" issue ?
<vagrantc> very fond of CAPITAL LETTERS to HIGHLIGHT IMPORTANT IDEAS
<tymp> okay, i think you're right.  i replied to her adoptionteachers message in an attempt to clarify the use of the personae.. but i guess it didn't work very well
<skippy> i.e.: we make it so easy that adoption teachers are less valued / important ?
<vagrantc> skippy: no, we've screwed everything up and we should focus on supporting CD-RW and DVD burners.
<tymp> * i think you're right, vagrantc, that it's lisa kochold
<vagrantc> er, hachold
<vagrantc> er.
<vagrantc> kachold
<skippy> well, I do think we should support CDRW devices; but that has little to do with User Oriented Design
<vagrantc> http://lists.freegeek.org/pipermail/adoptionteachers/2005-October/000058.html
<tymp> well, we should all probably be on the adoptionteachers list, if nothingelse
<skippy> oh right.  I read that.  I dismissed it as this person not understanding the intent of UOD.
<tymp> http://lists.freegeek.org/pipermail/adoptionteachers/2005-October/000059.html
<tymp> (my response to her)
<tymp> i think when we get more clear among ourselves, we'll be in a better position to make it clear to others..  and that should help, or at least, may be the best we can do
<tymp> * clear about the intent and process of UOD
<skippy> gah -- does no one instruct these people on the importance of line wrapping?
<tymp> skippy : that's a pipermail bug - in my opinion
<tymp> (some webmail clients send messages unwrapped)
<skippy> okay, so no one here has anything new to add re: User Oriented Design?
<skippy> I do, actually.
<tymp> so do i, but it's still amorphous
<vagrantc> i have some not particularly good insight
<skippy> I've been looking at the "stuff" I use every day, and trying to figureout how much effort went into it from the user's perspective.
<skippy> It's been an interesting way to look at many things I take for granted.
<skippy> tymp: amorphous ?
<tymp> not entirely formed
<skippy> anything you care to share tonight?
<vagrantc> a poorly formed idea can be moreuseful than none at all.
<tymp> eh, just random thoughts about the book.  it will serve better when i finish it and collect my thoughts..
<tymp> well, i think it is a good idea, and we should strive for it
<skippy> vagrantc: care to share your not-so-good insight?
<tymp> but it is really meant for application design, not os design - so this will complicate things for us a bit
<vagrantc> well, basically, we're not really making a strong commitment to developing personae and incorporating it into our design decisions ...
<tymp> because the purpose of the os is so broad
<skippy> tymp: we're not designing an OS.
<skippy> vagrantc: example?
<tymp> skippy : not exactly, but it is something broader than a single application
<vagrantc> skippy: well, in my opinion, none of the personae in the adoption section are very good. obnosis's is arguably the best one, but it's a little oriented towards teaching rather than distro needs
<vagrantc> tymp: we are working towards a single (or maybe two) working environment(s)
<skippy> i consider our goal to be a framework, more than an application or OS.
<tymp> skippy : what do you mean by 'framework'?
<vagrantc> i don't feel like i'm connected enough to the user-base that i thinkwe're trying to develop for, so i don't feel like i can really take it on.
<tymp> i think distro needs to be more connected to the user-base
<tymp> perhaps we can design some surveys
<skippy> tymp: well, I think it's clear we're not developing an application.  Nor are we doing nitty-gritty OS design.  We're making some selections for what'savailable; and I consider that to be more a "framework" from which other "stuff" can be done.
<skippy> tymp: alas, FGCMH doesn't yet have a user base, so we have a chicken and egg problem.
<tymp> skippy : i think i see what you mean.
<skippy> And relying on FGPDX to explain their user base seems unwise, given how pressed for time they all are.
<vagrantc> essentially, we are making package selections and pre-configuration,with a hint of branding ...
<tymp> there are a number of limitations to how much control we have of the functionality
<skippy> shall we move on to prognosis?
<tymp> i'm game
<vagrantc> sure.
<skippy> how IS this project looking?  Are y'all ready to throw the towel in?  Are we barking up the wrong tree?
<tymp> i still feel our project is generally ill-defined. though i'm not sure what to suggest
<tymp> besides setting some goals and deadlines
<skippy> should we perhaps shelve collaboration for a short time, and each group work on their own thing?  Then come back to see what we can synthesize?   Or is that asking for trouble?
<vagrantc> i think the package development is going ok, but it's a little stalled with disagreements between {gate} and myself on the multi-profile takeover scripts
<tymp> skippy : i simply haven't had time to work on it much
<vagrantc> i will likely have very little time for the next couple weeks. i might slip in a week or two of frenzied development sometime in november and/or december ...
<tymp> the most important thing to me seems to be getting feedback and creatinga process for putting changes in place
<vagrantc> i agree.
<tymp> my minor changes (i still think they're minor, and haven't heard any contradiction of that) have still not gotten tried out... after ... months?
<vagrantc> the technical aspects are relatively easy to implement once we know what we want.
<skippy> tymp: aye; and I doubt PDX will give much effort to the GNOME image.
<tymp> skippy : i think i will have to go down and put a box in place.. :/
<vagrantc> the CD installer has been relatively easy for me to work on, becausei have a relatively specific goal- create a CD to install freekbox3, lessdisks,baseserver and include some additional server software.
<tymp> but i'm still unclear how far meho got with putting up an fb-oly box
<tymp> vagrantc : i seriously intend to make an installer to my liking .. hopefully in november
<vagrantc> tymp: good. i'll try and help as much as i can.
<tymp> are there any measurable goals we can set?
<vagrantc> my other goal is to create infrastructure for custom distros.
<skippy> so, the definition of objectives would be:  creating a process for putting changes into place
<vagrantc> skippy: sounds good,.
<tymp> skippy : and those changes should reflect "user" input as much as possible...
<skippy> so:  what changes?  into what place?
<tymp> into production, no?
<vagrantc> changes would include: minor tweaks to freekbox3, and infrastructureto support other alternatives (such as the gnome variant)
<{gate}> at least into cvs/svn.  so that when an idea comes accoss one of the many lists it can at least go into a Q.  and maybe even have someone say they will do it
<tymp> in olympia, i basically have total freedom to change the release... but i'm not comfortable with that freedom - it doesn't seem right
<vagrantc> tymp: what doesn't seem right?
<tymp> {gate} : does that seem like something that will be resolved by having svn up and running and in use?
<tymp> vagrantc : being in the position to make unilateral decisions about whatadopters in olympia will get
<vagrantc> i think having svn running will help, but it still doesn't resolve differences of opinion
<{gate}> tymp: part of it.  but then RT or trac is needed for some too.
<vagrantc> tymp: well, the process in portland was largely no different.
<tymp> a more formal proposal method would be of help
<tymp> vagrantc : that's what i gather.  it would be better to have it more ...solicitous of input, no?
<vagrantc> tymp: that's what i've been trying to do the past year :)
<tymp> * more based on actual user feedback
<{gate}> at least have a vote for soemthing to make it in
<vagrantc> tymp: but hard to do remotely.
<skippy> is there any mechanism at PDX for users to submit feedback ?
<tymp> vagrantc : yeah.  and generally hard too
<{gate}> like at least 3 crutuil people have to agree its usefull or something like that
<vagrantc> skippy: no formal mechanism, per se.
<vagrantc> skippy: there's tech support, and there's feedback from adoption teachers...
<vagrantc> {gate}: one of the problems is that frequently people don't have an opinion ...
<skippy> okay, so in addition to our work on the actual "product" we need to help develop some process for user input.  Something more substantial than just popcon
<tymp> {gate} : i think we want a process, where proposals are open for commentand it's understood when and under what conditions they will be incorporated
<vagrantc> {gate}: so you might end up with 2 people disagreeing, and nobody else saying much.
<tymp> vagrantc : and that is the trend, so far, huh?
<vagrantc> tymp: to some degree.
<vagrantc> like my push for switching from xterm to aterm ...
<tymp> it's what i've seen mostly
<tymp> yeah
<vagrantc> i got feedback from stillflame and skippy ... not sure who else. onein the affirmative, one in the negative ...
<tymp> i am thinking that we should change over to gnome.  that seems do-able, based on recent posts.
<vagrantc> to me, it felt like a very trivial issue.
<vagrantc> tymp: i think stillflame was mostly thinking about the technical switch, and not the organizational switch, but i could be wrong.
<tymp> vagrantc : i have no objection.  i use gnome-terminal or ... what's the kde one?
<vagrantc> konsole
<tymp> aye
<skippy> vagrantc: I don't care much one way or the other (xterm / aterm).  I like xterm; but if aterm is a complete work-alike, so be it.
<skippy> as long as the user has been ocnsidered in the decision.
<{gate}> does aterm bring in any other afterstep stuff
<vagrantc> skippy: sure.
<tymp> i made ... http://wiki.freegeek.org/index.php/FreekBox_Development
<tymp> could be a place to formally post proposed changes, timelines for decision, comment process, etc
* vagrantc wishes for case-insensitivity in the wiki
<vagrantc> {gate}: aterm does not really bring in much, if any, additional dependencies than xterm.
<tymp> vagrantc : that would be a pretty deep hack.  but not impossible, i spose
* vagrantc thinks mod_rewrite
* vagrantc thwacks self with off-topic bat
<skippy> tymp: care to commit to bringing that URI to the list?
<vagrantc> tymp: i think some combination of list and wiki would be better ...
<tymp> vagrantc : ah, that could do it too.  okay i share your thwack
<tymp> vagrantc : yes, but the wiki as a semi-formal document - would work better than the list.
<vagrantc> i feel like wiki is a terrible place to discuss things.
<{gate}> I have no issues with aterm over xterm, hell I'm an old afterstep person anyways.  just make sure we have an alias or link to for xterm
<tymp> skippy : ok
<tymp> commit : post link to rough wiki distro development page
<skippy> next issue: popcon
* vagrantc cheers for data and results!
<tymp> do we have a topic in the agenda where the aterm/xterm item and other such things should go?
<skippy> tymp, not exactly.
<vagrantc> tymp: maybe a review of proposed changes should go into the weekly meetings ?
<tymp> i'd like to parking-lot it
<tymp> (parking lot : if we have time for it)
<vagrantc> looks like 5 or more machines reporting to freegeekcolumbus.org popcon
<skippy> I ran one of the anaylsis scripts on it.
* vagrantc prefers bike rack to parking lot, and table overall
<tymp> i am confused by the result data.  and, i can't tell if my results are continually getting incorporated
<vagrantc> looks like the last results were generated on the 18th
<tymp> vagrantc : yes, review of proposed changes sounds good for ongoing biz
<skippy> I can re-run the analysis, if y'all want.
<tymp> i have it in cron.daily... so, that doesn't seem right
<tymp> skippy : how often is the analysis running?
<skippy> tymp, whenever I execute it.
<tymp> ah, ok
<vagrantc> skippy: have you looked into making a more involved setup, like withpopcon.debian.org, that has sorted categories
<tymp> maybe that explains
<skippy> since there's so few people submitting, automating it doesn't seem helpful yet.
<vagrantc> tymp: default is a cron.weekly
<skippy> vagrantc: not yet.
<tymp> vagrantc : i know, i wanted to see more quickly if it was getting submitted regularly
<tymp> skippy : automating it would help me see how the results format works
<skippy> ok tymp
<skippy> COMMIT: automate analysis of popcon data.
<tymp> skippy : did you look at that script.. for displaying html results?
<tymp> - /usr/share/doc/popularity-contest/examples/popcon.pl
<skippy> tymp: not yet.  will look.
<tymp> i'm hoping that would make it clearer
<tymp> that seems good.  move on?
<tymp> time check?
<skippy> Install CD
<skippy> mutli-profile or otherwise?
<tymp> i think that has kind of been covered recently..
<vagrantc> i think at previous meeting, we agreed that {gate} would work on a CD for freegeek columbus, and i would continue to work ona  multi-profile CD ?
<tymp> we are each going to work on what we want
<skippy> commit: remove multi-profile stuff from future agendas
<skippy> SVN
<tymp> and i'm loosely commiting to a single profile installer
<tymp> what is the current status?
<vagrantc> who's got svn accounts?
<skippy> stillflame is not present, so this is basically on hold.
<skippy> I have an account.
<{gate}> i do
<tymp> i think i'll need to get a gpg key and stuff first
<vagrantc> if i were more stable, i would take over the svn project.
<vagrantc> but i have no idea what sort of access i will have in the future.
<vagrantc> internet access ...
<tymp> hmm
<skippy> I honestly don't understand why it's taking so long.
<vagrantc> sounds like several arbortive attempts due to hardware.
<tymp> once it is done, though, it will be low-maintenance, right?
<skippy> SVN isn't hard to set up; the import worked for me; and all the bells and whistles that PDX folks want ought not hold up the server.
<tymp> are they actually holding up the server?  i'm unclear.
<skippy> they were.  it took three weeks to get accounts created, didn't it?
<tymp> well, yes, but now?
<vagrantc> i guess, i will attempt to move it forward.
<skippy> do we actually have a _repository_ or do we just have a server?
<skippy> Last I saw was that there was no official repository
<skippy> just the SVN server
<{gate}> a server with some temp repo
<{gate}> not even an import
<vagrantc> i can try to work on it, since it's a big pain at this point.
<tymp> ugh.  and was the repository going to be in trunk/branch format?
<vagrantc> tymp: cvs2svn will do that
<skippy> the repository ought to be do trunk/branch
<tymp> agreed
<skippy> Active development should go on in trunk.
<skippy> tags and/or branches should contain historical snapshots
<tymp> so, that would happen when the cvs got transferred over
<vagrantc> commit: attempt to get svn functional
<skippy> meeting date / time
<tymp> vagrantc : so, we could get it functional now and add the bells and whistles without interfering?
<vagrantc> tymp: yes.
<skippy> Seems this date/time is as convenient as the other one for the folks who regularly participate.
<tymp> yes
<vagrantc> yes.
<skippy> and it seems no less convenient for those not participating regularly.
<vagrantc> but we have reduced PDX participation from minimal to non-existant.
<tymp> though, perhaps not for michael and.. right
<vagrantc> tymp: but michael actually said he preferred this time ... despite not showing up, really.
<tymp> lets see if we can rouse more involvement from pdxers for next monday
* vagrantc wonders if vagrantc can make it next monday
<tymp> transitions always seem to cause a little confusion
<skippy> here's a question that's not meant to be inflammatory even though it sounds like it:  do we _need_ PDX involvement?  They seem quite content with the status quo; which is what we're looking to change.
<vagrantc> we should make sure to be more on it about announcing the meeting onfriday and/or saturday, i think.
<vagrantc> skippy: i think we should do what we want, and when portland sees how much better it is, they will hopefully adopt it :)
<skippy> vagrantc++
<vagrantc> it's not worth trying to drag them into it if they don't seem vestedin it.
<tymp> skippy : i think we need them, yes.  the largest user-base is there.
<tymp> vagrantc : i guess it depends how much energy we'd want to spend 'dragging'.  i think a little more wouldn't hurt.  i certainly don't want to dismiss them.
<tymp> but i wouldn't really contradict what either of you said
<skippy> I don't mean to dismiss them; but if the meetings are largely things they're not likely to participate in, then I don't think we should bend over backwards to accomodate their scheduling.
<vagrantc> tymp: well, i want to get something done, and i feel like it's at least 3-6 months behind what i would like to see because of trying to get involvement from PDX
<skippy> if this date and time works for us, I propose we keep it.
<tymp> hmm
<skippy> if this doesn't work for us, speak up.
<tymp> lets keep it in ongoing items
* vagrantc agrees with tymp
<skippy> ok
<skippy> packaging & repository
<skippy> who added this?  What's the issue?
<skippy> is this something distinct from the SVN repository?
<vagrantc> i can think of a packaging related issue ...
<vagrantc> skippy: i think package repository
<tymp> it's an old item.  we need more people able to do packaging and maintainit..
<vagrantc> so, we need to get some new freekbox packages out the door, and a place to put them.
<vagrantc> the thing holding up another package release is incorporating the multi-profile takeover scripts ...
<vagrantc> and testing if my changes to magix actually work.
<{gate}> vag: they did not blow up last time I did an X install
<tymp> vagrantc : magix changes are in the cvs?
<vagrantc> as far as repository, the existing repository http://web.freegeek.org/freekbox3 isn't so terrible.
<vagrantc> tymp: yes.
<vagrantc> {gate}: and you're using the latest from cvs ?
<{gate}> 3 weeks ago.
<skippy> i'd like to mirror the repository here in columbus.
<{gate}> and I saw some magix changes in there
<vagrantc> skippy: that shouldn't be hard.
<tymp> to clarify : package release means having newer packages in cvs.  and having it in production in pdx still means someone updating the clone image?
<vagrantc> skippy: i can work with you on the mirroring stuff.
<vagrantc> tymp: package release means new packages at http://web.freegeek.org/freekbox3
<skippy> vagrantc: is there more to it than an rsync or wget ?
<vagrantc> skippy: either should work.
<tymp> vagrantc : ok, right.  pdx release is still involves the cloner image, though, right?
<vagrantc> skippy: setting it up so it gets updates as soon as they are available wouldn't be too much harder.
<skippy> ok.  what else needs to be discussed for this item?
<vagrantc> tymp: correct.
<tymp> when meho ran the oly script, it took an extremely long time getting updates, so i assume the cloner image is quite old.  oh well, though.
<vagrantc> maybe this would be an appropriate place to discuss packaging changes ? i.e. aterm
<vagrantc> tymp: yes, the cloner image tends to be very old.
<tymp> i had a thought : can we remove some of the xthis xthat programs?
<vagrantc> tymp: it may even be from a pre-sarge release.
<skippy> tymp: like what?
<vagrantc> the devil is in the details.
<vagrantc> i have gone over the freekbox3 package list and made all my package removal suggestions to the list several times.
<vagrantc> the only other thing we might want to consider is dropping packages that are depended on by other packages.
<tymp> vagrantc : xclipboard, xclock, xcutsel, xfontsel, xkill, xmag...
<vagrantc> tymp: have you tried to "apt-get remove" them? does it remove other things we want?
<tymp> i suppose i should make a comprehensive list, then.  no, i haven't tried.
<vagrantc> maybe post to the list removal suggestions?
<skippy> wesnoth !
<vagrantc> yes.
<tymp> commit : post and hopefully attempt some xthis xthat removal suggestions
<skippy> it sounds like the argument could be made to remove thunderbird, even.
<vagrantc> that brings up the other packaging things.
<tymp> what is still holding up wesnoth removal?
<vagrantc> splitting out the freekbox3-games stuff
<skippy> tymp: inertia.
<vagrantc> tymp: almost all of the people who want it in refuse to comment on it.
<skippy> fear of change.
<tymp> a formal process, again, would help this
<vagrantc> matthew, to his credit, did suggest it's removal.
<vagrantc> yes.
<skippy> tymp: a formal process will only help if people participate.
<vagrantc> part of the formal process can involve non-action.
<vagrantc> though people won't like it if something happens they didn't like...
<skippy> what about all the consensus talk scattered throughout the FG wiki?  They make it sound as though consensus is very important to them.
<tymp> skippy : no, if we say, this has been proposed and gone through the review process and it is being removed on this date.. then there's little room for complaint.  provided it's properly announced
<vagrantc> a formal process will help, having branches/forks to demonstrate alternatives will help convince people.
<vagrantc> skippy: consensus is very important at freegeek, but it's hard to bring consensus out of face-to-face meetings (hard enough there)
<tymp> skippy : but in consensus, there's still plenty silence, and saying nothing eventually amounts to consent
<skippy> okay.  So the current proposal is a separate "freekbox-games" package. How is that better than just `apt-get install <some games>` ?
<vagrantc> possibly a process for changes would be to appoint a committee that's allowed to make decisions in the light of no input.
<tymp> vagrantc : that sounds like a good idea
<vagrantc> skippy: if our choices for games change, they'll be pulled in on "apt-get upgrade"
<tymp> it could facilitate making all the games an add-on to the basic install too, no?  maybe that is too radical
<vagrantc> tymp: that's exactly the idea
<{gate}> we going to break out kde and gnome games too then
<{gate}> just because each desktop does contain a group of simple games
<vagrantc> {gate}: for the moment, i don't think we should bother.
<skippy> We need to include at least a few games in each core image.
<skippy> is pysol the best solitaire?  Isn't there something more svelt ?
<vagrantc> skippy: says you :P
<{gate}> just stick pysol, westnog ... in the package then
<vagrantc> at the moment, in cvs, it contains wesnoth, pysol and frozen-bubble
<skippy> vagrantc: almost every user I know plays solitaire on their Windows PCwhile waiting for something else to happen.
<tymp> skippy : it's a disease we must stamp out.  :P
<vagrantc> skippy: really demonstrates the isolation of the modern human condition.
<skippy> pity.
<{gate}> I just turn 45 degress either way and theres more to do
<tymp> how about his : with each freekbox, you get a free pack of actual cards
<vagrantc> heh.
<tymp> much healthier
<{gate}> but I do like to play on my pda
* vagrantc wishes pysol had several card sets
<vagrantc> the majority of pysol's size is the extra card-sets, which i think are optional.
<tymp> on the other hand, these type of social conditioning decisions are a little out of scope..
<skippy> making some sort of value statement about the human condition is certainly outside the scope.
<{gate}> I'm personally for keeping them in in some way or form
<tymp> i would find it convenient to use the windows norm as a default assumption of expectations
* vagrantc is a bit outside of scope
<tymp> skippy : yes, unfortunately :(
<tymp> heh
<skippy> I propose we select two or three games -- one card game, and one or two others -- to bundle.
<skippy> everything else can be assigned to a games committee.
* skippy secretly hopes that Mahjongg gets in
<tymp> skippy : as windoze has : a small set of really simple games
<tymp> are we off topic yet?
<skippy> tymp: sure; but I would prefer to see games distinct from Windows; else we'll be accused of simply copying.
<vagrantc> i personally don't support using computers for games, but that is largely outside of the scope of this discussion.
<skippy> so: packaging.
<tymp> vagrantc : yes, i think it's off mission to have games at all, in a way - except that they are assumed
<skippy> any additional issues?
<vagrantc> i'm unclear as to what to do regarding freekbox3-games ...
<tymp> i think that's enough
<skippy> as long as we're off-topic: i think it's vitally important to have games on computers.  not every tool need be used solely for work.  We don't always drive just to get somewhere.
<tymp> i would petition to remove frozen-bubble and wesnoth.  but, again, how bad will this hurt people?
<skippy> tymp: we'd need to get feedback from PDX adopters.
<skippy> I second the removal of both wesnoth and frozen bubble.
<vagrantc> if we split frozen-bubble and wesnoth and pysol-cardsets (but keep pysol), i would be happy.
<skippy> are there no other decent solitaire games?  is pysol the best?
<tymp> i think we are somewhat talking in circles, because we don't know how tomake it happen yet...
<skippy> ok.  let's table this.
<skippy> commit: bring games separation to the list.  proposal: keep pysol, puteverything else in a profile
<vagrantc> i'll experiment with ways to make games optional ?
<tymp> vagrantc : do you feel like you need an answer to more on with your work?
<tymp> ok
<skippy> Propose and approve changes
<vagrantc> commit: experiment with ways to make games optional
<skippy> how does one currently propose changes to the Freekbox?
<tymp> with wishful thinking?
<vagrantc> basically, you talk to enough people at freegeek PDX in person and convince them it's a good idea, and do all the work to make it happen
<skippy> blech.
<vagrantc> or you just commit to cvs.
<skippy> I strongly dislike the latter approach.
<vagrantc> and if you're good, you post about major changes to the list.
<vagrantc> or some combination thereof.
<vagrantc> since freegeek PDX is insane, i think the best approach is to make the code in cvs/svn not change anything for them, but support other alternatives,too.
<tymp> basically, i think, 1) we need a formal format to propose changes, including rationalle, 2) a clear procedure to clarify and express opinion, 3) a good mechanism to publicize the process
<vagrantc> tymp: sounds good to me.
<tymp> * that is "...i think we need, 1) ..."
<tymp> commit : propose a wiki template for distro changes, and raise the issueof clarification process on list
<tymp> skippy : "the latter approach" is just commit to the cvs?
<skippy> tymp: yes.
<skippy> another project I'm involved with uses that approach; and it's unfriendly.
<vagrantc> i feel like a formal process is a little overkill for many changes- there should be some way to define minor changes that are acceptible on a smaller scale.
<tymp> skippy : i agree
<tymp> vagrantc : yes.  maybe skip the formal proposal and clarification for minor changes, but i think the mechanism to ... be transparent about it is still important
<skippy> until we all have a better feel for the "scope" of any change, I thinka formal process is perhaps the best middle ground.
<vagrantc> tymp: absolutely.
<tymp> (it is just so hard to know what silence means)
<skippy> could we use an "intent to commit" mechanism?
<tymp> what do you mean?
<skippy> "I intend to commit this change.  You have five days to comment beforeit goes in."
<skippy> just brainstorming.
<vagrantc> honestly, i sometimes make 50 commits in a single day.
<vagrantc> so that would seem... crippling.
<skippy> yes, but you're also the only one working on some of those things, aren't you?
<{gate}> ok, we need to get vagrantc a more relieable machine
<vagrantc> sort of ... there are a lot of things that both {gate} and i are working on that overlap
<{gate}> I feel bad when I do 3 commits in one day.
<vagrantc> {gate}: ?
<{gate}> course then the 2nd two are aways fixing what I broke or missed
<tymp> skippy : i think, maybe, rather than applying that to cvs commits, have another level of commitment approval - the change will be consider approved and can propagate into package changes and cloner image changes if no one says otherwise within n days..
<vagrantc> it will be much easier with svn, as we can more readily work with branches.
<skippy> vagrantc: what do you propose?
<vagrantc> there's a big difference, too, with maintenance changes and bugfixes...
<tymp> i think if we get some formality in place, we can work out the details of what constitutes what level of change from there... ?
<tymp> case-by-case, it should be relatively clear how much puclicity is calledfor ?
<vagrantc> skippy: i guess, people should use their judgement ... if they're about to embark on a major change that will affect a lot of people, do intent to commit mails with a long time ... and if it's a really minor change, commit it and mail, and if it's a maintenance change, just commit ...
<tymp> and guidelines would follow
<tymp> one reason i'd like to see more formal methods is that it would be easier for non-tech people to participate
<tymp> vagrantc : that sounds about right i think
<vagrantc> i think a formal method is important for major changes, but a more informal approach for the day-to-day coding ...
<tymp> yes
<vagrantc> transparency being key.
<tymp> skippy : does that sound like a beginning?
<skippy> the only remaining issue then is to define a process for rolling back a commit.
<skippy> under what circumstances would a commit be reverted?  how does that get determined?
<tymp> skippy : i think, once the process has gone through, transparently, rolling-back is a change in itself
<tymp> changing the process itself would be another 'change' ... and should have deliberative overhead appropriate to it's scope, etc..
<skippy> so, the consensus is that anyone can commit small changes (that don't affect many people) whenever they want; and anyone can commit big changes after they announce / discuss it ?
<vagrantc> i would agree with that... and before reverting someone else's change, it is generally good to communicate about it.
<vagrantc> i.e. reverting a small change that was a disasterous security hole
<skippy> Fork? Branch?
<skippy> is this still an issue?
<tymp> my thinking lately is still that it's best to avert a branch or fork, but seems like we should just move to gnome
<tymp> i don't think it bears a lot of discussion at this moment..
* skippy gapes at tymp
<vagrantc> tymp: branches are merely the sandbox in which you play to test changes.
<tymp> vagrantc : okay.  ...somewhere there was a suggestion that freekbox-gnome was a branch rather than a fork, though.
<tymp> skippy : why?
<vagrantc> tymp: it started as a fork, and we're working on merging it into a variation on a theme.
<skippy> tymp: you seemed strongly opposed to GNOME when we brought it forward. The change surprises me.
<vagrantc> maybe most of the innovative development should be on GNOME, since it's near-impossible to get changes to the freekbox3 (kde)
<skippy> fine with me.
<tymp> skippy : no, sincerely, i just want to take the simplest path.  i think one window-manager is by far simpler.  i would want to explicate the argument for whichever path we chose as much as possible.
<skippy> can we remove this agenda item from future meetings?
<vagrantc> tymp: though i still think it would be good to get your changes in.
<tymp> vagrantc : i think if i get slightly less bashful, my changes will see the light of day
<vagrantc> skippy: i don't see need to continue to evaluate on a week-by-week basis.
<skippy> going once...
<tymp> is this clear? -> trying to get my changes into fb3 is partly an experiment to see what that entails
<skippy> sold to the man in the funny hat.
<skippy> Goals / Deadlines
<tymp> well, i'd like to clrify the language more in the future: fork vs branch
<tymp> (but ok)
<skippy> go ahead, tymp: clarigy
<tymp> three minutes left
<skippy> clarify, even
<vagrantc> tymp: i don't think there is a clear definition.
<tymp> let's leave it for now
<skippy> goals / deadlines.  How can we?
<skippy> I'd like a more accessible scheduler / tracker thingie.  I've lost my RT password, and there's no automated tool to reclaim it.
<skippy> being so utterly reliant on PDX is ... limiting.
<tymp> so, somewhere i should admit, that one possible goal i see for freekbox is a really significant contribution to linux: a minimal usable distro geared tobeginners.  (but i don't want to bring that up at this moment)
<vagrantc> i'd rather use track, since you can anonymously view tickets, and add tickets without logging in, etc.
<vagrantc> trac
<skippy> *cough*ubuntu*couhg*  =)
<skippy> I'd much rather see trac in use, too.
<skippy> it has built in milestones, so that code can be driven by completed milestones, instead of developer whimsy.
<skippy> s/code/releases/
<vagrantc> i wish ubuntu would only release once a year- then have a chance to form an opinion before they make another release.
<{gate}> I like trac because svn and tracking are in one place
<vagrantc> any RT fans?
<skippy> *crickets*
<{gate}> vag.  they will be releasing a "stable" branch every 1.5 years and support it for 3
* vagrantc cheers
<{gate}> or so they claim
<vagrantc> {gate}: yes, ubuntu is largely claims ...
* vagrantc is offtopic
<skippy> so, we're all in favor of trac.
<vagrantc> so ... my goals are largely what they've always been.
<skippy> how can we set deadlines ?
<tymp> rt is there.  trac is there too
<tymp> wait a minute
<tymp> skippy : i can probably reset your rt password.
<tymp> rt is good for general organizing.  trac is probably better for development.
<vagrantc> yes.
<skippy> tymp: does RT have its own password db?  I like trac because it used HTTP basic auth, which means you can point it at nearly any authentication repository (PAM, mysql, LDAP, etc)
<tymp> some of us will have to use rt because it's there.  so my question is ... how much trouble will having two ticket-tracking systems be?
<skippy> the less reliant we are on PDX for administrivia, the better everything will be.
<tymp> skippy : i don't know.  stillflame made me an admin, which still makes me nervous, and i haven't played extensively with it
<vagrantc> tymp: well, essentially the RT distro queue is ignored by the activedistro developers. so maybe we should kill the distro queue.
<skippy> if Trac can be used for code tickets, and milestones, that's a good start.
<tymp> skippy : i think you underestimate the work involved in replicating whatpdx has accomplished... maybe?
<vagrantc> what work are you talking about, tymp?
<skippy> tymp: I almost certainly underestimate it; because I see so little of it; and nothing (much) happens with any real expediency.
<tymp> i have made two distro rt tickets: install fb-oly and install fb-gnome.would those be appropriate trac tickets?
<tymp> skippy : fg-pdx is a huge operation
<skippy> tymp: that begs the question:  are they good RT tickets?
<vagrantc> we could also forward the distro queue to the distro list, or make adistro list for the RT queue ...
<skippy> tymp: so I keep hearing.  It's still ambiguous to me.
<tymp> skippy : they fit the general scope of rt, in that they are things that an individual can do in the material world.  that's my question.  i don't know.is trac bug-tracking appropriate to that kind of thing?
<vagrantc> i also have another goal: getting funding (to assist with travel expenses) for a freegeek conference sometime in the next 12-18 months
<tymp> skippy : i don't feel like you take a fair burden of responsibility for the fact of the ambiguity.  i understand that you can't know how overwhelmed andoverworked everyone in pdx is, but i would like if you could give them more benefit of the doubt..
<tymp> skippy : have you read the whole wiki?  ;)
<skippy> tymp: I'm a father of two; I work full time; so does my wife.  We haveactive social lives; participate in school functions and soccer; yadda yadda yadaa ... yet here *I* am, and I got SVN installed in days.
<skippy> So forgive me if I'm a little impatient.
<skippy> I don't see how them being a huge operation explains away any of my perceived lack of movement from them.
<vagrantc> skippy: think about being a father of 100 ...
<vagrantc> skippy: and having 10 parents ...
<skippy> tymp: what work specifically were you speaking about above?
<tymp> skippy : administering a 501c3 with all of portland's programs is where the work is.  there is almost no technical work that gets done.  there are problems, i think, but there are reasons for them.  expressing frustration is rarely a solution to anything in itself
<skippy> indeed.  expressing frustration isn't a solution.  I cannot solve PDX's problems.
<tymp> skippy : i will try to send you a tar of the last month's mailing-list archive, for the 60 public lists (i think there are also 20 private ones) - and that only represents the electronic communication, which probably represents lessthan 10% of the actual organizing work.
<skippy> I do not want to be beholden on PDX's scheduling in order to see my local Free Geek succeed.
<tymp> skippy : pdx's problems are freegeeks problems are our problems
<vagrantc> i think we can work autonomously, with an eye towards co-operation.
<skippy> I disagree with that characterization; but it's off topic.
<tymp> skippy : no, but you are dependent on what pdx has accomplished for whatyou are and can doing
<tymp> *are doing and can do
<skippy> are there any commitments for goal setting or deadline making?
<tymp> okay, my point being, you said ...
<tymp> " the less reliant we are on PDX for administrivia, the better everything will be."
<tymp> to clarify: by 'we' you mean fgcmh?
<skippy> yes.  where administrivia == things like resetting RT passwords; setting up non-critical new infrastructure; helping to advance the things that startups need, as opposed to what the mothership needs.
<tymp> skippy : it's a balance of cooperation and expediency.  it's kindof the whole ball of wax.  ah well
<tymp> i think the answer to "how can we set goals and deadlines?" is, "the hard way" :)
* tymp does enjoy talking too much
<vagrantc> is anyone else interested in trying to do a freegeek conference?
<tymp> yes!
<skippy> absolutely.
<{gate}> in mexico
<vagrantc> should we try and pursue funding for sending freegeek folks to the debian conference in mexico this coming may?
<tymp> in chicago?  i might be in chicago in spring
<skippy> what's involved with that sort of thing, vagrantc ?
<tymp> vagrantc : i'm really curious about that.  but.. to echo skippy's question
<vagrantc> skippy: the event, or the pursuing funding?
<{gate}> would a debian confernce be a bit too distracting for some of the other things
<skippy> vagrantc: funding.
<vagrantc> if we could meet before/after the debian conference, for our own inscruitable purposes
<vagrantc> skippy: that part is not my strong point :)
<tymp> i think the debian conference is one thing.  a freegeek conference is maybe appropriate to the startups list
<vagrantc> the debian conference, if we still want to use debian, would most specifically be useful to distro development.
<skippy> it's likely that much of the Debian conference would be out of my league, anyway; so a concurrent event would be okay
<{gate}> I agree is skippy
<skippy> I like that sentence.  =)
<vagrantc> it also would seem good to have a conference in portland for folks to visit the mothership, and conferences at some of the local startups to connectwith the diversity of things
<{gate}> I spend too much of my time working on comerical linuxs to really get the most out of a debian conference
<{gate}> we here in columbus where talking about heading up to pdx for a few days
<skippy> several FGCMH folks have kicked around the idea of a weekend visit to PDX
<skippy> in order to see how things work first-hand.
<vagrantc> i would recommend a friday-saturday visit ...
<tymp> skippy : and you should come up to olympia when you do.  it's a two hourdrive.
<vagrantc> if possible
<tymp> skippy : i'm flexible, and others in oly would be
<tymp> could there be a tentative date?
<skippy> I likely won't be able to make any such pilgrimage until the new year
<vagrantc> it would also be good to do some gpg signing.
<tymp> can we shoot for february?
<tymp> or january?
<skippy> still too soon for me to commit to anything.
<vagrantc> i probably can't make it then ... it would have to be earlier or later, most likely.
<tymp> march?
<tymp> april?
<{gate}> ya, after ticket prices stop
<{gate}> drop
<skippy> much flux at $employer makes it difficult for me to get precise righ now.
<tymp> goal : set a rough date for a conference?
<vagrantc> before the meeting disintegrates ...
<tymp> timeline : 2 months?
<vagrantc> we should figure out who's posting a log ...
<skippy> I'm logging, so I can paste it tomorrow.
<skippy> COMMIT: paste the raw log.
<tymp> i will post the log if someone will fish out the commitments... dang, too slow
<vagrantc> and summarizers?
<skippy> I can grep the commits from the log.
<vagrantc> i could, too.
<tymp> yay
<skippy> someone else can summarize.
<vagrantc> yes.
<vagrantc> consensus!
<skippy> any closing remarks?
<tymp> yay for 'someone else'
<vagrantc> that wasn't too bad.
<tymp> a lovely meeting.  truly, a testament to... something
* tymp is tired
<skippy> </meetup>