On Thu, 05 Aug 2004 21:16:25 -0400, Toshio <toshio@xxxxxxxxxxxxxxx> wrote: > My priority is to get the most people contributing and learning what > makes good packaging. To my way of thinking, the best way to do that is > to let people package the latest one or two applications without having > to flush the whole OS. And then (the hard part) get them to stick with > them as others critique and add their knowledge of what would make those > packages better. A fair point. Everything has trade-offs. I could live with new packagers being encouraged to build against the latest Core release for a window of time with an intent to sync development with help. But I think for example encourging new contributors to target FC1 right now is a dimishing returns situation even on the mentoring front. Contributing is part access and part responsibility, I think that at a minimum its appropriate to require new contributors to be targeting new packages against the newest available Core release instead of the oldest available as a compromise between making the process accessible and making sure packagers are committed to taking responsibility. If you can't be bothered to run the latests release, thats going to lead to significant problems to your ability to maintain a Fedora package, > Although I do think it's a goal worthy of being done at the collection level. I still think you have a different interpretation of Tiemann's strawman than I do. Hopefully Tiemann finds time to read these rantings before he redrafts to clarity what 'at the collections level' means in your sentence. I'll refrain from further twisting Tiemann's proposal for my own agenda until his promised update next week. > I think the syncing of packages is the least of your worries. Creating > livecd and Rule based mediasets through cherry-picking Extras strikes me > as close to impossible even with ordained syncing. Cough... have you see the work Dirk Westfal is doing with his custom rpm based livecd creation templates? http://www.linux4all.de/livecd/barebone/index.htm I should let Dirk comment on the difficult livecd issues are as he views them. And i should let Marco comment on the difficult rule issues are as he views them. What limited personal communication i've had with both of them makes me think getting Extras synced with Core helps them. My assessment of the situation could of course be wrong, so it would be nice for them to at least give a brief "Jef is on crack" response if I'm offbase here. > Ironically, that's actually pretty close to my thoughts on what belongs > in Core vs Extras: How much harm does instant gratification get you? If its not co-ordinated with appropriate action tied to the devel tree.. it potentially gets you a broken update path from Core release to Core release. > .... but I don't think a requirement to sync with Core development is > reasonable. Forcing people to use unstable software so they can > contribute isn't why I'm packaging. Trade-offs, personal interests played off against larger interests of the project you are contributing to. I want a balance between the two. I'm not saying that people can't build new stuff for FC1 right now, but I want their desire for instant gratification balanced against the larger projects need for continued maintainence of that package for FC2 and FC3 development that is currently on-going. > More > reasonably, there are going to be times when a package is created on a > FC-release-X box, QA'd by others on FC-release-X boxes, and the build > fails on RawHide is that grounds to exclude it? I want people to committed to making a good faith effort to work on issues in the development tree. I have no illusions what-so-ever that all issues with Extras packages are going to be resolvable in a timely manager inside development. I fear for the sanity of anyone who takes of the challenge to maintain wine as an extra, thats going to be a constant pain. I just want a commitment to make the effort. So no i don't think failing to build in rawhide is a reason to exclude a specific package from existing releases. But if the packager isn't working to resolve the problems with the package in the development tree... that needs to have some consequences. -jef
