Build system meeting minutes day 2

Oct 26 16:00:36 to Oct 26 18:50:32 

<_bernie>   who's there?
<c_scott>   hey all
<_bernie>   m_stone: are you there?
<m_stone>   _bernie: yup
<_bernie>   :)
<_bernie>   ok, I think the next point was:
ability for some of us to add/remove package ACLs for our 
developers without going through Fedora admins. [bernie, cscott]
I asked J5 about this a few days ago. he said there was no problem
<_bernie>   f13: maybe we should wait for notting, gredek, mbonnet, etc?
<m_stone>   _bernie: are you saying the problem is fixed, then?
<dwmw2_BOS> what does 'Fedora admin' mean in this context, and why can't 
bernie and/or cscott be one (or two) of those anyway?
<_bernie>   m_stone: he just told me he had talked with some colleagues 
and they agreed to give some of us admin privileges for the OLPC-2 branhc
<f13>       I"m here.
<_bernie>   dwmw2_BOS: the "admin" privileges we need are:
- giving acls to others
- branching/ubranching packages in OLPC-2
- ability to add entirely new packages (but we already discussed this 
yesterday)
- maybe ability to sponsor new developers
<_bernie>   GA
<f13>       all that could be easily done by more than one person in your group
<_bernie>   J5 is coming too
<_bernie>   sorry, c_scott is super-busy with 10 other things too
<_bernie>   he's telling me what we need quickly so I can relay it to the channel
<c_scott>   i'm here, but distractable
<c_scott>   the short list of questions for today is:
<c_scott>   a) currently J5 is doing our builds for us; are there fedora folk here 
who can "do what J5 does" (in terms of having the right ACLS) -- J5 will probably 
need to describe what exactly this entails....
<J5>        c_scott: you need to clarify 'builds'.  Do you mean rpms or the OLPC 
image?
<f13>       what does "builds' mean?
<c_scott>   b) i think we outlined a "way forward" for OLPC's build process 
yesterday; I need to know more about exactly how to get SRPMs with a given tag 
from koji.  I think I got the answer to this yesterday (look at the koji/mash source) but 
I haven't had time to chase it down and try it out.
<dgilmore>  c_scott: i could do whatever it is J5 does
<_bernie>   we had this ambiguity sorted out yesterday
<J5>        c_scott: so the best way to get sources is through the CVS repos
<_bernie>   Use either "package build system" or "compose tool"
<c_scott>   J5: i mean the bundle of tasks that need to be done when jg/kim say, 
"we need a 621" or whatever.
<c_scott>   J5: it's a vague description because not even I know exactly what's 
involved (which machines, which steps)
<c_scott>   for example, the builds appear on olpc.download.redhat.com -- who can 
put stuff there?
<dwmw2_BOS> f13: 'builds' means compose.
<c_scott>   i should clarify that this is primarily a short-term question -- we 
have a way forward, but we need help in the next two weeks.
<J5>        c_scott: those machines are going away.  You should put builds on 
your own servers
<c_scott>   j5: again, i'm talking about the next two weeks.
<f13>       c_scott: IIRC access to do the 'builds' would be on your side of the 
house, not Fedoras.
<c_scott>   f13: i wish it were that simple.
<f13>       c_scott: because by that time the Fedora side of things are done and 
sitting in public yum repos that anybody can access.
<f13>       modulo any Red Hat hardware that j5 may have been using in the colo
<c_scott>   f13: there's a mix of koji steps and access to redhat machines involved, 
and i don't know where the lines are currently drawn.
<J5>        c_scott: all you need pilgrim and one or more repos
<J5>        c_scott: so koji builds and creates static repos, pilgrim pulls it all 
together
<dwmw2_BOS> the only access to 'special' machines is presumably to upload the 
resulting image -- and that only matters if you're desperate to keep the 
'olpc.download.redhat.com' URL
<c_scott>   ok, let me back up.
<c_scott>   we've got a short-term crisis here:
<c_scott>   i'm currently responsible for far too much work at OLPC.
<c_scott>   i'm doing everything J5 used to do, plus lots of things other people 
used to do, and some stuff no one was previously doing.
*           dwmw2_BOS waits c_scott to get to the point
<J5>        c_scott: i.e. you guys need to hire someone
<c_scott>   Kim, Jim, and Walter think that we can address my short term insanity 
(freeing me to work on Yet More Things Which Urgently Need To Be Done) by reverting 
to the "J5" build process for the next two weeks.
<dwmw2_BOS> J5: creating builds is just a simple matter of running (the right 
version of) pilgrim with the right configuration, right?
<c_scott>   The question is: can anyone other than J5 do that process?
<J5>        dwmw2_BOS: yes, plus doing the ChangeLogs which is a pain
<dwmw2_BOS> those are done manually?
<c_scott>   J5, dwmw2_BOS: no this isn't true.
<_bernie>   dwmw2_BOS: yeah, I created builds myself this way
<J5>        c_scott: danw can
<_bernie>   dwmw2_BOS: on my desktop
<_bernie>   dwmw2_BOS: even before I had a fedora account
<J5>        dwmw2_BOS: ya, I never got around to automating it
<_sj_>      re
<J5>        c_scott: are you also talking about maintaining stable builds via push 
instead of pull?
<J5>        i.e. tagging RPMs to go into the release?
<_bernie>   dwmw2_BOS: the problem IMHO is *not* in the compose tool... if we want 
to push packages in koji...
<_bernie>   (talking with scott in person)
<dwmw2_BOS> So in the short term, c_scott doesn't seem to care about the details 
-- he just wants someone to run pilgrim when needed (and manually do the changelogs) :)
<_bernie>   J5: we'd very much appreciate if somone with better understanding of the 
internal redhat process could help us for the time being
<_bernie>   that's to address the short term problem...
<_bernie>   we also have medium and long term problems...
<_bernie>   but this one is more urgent
<dwmw2_BOS> J5: is there an issue with _where_ the packages come from? Are we 
being sensible and enforcing a policy that everything is in CVS and built through 
koji, so there's proper source access and everything's in a sane yum repo?
<J5>        _bernie: I'm gone in a week
<J5>        dwmw2_BOS: some packages aren't going through koji yet
<_bernie>   we're currently in the situation of choosing to distract people like 
c_scott from their duties OR get the builds done.
<J5>        _bernie: now you know how much work it was ;)
<_bernie>   J5: dan williams also did a few builds in the past. could he help, maybe?
<_bernie>   J5: i always did
<marcopg>   _bernie I don't think the process itself is very complicated
<marcopg>   _bernie it's matter of having someone that can actually focus on it
<dwmw2_BOS> is it documented anywhere?
<dwmw2_BOS> other than the changelogs, is any of it not automatable?
<marcopg>   _bernie I'm sure me or j5 or dcbw could help this person figure out the 
rh internal details
<J5>        so I sent you guys a person to hire
<_bernie>   marcopg: yes, for some of us it's not a matter of understanding
<_bernie>   marcopg: it's also a matter of time. it takes almost full-time commitment
<dwmw2_BOS> marcopg: there _are_ no rh-internal details, are there? Other than just 
uploading the result to olpc.download.redhat.com?
<J5>        _bernie: you guys have joyride running right?
<J5>        dwmw2_BOS: no there aren't any
<marcopg>   dwmw2_BOS: tagging packages
<J5>        dwmw2_BOS: marcopg, but that is a fedora thing we can give access to 
someone at OLPC
<marcopg>   assuming we want to do it the trial-3 way
<marcopg>   J5: right
<marcopg>   the real problem is having someone at olpc that can focus on this, ihmo
<marcopg>   anything else can be easily solved
<_bernie>   (syncing with cscott...)
<f13>       marcopg: tagging packages is /not/ RH specific
<J5>        _bernie: you could just have a mirrored repo and a script to pull in the 
changes you want
<_bernie>   J5: I installed koji on my devel machine
<_bernie>   J5: it turned out to be non-trivial to setup and keep running
<dwmw2_BOS> as I see it, the ideal endpoint we want to get to is...
<_bernie>   J5: mbonnet and others helped me out a lot, though
<marcopg>   f13: I just meants that's something currently no one at olpc can do, but 
sure that can be fixed
<J5>        use that as a stable repo and have joyride build images as changes come in
<dwmw2_BOS> OLPC folks can approve packages and branches to easily add stuff in the 
OLPC-2 collection
<marcopg>   _bernie I hope you are not even considering the idea to run your own koji 
instance for frs
<dgilmore>  dwmw2_BOS: that should be afirly easy to do
<dwmw2_BOS> it's easy for _anyone_ to just run pilgrim^Wlivecd-tools to spit out an 
image pulling from that repo, and even add their own repos
<J5>        _bernie: but you don't even need koji for that.
<marcopg>   _bernie it's just too late and no one has time to get that done
<dwmw2_BOS> (and ideally it'll be livecd-tools, I think, because that's what's 
used upstream and is maintained?)
<_bernie>   marcopg: (no, I'm more focused on mid-term issues)
<_bernie>   marcopg: I thought we were covered for FRS
<_bernie>   marcopg: until now, that is
<J5>        dwmw2_BOS: it is pilgrim, not LiveCD tools.  It didn't have some features 
we needed
<marcopg>   _bernie *please* let's focus on short time until frs is over. The current 
status of things is an unbelivable mess
<_bernie>   J5: yes, I also added an extra yum repo to my builds in the past
<_bernie>   J5: I know how to do that
<dwmw2_BOS> J5: livecd-tools doesn't have features we need? Surely that can be remedied?
<_bernie>   J5: and so does c_scott
<J5>        dwmw2_BOS: yes, just not in timeframe we had
<_bernie>   J5: the thing is... you said it!... it requires a lot of time
<_bernie>   J5: and it's not just time.
<J5>        _bernie: hire someone
<m_stone>   J5: may I cite Messr. Brooks here?
<_bernie>   J5: I can do the technical thing but I'd not accept the responsibility 
to be a build master
<dwmw2_BOS> I still don't understand why builds take so much time. What people-time 
is involved other than creating the changelogs?
<_bernie>   m_stone: hehe
<_bernie>   J5: it takes time
<_bernie>   J5: it's not like hiring a janitor
<m_stone>   dwmw2_BOS: education, getting authorization to use servers referenced in 
the existing system or patching them out of pilgrim,...
<_bernie>   dwmw2_BOS: my opinion is that a script can make the builds, but it takes 
some human being to see how it comes out, remove the crap that doesn't work, etc...
<f13>       it doesn't seem like the needs initially are going to be much for this 
build master.
<m_stone>   dwmw2_BOS: answering questions about why it broke.
<f13>       and if it doesn't work out beyond the initial needs, find somebody else?
<_bernie>   m_stone: I think me and you are talking about different people in the process
<m_stone>   f13: the long and short of it is that we're really swamped. :)
<_bernie>   m_stone: I'm thinking about the build master... you're talking about the 
the packagers
<f13>       m_stone: I understand that, but I'm at a loss as to how we can help you more, 
other than by giving you a person.
<m_stone>   f13: I understand that.
<f13>       (which last I checked, I have no people to give (: )
<dwmw2_BOS> m_stone: regarding education: presumably j5 can hand off to someone or 
preferably document the process, in the time he has left.
<J5>        m_stone: _bernie already knows how to point it to other servers, both him 
marcopg and cscott know how to use pilgrim to build, joyride is already doing automatic 
builds from what I heard.  It is just a matter of putting rpm's somewhere, running 
createrepo and changing the repo pilgrim points to
<f13>       We can make it so that whomever is doing the work has all the necessary 
rights and accesses to get the work done (correctly)
<m_stone>   f13: you've been enourmously helpful already, just by correcting 
misconceptions we had about the Fedora process and about how koji works.
<dwmw2_BOS> m_stone: authorisation shouldn't be an issue for anything but uploading 
the final results, should it? Apart from tagging packages into the OLPC-2 collection 
which I think _bernie and other people can already do?
<m_stone>   dwmw2_BOS: activities need it right now too.
<dwmw2_BOS> m_stone: elucidate?
<m_stone>   http://olpc.download.redhat.com/activities/
<_bernie>   J5: now cscott is again away... last thing he told me is that we lack time 
to do all these things
<marcopg>   m_stone: just move that to d.l.o
<m_stone>   marcopg: as you stated.
<marcopg>   m_stone: and you solved this for the short time
<m_stone>   And as I stated, and have written in the email sitting in front of me.
<J5>        _bernie: but isn't joyride doing that stuff already?
<J5>        in which case you could just move rpms into the tmp repo
<_bernie>   J5: the joyride builds are hard to stabilize unless we re-route them 
through cvs -> koji -> static-repo
<marcopg>   _bernie we just need someone that can spend a couple of hours a day doing 
the work j5 was doing
<f13>       oh yeah, we can make the static-repo link refresh more often too if that 
will help you, although there are dangers in that.
<dwmw2_BOS> _bernie: of course. We shouldn't include _anything_ which isn't in CVS and koji.
<marcopg>   _bernie what takes time is the manual process, and we need someone to take 
care of that
<marcopg>   _bernie but clearly not cscott or mstone
<_bernie>   dwmw2_BOS: at this time, if we exclude everything which is not in koji, we 
revert to build 619
<_bernie>   (or whatever the last build is)
<dwmw2_BOS> marcopg: by 'the manual process' you mean tagging packages into the 
appropriate collection, then running pilgrim? (and writing the changelog)
<_bernie>   dwmw2_BOS: all the development we've done later on sits in public_rpms/
<_bernie>   marcopg: is that right or close-to right?
<dwmw2_BOS> _bernie: well, that can be remedied quite quickly, presumably?
<dwmw2_BOS> and was exceedingly bad practice.
<_bernie>   dwmw2_BOS: probably, yes.
<marcopg>   dwmw2_BOS: yeah, that and uploading the activity bundles which activity 
authors put in trac
<J5>        _bernie: well that is the danger of not going through the build systems.  
koji might have been a bit of overhead but it enforced policy
<dwmw2_BOS> so, in the _short_ term (i.e. in the next day or so) we could make sure 
that all current packages are actually committed and built through koji, so they appear 
in the repos?
<dwmw2_BOS> apart, perhaps, from the activity bundles which we can put into a static 
repo elsewhere which pilgrim pulls from?
<dwmw2_BOS> and joyride could run hourly, pulling from those but _not_ /home/*/public_rpms,
 and give us 'standard' builds without changelogs?
<J5>        _bernie: you know this shouldn't have come up.  I kept telling everyone to 
call me and I would come in and help you guys with migrating the build systems but no 
one ever did and I am going to be gone for a month now.
<dwmw2_BOS> dgilmore: would you be willing to help babysit that?
<_bernie>   dgilmore: sorry, I just noticed reading the backlog that you said "I can do it"
<dgilmore>  dwmw2_BOS: sure i willhave some time this weekend i could do some work
<dwmw2_BOS> that's great; thanks
<dgilmore>  _bernie: if you get me SRPMS i can check them ina nd build them
<dwmw2_BOS> so, the way forward, as I see it:
<J5>        dgilmore: there are a couple of packages still under review and the marvel 
wireless firmware needs to be submitted
<dwmw2_BOS> we modify (or run another copy of) the 'joyride' system which runs pilgrim 
hourly, so it pulls just from OLPC-2 collection and some static repo which has activities 
in.
<dwmw2_BOS> we take the newer packages which are currently lying around, and make sure 
they get into the OLPC-2 collection (with dgilmore's help -- thanks!)
<_bernie>   J5: for taboo things like binary blobs we can still use the tmp repos, 
can't we?
<dgilmore>  J5: i can look at and approve them  and could submit the firmware
<dwmw2_BOS> profit.
<dwmw2_BOS> ongoing, we just need to be able to tag packages for OLPC-2 and detag them 
if they offend us -- which we can already do, right?
<dwmw2_BOS> and ideally add new packages quite easily, but we have the static repo for 
that, for now.
<dwmw2_BOS> anyone see any problems with that?
<J5>        dgilmore: etoys is still in review because the author doesn't want to sign 
the nda
<dgilmore>  J5: do you have a list of what is under review?
<J5>        sorry not nda
<dgilmore>  CLA?
<J5>        the cla
<J5>        ya
<_bernie>   nda?
<marcopg>   dwmw2_BOS: activities are not rpms
<J5>        CLA
<dwmw2_BOS> ideally, we'd want to be able to upload the results to 
olpc.download.redhat.com -- but that isn't really a showstopper (and I can probably 
be given access for that anyway)
<f13>       I can make it so that any fedora packager can tag/untag things from olpc-2
<J5>        _bernie: Contributors license agreement
<f13>       (basically unlock the tag)
<_bernie>   J5: we talked about the CLA yesterday
<m_stone>   dwmw2_BOS: marcopg is correct that we can patch olpc.download.redhat.com 
out of pilgrim in short order.
<_bernie>   J5: it seemed we could have an exception for OLPC....
<_bernie>   J5: *seemed*
<dwmw2_BOS> f13: 'any member of olpc group' would be better, if that's technically 
possible, but I think 'any packager' is probably OK too
<dwmw2_BOS> m_stone: indeed. I was just mentioning it since it seemed to be so much 
of an issue to some :)
<f13>       dwmw2_BOS: it might be possible, but in reality, nobody cares about it 
but the olpc groups
<_bernie>   J5: the reason being that RH does not really distribute these RPMs... 
they just receive them from us and return back to us
<dwmw2_BOS> f13: fair enough
<f13>       _bernie: erm, nto quite.
<J5>        _bernie: we do distribute them
<f13>       _bernie: they're on koji which is a public distribution point.
<_bernie>   f13: (lemme re-read the irc log)
<_sj_>      dgilmore: thanks!
<_bernie>   f13: ah, I see.
<J5>        _bernie: and some of them may go into Fedora or a spin of fedora
<m_stone>   dwmw2_BOS: I'm fine with patching pilgrim. I'm not fine with patching 
pilgrim without serious review of the patches, preferably by c_scott.
*           dwmw2_BOS sends beer and a couple of ultra5s to dgilmore
<f13>       my comment about the CLA was that there could be a cla_olpc that blanket 
covers any OLPC employee/contractor.
<_sj_>      j5: what happens if there isn't a cla agreement?  they can't be included 
through this build process?
<dwmw2_BOS> m_stone: er, did we talk about patching pilgrim?
<J5>        _sj_: the author can not access the Fedora systems
<dwmw2_BOS> changing the urls it pulls from doesn't count as patching, sirely?
<f13>       I'd be worried if they won't sign the cla.  Without something like a cla 
how can you be assured that the person has the legal right to contribute said code to 
an opensource distribution?
<dgilmore>  dwmw2_BOS: i appreciate the root beer and U5's
<J5>        _sj_: so you can designate someone to do the contribution who has signed 
the cla
<J5>        f13: fear of the CLA is due to its legalese even though it just syays you 
guarantee what you submit can be distributed by Red Hat and Fedora
<_sj_>      got it
<_bernie>   (sorry, I'm being distracted too)
<_bernie>   here I am
<_bernie>   f13: yes, I guess that would be fine
<f13>       J5: yeah, there has to be legalese at some point.  if there was cla_olpc, 
OLPC employees and/or contractors wouldn't see the Red hat specific legalese, but would 
see something regarding the work they do belonging to OLPC or what not, and OLPC itself 
having an agreement with Red Hat regarding distribution of the software.
<f13>       J5: (we have this already for say cla_redhat, cla_dell, and I think there 
is one more)
<J5>        y
<J5>        ya
<dgilmore>  f13: cla_ibm
<f13>       J5: it becomes OLPC's responsibilty that the employee/contractor knows 
whats going on and whatnot, but RH can be safe in that if the person is in cla_olpc, 
they're good to go.
<f13>       dgilmore: ah thanks.
<_bernie>   f13, J5: I think this particular issue is to be discussed with jg (and 
Alan Key maybe)
<J5>        f13: we should have the freedom law center vet it to ease peoples minds
<_bernie>   J5: you said you'll be with us one more week, did you?
<f13>       yeah, this really feels like middle-term work though
<dwmw2_BOS> djbclark: please could you give dgilmore an account on dev.laptop.org?
<_bernie>   m_stone is showing joyride to dwmw2_BOS.
<_bernie>   he apparently had never seen it
>f13<       sorry there's much offline talking
>f13<       we're a bit confused
<dwmw2_BOS> ok, so for the record and to verify my understanding. Our "official" 
build #617 is still based solely on what's in the OLPC-2 collection, along with the 
non-RPM activities?
<m_stone>   dwmw2_BOS: that is my understanding.
<dwmw2_BOS> we have local 'joyride' builds which also  pull in packages 
from /var/www/sugar/rpms/ on dev.laptop.org (and some less important stuff from 
home directories)
<J5>        build 621 is coming out soon
<dwmw2_BOS> J5: but still includes only stuff in OLPC-2 (+ activities)
<dwmw2_BOS> ?
<m_stone>   dwmw2_BOS: #6?? includes OLPC-2 + /var/www/sugar/rpms.
<J5>        dwmw2_BOS: olpc2-trial3
<dwmw2_BOS> m_stone: oh. j5 is pulling from there too?
<m_stone>   dwmw2_BOS: that repo is named 'olpc-devel-tmp'
<m_stone>   dwmw2_BOS: I believe so. J5?
<marcopg>   m_stone: he is
<dwmw2_BOS> where might we find the _sources_ to these binary packages?
<_bernie>   dgilmore: you said you could work full-time to help us with the builds?
<marcopg>   dwmw2_BOS: for many of them you can't
<_bernie>   dgilmore: you were one of the koji developers, right?
<marcopg>   dwmw2_BOS: some are in kojy, some in random dirs on d.l.o
<dgilmore>  _bernie: indeed i could.  I am not a RH employee
<marcopg>   dwmw2_BOS: and some are just on the machine of whoever built them
<_bernie>   dgilmore: oh, I was worried there would have been a conflict otherwise.
<dgilmore>  _bernie: and im currently looking at options that are out there as my 
work has started migrating to a platform i dont agree with
<_bernie>   dwmw2_BOS: for mine, they're where the binaries are.
<dwmw2_BOS> ok. So the task for the weekend, which dgilmore seems to have volunteered 
for and which I shall assist with, involves looking to see who _owns_ each binary 
package, then applying percussive persuasion to that person in order to find the patches 
(and maybe even the reasoning for them), then getting it into cvs and koji and olpc-2
<f13>       dgilmore: ubuntu?  (:
<djbclark>  dwmw2_BOS: sure. you are dwmw2 as username I presume? also, can I get your 
and dgilmore's full name and email addresses, and a list of projects you need write 
access to? Just send that stuff off to danny@laptop.org
<dgilmore>  _bernie: i help look after  fedora koji.  i have submitted some patches and 
 i am the prinicipal person working on secondary archs
<_bernie>   dgilmore: :-)
<dgilmore>  f13: worse
<m_stone>   dwmw2_BOS: for people who have their SRPMS handy (like me), where should 
we put them?
<dgilmore>  danny im Dennis Gilmore  dgilmore@fedoraproject.org
<dwmw2_BOS> djbclark: I have an account already -- it's dgilmore who needs it
<dgilmore>  m_stone: somewhere i can grab them from
<f13>       _bernie: have you been shown cvs-import.sh ?
<djbclark>  dgilmore: oh okay, so just email me your ssh public key, and what projects 
you want access to
<m_stone>   (_bernie is chatting with jg and c_scott)
<marcopg>   dwmw2_BOS: for joyride, we had already got rid of the tmp rpm
<_bernie>   ok, back from chatting
<dgilmore>  djbclark: ok  i really dont know what projects ill need access to
<dwmw2_BOS> marcopg: que?
<_bernie>   dgilmore: you're located south of chicago, are you?
<marcopg>   dwmw2_BOS: of the tmp yum repository
<dgilmore>  _bernie: yes
<marcopg>   dwmw2_BOS: all of these packages are in public_rpms
<marcopg>   dwmw2_BOS: most of them in the one of the people which actually own/build 
these packages
<_bernie>   dgilmore: that could be an issue... doing integration off-site may be a problem.
<djbclark>  dgilmore: k cool just ignore that bit and ping me when you know
<marcopg>   but well if the plan is to restart from 620... I guess that's not really 
useful
<_bernie>   dgilmore: anyway, let's talk about it after the meeting
<dgilmore>  _bernie: ok
<m_stone>   dgilmore: my srpms are at http://dev.laptop.org/~mstone/releases/SRPMS/
>c_scott<   wanna let you know that I appreciate all the work you're doing for OLPC.  
I'm catually surprised how much pressure you can take.
<m_stone>   the relevant ones are pyvserver-1.0-0.3.fc7.src.rpm and rainbow-0.6.6-1.fc7.src.rpm
<m_stone>   I look forward to learning how they should have been handled in the first place.
<dgilmore>  m_stone: great ill grab them tonight
>c_scott<   even if we have disagreement on a few points, I think the goal is the same
<_bernie>   f13: yes... I used it a couple of times
<dgilmore>  J5: do you have a list of OLPC packages needing review still
<f13>       ok.
<f13>       it can make getting new builds into koji really quick and easy
<_bernie>   f13: can it create new modules in cvs too?
<f13>       _bernie: no, due to some ACL stuff.
<f13>       _bernie: but you can use it to import new versions of packages to existing branches.
<f13>       isntead of manually uploading the tarball and checking in a new spec
<_bernie>   f13: ah... cool!
<f13>       _bernie: basically Cd to the module/branch you want to import the build on, then 
do ../common/cvs-import.sh foo.src.rpm  and it'll import it onto that branch
<f13>       cvs up; make build; profit.
<_bernie>   today I think we made an important point.
<_bernie>   f13, c_scott, dwmw2_BOS, cjb, J5, m_stone, marcopg, dgilmore: are we all 
positive that over the next few days we'll try to push as many of the "rogue" rpms we 
have in joyride to koji.fedoraproject.org ?
<m_stone>   that is my understanding.
<marcopg>   dgilmore: https://bugzilla.redhat.com/show_bug.cgi?id=343741 I'd need to 
get this one into the build, but no reviews yet
<_bernie>   this means that whatever compose system we use, we'll get the same input 
rpms and they'd be built with a stable process, and source will be in cvs.fedoraproject.org.
<m_stone>   I do not understand what we want to do with activities and their source code.
<marcopg>   _bernie I'm all for it
<_bernie>   m_stone: good question :-)
<_bernie>   m_stone: they have exactly the same problem of RPMs... indeed.
<_bernie>   well, this is a problem we had before and we still have now
<_bernie>   since it's not a "regression" of the last few weeks, I'd say let's 
manage it another time :-)
<marcopg>   _bernie we need to at least solve the problem of how these goes into the builds
<m_stone>   We don't have to solve it now.
<m_stone>   I'm really thinking of how to write this email that marcopg asked me to write.
<marcopg>   and my proposal for that is to just move them on d.l.o
<_bernie>   marcopg: yes.
<m_stone>   Which I'm fine with.
<_bernie>   marcopg: agreed.  who can physically do it?
<m_stone>   me.
<m_stone>   I just download the ones presently on olpc.download.redhat.com.
<_bernie>   marcopg: c_scott specifically asked to be kept free for his higher FRS 
priorities.
<marcopg>   m_stone: I can prolly do that more easily if you want
<_bernie>   do we all agree m_stone will do that?
<marcopg>   m_stone: since I have ssh there
<_bernie>   So it's marcopg VS m_stone
<m_stone>   marcopg: i'll take care of it. consider it incentive for me to actually 
get those patches merged.
<_bernie>   it's on!!!
<dgilmore>  marcopg: i took that bug
<m_stone>   marcopg: I was going to do what J5 does: wget -R
<marcopg>   m_stone: fine with me :)
<marcopg>   m_stone: ooh nice, that works
<marcopg>   dgilmore: thanks!
<_bernie>   can we say the meeting is over for today?
<_bernie>   I think we have the most important things sorted out
<marcopg>   one thing before we do
<dgilmore>  _bernie: i think so
<_bernie>   and it's one of those rare moments where everyone seem to agree with 
each other
<_bernie>   :-)
<marcopg>   are we planning to base this on the trial-3 static repo?
<m_stone>   yes.
<_bernie>   marcopg: ah, you had to ruin everything with this question!
<_bernie>   haha
<marcopg>   heh
<_bernie>   marcopg: yes, I think so too.
<m_stone>   why do you ask?
<dwmw2_BOS> what is in the trial-3 static repo that isn't in the OLPC-2 collection 
(... and why?)
<_bernie>   if we fetch the stuff we have in joyride and push it to koji, we re-add 
the features one at a time
<marcopg>   dwmw2_BOS: my understanding is that trial-3 was forked out from OLPC-2 at 
some point
<marcopg>   dwmw2_BOS: and then packages in OLPC-2 needed to be tagged to get into trial-3
<_bernie>   marcopg, dwmw2_BOS: who will do the tagging/untagging work?
<marcopg>   dwmw2_BOS: so, for example, trial-3 doesn't have the fedora updates
<_bernie>   marcopg, dwmw2_BOS: which is another way to say: "who'll be making 50% 
of the decisions build master does?"
<marcopg>   _bernie thought we decided to just include everything that gets built 
into OLPC-2
<marcopg>   _bernie and hence use OLPC-2 rather than trial-3 as a base
<dwmw2_BOS> that makes sense, unless it means we pull in scary updates from 
dist-f7-updates and that makes us unhappy?
<marcopg>   pullling in updates automatically is sort of scary
<f13>       erm.
<marcopg>   maybe it's possible to require these to be tagged to get into OLPC-2 
instead? f13?
<f13>       that's the whole point of a freeze tag
<f13>       that's what trial3 was about, requires tagging to get into it
<f13>       we can create another "trial3" like tag, or refresh trial3 with all 
the latest stuff in dist-olpc2 as of "moment in time" and update it on demand with 
specific builds.
<marcopg>   f13: right. But we don't currently have anyone that can do the tagging 
manually
<dwmw2_BOS> don't we?
<marcopg>   well
<marcopg>   (11:23:22 PM) _bernie: marcopg, dwmw2_BOS: who will do the tagging/untagging 
work?
<marcopg>   if someone can answer that question we do I guess ;)
<f13>       decide who will do the tagging or more importantly the /deciding/ of what 
to tag.
<dwmw2_BOS> well, strcmp("can","will"). ideally, any of us _can_ do it.
<dwmw2_BOS> and that means that more of us _will_ do it when we need to
<_bernie>   f13: this brings up the next point in the list
<f13>       I can make it so just about anybody can do the act of tagging, bu the more 
important question is who is going to decide /what/ to tag?
<_bernie>   f13: which is maybe too late to discuss
<f13>       it's late for me :/
<dwmw2_BOS> how does that work at the moment? j5 just makes arbitrary decisions with 
no input?
<_bernie>   f13: but it was: ability to create short-lived dist tags for experimental 
or integration streams such as "olpc-xtest", "olpc-sugar", "olpc-trial4", and so 
on [bernie]
<dwmw2_BOS> people build new packages and just wait around and hope that j5 notices 
them and decides to include them?
<marcopg>   dwmw2_BOS: during code freeze jim and kim approve stuff that goes in
<marcopg>   dwmw2_BOS: and j5 get in only approved stuff
<dwmw2_BOS> right. There's your answer then.
<_bernie>   f13: yes, let's talk about it another time
<dwmw2_BOS> jim and kim can tag the builds they want rather than telling j5 to do so
<_bernie>   f13: I'm sure it's trivial to address
<_bernie>   dwmw2_BOS: that would be great
<marcopg>   dwmw2_BOS: sounds good to me
<_bernie>   dwmw2_BOS: if we kan jive them the koji acls they need
<dwmw2_BOS> I think we might need them to get accounts first.
<f13>       yes, they need accounts.
<f13>       and sponsors, but we can easily fudge the sponsor thing.
<_bernie>   f13: I'll ask them to go through the fedora user account process then
<f13>       we'll leave the 'freeze tag' unlocked so as valid account holders they 
can do tagging.
<dwmw2_BOS> I can sponsor them, can't I?
<_bernie>   is that fine with everybody?
<f13>       dwmw2_BOS: are you a sponsor in the account system?  (if not we cna 
probably fix that)
<dwmw2_BOS> makes sense.
<_bernie>   dwmw2_BOS: thanks
<dwmw2_BOS> f13: I don't remember. I think so, but ICBW
<f13>       I have to go talk to some other people about a beta release today, sorry 
droping out.
<dwmw2_BOS> f13: ok, thanks much!
<f13>       np
<marcopg>   _bernie are we ok with no changelogs for now? (well except for automatic 
rpm diff)
<_bernie>   that would require jg and kim to sign the CLA
<_bernie>   marcopg: well we have the old changelogs, don't we?
<marcopg>   _bernie well, j5 manually put together the old changelogs
<_bernie>   marcopg: I'd like them, but it's a completely orthogonal issue
<_bernie>   me thinks
<_bernie>   marcopg: MANUALLY?
<marcopg>   yeah manually
<_bernie>   marcopg: no, I think he had some script
<_bernie>   J5__: really?
<f13>       no, he said manually
<_bernie>   ah, I see.
<marcopg>   _bernie I doubt since I send him my changelog by mail
<marcopg>   sent
<f13>       16:20 <J5> dwmw2_BOS: yes, plus doing the ChangeLogs which is a pain
<f13>       16:21 <J5> dwmw2_BOS: ya, I never got around to automating it
<marcopg>   maybe we could have people which build rpms add entries to a wiki page or 
something
<marcopg>   not sure how well it would work out but... it would be better than nothing
<marcopg>   that + automatic packages diff might be good enough
<_bernie>   jg and dwmw2_BOS are discussing the CLA
<_bernie>   until the CLA issues are sorted out, do we really need it also for people 
who can only tag/untag packates?
<f13>       yes
<f13>       but we could identify maybe somebody else that can do the tagging since 
it's very quick steps/
<_bernie>   I'm looking for alternatives
<f13>       ?
<_bernie>   f13: I can do it
<_bernie>   f13: I volunteer
<marcopg>   I think we can also trust people that builds rpms to do it
<f13>       koji tag-pkg olpc-trial4 name-version-release
<marcopg>   once they got approval from jim and kim
<f13>       marcopg: you can do that too.
<_bernie>   it does not involve build master responsibility because I'd been told 
what to tag by my superiors anyway
<f13>       question I have.
<f13>       are you going to re-use olpc-trial3 or are you going to want a new tag/url?
<_bernie>   marcopg: yes, that's what you thought me about the sugar development process
<marcopg>   f13: I guess a new tag would be good
<marcopg>   f13: in case we need to do new images based on trial-3
<_bernie>   marcopg: the key is not the actual commit access
<marcopg>   f13: can the tag "inherit" from trial-3 though?
<f13>       I can do that, seems odd though.
<_bernie>   marcopg: as long as there's strong editorial control over what goes in 
the builds
<marcopg>   f13: it is :)
<f13>       you want to keep the trail-3 collection frozen, and just add things on 
top of it somewhere else?
<_bernie>   which is what I've always been begging for.
<marcopg>   it's just that
<f13>       marcopg: was that directed at me?
<marcopg>   trial-3 seem to have newer alsa-lib than OLPC-2 for example
<f13>       that seems... strange.
*           f13 wonders how that was accomplished :/
<marcopg>   f13: not sure, maybe we tagged a build which has not yet been pushed in the f7 updates?
<f13>       $ koji list-tags --build alsa-lib-1.0.14-4.fc7
<f13>       dist-fc7-override
<f13>       dist-fc7-updates-candidate
<f13>       olpc2-trial3
<f13>       it's a canidate update, that hasn't been pushed out stable yet.
<marcopg>   right
<f13>       ok, do you want this new collection to have allof current dist-olpc2, plus trial3 ?
<f13>       (or that as of say Monday?
<marcopg>   f13: that make sense to me
<marcopg>   m_stone: _bernie what do you think?
<f13>       and do you want this tag to self update whenever trial3 gets updated (or is trial3 
completely static not changing ever again?)
<marcopg>   trial3 *might* change
<marcopg>   so if we can avoid changes in trial3 to update this tag, that would be better
<f13>       sure.
<f13>       we'll just copy from trial3 to this tag instead of setting up inheritance.
<marcopg>   sounds good
<f13>       anyway, I'm late for teh bus, and won't be around much tonight.  I'll happily setup 
whatever holding tag you'll need on Monday, if that's not too late for you.
<marcopg>   f13: that works I think, thanks!
<f13>       np
<_bernie>   marcopg: sorry, I was afk
<_bernie>   marcopg: let me catch up
<marcopg>   _bernie there is still way too much undefined.
<marcopg>   _bernie We need to sort out the changelog process and who is responsible of actually 
running off the builds (pilgrim)
<marcopg>   more than anything else we need someone with at least a bit of time to lead this thing