Some comments about meetings and organization.
Hello all, I tried to comment this in the irc but nobody give me an answer or opinion about. I will try to explain it as best as I can. I was thinking in the fact that there are a few meetings and they seem to be organized in the moment (may be some points are thought before it). In my opinion can be a good idea to make a little list with interesting points to be discussed in a meeting and try to put them priorities. I thougth in 2 meeting in a month, but this can sound hard because time is quite expensive in some cases. May be we can make an effort and try with one meeting per month. My first point of this is that seems hard to maintain core/opt ports and by now, there are only 3 sys/core devels (maintaing xorg too). I see communication one of the best ways to keep alive a project (IMO organization, in all senses, too, but if the first point is hard, this is harder). I can see some people (most of them in contrib), doing a great job and seems that contrib isn't a repo to trust, I can't say anything about this because I feel that contrib maintainers keep well done ports updated and I feel that their work isn't well valued. With this email I am trying to get people (core/opt/contrib members, maintainers, users, retired members,...) opinion about what I said. I am sorry about my english level, I tried to explain it in the best way and with the less words to don't bore anybody. I hope this can be a start point to try organizing a bit some points. Regards, pitillo. Learning bit by bit. pitillo
Hi, pitillo! pitillo schrieb:
I tried to comment this in the irc but nobody give me an answer or opinion about. I will try to explain it as best as I can.
It doesn't seem there is much feedback on this topic. :-]
I was thinking in the fact that there are a few meetings and they seem to be organized in the moment (may be some points are thought before it).
In my opinion can be a good idea to make a little list with interesting points to be discussed in a meeting and try to put them priorities. I thougth in 2 meeting in a month, but this can sound hard because time is quite expensive in some cases. May be we can make an effort and try with one meeting per month.
Personally, I prefer conclusive/informative mails and discussions here on the list, primarily because my workstyle doesn't fit to the more or less "real-time" IRC flow.
My first point of this is that seems hard to maintain core/opt ports and by now, there are only 3 sys/core devels (maintaing xorg too). I see communication one of the best ways to keep alive a project (IMO organization, in all senses, too, but if the first point is hard, this is harder). I can see some people (most of them in contrib), doing a great job and seems that contrib isn't a repo to trust, I can't say anything about this because I feel that contrib maintainers keep well done ports updated and I feel that their work isn't well valued.
Well, from my point of view, I am pretty fine how the current core + opt + contrib is maintained. I try to give feedback as much as possible if I come to some outdated versions or obvious bugs. But aside of that, I don't need/expect more from the core maintainers. Thanks to them for the good work! Because I am always tight in time for recurring tasks like system updates and new versions, I am currently planning to offload some tasks and automate as much as possible. So, the idea is: - automagically check for updates on websites/ftp servers/... for updates of some packages ('ve seen some script somewhere around). - build a (weekly) CRUX snapshot with the latest available ports. (being able to react to users like jorg with hardware support issues) - check for errors and fix as they come. - do that for all platforms (x86, ppc) The ultimate goal is to get to more current versions, find bugs/problems more quickly in my development process and avoid them to leak into my production systems. I got some infrastructure (root-server) ready for this. But because of lack of time, things just go sloooowly. Feedback / Ideas are of course welcome. Clemens -- Paui Technologies
participants (2)
-
Clemens Koller -
pitillo