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:

1. user-oriented-design
2. Prognosis (how is this project looking?) & Long-term outlook (including definition of objectives, estimation of required work, and timeline)
3. hosting our own popularity-contest server (http://popcon.debian.org)
4. Install CD: multi-profile or otherwise?
5. 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
6. how is the meeting time/date (tuesdays, 7pm, -0700) (mondays, 5:30pm, -0700) for active participants?
7. packaging & repository
8. How to propose and approve changes to FreekBox3
9. Fork? Branch?
10. How can we set goals and deadlines?

new items:

(posted friday before the meeting or sooner)

1. new items here

late items:

(posted saturday before meeting or later) may not have time

1. late items here

log / summary

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

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>