fesco-townhall
LOGS
16:59:36 <jds2001> #startmeeting FESCo Townhall
16:59:36 <zodbot> Meeting started Tue Nov 27 16:59:36 2012 UTC.  The chair is jds2001. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:59:36 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:59:48 <jds2001> zodbot: hello? :D
17:00:24 <zodbot> jds2001: Error: Can't start another meeting, one is in progress.
17:00:38 <jds2001> #meetingname fesco-townhall
17:00:38 <zodbot> The meeting name has been set to 'fesco-townhall'
17:00:50 <jds2001> OK, let's get started.
17:01:19 <jds2001> abadger1999 (Toshio) sends his regrets.
17:01:43 <jds2001> First, let's get a brief introduction from each of the candidates.
17:02:33 <jds2001> limburgher: i guess we can start with you :)
17:02:45 * jds2001 going alphabetical by IRC nick :)
17:03:09 <limburgher> Hi, Jon Ciesla, current/outgoing FESCO member, package maintainer for 5-6 years, minor Infrastructure involvement.
17:03:53 <jds2001> mitr?
17:04:50 <mitr> Hello, Miloslav Trmač, current FESCo member, contributing for ~10 years, dayjob focuses on security; priority for Fedora is to make it better at integrating various upstreams into a coherent distribution
17:05:18 <jds2001> cool. mjg59?
17:06:24 <mjg59> Hi, I'm Matthew Garrett. I've been working on Fedora since 2008, been on Fesco for a decent amount of that, I've recently been doing a lot of work on UEFI and Secure Boot
17:07:13 <jds2001> mmaslano?
17:08:14 <mmaslano> hello, Marcela Mašláňová. I'm current FESCo member, I'm contributor last 6 years. My dayjob is focused on interpreted languages. I'm member of Perl SIG.
17:08:35 <jds2001> cool, msivak ?
17:08:44 <msivak> Hi, Martin Sivak, anaconda devel, Python teacher and currently the maintainer of firstboot and couple of smaller packages. Linux user since 1999.
17:09:04 <jds2001> and last but not least, sgallagh?
17:09:23 <jds2001> (btw, for the questions, feel free to go in any order that you like)
17:09:37 <sgallagh> Hi, I'm Steve Gallagher. I'm a former FESCo member, package maintainer for several applications for the last five years. I maintain ReviewBoard for Fedora Infra and have been working on building an OpenShift Gerrit template. I've also been the lead developer on the SSSD and I am currently employed by Red Hat as the BaseOS Architect working to bridge the gaps between project teams. I'm also heavily involved with the OpenLMI system m
17:10:01 <jds2001> oops, too long
17:10:12 <jds2001> last we got was OpenLMI system...
17:10:20 <sgallagh> I'm also heavily involved with the OpenLMI system manageability project.
17:10:50 <jds2001> ok, cool. And for our first question from FranciscoD
17:11:05 <jds2001> Q: What do you think are the goals of a Fedora release? Do we have generic goals such as "add new features"; "present lastest  versions", or should/do we set concrete goals, such as "Fedora 18's goals are to have a new $core-application" or "Focus on improving  support for $audience-subgroup"? If we work with generic goals, is that good enough?
17:11:42 <limburgher> I feel that the goals of each Fedora release should include software version updates, new features, and better integration of existing software.  Additionally, it's good to see groundbreaking changes, like systemd, new desktops, and new platforms.  Each release should be a tangible improvement to the end user.
17:12:31 <mjg59> jds2001: Answer in turn, or as we write stuff?
17:13:01 <jds2001> mjg59: whatever order
17:13:16 <mmaslano> I guess we should focus on integration of software more than on new features. I don't think new features should break usability of old features (for example one year old).
17:13:37 <sgallagh> I think the goal of a Fedora release SHOULD be to get new technology into the hands of users as quickly as we can without sacrificing stability and compatibility. We want to stay true to our basic tenet of being the First to deliver new features, but failing to deliver them stably will only sour our users (and lose them as potential contributors)
17:13:41 <msivak> I do not think generic goals work too well anymore, we have had big changes staged for the past couple of releases and the distro was not ready without those finished. So I would like to have at least some specific goals we can use when decision about release/slip needs to be done.
17:13:43 <mitr> What happens in Fedora releases is primarily driven by upstream efforts, Fedora follows that and should integrate them well (e.g. updating users of an updated library that haven't been yet updated upstream).
17:13:45 <mitr> There are quite a few upstreams that are Fedora specific, so in that sense it's both "add new features" and "present latest versions."
17:13:47 <mitr> I would very much like to start setting Fedora-wide goals for a release, to be able to accomplish things that are too big a task for an individual or a small group of people.  We can start with "small things" like getting the sysv->systemd migration done, and see whether the scope of goals should be expaneded later.
17:14:06 <mjg59> Specific goals per-release would imply a kind of top-down leadership that doesn't exist in Fedora. If we wanted that kind of leadership, I think that would have to be a movement that started with the community.
17:14:47 <mjg59> Practically speaking, what happens now is that features that people want to drive in Fedora get driven. Sometimes that's as simple as software updates, sometimes it's a wholescale reorganisation and integration of fundamental parts of the stack.
17:15:00 <mjg59> And I think that process works.
17:16:17 <mjg59> The Ubuntu-style "We have decided that our next release will include these features. Now go and implement them for us" approach really isn't one I see working in Fedora :p
17:16:18 <jds2001> ok, lacking any more questions, I have one :)
17:16:27 <jds2001> mjg59: :)
17:17:44 <jds2001> for wide-ranging features such as the aforementioned sysV->systemd migration, what do you think the role of feature owners should be in eihter updating packages that depend on it (i.e. doing hte migration for the packages) or driving the relevant maintainers to do the work?
17:17:45 <msivak> mjg59: true, but what about.. is the goal "deliver all newest versions at some date" or "take proposed and pushed features and make them the release driver"?
17:18:12 <jds2001> obviously, one would need provenpackager status to implement changes oneself in packages they dont own.
17:18:45 <jds2001> im thinking of the kernel model, where if you change an interface, it's incumbent upon you to change all consumers.
17:18:54 <limburgher> I think feature owners should drive the coordination, which may include finding a PP to assist.
17:19:23 <mjg59> I think feature owners should take responsibility for ensuring that integration work is done, whether that's by doing it themselves or helping others implement it
17:19:51 <msivak> I do not think actually commiting to other peoples projects work, proven packages does not mean proven developer, especially when it touches some complicated project like gcc/glibc
17:19:53 <sgallagh> I think that wide-ranging changes to the OS should require a FESCo sponsor. Someone who would be responsible for wrangling regular packagers where possible, or petitioning a provenpackager to do work where the maintainer is unavailable.
17:20:12 <msivak> but actively working with the maintainers and proposing patches might work well
17:20:21 <mmaslano> Feature owner should provide at least documentation, and he shouldn't push changes without discussion with maintainer. Better tracking of what must be done would also improve the current situation.
17:21:00 <mjg59> mmaslano: I don't entirely agree. For some trivial modifications, I think it's entirely acceptable for the feature driver to do the change without discussing it with the maintainer first
17:21:14 <mjg59> mmaslano: They should obviously let the maintainer know what they've done and why
17:21:16 <mmaslano> mjg59: it's hard to say what is trivial
17:21:17 <msivak> having a "merge request" capability somehow integrated into FAS or bugzilla might also help
17:21:23 <sgallagh> mjg59: I think FESCo needs to be involved in the determination of "trivial"
17:21:58 <mjg59> sgallagh: For example, the current config file rework - I've no problem with that being done by the feature owner (and in fact we basically tasked the feature owner with doing that work)
17:22:16 <mitr> "That depends".  The binding condition should be that the work of other people isn't broken, especially without adequate notification.  So, for distribution-wide changes that the feature owners can't manage themselves, having it coordinated for everyone is the only option.  For smaller changes, or changes where it really doesn't matter whether "everything gets done", it's better when the responsibility is on the feature owners (i
17:22:16 <msivak> I agree with marcela, lots of projects have internal structure which isn't entirely obvious for an outsider
17:22:18 <mitr> t places the burden on those who want the change).
17:22:37 <sgallagh> msivak: Adding new features to Fedora Infrastructure is a noble goal, but someone needs to do that work. Perhaps running Fedora's pkgdb git on Gerrit might be a start?
17:22:48 <msivak> sgallagh: yes, it might
17:22:54 <limburgher> I'd ideally like to see each feature have a sub-wrangler in FESCO, that could assist with all of this.
17:23:07 <sgallagh> limburgher: +1
17:23:16 <mjg59> msivak: Well, on a tangent, but - if your package is maintained in such a way that it depends on information that's not obvious to another packager, that's already a problem for a collaborative project
17:23:26 <mitr> msivak: upstream projects and their Fedora packaging are, at least conceptually, separate.
17:23:29 <limburgher> mjg59: <nods>
17:23:31 <mjg59> msivak: What if you're on holiday and there's a security issue?
17:23:41 <mitr> As a matter of principle, we can't satisfy every upstream.
17:24:01 <msivak> mjg59: well if it is a critical package, you shouldn't be the only one working on it
17:24:19 <sgallagh> msivak: When a security issue is found, *all* packages are critical :)
17:24:48 <mjg59> msivak: So obviously yeah I don't think it's a great idea for just anyone to be committing to glibc. But anyone sufficiently skilled should be able to commit to the glibc package without needing to do incredible amounts of research first.
17:25:07 <jds2001> shall we move on to the next question?
17:25:44 <jds2001> this one is from misc
17:25:51 <jds2001> "how do you think fesco can scale with a growing community and number of feature[s]"
17:26:12 <sgallagh> I think that's two different questions, one of them unfortunately misleading.
17:26:15 <mjg59> I don't think there's any problem with the number of community requests being brought to fesco
17:26:42 <mjg59> Or with fesco's ability to keep track of the significant changes being carried out by the fedora community
17:26:52 <limburgher> I agree with sgallagh.  The first we're doing well with.  The second is another issue.
17:26:56 <mjg59> The number of features, on the other hand, *is* a problem
17:27:01 <mmaslano> The number of features is a problem. But I believe we can propose new feature process where we can get rid off marketing features
17:27:06 <mjg59> And there's a bunch of reasons for that
17:27:15 <sgallagh> I think that while we've seen more Features proposed in recent releases, only a few of them have required significant effort beyond a rubber-stamp and a "ok, go ahead"
17:27:21 <mitr> FESCo is currently able to handle the "load" with what it does right now.  But we can do better, and the https://fedoraproject.org/wiki/User:Mmaslano/Feature_process proposal is a significant part of that - spend less time on changes with local impact (at the same time giving everyone more voice in the decision), and spend more time on significant integration challenges.
17:28:13 <mjg59> But yes, reworking the feature process is an important part of ensuring that fesco can continue to keep track of technical issues without also having the burden of approving marketing messages
17:28:34 <mmaslano> sgallagh: yes, but we'd like to go through planned features more, check dependencies etc.
17:28:40 <sgallagh> Yeah, I think that if we can eliminate some of the rubber-stamp features, we'll see that there are far fewer serious issues than the Feature list length seems to suggest
17:28:49 <limburgher> mmaslano: +1
17:28:59 <msivak> it is mostly about keeping people informed and notified, I think we can do better
17:29:18 <sgallagh> mmaslano: I'm fully supportive of that. I haven't had a chance to read your proposal carefully yet, but I agree on most of the high-level points.
17:30:02 <mmaslano> well it's not my proposal. It was a cooperation of few current members
17:30:36 <mmaslano> that should be first goal for new fesco, review feature process and came with plan for next release
17:30:42 <sgallagh> +1
17:33:28 <msivak> I am also for clearly restating the Fedora goals, because it looks to me we are currently in a kind of "split" and cannot decide whether we like ubuntu simple polished style or a bit rougher bleeding edge style.. both have their proponents and it is not possible to satisfy both groups 100%
17:33:43 <jds2001> our next question comes from tflink
17:33:46 <jds2001> My question is based partially on mitr's responce to the question: "where do you see fedora in a year" saying in part: "Better QA (more  automated testing, more involvement of testers in planning of updates and feature integration); in my experience doing such work upfront
17:33:52 <jds2001> pays off in the future, especialy when a component is faced with a large magnitude of "external" changes, like it is often thae case within  Fedora."
17:34:19 <jds2001> so can candidates comment on how they see this working, if they agree?
17:35:20 <jds2001> "as someone involved in QA, I'm not against this in principle but I hear some talk about more automation or more QA involvement. As a group,  we're already rather busy keeping up with Fedora releases and I doubt that a general mandate would accomplish this goal. Would you support  such an initiative? If so, how would you see it working? How do you see QA's role in Fedora
17:35:29 <sgallagh> Truthfully, it sounds like a good idea in theory. In practice, I think you'll find that volunteer maintainers won't be fond of extra steps in creating their updates.
17:35:52 <limburgher> I think QA is critical, but we can't be afraid of rough edges.  Fedora has always been bleeding edge, which is why it is as vital a distro as it is.  Let Ubuntu be Ubuntu.  We're building something usable, yes, but also leading the way forward.
17:35:54 <msivak> exactly, it pays off, but somebody needs to write the tests...
17:36:15 <mjg59> I think if fesco wants more automated QA, fesco gets to write more automated QA
17:36:22 <mitr> I'd like to get package maintainers more involved in the QA effort - writing their own automated test cases, discussing planned updates with a dedicated QA owner, if any[1]; and motivating people to get involved in QA more by relaxing some formal requirements in such cases (e.g. "if you have an automated integration test that passes, that counts as a +1 karma for updates; an ack by a dedicated QA owner allows an immediate push to
17:36:24 <mitr> stable")
17:36:37 <sgallagh> For better or worst, most updates in Fedora are rebases to new upstream releases. They either get tested during the updates-testing window or don't. I'm not sure we can do much to enhance that, short of modifying yum/PackageKit to start suggesting updates-testing packages
17:36:48 <mjg59> Part of fesco's role is to provide technical guidance, but I think that's much more feasible if fesco also provides technical leadership
17:37:02 <limburgher> mjg59:  +1, that's our role.
17:37:04 <mjg59> And the best kind of leader is the one who goes out and does the work that needs doing
17:37:18 <mjg59> If we have a vision, we shouldn't shy away from doing the work to make that happen
17:37:39 <mitr> [1] QA owner - the idea is to have a second pair of eyes who follows the package over time.  As it stands now, that would be adding more QA load to current volunteers, but the simplified process would encourage developers to "pair up" as QA owners, bringing more manpower.
17:37:44 <limburgher> That's why FESCO needs to get more involved with each feature.
17:37:56 <msivak> sure, but how many packages there are in fedora? we can show the way, but we do not have the manpower or expertise to work with all the packagesw
17:38:24 <msivak> I like mitr's peer-review
17:38:34 <limburgher> It's part of FESCO's job to evaluate features and split or scale them if they're too ambitious.
17:38:45 <mjg59> msivak: For stuff like automated QA, we can take responsibility for implementing a best-practices demonstration for a few packages
17:38:51 <msivak> and I said it before, if the packages are smaller, more fine grained then the testing gets easier
17:38:57 <sgallagh> limburgher: Sure, that makes sense for Features. But I think we're talking here about all individual packages.
17:39:07 <sgallagh> Which I think is too unwieldy for simple solutions.
17:39:13 <mitr> msivak: sure, but the testing needs to happen in the first place.
17:39:14 <limburgher> Agreed.
17:39:34 <mmaslano> I'm not sure how many fedora qa we have, so do they have capacity to work on features with feature owners?
17:39:44 <mmaslano> it would be helpfull, but I'm not sure if it's doable
17:39:45 <jds2001> tflink adds that there's definitely interest in automation, but no manpower.
17:39:48 <mitr> mmaslano: They don't right now.
17:39:59 <sgallagh> Ultimately, many Fedora packages are reliant on their upstreams having done due diligence. Which is not always the case, unfortunately.
17:40:10 <jds2001> (they're consumed wih release validation most of the year)
17:40:20 <sgallagh> We try to rely on the Bodhi updates process to weed out the updates that break stuff, but that does not always work
17:40:29 <mitr> Right now we would probably get QA owners for a handful of packages - OTOH various upstream teams already team up on providing karma to each other's packages, this  would just get them a little more involved
17:40:32 <msivak> mitr: right, but when you have isolated packages which do not require extensive environment setup to do a simple test, it gets much easier
17:40:48 <mmaslano> we, developers, can write more tests for our packages as part of upstream tests
17:40:59 <mmaslano> imho we should focus more on integration tests
17:41:05 <mitr> s/upstream teams/SIGs/ above
17:41:08 <mjg59> Of course, there's also broader integration QA that could be done
17:41:34 <mjg59> It wouldn't be impossible to do a nightly test compose from updates-testing and check whether it at least boots to each of the desktops
17:41:59 <mitr> mmaslano: right, quality at the individual package level is... sort of.. upstream's responsibility.  Making sure that, to pick a challenging example, rawhide boots, is Fedora's
17:42:02 <mjg59> ...which kind of brings me to another point. We talk about QA a lot, but we obviously focus QA on releases rather than rawhide.
17:42:17 <msivak> mmaslano: even integrated unittests that check the package in isolation are usefull, we could promote the check section in spec files more
17:42:18 <mjg59> How do we make rawhide useful?
17:42:45 <mjg59> Right now it's impossible to know whether rawhide will even boot at any given time
17:42:52 <jds2001> im going to voice tflink since this is his question.
17:42:57 <jds2001> or not
17:42:59 <mjg59> Which makes it pretty much impossible to do any kind of development against rawhide
17:43:02 <jds2001> 12:42 -!- #fedora-townhall You're not a channel operator
17:43:03 <sgallagh> mjg59: My suggestion a long time ago was that Fedora N+1 should be branched from Fedora N, not Rawhide.
17:43:04 <mitr> mjg59: I think automation has to be a major part of the answer - we will never be able to stabilize it using the manual effot that is spent on releases.
17:43:15 <sgallagh> Then we can use Rawhide as a true testbed and merge things in only when they're ready.
17:43:31 <sgallagh> As opposed to snapshotting Fedora N+1 work from a known-unstable place
17:43:42 <mjg59> sgallagh: Well, the point here is that right now it's almost impossible to develop features against N+1 until branch
17:44:08 <jds2001> we have no further questions, so tflink is voiced to conitnue this :)
17:44:11 <mjg59> And then we end up with problems like Anaconda taking too long because it got developed against N rather than N+1
17:44:11 <sgallagh> Right, but I'm suggesting that with git, we could basically branch N+1 as soon as N hits beta
17:44:16 <mitr> sgallagh: That would require distribution-wide branches and merges to work well.  That might be useful for many reasons, however the infrastructure implications are really non-trivial  (and when merging thousands of packages, there will _always_ be conflicts)
17:44:37 <mjg59> sgallagh: Wouldn't the first thing to happen then just be people merging their rawhide branches over the top of the new branch?
17:45:05 <msivak> sgallagh: we have hard time working on anaconda even after branch, you generaly need N+1 tools to develop N+1 feature and that is not always working well.. and when the tools are crashing on you and you have no alternative.. well you can imagine the mood we get into
17:45:28 <mjg59> I think there's two main approaches we could take to rawhide. The first is a change in the way people treat rawhide - we could encourage people not to commit to rawhide unless they're running rawhide
17:45:44 <mjg59> The second is that we could actually impose some level of process on rawhide
17:45:57 <sgallagh> mjg59: That first option doesn't really work since our current policy demands clean upgrade
17:46:02 <tflink> I'd love to see more of what mjg59 is talking about: more testing before the release process. with the example of anaconda, it would have been great to have a semi-frozen rawhide for them to work with while they worked on anaconda
17:46:06 <msivak> you mean like stable vs. testing in bodhi?
17:46:14 <sgallagh> Unless you mean "not to commit to rawhide other than what's in Branched"
17:46:37 <mitr> tflink: To me, freezing is primarily a defense against incompatible changes, which... ideally shouldn't happen as often as they do
17:46:38 <tflink> so that there is a new-ish tree that could be built on, just focusing on what needs to be changed
17:46:45 <mjg59> I do note that right now nobody knows what the process is
17:46:47 <limburgher> Then why Branch?  Wouldn't rawhide and Branched just change places?
17:46:54 <mjg59> During branched, should people be committing to branched or to rawhide?
17:46:57 * tflink isn't trying to pick on anaconda, it's just an example
17:47:02 <mjg59> The way inheritance works encourages the former
17:47:02 <mitr> Testing for rawhide can organically grow from test setups built for updates
17:47:12 <mjg59> Which, to me, seems backwards
17:47:48 <limburgher> I think the "commit to rawhide first" model can continue to work.
17:47:58 <tflink> mitr: yeah, but freezing is done at the last minute. I'm not talking about freezing rawhide but providing the capability for groups to have rawhide snapshots to work off of
17:48:14 <mjg59> So ideally it would be possible to start developing features in rawhide the day after branching, right?
17:48:29 <tflink> so that there is less time spent on any rawhide changes but it should be easier to merge the work and produce images or other products needed for development
17:48:39 <mitr> limburgher: I think that's the only possible one - but we could more strongly set the expectation that you only commit things that you are convinced will work, that committing experimental code because "it's rawhide" is not acceptable.
17:48:41 <mjg59> And our release process actually kind of depends on that
17:48:50 <sgallagh> Perhaps we could change the way rawhide does its repocreation. We could potentially require that Rawhide completes a successful nightly compose before new package updates enter the installable repo.
17:48:56 <mjg59> The window between branch and freeze is so small that there's no time to do real development on a release there
17:48:58 <mmaslano> mitr: I second that
17:49:04 <limburgher> mitr:  Totally.
17:49:10 <msivak> mjg59: in theory, but when everybody dumps their stockpiled changes at the same time, the rawhide breaks.. and it will stay broken for weeks
17:49:10 <sgallagh> We'd have to allow buildroot overrides of course (and this would largely eliminate chain-builds though)
17:49:15 <mjg59> msivak: Exactly
17:49:29 <limburgher> rawhide needs to be allowed to be broken, but only if work to fix it is planned and underway.
17:49:32 <mjg59> msivak: Our release schedule and development model are based on a false assumption that you can develop against rawhide
17:49:47 <mitr> sgallagh: That would require something like O(number_of_packages_updated_per_day) composes per day, wouldn't it?
17:49:52 <mjg59> And we need to figure out why
17:50:08 <mjg59> limburgher: I'm... not entirely in favour of that
17:50:12 <sgallagh> mitr: No, I'm suggesting one compose per day to populate the repos
17:50:24 <sgallagh> We'd have to maintain a separate buildroot though
17:50:31 <mjg59> limburgher: It's probably worth comparing to Debian unstable, which is roughly equivalent to rawhide but which has much better usability
17:50:37 <jds2001> we have one final question that i'd like to get in....
17:50:38 <mitr> sgallagh: Ah, I understand now.
17:50:39 <tflink> mitr: I think that we could do it with some dependency resolution tests as things are built in addition to one compose per unit time (day, half day etc.)
17:51:05 <jds2001> from misc: "what are the plan for accomodating the conflicting needs between platform stability, and being first on feature, since one of the complaint  is that fedora change too often to work on it"
17:51:17 <msivak> mjg59: the main issue here are libraries, development tools and the bare system, when those are at leas semi-stable end user apps can be fixed easily
17:51:21 <sgallagh> mitr: And the idea would be that the repos wouldn't actually get populated from the pending packages if the compose breaks. Someone would have to fix it and then rekick the compose
17:51:56 <mjg59> Could do with a clarification: are we talking about plaform stability between releases, or within a release?
17:52:09 <mjg59> (Or during development?)
17:52:18 <jds2001> between releases
17:52:45 <limburgher> I think increased use of tags could help, like the way we've done boost updates.
17:52:54 <jds2001> (though i personally would be interested about within a release as well)
17:53:00 <mjg59> It may sound like I'm ignoring reality here, but I think the platform churn will settle down
17:53:30 <mitr> Regarding platform stability, we have to accept what various upstreamsgive us in the current model  (whether stable or not, and compatible or not).  We could define a "Fedora managed platform" that we drive more strongly, but that would be a huge change.
17:53:30 <mjg59> The changes we're looking at for F19 are far less aggressive in that respect than the previous few releases
17:54:09 <msivak> we can't have both.. either we have the newest stuff or the stable environment, we just need to figure out what we want the most
17:54:30 <mjg59> msivak: We can have both, providing that upstream are providing a stable platform
17:54:31 <mitr> My preference is to, instead of "doing an Android" and having our own platforms (as if we didn't have enough of them already), to roll with the upstream changes, and "only" make sure we handle them well.
17:54:38 <mitr> mjg59: Which they aren't.
17:54:49 <mjg59> mitr: I think we're getting to the point where they are
17:54:58 <mjg59> We've had a huge number of transitions over the past 18 months
17:55:05 <mitr> mjg59: I don't see any decrease in rate of change
17:55:18 <mitr> but predictions are hard, of course
17:55:19 <mjg59> We're not looking at anywhere near as many in the near future
17:55:22 <msivak> mjg59: no, if Fedora wants the newest stuff from upstream, we have no change of keeping API stable
17:55:34 <msivak> chance
17:55:36 <mjg59> msivak: Sure we do, if upstream themselves are maintaining API
17:55:49 <mitr> mjg59: Well, then there are the long unresolved changes like Python 2-> Python 3 that we've been more or less sweeping under the rug for years
17:55:51 <msivak> mjg59: but if they change it?
17:56:20 <msivak> we could reject changes like that, but then we are not bleeding edge
17:56:31 <mjg59> msivak: My point is that upstream churn isn't an inherent reality
17:56:34 <limburgher> mitr: The whole community is.  I think this will pick up when GNOME goes Python3.
17:57:03 <mjg59> msivak: We work with a large number of upstream people. Fedora's a desirable target for many of them.
17:57:20 <mjg59> msivak: We do have the ability to work with them to encourage compatibility here
17:57:20 <msivak> mjg59: it is.. I see it in bugzilla every day, some packages have a really fast changing API
17:57:25 <mmaslano> I guess for python3 are blockers yum, anaconda etc. If we have manpower to rewrite them, we can change deafult safely
17:57:36 <mitr> msivak: One thing that we coul perhaps do, is to discuss particularly troublesome API changes, and try to push components that over time show uninterested in providing a stable base for others to work on "to the margins", e.g. out of the default spin.
17:57:37 <sgallagh> msivak: I agree with mjg59 here. If upstream is churning API constantly, one of our downstream responsibilities is to educate them on the problems that causes.
17:58:04 <msivak> sgallagh: you can educate them, but you cannot force them
17:58:26 <mjg59> Of course, it'd be easier if we defined a platform that was somewhat abstracted from the lower layers
17:58:38 <mjg59> C, it turns out, is a really dreadful language for this
17:58:45 <mitr> mjg59: Paradoxically, only the very lowest layers (kernel & glibc) are really stable.
17:59:01 <sgallagh> msivak: Well, that's not entirely true. If an upstream is breaking ABI constantly, they won't maintain a user base in the long-term. Ultimately they'll either shape up or die off.
17:59:10 <msivak> and I am all for making the packages more fine grained with better contained API changes.. but if the upstream does not listen, we have to either move to a different project or live with it
17:59:46 <sgallagh> mitr: I'm not so sure I agree with that. glibc has broken its promises a couple times in the last two years...
18:00:09 <msivak> sgallagh: unfortunately, Network Manager still has it's userbase and they are changing the API very often
18:00:34 <jds2001> #chair
18:00:34 <zodbot> Current chairs: jds2001
18:00:38 <jds2001> #chair FranciscoD
18:00:38 <zodbot> Current chairs: FranciscoD jds2001
18:00:54 * jds2001 has a hard stop right now, but this is good.
18:01:00 <mitr> One thing that hasn't been mentioned here, and that could definitely be improved, is having the maintainer of the package that changes the API to notify others about it and help with the transition.  The policies do already require that, but it happens much more rarely than it should.
18:01:01 <sgallagh> msivak: That particular example is one that I am fully aware of. I have been in conversations with them about that. I'm expecting that to stabilize now.
18:01:02 <mjg59> But hey, why doesn't Fedora take the lead in defining a useful platform with upstream buy-in?
18:01:08 <jds2001> thanks everyone!!, FranciscoD can finsih up :)
18:01:14 <FranciscoD> thanks jds2001 :)
18:01:27 <sgallagh> thanks jds2001
18:01:36 <FranciscoD> Folks, we're past the 1 hour mark. If you could please have your final comments in, we'll wrap up :)
18:01:37 <mjg59> And by "useful platform" I mean "Not LSB"
18:01:44 <mitr> mjg59: Some upstreams take "the lead in defining a useful platform", and what to do if they differ, as they will?
18:02:05 <msivak> can we force major version number change for incompatible API changes? and keeping the legacy API until everybody moves over?
18:02:16 <mjg59> mitr: We work with them as part of the community
18:02:35 <sgallagh> msivak: In some languages like C, we have SOnames for that. But Python/Ruby are tougher to deal with.
18:02:37 <mjg59> If nobody upstream believes there's any value in a defined platform, we can never offer one
18:02:38 <mitr> mjg59: that's... not an answer.
18:02:46 <mitr> there wil be confclits.
18:02:47 <mjg59> So it's not worth worrying about it at the Fedora level
18:03:21 <mjg59> Practically speaking, what's happening is that whatever Ubuntu ships is becoming the Linux platform
18:03:29 <msivak> sgallagh: we need to pay attention to the API changes in sonames, automated testing could help with that
18:03:35 <mitr> msivak: All that is possible; it would be a really huge change in what Fedora is and expects.  I don't know, perhaps we will need to do that.
18:04:00 <sgallagh> msivak: Yes, tools can be written to help detect ABI changes. I know the samba project has a suite for this that we could perhaps appropriate.
18:04:12 <mjg59> And games appear to be shifting to Mono
18:04:22 <msivak> at least we would have an early warning
18:05:02 <mjg59> Anyway. Uh. Final comments.
18:05:09 <sgallagh> mjg59: You make a good point about Ubuntu. We need to try to focus our efforts on making Fedora the place where new development is happening again.
18:05:56 <mjg59> Fedora's something different in the Linux world. It's a collaborative project with a huge amount of technical ability that doesn't have to worry about paying bills and isn't so overloaded with process that nothing ever gets done.
18:06:34 <mjg59> Preserving that is worth effort from everyone, and regardless of whether I'm re-elected to fesco I'll be putting in that effort.
18:06:35 <sgallagh> Final comments: Fedora's future depends on developer support. We need to direct our focus on making developers want to work in Fedora again. This (to me) means cleaning up the Feature process, making Rawhide usable and improving our tooling and packaging processes.
18:07:49 <mmaslano> The developers are the most important to Fedora. We should work on infrastructure, make easy procesess and better tools for co-operation.
18:07:55 <limburgher> Final comment:  We need to keep moving forward by defining the future, and adapting to changes.  It's what's gotten us as far as we've come, and will continue to serve us well.
18:09:00 <msivak> Well.. we need to focus on recognizing the potential breakage (ABI, dependencies, ..) early. I think that making packages into smaller units which can be tested separately (no big break in the whole subsystem.. just a smaller one) could save us and FedoraQA the time needed for thinking out and implementing bigger changes. This way we can make better and more stable platform for our developers to use.
18:09:35 * FranciscoD waits for any more final comments
18:11:29 <mitr> Final comment: The fundamental purpose of a distribution is to integrate various upstreams into a well-working whole.  We need  improve in this area; this will give us breathing room to more substantially improve in the future.
18:12:39 <FranciscoD> Looks like we have everyone's input.
18:13:01 <FranciscoD> Thank you all for coming to the FESCo townhall: candidates, and community members over at #fedora-townhall-public
18:13:26 <FranciscoD> A special thank you to jds2001 for moderating the session.
18:13:39 <FranciscoD> I wish all the candidates luck for the ballot.
18:13:45 <limburgher> Thanks all!
18:13:57 <mitr> jds2001, FranciscoD, everyone:  Thanks!
18:14:01 <sgallagh> Thanks!
18:14:20 <msivak> Thanks everybody
18:15:10 <FranciscoD> OK. Ending meeting. Have a good morning/afternoon/evening/night everyone :)
18:15:14 <FranciscoD> #endmeeting