-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Fri, 2017-08-25 at 16:23 -0400, Matthew Miller wrote: > 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. Agree here, but we need to support people when they want to make Fedora leader in some area instead of silently ignoring them for 2 releases (that's just my real example). > > 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. That's why we need to work on automation of things, testing and so on. For example, even small targeted-rebuilds after bumping soname requiring manual work. Retiring of rdma stuff broke composes. There are a lot of bad things which could have been prevented if we had automation. I don't think that we need to extend schedule to 9 months, but for F27 we could have shrinked big changes. > > There's _really_ not a great answer here, but I think what we're > doing is the best of the available choices. So why we didn't push back modularity / Factory 2.0 and other stuff from F27? Since it's most of breaking parts. We could had F27 without that stuff to disturb people less due to short schedule. > > > 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_. Honestly, I was always impatient on waiting pagure-dist-git deployment! I always wanted to send PRs instead of attaching patches in bugzilla. I think this should bring more contributions from people.. Just my 5 Kč. > > > 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. Can we finally kill this comps stuff please? > > 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.) You could have one branch and buildsystem would build it against all "distributions", why to invent new thing? Which also involves new data format and additional maintenance. I see way bigger problems in Fedora than this, tbh. > > 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. It's definitely 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. That's not true 😉 I'm maintainer of gpgme and I've got forced to apply some patches related to Platform Python stack (which is one of modularity changes). You underestimate how Modularity affects distribution. > > > > > -- > Matthew Miller > <mattdm@xxxxxxxxxxxxxxxxx> > Fedora Project Leader > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx - -- - -Igor Gnatenko -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlmhhL4ACgkQaVcUvRu8 X0xW1A/+POBWoiTO1XNOLDXxWBfj+v2wa856Yesi4omsHm5duGlXXSYUBwVTZuhQ gYzwETE9hr+DZbdVBnaZp0i36D8ZN6c9JpGlhiqh+XLlQdZwbDbpe4uq0vAAr9tP AwwUWt2Oinz9qDDhswtK5fDNCpQNykRArWmE74KYSddfEaiOdHAOJ/jilAMZynQF bMPuM0k55jAYh4k+3B4tk0SdzSh0PbPQ2E46V9AcYiqiQO19he7gxMVjq6McSTdL 0NQorFPHwTCcej5ntKPpoU5VZF4TQi3jychVec2HRQSJ68jRSe4yPRIDTYw8jwsu ViDnqvGc4V0PsDa/xPLZUoN2imemxYSp9VUnN8kxJHYn3QMAwbHqmPpoFCLFgC+z OsTeHMFAsYHce7x0tYeUr/M3NZWTTnUeUhzvFp9t7e9ti4UNoCOIImbizc9/ZQRy 5A4D/tZP8CvvdKdPeKm11AXy/EhzCoIUeVoqF869SG6nZCg5yIJ3WX6B4ATVZc4Y Mq29VUF+POZKyEzgsIVPgqMyZDHqCg9n0bNtg171oTtocdauGj/mFp9iO8YoBDIx 3gTcfX3Wnb6AezClaOZwASPKWG2STXQgjLXlHOg4fov/fA4IrPW0lUP2mos8DvUl J4VhkRXMZTynKnZ7T9TIJ4T6PmalJcxFvpMAnAHscCKw9Obi69A= =Xj7A -----END PGP SIGNATURE----- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
