16:00:13 <geppetto> #startmeeting fpc
16:00:13 <zodbot> Meeting started Thu May 28 16:00:13 2015 UTC.  The chair is geppetto. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:13 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:13 <geppetto> #meetingname fpc
16:00:13 <zodbot> The meeting name has been set to 'fpc'
16:00:13 <geppetto> #topic Roll Call
16:00:26 <mbooth> Hi
16:00:31 <geppetto> #chair mbooth
16:00:31 <zodbot> Current chairs: geppetto mbooth
16:01:05 <mbooth> Sorry for not anouncing my absence last week -- I was very far AFK when I remembered...
16:01:22 <geppetto> it's fine, we had like 7 people at one point :)
16:01:27 <mbooth> Wow!
16:01:43 <geppetto> SmootherFrOgZ: tibbs: ping
16:01:55 * SmootherFrOgZ is around
16:02:03 <geppetto> #chair SmootherFrOgZ
16:02:03 <zodbot> Current chairs: SmootherFrOgZ geppetto mbooth
16:02:52 <tibbs|w> Howdy.
16:03:00 <geppetto> #chair tibbs
16:03:01 <zodbot> Current chairs: SmootherFrOgZ geppetto mbooth tibbs
16:05:38 <geppetto> Orion is on IRC, but not responding to pings … tom said he wouldn't be around today
16:06:03 <geppetto> I can't see the others :(
16:07:21 <tibbs|w> Well poo.
16:07:46 <tibbs|w> Anything worth BS'ing about for a few?
16:08:35 <geppetto> Schedule is: https://lists.fedoraproject.org/pipermail/packaging/2015-May/010668.html
16:08:59 <geppetto> probably the main thing is updates to 531 … the weak deps. stuff
16:09:01 <tibbs|w> Wheee.
16:09:03 <Rathann> I'm here, sorry for being late
16:09:12 <geppetto> Cool … and then we had 5 :)
16:09:16 <geppetto> #chair Rathann
16:09:16 <zodbot> Current chairs: Rathann SmootherFrOgZ geppetto mbooth tibbs
16:09:22 <geppetto> #topic Schedule
16:09:27 <geppetto> https://lists.fedoraproject.org/pipermail/packaging/2015-May/010668.html
16:09:32 <tibbs|w> geppetto: Did the bootstrapping thing not make it on the agenda?
16:09:39 <geppetto> jsilhan: You want to go first, or waiting for people?
16:10:06 * ffesti is here
16:10:08 <geppetto> tibbs: We can always come to it anyway
16:10:14 <tibbs|w> I guess I moved it to meeting too late.
16:10:26 <geppetto> #topic #531 	Establish guidelines for use of weak dependencies in package specifications for F23.
16:10:27 <geppetto> .fpc 531
16:10:27 <geppetto> https://fedorahosted.org/fpc/ticket/531
16:10:29 <zodbot> geppetto: #531 (Establish guidelines for use of weak dependencies in package specifications for F23.) – fpc - https://fedorahosted.org/fpc/ticket/531
16:11:10 <ffesti> I basically rewrote https://fedoraproject.org/wiki/PackagingDrafts/WeakDependencies
16:11:57 <ffesti> Unlike I promissed last meeting I did not come up with two variants for the reverse deps
16:12:10 <ffesti> but may be the one I have is good enough
16:12:29 <tibbs|w> It's certainly concise.
16:12:38 <ffesti> The thing we still need to discuss is the time line for introduction
16:12:52 <ffesti> see last section
16:12:53 <tibbs|w> That depends more on tooling, I'd think.
16:13:43 <tibbs|w> What does old RPM do when it sees these in a spec?
16:13:53 <ffesti> well the short story is: yum does not and probably won't ever support weak deps
16:14:08 <ffesti> rpmbuild will refuse to build them
16:14:14 <tibbs|w> I think the question is less about "support" and more about "blow up".
16:14:25 <ffesti> rpm will just ignore the tags if they are in an binary rpm
16:14:35 <tibbs|w> OK, so what's the earliest version of RPM which will build a spec with such dependencies?
16:14:56 <tibbs|w> We don't have to worry about EPEL here, but it's polite to at least tell them that they'll need a guideline?
16:15:16 <ffesti> the problem is if packages rely on weak deps and people are still using yum they will end up with non working packages
16:15:22 <geppetto> ffesti: In the last part you could say that it's fine to add new weak/hint deps. … but can't replace requires with recommends until F23
16:15:25 <ffesti> like missing essential parts
16:15:44 <geppetto> Well, you can turn off recommends in dnf right?
16:15:56 <ffesti> well, the new/old scheme does not really work
16:16:27 <ffesti> geppetto, yes, but you basically give up the guarantee to get a working set of paclages
16:16:42 <geppetto> that doesn't sound very useful
16:16:53 <ffesti> this is fine if you do that on purpose - it may not if you juts continue using yum
16:16:58 <orionp> hello
16:17:02 <Rathann> I think it's 4.12.0+
16:17:04 <geppetto> #chair orionp
16:17:04 <zodbot> Current chairs: Rathann SmootherFrOgZ geppetto mbooth orionp tibbs
16:17:15 <geppetto> Rathann: wrong window?
16:17:16 <Rathann> according to the release notes
16:17:27 <ffesti> well it is useful in the sense that it gives you a smaller footprint that you can add the packages you really need by hand
16:17:56 <Rathann> geppetto: no, tibbs|w asked about the earliest rpm version
16:18:01 <ffesti> which is what the container people urgently want
16:18:27 <Rathann> http://www.rpm.org/wiki/Releases/4.12.0
16:18:42 <ffesti> yup, weak deps are supported in rpm for quite a while now
16:18:43 <geppetto> Rathann: Ahh, sorry.
16:19:09 <Rathann> geppetto: so this means F21+
16:19:20 <geppetto> ffesti: If that is the direction you want to go then you really need to reword the "weak deps." section … Eg. "Weak dependencies though may only be used if not installing the target package will not create an error" is just false.
16:19:26 <Rathann> not even EL7
16:20:01 <tibbs|w> Also, you can wrap these in %if/%endif?
16:20:12 <tibbs|w> Sorry, someone was at the door just before I hit enter there.
16:21:05 <geppetto> ffesti: But as said in the last meeintg … I don't think abusing weak deps. for the container people is the right direction. Have them workaround it better, and then install_weak_deps config. becomes viable for normal people
16:21:11 <ffesti> well, the policy is currently written with the assumtpion that weak deps are fully supported
16:21:29 <geppetto> But *shrugs*
16:21:34 <tibbs|w> Basically, if RPM in F21+ will build these, I'm happy to implement this now.
16:21:47 <ffesti> the "compatibility" section should state the point in time when this can be assumes and what to do previously
16:22:12 <tibbs|w> Might be nice to make an rpmlint test to warn about them not being actually functional with yum.
16:22:12 <ffesti> assumed
16:22:30 <tibbs|w> I guess people can still use yum in F22 if they really want to, even though dnf is the default.
16:23:12 <geppetto> meh … I kind of treat that like using any non-default package manager
16:23:17 <geppetto> they better know what they are doing
16:23:19 <tibbs|w> Indeed.
16:24:02 <ffesti> well my version of the "Compatibility" section assumes that yum can be used within F22
16:24:31 <geppetto> Yeh.
16:24:37 <ffesti> but I do not care about what policy we actually want to put there
16:24:41 <tibbs|w> So, basically, I like where we are.  Needs a quick cleanup pass but I don't have any tangible complaints on first reading.
16:24:46 <ffesti> just adjust the Fedora release
16:25:28 <geppetto> Well, as I said you want to match the expectations … if you reall can't toggle install_weak_deps without breaking stuff, then that needs to be documented.
16:26:04 <tibbs|w> Documented in the package or documented in the guideline?
16:26:20 <ffesti> well, "break" is a very broad term
16:27:04 <geppetto> tibbs: Probably both?
16:27:05 <tibbs|w> If you install with yum or weak deps disabled and the package doesn't actually work because it's missing important stuff, that's broken.
16:27:06 <ffesti> "But it is OK to create packages that are not useful without adding some of its weak requirements."
16:27:30 <ffesti> I mean what do you expect to happen if those packages are not installed...?
16:27:35 <tibbs|w> The question is whether we want to allow that now, later, or not at all.
16:28:07 <ffesti> well, that's the purpose of the weak deps
16:28:10 <ffesti> basically
16:28:24 <geppetto> ffesti: I guess my line would be "if the normal/expected functionality works, but other stuff doesn't … that's fine."
16:28:27 <ffesti> for a normal installation you are not supposed to turn them off
16:28:49 <geppetto> But if you install apache with weak deps. turned off and you can't serve files over http … that's just broken.
16:29:00 <tibbs|w> I see this as being most useful in situations such as the following:
16:29:21 <tibbs|w> Your app can talk to a database.  It can Suggest: mysql libs, postgres libs, sqlite, etc.
16:29:21 <geppetto> I guess it gets a lot more grey if you can't do CGI … but meh.
16:29:25 <Rathann> geppetto: I'd expect the minimal apache installation to be able to serve static html and nothing else
16:29:47 <tibbs|w> Now, if you have weak deps on, you get all of those libs, which is basically the situation today.
16:29:50 <Rathann> probably even mod_ssl would be in Recommends:
16:30:08 <tibbs|w> If you're going minimal, you can turn weak deps off.  You don't get a package that works because it has no database libs.
16:30:14 <tibbs|w> But you can install just the one you want.
16:30:19 <tibbs|w> Now, would we allow that?
16:30:34 <jsilhan> Would it be hard to treat Recommends as Requires in yum? and forbid reverse weak deps until f23? btw hi
16:30:38 <geppetto> Rathann: Maybe … I can see the desire on all sides there, although I think they might be better off using metapackages much like git vs. git-core etc.
16:30:39 <tibbs|w> It's completely in the spirit of weak deps, but it's also a broken package without them.
16:30:45 <ffesti> well, back ends should not be done with weak deps but with virtual provides
16:30:50 <geppetto> jsilhan: No, that'd be fairly trivial
16:30:58 <ffesti> so you have to install one of them
16:31:13 <tibbs|w> And for the record, I believe the situation I just outlined is acceptable.
16:31:14 <Rathann> geppetto: well, metapackages are often a workaround for when weak deps weren't there
16:31:27 <ffesti> weak deps are about packages which you might want all of them
16:31:44 <ffesti> but sometimes only some
16:32:43 <ffesti> yup, meta packages give a better perspective
16:32:52 <Rathann> so, this sentence needs to be reworded: "But it is OK to create packages that are not useful without adding some of its weak requirements."
16:32:57 <Rathann> it's not OK
16:32:58 <ffesti> you can remove them but you might end up with a very bare package
16:33:29 <Rathann> "It's fine to create packages that are missing some functionality without some of their weak dependencies."
16:33:56 <ffesti> ok, I'll change that
16:33:57 <Rathann> but basic functionality must be working
16:33:59 <ffesti> give me a sec
16:34:55 <tibbs|w> Rathann: So in the situation I outlined, what would you do?
16:34:57 <tibbs|w> I guess have a hard dep on sqlite, since it's the smallest.
16:35:04 <Rathann> we're also missing a real life example for the first use case, i.e. "Weak dependencies allow smaller minimal installations while keeping the default installation feature rich."
16:35:38 <tibbs|w> The example I just outlined would cover that.
16:35:51 <ffesti> Changed to " But it is OK to create packages that have very limited functionality without adding some of its weak requirements."
16:35:58 <geppetto> tibbs: I guess you don't want a hard dep. on it
16:36:02 <Rathann> tibbs|w: if it doesn't work without a database engine, then it has to have Requires: db-engine or something like that
16:36:07 <Rathann> a virtual provide
16:36:26 <ffesti> yup
16:36:41 <orionp> For DBs that almost never works as they can be hosted elsewhere
16:36:43 <ffesti> think about a media player
16:36:58 <ffesti> there is not a single file format that it really needs to support
16:37:01 <Rathann> orionp: oh, right!
16:37:25 <Rathann> so in that case yes, the package can have no hard requirements on any db engine
16:38:24 <Rathann> does anyone have an example where it would be useful not to add any hard db-engine Requires: to cut some dependency graph branches?
16:38:27 <ffesti> so if you create a special appliance that plays only ne video you can strip the package list down to just on backend (assuming they are all pacaged separately)
16:41:47 <tibbs|w> Rathann: Well, to be honest the mysql libs and postgres libs aren't really that huge so you're not saving a massive amount of space.
16:41:52 <geppetto> so … again … this is "works in special case, but breaks in normal case with install_weak_deps=false"
16:41:54 <tibbs|w> But pretty much any database-driven web app.
16:43:15 <Rathann> geppetto: well the normal case would be install_weak_deps=true, wouldn't it?
16:43:23 <geppetto> You can't have it both ways … either the policy is "install_weak_deps=false is viable for normal humans, and special cases have to be handled by something else" or "special packages ftw. replace requires with recommends all you want, just users shouldn't ever turn weak deps. off because they aren't that weak"
16:43:25 <ffesti> yes, of course
16:44:02 <geppetto> Rathann: Well, that depends on if that's a sane user config. … or if that's just for super special kickstart only, you get to keep all the peices when nothing works anymore.
16:44:10 <Rathann> :)
16:44:13 <ffesti> well, switching them off globaly is not the inteeresting use case
16:44:24 <ffesti> and you do not have to switch them off
16:44:34 <ffesti> you also can just remove the pakcages you do not need
16:44:45 <Rathann> personally I'd probably keep them on and just selectively uninstall unnecessary packages
16:44:53 <ffesti> which you could not if they were added by strong Requires
16:45:37 <geppetto> ffesti: I thought one of the dnf devs said that they are treated as normal requires when installed too, unless the install_weak_deps=false?
16:45:47 <ffesti> This whole "what happens if user switch them off" discussion is beside the point IMHO
16:46:34 <tibbs|w> I agree.
16:46:36 <ffesti> nope, they are treated "as requires" in the sense that dnf tries to fulfill them
16:46:48 <jsilhan> geppetto, yes, like normal requires but in case of conflict they are ignored. it's written in the draft that install_weak_deps=true is by default
16:46:56 <tibbs|w> If you know what you're doing, switch them off and understand that there are some deps that you'll just have to specify manually.
16:47:00 <ffesti> but if they fail - because you excluded or delete the package - they do not fail the transaction
16:47:21 <tibbs|w> This absolutely _must_ be documented, though.  I would say right in %description.
16:48:24 <geppetto> jsilhan: But if you leave install_weak_deps=true, install something that brings in weak deps, and then remove a weak dep. … does it then get rid of the weak requirer?
16:48:29 <ffesti> hmm, I had a phrase about this in my hands a few days ago...
16:48:40 <ffesti> did I delete it on accident?
16:48:53 <geppetto> tibbs: You want to list all the weak deps. in description?
16:49:08 <geppetto> tibbs: Like repoquery -q --recommends output?
16:49:10 <tibbs|w> Not really, since you can get those easily by other means.
16:49:21 <jsilhan> geppetto, it should as any userinstalled package
16:49:34 <tibbs|w> But something needs to actually say that there are weak deps without which the package may be broken.
16:49:35 <ffesti> tibbs, actually it is right in the "Weak deps" section
16:50:07 <ffesti> yes the description is short
16:50:24 <ffesti> but it is a packaging policy and not tthe rpm or dnf documentation
16:50:56 <geppetto> ffesti: So if I'm reading it right, jsilhan just said that you can't remove weak deps. … without changing the config.
16:51:04 <rholy-afk> if they will be removed when "install_weak_deps=false", then the name is misleading...
16:52:37 <rholy-afk> ...ehm, ignore me, I misread that...
16:52:46 <jsilhan> yes, they you can. and any packages requiring/recommending (and installed by dependency) it will be erased
16:53:59 <jsilhan> and other way round (as you probably mean) by that config
16:54:08 <jsilhan> I wrote that the name could change
16:54:15 <Rathann> tibbs|w: do you consider a package that doesn't work without any db-engine (but can use a remote one) broken if you're able to uninstall all db-engines?
16:54:23 <geppetto> how can you change the config. now … it's in F22
16:54:25 <jsilhan> we don't know the use cases yet so the right name
16:54:32 <tibbs|w> Rathann: I would not.
16:54:45 <tibbs|w> That's a pretty common case now and nobody complains.
16:54:54 <Rathann> ok then we shouldn't end up with broken packages if we remove any weak deps
16:54:56 <tibbs|w> But what about database libraries?
16:55:07 <jsilhan> the config option is not done
16:55:11 <jsilhan> yet
16:55:23 <geppetto> jsilhan: The config. option isn't in F22?
16:55:24 <Rathann> well if you link against any then rpmbuild will generate hard Requires on the sonames
16:55:30 <Rathann> no issue here
16:55:31 <jsilhan> no
16:55:39 <Rathann> tibbs|w: ^
16:55:47 <geppetto> ffesti: Ok, so the config. option shouldn't be in the policy … as it doesn't exist.
16:56:03 <tibbs|w> Rathann: Not for scripting languages.
16:56:06 <geppetto> tibbs: We have packages that you can install, but don't work because there's no DB, now?
16:56:18 <ffesti> I kinda had hope it might be implemented by now...
16:56:27 <tibbs|w> geppetto: We have plenty of packages that do nothing because you have to configure them to talk to _some_ database.
16:56:52 <Rathann> tibbs|w: in that case there should be a hard dep there
16:57:04 <tibbs|w> Hard dep on what?
16:57:14 <tibbs|w> Surely not mysql-server or postgres-server.
16:57:33 <tibbs|w> Byt python-mysql or python-postgres or whatever?  Maybe.
16:58:48 <Rathann> tibbs|w: the latter, yes
16:59:02 <Rathann> or rather python-db virtual provide
16:59:05 <ffesti> no matter how you get this solved: This is not a use case for weak deps (but virtual provides)
16:59:11 <Rathann> yes
16:59:35 <Rathann> the basic rule should be that removing weak deps must not render any package completely useless
17:00:08 <tibbs|w> I can go with that.
17:00:16 <Rathann> i.e. must not make it crash or unable to perform even the most basic operations
17:00:31 <tibbs|w> If it's a real issue, python-sqlite3 (or whatever) is tiny and gives you a database.
17:00:46 <ffesti> I kinda assume that this rule applies to packages no matter whether they have weak deps or not...
17:01:03 <geppetto> Rathann: That in the default usecase?
17:01:04 <ffesti> but it might bring up the question of weak deps in meta packages
17:01:15 <ffesti> which are by default completely useless..
17:01:26 <Rathann> geppetto: sorry, I don't understand the question
17:01:29 * ffesti runs
17:02:56 <Rathann> ffesti: hm, metapackages should (or: must) have at least one hard dep to be useful, right?
17:02:58 <geppetto> Rathann: As in people might make some package perform perform a basic operation (without the weak deps.) … but only in special/weird usecases … where the default usecase is completely useless
17:03:42 <Rathann> geppetto: that special/weird usecase could be the cloud image usecase where you want to have minimal deps and minimal functions
17:03:48 <Rathann> and I'm fine with that
17:04:08 <geppetto> I'm not sure I see the difference then
17:04:24 <geppetto> If only 1 out of 100 users are going to see something useful
17:04:52 <Rathann> IMO, the default usecase is what upstream recommends (to be enabled/installed) and what makes sense for a given Fedora product
17:05:03 <Rathann> that also assumes the weak deps are enabled by default
17:05:34 <Rathann> geppetto: I think you worry too much - do you have a specific example?
17:06:14 <geppetto> Rathann: The main usecase "everyone" is talking about is cloud+systemd where cloud people want the minimal to not be functional on non-cloud
17:06:28 <geppetto> As in, your system won't boot.
17:06:52 <Rathann> hm
17:07:29 <Rathann> I'm fine with that as long as systemd is in dnf protected packages list
17:07:52 <Rathann> and that list is installed by default on all other products
17:07:52 <ffesti> well the way to handle this is not to have a general policy about weak deps but about the core system demanding they are reachable via the base comps group via strong deps (aka Requires:)
17:07:57 <geppetto> Rathann: You mean the parts of systemd that would be under the weak deps?
17:08:17 <Rathann> geppetto: whichever parts cloud image doesn't need, yes
17:08:26 <jsilhan> Rathann, dnf is protected and requiring systemd
17:08:50 <geppetto> ffesti: But this will leak out into other things … unless there is some specific exception just for systemd
17:08:58 <Rathann> and that should suffice IMO
17:09:25 <geppetto> ffesti: Where people will say "You install XYZ without weak deps., and it doesn't work for 99% of people but it works in this one weird case, so it's fine via. policy"
17:09:52 <Rathann> geppetto: but why would you install XYZ without weak deps?
17:10:12 <Rathann> the default will be to install with them
17:10:16 <tibbs|w> Can we just say "please try to make sure your package has some useful functionality when weak deps are disabled" and actually trust the packagers?
17:10:19 <ffesti> May be the way around this is to bite the bullet and just say: if you turn them off your system will not boot: Make sure you know what you do
17:10:43 <tibbs|w> I mean, someone will always lawyer things to death.  We don't have to waste our time trying to make things 100% munchkin proof.
17:11:01 <geppetto> ffesti: And that's kind of fine, but we then need to set that expectation in the policy
17:11:07 <tibbs|w> And if a packager gets it wrong, there's bugzilla and provenpackagers.
17:11:15 <Rathann> I think having to disable weak deps and remove systemd from protected list should be enough of a hurdle for shooting yourself in the foot
17:11:52 <geppetto> The main thing I'm trying to get down is if the config. will be viable for normal people, and packagers should take it into account … or if it won't, and they should just trust us.
17:11:55 <Rathann> geppetto: you won't stop people from using rpm -e --nodeps
17:12:22 <Rathann> and you see --nodeps mentioned in quite a few places on the web
17:12:26 <geppetto> Because if we say it's viable, I can guarantee a bunch of "I like minimal" people are going to turn it off.
17:12:38 <rholy-afk> Hm, weak deps may not be installed because of a dependency conflict. So, one can install XYZ without weak deps unintentionally.
17:13:25 <geppetto> Rathann: but nobody is ever implying that's a good idea, or even viable
17:14:25 <Rathann> geppetto: Exactly. Having a minimal package set that boots as a container but not on bare metal, on the other hand, is a good idea and should be viable.
17:14:33 <geppetto> And while I don't think it's a great idea, if we want to go the same way with recommends … that's fine, I'll still +1 it. I just want it to be clear in the policy that you can't turn them off without being at the level of --nodeps.
17:16:05 <Rathann> rholy-afk: what happens if a package in protected set is a weak dep and has a dependency conflict?
17:16:31 <geppetto> Rathann: protected is a plugin, and only comes into force on remove.
17:16:59 <rholy> yeah
17:18:03 <ffesti> Add those packages to the proper comps groups - for god's sake!
17:18:24 <geppetto> ffesti: we don't control that
17:18:47 <geppetto> ffesti: And unless you want to put something in your policy about it, it's not really answering the question.
17:19:16 <Rathann> ok, so the weak-but-required-in-default-case boot-critical package will get installed in default installation and you won't be able to remove them unless you disable the protected plugin
17:19:23 <Rathann> that's good enough for me
17:21:22 <Rathann> but if the majority prefers that we don't allow that, I won't oppose
17:21:49 <geppetto> ok, so do you want to single systemd out somewhere … or have it be a generic weak deps. thing that they really can't be turned off?
17:22:12 * geppetto thinks deja vu is cool
17:23:47 <Rathann> geppetto: or... removing weak deps must not make system unbootable
17:24:29 <geppetto> I guess that's a viable workaround we can all wink at
17:24:48 <tibbs|w> We really shouldn't single out one package in any of our guidelines.
17:25:00 <tibbs|w> Can we just let them be guidelines and trust packagers to do something reasonable?
17:25:12 <tibbs|w> And trust the rest of the system to fix things when they don't?
17:25:25 <Rathann> that is my sentiment as well
17:25:48 * Rathann points out that we're almost at the 90 minute mark
17:25:59 * geppetto sighs
17:26:56 <geppetto> The point is for the guidlines to say what is reasonable … there are few ways of saying "don't use weak deps. to make it so nothing works, without the known desired systemd failing it"
17:26:57 * geppetto shrugs
17:27:49 <geppetto> Do we want to vote on it today?
17:28:43 <Rathann> ffesti: there's a typo in this sentence: " (Future versions of dnf might also allow to switch weak deps of on the command line) "
17:28:54 <Rathann> switch weak deps of_f_
17:29:36 <ffesti> fixed
17:29:38 <Rathann> also, I'm not able to parse this sentence: "Hint may not be used were the packages common use cases - use strong (Requires) or weak dependencies for that. "
17:33:04 <ffesti> hmm, still trying to come up with a more clear sentense
17:33:19 <Rathann> ffesti: so which part of the draft would go into the main guidelines and which into a subpage?
17:33:26 <ffesti> it is about not using Hits for stuff wewre you actually should use Requires: or Recommends:
17:33:29 <tibbs|w> geppetto: I think we should probably postpone if we want to do anything else.
17:33:45 <Rathann> yeah, it's not ready for voting as-is, I think
17:33:53 <tibbs|w> I am prepared to vote in the ticket once the draft is done.  I'll be happy to make a grammar pass as well.
17:34:32 <Rathann> my time is running out today
17:34:50 <Rathann> also, I won't make it next week, because of public holiday
17:35:39 <Rathann> so thank you and bye
17:35:39 <geppetto> Ok, are there any tickets we want to discuss this week then?
17:36:43 <geppetto> tibbs: you mentioned a bootup ticket, is that important?
17:36:51 <geppetto> I don't think anything else on the Schedule was, so …
17:37:09 <tibbs|w> Hard to tell, but we probably owe them a look at it since there was a lengthy response in the ticket.
17:37:09 <ffesti> Rathann, better now?
17:37:50 <ffesti> I have no idea yet how to integrate this into the policy
17:38:02 <ffesti> most of the page should probably be on a sub page
17:39:01 <ffesti> may be with a 3 sentence paragraph accompanying the link
17:40:11 <tibbs|w> The bootstrap thing is 529, BTW.
17:40:40 <ffesti> probably in the Requires section
17:40:58 <tibbs|w> I think they should just go ahead.  These files aren't specs and they shouldn't be treated any differently than any other random shell script someone may want to check into their package.
17:41:48 <ffesti> So is there anything I can still do to help with this?
17:41:58 <geppetto> tibbs: Yeh, I'd say it's at the same level as documentation
17:42:01 <tibbs|w> If they want to document how those scripts work, I'd be perfectly happy to review a guideline draft but I don't think it's necessary.
17:42:15 <tibbs|w> I'll just say that in the ticket and tell them to go ahead.
17:43:24 <geppetto> ffesti: Helping with were to put it? … It's not a big deal, can work it out when it gets voted on.
17:43:39 <ffesti> ok
17:44:30 <geppetto> tibbs: Rathann: You got any specific advise for stuff ffesti should work on before next meeting?
17:44:53 <tibbs|w> I don't really.  I owe the thing a good read, though.  Will comment in the ticket if I see anything.
17:45:14 <ffesti> ok, read you there then
17:45:26 <geppetto> #topic Open Fllor
17:45:48 <geppetto> Ok, I'll give ya'll a couple of minutes and then close.
17:46:01 <tibbs|w> Nothing from me.  Just replying to 529 now.
17:46:13 * geppetto nods
17:48:42 <geppetto> Ok, see ya next meeting
17:48:51 <geppetto> #endmeeting