2011/8/23 Peter Bonivart <[email protected]>: >> As a project, we'll be better off if we focus on one project at a time >> and get it finished, meaning, completed enough to be pushed out to the >> world. This way, we deliver to our users. > > I've been pushing that view to several of you for a long time, glad to > see someone else supporting it. It's obvious, both by your long list > above and by the almost two month long interruption in package > release, that we add tasks quicker than we complete them. Maybe we > should have some cap on how many tasks we have going at once?
Yes. There's one more thing to look at: who is contributing to projects. If we say that we work on 1 project, we need to make sure that all maintainers can contribute to that project. I imagine that Dagobert is able to work on pretty much any project you can think of. That doesn't have to be true for other people. So if we only focus on getting more people involved in the works, we would get a big boost, regardless to whether we cap the number of projects or not. > Another problem is the size of the tasks and how they tend to grow. > Perl is one example where the last step of 64 bit is holding > everything up, we have open bugs and an obsolete version of Perl, I > think we should have fixed those issues and then continued on with 64 > bit after that. Divide the tasks into steps that the users can benefit > from. Yes, and it's best if someone pays attention to that and suggests how to divide ongoing projects into parts. > If I'm correct the release process task was previously stuck on > signing the catalogs, then on notifying someone when the signing > process stopped and now it has sucked in the package browser on the > web site and Mantis integration into its black hole. :) I'm wondering > if this couldn't have been done in steps so users could have gotten > updates by now? Was this discussed on the list or only between those > involved? It's blocking on generating the new key and deploying it on cswsign. I'm talking to Ihsan about it, I think he has the key ready, and we need to escrow it, the way we decided in a vote some time ago. > I'm fine with people actually doing the work having more say > but by making stuff complex you also exclude people. I agree that keeping things simple is beneficial. However, there are cases where it's impossible to keep things simple and be able to do advanced tasks at the same time. Usually, we try to decouple functionality into smaller and easier to understand modules. For example, checkpkg is complex at places, but writing a single check is easy: you get a data structure, you pull out the list or dict you want, you look at the data that interests you and you call a function to report an error. It doesn't get simpler than that, at least I can't think of a simpler way to do it, given how complex are the packages themselves. Perhaps it's the matter of documentation and encouragement? If you have any ideas how to make things easier for people to get involved, please share. Maciej _______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
