On Fri, Aug 25, 2017 at 10:06:42AM -0400, Neal Gompa wrote: [snip] Thanks Neal. This is much more useful and I appreciate you taking the time despite the frusturation. > I'm extremely frustrated by how much half-baked-ness has been going on > in the last couple of months. Schedule shrinkage, features getting > cut, this modularity thing being implemented in a way that's looking > increasingly impossible to bypass while everyone I've talked to seems > to indicate that all of this is prototypical and likely to be > completely reworked again (which has already happened at least once This is a lot to unpack, but I'll try as much as I can. Some of my comments are pushback, but don't take that to mean I'm not taking the concerns seriously. Fedora *is* a project for baking things, and half-bakedness is an inherent step in baking. And I don't just mean in a "testing stuff for RHEL" sense — Fedora _should_ be leading in the distro space overall. On the other hand, we _don't_ want to be _unbaked_ (or "bleeding edge", if you like). We want what gets to users and to our mainstream contributors to be better than that. I hear three different main frustrations here: first, the short F27 schedule; second, frustration with with the packagedb retirement; and third, modularity. Schedule ======== I talked about the schedule and features with you a little bit on Twitter, but I'll say it in more than 140 characters here. Keeping to the schedule as we've defined for years isn't really "schedule shrinkage". It just feels new because we've never _really_ stuck to it before. In retrospect, I really wish I'd pushed for a shorter _F26_ schedule when that was being defined last year, but here we are now. I previously brought up the idea of flat-out changing the schedule to 9 months instead of 6 months, but literally no one supported that — there was a strong feeling that the six-month cadence is important. So, here we are figuring out how to live with that. Pushing back features is really only the way to do this. Cramming everything in would be even more chaotic. But, the important thing is that when we do it this way, we know with reasonable certainty that the F27 release will come out at a predictable time not so far in the future. Features which miss this release _will_ get to users in a reasonable timeframe. If, instead, we lengthened the schedule, adding 6 months from the F26 release, we'd be in mid/late December, which we know from experience means January. With delays, maybe February pushing March. And then, we'd be in the exact same position for F28, debating whether to shorten that or instead schedule for September instead of May. That would actually be _more_ delay for _more_ things. There's _really_ not a great answer here, but I think what we're doing is the best of the available choices. Pkgdb retirement =================== On the one hand, the new https://src.fedoraproject.org/ site is awesome. It's going to open up a whole lot of potential for new workflows and new contributors. On the other hand, yeah, the pkgdb retirement _was_ half-baked in retrospect. But, the people working on that are still baking. When you hit specific issues which impact your work, *please* file tickets at https://pagure.io/fedora-infrastructure/issues so they can get tracked and fixed. I'm not sure I really understand the part about not being able to see what's available in Fedora. From a user perspective, https://apps.fedoraproject.org/packages/ works very well for me (and it's _way_ faster than it was several years ago). From a contributor perspective, https://src.fedoraproject.org/ seems adequate if not yet perfect. The ability to display readme files _alone_ seems like a big step forward. It'd be nice to have better search and browsing, but the original pkgdb web UI wasn't great there _either_. Modularity ========== Yes, there's a lot of prototyping and reworking. Some of this may fail. But that's how it should be — it's really not possible to have innovation without trying some unsure paths. If you want to try other paths that help us solve some of the same problems, I'll support experimenting with them too. On your specific complaint about DNF not distinguishing between rpms and modules, you're definitely not alone; the Boltron feedback overwhelming tilted that way. See earlier thread on topic — and as I said in that thread, I think it makes most sense to treat modules like "super comps groups" (with either a superset of existing groups syntax and reuse of @, or simply a different syntax). In any case, this feedback _is_ important and _is_ listened to. I do want to _strongly_ stress, though, that the point of modularity isn't to avoid parallel installability. That's a separate problem. Modularity will allowing *us* at the packaging end to separate source and spec lifecycle from binary and artifact lifecycle. And, it will also allow those of us working on assembling spins and more options — for example, we can have different streams for Atomic without needing to actually duplicate every package. (And we could do the same for KDE or whatever other artifacts would benefit from that, if we want.) And that's not even with doing arbitrary branching for individual packages. If everything works out successfully with _that_, it will eventually make _less_ work for packagers. Right now, I have a package which I maintain for F25, F26, Rawhide, EPEL6, and EPEL7. There's no difference in any of the versions and no real reason to keep them separated; in the future, I will be able to have just one branch that goes to all of them. Or I could have a "stable" and "experimental" branch that people could choose from regardless of the base. This can benefit *way* more packages than simply leaf desktop applications. Will we get there? I don't know! It's new and different and definitely scary. But... it's also worth trying. In the meantime, if you're a packager who doesn't care about any of this, until modularity can demonstrate real success and advantages, you can _continue_ to not care. Modules are going to be drawn from f27 (and I expect f28) streams which will act as always, and even if Fedora Modular Server is a success, I expect we'll also provide a minimal install from which a traditional Fedora-based server can be built for a good long time. -- Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> Fedora Project Leader _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
