path: root/meeting-logs/20130924.txt

<ulm> let's start                                                       [21:00]
<ulm> roll call
* scarabeus here
* rich0 here
<creffett> here, proxying for dilfridge
<scarabeus> creffett: but you are uglier than him! you can't! ;-)       [21:01]
* WilliamH here                                                         [21:02]
<ulm> blueness: dberkholz:
<dberkholz> hi
* blueness here
<ulm> k
<ulm> first topic: separate /usr                                        [21:03]
<ulm> http://thread.gmane.org/gmane.linux.gentoo.project/2946
<ulm> WilliamH: can you summarise?
<dberkholz> btw seems that i'm the only person using the google calendar for
            meetings.                                                   [21:04]
<WilliamH> ulm: is that the same link as
           http://comments.gmane.org/gmane.linux.gentoo.project/2946
<WilliamH> s/link/thread/
<ulm> dberkholz: hm, should we add such extra meetings?
<ulm> dberkholz: just remind the chairman then                          [21:05]
<dberkholz> ulm: i have a ridiculous schedule so i'd actually forgotten this
            was scheduled for today till i got pinged
<ulm> WilliamH: yeah, same posting
<blueness> WilliamH, there is still no documentation for separate NFS mounted
           /usr
<WilliamH> The thread I just linked is the original thread where I brought
           this back up.. Basically we were looking for issues that would
           block us from going forward and saying that
<WilliamH> we are ready to drop support for separate /usr without an
           initramfs.
<ulm> blueness: that's bug 481660?                                      [21:06]
<willikins> ulm: https://bugs.gentoo.org/481660 "Documentation for an early
            boot mechamism with a separate NFS mounted /usr is lacking";
            Gentoo Linux, Unspecified; CONF; blueness:base-system
<blueness> yep
<WilliamH> blueness: the position seemed to be that there is no need for
           separate documentation.
<WilliamH> blueness: for nfs.
<blueness> why?
<blueness> does it just work?
<WilliamH> blueness: I don't use nfs, but that was my understanding, it should
           just work (tm)                                               [21:07]
<WilliamH> blueness: it depends of course on what is in the initramfs, but
           iirc genkernel supports it.                                  [21:08]
<ulm> WilliamH: from some of your previous posts I had the impression that you
      intend to remove separate /usr support proactively
<rich0> That seemed to be the consensus - I didn't get a chance to test it
        personally, but that wouldn't take long to confirm one way or another.
<ulm> WilliamH: like removing gen_usr_ldscript from ebuilds
<ulm> WilliamH: and I'm a bit worried about it
<blueness> me too                                                       [21:09]
<ulm> WilliamH: so is this going to happen if we vote yes today?
<WilliamH> ulm: that is really a separate topic... mainly it should probably
           be discussed among base-system and toolchain...              [21:10]
<WilliamH> ulm: that is where most of the gen_usr_ldscript stuff is being
           done.
<blueness> WilliamH, it is not a separate topic, c'mon!                 [21:11]
<ulm> well, if we vote in favour of dropping support, we'll give base-system a
      carte blanche
<_AxS_> blueness: for genkernel initramfs, yes it just works.           [21:12]
<WilliamH> We have already stated our intent to drop support eventually.
<blueness> _AxS_, thanks
<scarabeus> i am in favor letting them doing what they feel fit, if most stuff
            work, there always be something cornery
<ulm> WilliamH: right, but from discussion in the august meeting my impression
      was that maintainers shouldn't remove existing support without a good
      reason                                                            [21:13]
<rich0> There will never be a "good time" for this.  My personal sense is that
        if we feel there are other things that need to be done to be ready we
        should identify them.  If it is just a matter of waiting to give
        people some time to setup initramfs/etc I could understand that, but I
        do want to avoid delay simply to avoid the unpleasant.
<WilliamH> ulm: the thing is, all it takes is one maintainer having a "good
           reason" to remove support.                                   [21:14]
<blueness> scarabeus, ulm yeah but i'm worried about more mariginal systems
           like the uclibc systems i work on, i need to know what removing
           gen_usr_ldscript would do there
* WilliamH agrees with rich0
<rich0> I'm also speaking generally, and not about things like
        gen_usr_ldscript in particular which need to be looked at beyond their
        impact to needing an initramfs and so on.
<WilliamH> If there are specific reasons we aren't ready we should fix them.
<rich0> However, I think the base-system team could be trusted to do that, as
        with any other detailed change.                                 [21:15]
<ulm> WilliamH: please remind me, did we push a news item for this already?
<WilliamH> ulm: No, but we can't without a yes vote that says we are ready to
           do so.
<rich0> I don't think we had a news item, and it probably wouldn't hurt to
        have one.  A news item and a delay for implementation would make more
        sense than just waiting.
<creffett> I have one other concern from dilfridge
<creffett>
           http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?part=1&chap=4
           <-needs to be clear that you will need an initramfs/early boot
           mechanism
<WilliamH> We have to vote that the documentation is ready.             [21:16]
<creffett> not a blocker, but would be nice to have
<creffett> also might want to not suggest separate /usr in the example there
<rich0> creffett: would you mind logging a bug for that, and adding it to the
        tracker?
<creffett> rich0: sure, mind linking the tracker?
<WilliamH> creffett:  http://bugs.gentoo.org/show_bug.cgi?id=481202     [21:17]
<rich0> bug 481202
<willikins> https://bugs.gentoo.org/481202 "Tracker - Documentation or
            Implementation Issues for Dropping of Separate /usr Support";
            Gentoo Linux, Unspecified; CONF; rich0:rich0
<creffett> thank you, filing
<ulm> hm, that bug still has another open blocker
<rich0> Beyond a news item, any other items that need attention?  I'm more
        concerned with a roadmap that gets us somewhere.
<rich0> That was the NFS one - probably can be closed out.              [21:18]
<blueness> yeah close that one
<WilliamH> rich0: Once the news item is done, and we give a little time for
           people to switch,
<WilliamH> rich0: whatever maintainers do should be transparent after the
           switch.
<ulm> WilliamH: how much time? three months?
<blueness> WilliamH, is there an easy way for me to test what will happen if
           we drop gen_usr_ldscript on the systems i work on?
<blueness> et for zlib
<blueness> can i just comment it out of the ebuild and see what happens?
                                                                        [21:19]
<WilliamH> ulm: That seems a little long...  the switch isn't a process that
           takes a long time or a whole lot of work?
<_AxS_> IMO bug 481660 can be closed.  Documentation may be needed for dracut
        and definitely would be needed for a roll-your-own, but overall a
        genkernel initramfs suffices and iirc tha main
        'get-an-initramfs-for-separate-/usr' documentation should be fine for
        that
<willikins> _AxS_: https://bugs.gentoo.org/481660 "Documentation for an early
            boot mechamism with a separate NFS mounted /usr is lacking";
            Gentoo Linux, Unspecified; CONF; blueness:base-system
<ulm> WilliamH: the relevant time is that some users don't update so often
<ulm> so certianly one week would be too short                          [21:20]
<WilliamH> ulm: agreed, a week is too short.
<ulm> and one year is probably too long
<WilliamH> ulm: yes, a year is definitely too long.
<rich0> This is a really big change.  I think three months is probably a good
        amount of time.  In the meantime I wouldn't expect maintainers to put
        a huge amount of effort into fixing bugs with not having
        initramfs/etc.                                                  [21:21]
<WilliamH> ulm: that's why I said 3 months seems a little long...
<dberkholz> are we actually breaking backwards compat in that it's impossible
            to upgrade? that's not my understanding.
<blueness> dberkholz, i think so
<WilliamH> dberkholz: not that I know of...
<rich0> Nope - only real impact here is that your system might not boot, in
        which case you boot from an install CD, chroot, configure an
        initramfs, and reboot.
<WilliamH> dberkholz: no it isn't going to be impossible to upgrade.
<dberkholz> i think 30 days is probably fine, given that there's a clear,
            specified upgrade path                                      [21:22]
<rich0> It is still painful if you didn't prepare.
<dberkholz> it's not like systems break the second they sync
<_AxS_> (..which can be a much bigger issue on a headless remote box..)
<WilliamH> dberkholz:  what would happen if you have separate /usr is
<dberkholz> you sync, you upgrade, you ignore the docs, you reboot, it fails
<scarabeus> _AxS_: we can show news item, like we do with other items, like we
            didn't break boot with udev a lot :P
<WilliamH> dberkholz: once a maintainer makes the changes, if you don't have
           an initramfs, you could end up in a situation where you would be
           unbootable.                                                  [21:23]
<_AxS_> scarabeus: *nod*
<dberkholz> this doesn't seem much different from any of dozens of other
            updates requiring manual effort
<WilliamH> dberkholz: that is after you upgrade the affected package
<WilliamH> dberkholz: but it would be fixed as soon as you
<WilliamH> dberkholz: put an initramfs in place
<WilliamH> I'm not for a multi-month delay on this.                     [21:24]
<dberkholz> it would be worthwhile to make some effort to detect whether we're
            on a system that will break and explicitly notify there
                                                                        [21:25]
<creffett> WilliamH: it's waited this long, I don't think a few months will
           make a difference in the long run
<dberkholz> in any ebuild with breaking changes
<ulm> how about this:
<ulm> "The Council agrees that all preparations for dropping support for
      separate /usr without an initramfs or similar boot mechanism are
      complete. A news item will be prepared, and users will be given two
      months to switch after the news item has been sent."
<blueness> ulm, sounds good actually                                    [21:26]
<scarabeus> wfm
<WilliamH> ulm: why not s/two months/one month/
<dberkholz> i'd prefer 30 but 60 is not terrible.
<scarabeus> two months are like package drop so our default timeout :)
<WilliamH> scarabeus: ?
<creffett> WilliamH: again, it's waited this long, I don't think it will be a
           huge problem to wait another month
<scarabeus> WilliamH: 60 days are package mas for removal :)
<scarabeus> *mask
<WilliamH> scarabeus: no, it is 30?
<ulm> ok, everyone state a time period please, and we'll take the median
                                                                        [21:27]
<_AxS_> scarabeus: 30, according to treecleaners
* ulm 90 days
<dberkholz> 30 days are like stabilization so our default timeout =)
* WilliamH says 30 days
<rich0> I'm fine with anything in the 30-90 day range.
<blueness> me too                                                       [21:28]
<blueness> if we wait too long we might want to send a second news item
           reminder, else people would forget
<ulm> creffett: scarabeus: ?
<rich0> We could always vote on your proposal with 30 days, then if it fails
        try again at 60, and so on.
<rich0> using ulm's text                                                [21:29]
<WilliamH> I agree with blueness, that's why I say 30 days, keep it short and
           sweet.
<creffett> ulm: 30-90 acceptable to me too
* scarabeus agree with 30-90
<dberkholz> 30-90 is acceptable to everyone. the question is which of those
            numbers to pick.
<_AxS_> averaging out responses = 45 days
<dberkholz> 30,60,90
<WilliamH> It seems that the majority who care say 30
<ulm> ok, let's vote
<creffett> I can live with 30, but again, I don't see the harm in 60/90
                                                                        [21:30]
<_AxS_> wait -- might it be better for this if it's an actual set deadline
        instead of a duration?
<ulm> "The Council agrees that all preparations for dropping support for
      separate /usr without an initramfs or similar boot mechanism are
      complete. A news item will be prepared, and users will be given one
      month to switch after the news item has been sent."
<ulm> one month variant
* WilliamH votes yes
* ulm votes no
* rich0 yes
* scarabeus yes
<dberkholz> yes
* blueness yes
* creffett abstains
<ulm> 5 yes, 1 no, 1 abstention
<ulm> accepted
<ulm> anything else for this topic?                                     [21:31]
<ulm> seems not
<ulm> next, open bugs with council involvement
<ulm> let's start with bug 481202 with is related to the previous topic
                                                                        [21:32]
<willikins> ulm: https://bugs.gentoo.org/481202 "Tracker - Documentation or
            Implementation Issues for Dropping of Separate /usr Support";
            Gentoo Linux, Unspecified; CONF; rich0:rich0
* WilliamH volunteers to work on the news item text
<rich0> I don't really see any action required there by us.
<creffett> just added my bug as a blocker
<ulm> WilliamH: ok, I'll note this as action
<blueness> yeah close that one
<rich0> Beyond all previously discussed.
<rich0> Oh, leave the tracker for now, but I think nothing there is a real
        blocker to moving forward.
<ulm> k
<ulm> no action for this bug, but leave it open for the time being      [21:33]
<ulm> bug 477030
<willikins> https://bugs.gentoo.org/477030 "Missing summary for 20130611
            council meeting"; Doc Other, Project-specific documentation; CONF;
            ulm:council
<_AxS_> someone should probably add a comment on the bug about the decision
        and maybe a link to the minutes/summary
<ulm> any progress there?
<ulm> _AxS_: yeah, we can do that                                       [21:34]
<ulm> seems no progress for the missing log
<ulm> bug 457000 is related                                             [21:35]
<willikins> https://bugs.gentoo.org/457000 "Missing log and summary for
            previous council meetings"; Doc Other, Project-specific
            documentation; CONF; ulm:council
<ulm> if there are no objections, I'll add the log and summary for the
      20080515 meeting
<ulm> as outlined in comment #8
<blueness> okay                                                         [21:36]
<ulm> anyone against it?
<scarabeus> nope
<ulm> seems not
<creffett> nope                                                         [21:37]
<_AxS_> for the others; does this still fall in jmbsvicetto's domain?  or can
        others do the work (assuming they have access to the logs)?
<ulm> _AxS_: the others are done
<_AxS_> Oh ok nvm
<ulm> bug 480408 is next
<willikins> ulm: https://bugs.gentoo.org/480408 "Add
            /releases/${arch}/verified tree for tested autobuilds"; Gentoo
            Linux, Unspecified; CONF; mattst88:release
<blueness> ulm, i'm not sure what we need to vote on there, it seems
           jmbsvicetto has a plan                                       [21:38]
<blueness> are we voting on jmbsvicetto comment 4?                      [21:39]
<_AxS_> ...maybe vote to leave it to releng and un-CC council?
<ulm> oops, I just see that we had discussed this one in august already
<ulm> "No action to be taken by the council. This should be sorted out within
      the releng team."
<ulm> says the summary of the 20130813 meeting
<ulm> so action is to remove council from CC, I guess                   [21:40]
<rich0> ++
<ulm> I see no objections                                               [21:41]
<scarabeus> not really :)
<ulm> finally, bug 485448
<willikins> https://bugs.gentoo.org/485448 "Migrate council project page to
            the wiki"; Doc Other, Project-specific documentation; CONF;
            ulm:council
<ulm> has anyone looked at the wiki page?
<ulm> http://wiki.gentoo.org/wiki/Project:Council
* scarabeus liked                                                       [21:42]
<dberkholz> It looks wiki-ish
<blueness> i like it
<ulm> dberkholz: sure ;)
<rich0> wfm
<blueness> dberkholz, is that bad?
<ulm> dberkholz: not gorg-ish any more
<dberkholz> yeah, actually. but that's not really a conversation for here. we
            need a better skin.
<creffett> well, everything looks wiki-ish...we're using a wiki for everything
           :P                                                           [21:43]
<dberkholz> is there some way to fold that really long list of council logs by
            default?
<ulm> dberkholz: yeah, I've thought about this, too
<dberkholz> nobody will scroll past that to see anything at the end
<dberkholz> either that or put it on its own page and link to it
<ulm> we could split the table by council terms
<ulm> or by years
<dberkholz> i would just throw it on a subpage.                         [21:44]
<ulm> dberkholz: or that
<dberkholz> seriously, how many people ever read that, compared to the other
            stuff
<creffett> subpage++
<_AxS_> meeting chairs/logs could go at the end, they don't really need to be
        right up there with meetings...
<ulm> dberkholz: or we could fold it by default
<ulm> that's maybe easiest
<blueness> yeah subpages sounds best                                    [21:45]
<ulm> apart from that detail, any objections against completing the migration?
                                                                        [21:46]
<ulm> i.e. the old project page would redirect to the wiki
<ulm> again, I see no objections                                        [21:47]
<dberkholz> yeah that sounds great.
<dberkholz> can't wait to get maximal content moved to the wiki
<ulm> and I'll ask infra to redirect http://council.gentoo.org/ to the wiki
      page                                                              [21:48]
<dberkholz> then we can focus more on making the website effective without
            ridiculous legacy costs for any changes
<a3li> ulm: read the bug and don't bother us!
<ulm> a3li: why should we have a double redirect?                       [21:49]
<ulm> a3li: or is it difficult to update it?
<a3li> to not have to update it for every project, yes
<ulm> well, council isn't a project exactly                             [21:50]
<ulm> any other opionions on this?
<ulm> *opinions                                                         [21:51]
<ulm> looks like we're done then                                        [21:52]
<ulm> no open floor today
<WilliamH> I would like to have the council proof my newsitem text... is now a
           good time?
<rich0> I don't see why that can't go through the normal bikeshedding, but I
        don't object.                                                   [21:53]
<ulm> WilliamH: I'd suggest that you send it to council@g.o
<ulm> but of course, we can also do it now
<WilliamH> ulm: Ok, I'll just add council@g.o to the newsitem email along with
           pr@gentoo.org when I send it to -dev.                        [21:54]
<ulm> WilliamH: sounds good
<WilliamH> ulm: hang on
<WilliamH> http://bpaste.net/show/135076
<WilliamH> The date will be replaced with the date the news item is committed.
<WilliamH> and the rest of the headers will be filled out of course.    [21:55]
<ulm> WilliamH: make it a round date, like 1-Nov-2013                   [21:56]
<ulm> assuming that this will be posted in september still              [21:57]
<_AxS_> .. a week of bikeshedding would put its post date at just before
        Oct.1st ..
<WilliamH> Ok 1-nov-2013 is fair enough. :-)                            [21:58]
<rich0> I'd change it to talk about other alternatives beyond initramfs - it
        is a news item after all.  However, that probably is best bikeshedded
        offline.
* WilliamH corrects the text
<ulm> WilliamH: maybe s/you will find/you may find/                     [21:59]
<_AxS_> rich0: ..  isn't initramfs the only officially supported solution for
        sep-/usr now tho?
<rich0> ulm: ++ I thought that as well
<rich0> It is by far the best documented one, but there are other options.
<rich0> Not sure I'd go into details, but we could mention that they exist.
                                                                        [22:00]
<rich0> The only thing that matters is that you have /usr mounted when you get
        into the meat of rc.
<_AxS_> rich0: there are options for making it work, but iirc based on this
        and prior votes, the only officially supported solution is either
        initramfs+sep-/usr or /usr-on-/
<rich0> Well, we don't have to mention it then.                         [22:01]
<ulm> I suggest that we continue bikesheeding of the news item in the -dev ML
<rich0> Agree
<rich0> Others might have more valuable input as well.
*** ulm (~ulm@gentoo/developer/ulm) has set the topic for #gentoo-council:
    "Next meeting: 8 Oct 2013 at 19:00 UTC |
    http://www.gentoo.org/proj/en/council/utctolocal.html?time=19:00 |
    http://www.gentoo.org/proj/en/council/"
<ulm> finally, we're done for this month then
<ulm> next meeting 8 Oct                                                [22:02]
<ulm> dilfridge will be chairing
<scarabeus> so one week without meeting? :P
<rich0> Just in time for a call for agenda items :)
<ulm> dilfridge: call for agenda items should be sent today ;)
<ulm> rich0: right
<WilliamH> heh
<ulm> so thanks everyone                                                [22:03]
<WilliamH> We have had several extra meetings, but we are getting things done.
           :-)
<ulm> and I close this meeting
<WilliamH> So I don't mind the extra meetings.
<blueness> until next time!                                             [22:04]
<creffett> hey, better to have people percieve the council as getting stuff
           done                                                         [22:05]
<rich0> thanks ulm...  we got our money's worth out of you this time.
<creffett> instead of pushing everything back
<rich0> creffett: ++ - yes, I feel like we're really moving along.
* WilliamH agrees with creffett  
<rich0> Now we just get to see how that news item goes over.  :)        [22:06]
<WilliamH> rich0: heh, get your fire-proof suit on
<rich0> I signed on for it.  :)
* creffett opens the bar