Re: [vdsm] VDSM Repository Reorganization
Hi Vinzenz, On 02/18/2013 05:43 PM, Vinzenz Feenstra wrote: It would be nice to come to an agreement any time soon. I would like to apply all the change as soon as possible. I would not like to see this go into the depth of a dead hole. The absence of feedback typically means one of 6 things: * No-one read it * No-one understood it * No-one cared * No-one is paying attention to you any more * It's so ridiculous it's unworthy of comment * Everyone who read it agrees I suggest you assume the last one, and proceed until someone starts shouting at you ;-) Thanks, Dave. -- Dave Neary - Community Action and Impact Open Source and Standards, Red Hat - http://community.redhat.com Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13 ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] VDSM - top 10 with patches with no activity for more than 30 days
Hi, On 02/28/2013 06:51 PM, Doron Fediuck wrote: thoughts on how to trim these? (in openstack gerrit they auto-abandon patches with no activity for a couple of weeks - author can revive them back when they are relevant) Review day? Anyone thinks a monthly review day will help? Yes, definitely a review day (announced beforehand) would help - another thing which would help in general is a page where you can see the oldest unreviewed patches. Also, I would love to see us have some social way that people can start reviewing patches when they join the project - there's no better way to understand the project. The best way to lower the number of unreviewed patches is to have more reviewers. Also - as someone not that familiar with Gerrit, what's involved in picking up someone's patch and revising it for them? A pattern I see over over again is: Jane submits patch Alex reviews: -1 with suggestions for improvements Jane submits patch rev #2 Barry reviews: -1 (whitespace issues) Jane submits patch #3 Hoda reviews: -1 with suggestions for another approach Jane loses interest and patch remains *almost* ready forever until it no longer applies or gets dropped. Is there a way we can promote adopt a patch where you take someone else's patch and push it through review? Cheers, Dave. -- Dave Neary - Community Action and Impact Open Source and Standards, Red Hat - http://community.redhat.com Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13 ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] vdsm - closer to open source versioning and release cycle
HI all, On 07/02/2013 09:17 PM, Alon Bar-Lev wrote: From: Federico Simoncelli fsimo...@redhat.com From: Kiril Nesenko ki...@redhat.com 1. We would like to see this [1] merged. We should start acting like a normal open source project and upstream should not be distro oriented ! [1] http://gerrit.ovirt.org/#/c/12448/ [1] is unrelated to being open source or being distro oriented. I agree with Federico - this is a distinct issue. If the patch were removing a dependency on the way a certain distro did something, then the comment would be correct. Just to summarize the patch [1], beside the technical details, it all comes down to change the release cycle bumping the version at the beginning of the development cycle. This might be common in java projects (and their tailored build systems as maven) but it's rather unconventional in python and in any other open source project that vdsm is relying upon, e.g. libvirt, qemu, etc. Bumping the version early (at the beginning of the development cycle) means that you are generating tarballs/rpms/debs/etc... advertising a version that is not released/finalized or complete (e.g. missing APIs). Which is perfectly ok, as you do work toward this version and you release tarballs/rpms/debs with pre-release signature. Release version naming is, mostly, not that big a deal. The important thing is the management of user expectations. - You don't want people to think that they're getting stable software when installing a 4.10.3-alpha package (or whatever) - You don't want people pulling the 4.10 branch to be under the impression that they are getting a stable release branch if in fact they are getting a development branch I think the version numbering/naming is less important than branch naming in this situation. The development should happen on feature branches, merged into master. Branches should only be created for a release when it is in pre-release stabilisation (so, after feature API freeze). Cheers, Dave. -- Dave Neary - Community Action and Impact Open Source and Standards, Red Hat - http://community.redhat.com Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13 ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
[vdsm] oVirt developer meeting @ KVM Forum
Hi everyone, Put the date in your calendar! The oVirt developer meeting will be held in Edinburgh on October 23rd alongside the KVM Forum. As most of you know, the KVM Forum is happening alongside LinuxCon Europe and CloudOpen Europe in Edinburgh this year, on October 21-23. As we proposed to the oVirt board in January, we would like to take advantage of this gathering of KVM core developers to plan the future of the oVirt project too. In addition to the numerous oVirt presentations which have been proposed both for CloudOpen and the KVM Forum, we will be setting aside one day for developer working sessions. The agenda for these sessions is not (yet) set - we will have subject matter experts leading discussions on the future of their component, where oVirt fits into the broader world of virtualization and the cloud, and how we can grow the community. Among the topics which may be on the table are: * Storage - integration with Gluster, Ceph, Swift, Cinder, NetApp, EMC * Core virtualization - what's missing to make oVirt the best virtualization solution on the market? What's next? How can oVirt best take advantage of the latest KVM features? * Networking - Going beyond Quantum integration: L2 and L3 networking in oVirt * User interface engine - making oVirt nicer to use and easeir to learn * Ecosystem - Integration with OpenStack, CloudStack; migration strategy from vSphere; integration with other 3rd party projects - what is our place in the world? * Community and marketing - Should we add a forum? How can we grow the user base and community of oVirt? (Note, these are just my ideas - topics will be set by session leaders on a specific topic). What next? First, if you are interested in the future of the oVirt project, please plan to attend the developer meeting. If you are active in oVirt, but cannot finance your travel to the event, please send an email to dne...@redhat.com - I can't promise anything, but we do not want budget constraints to be the main reason for someone missing the meeting. Second, if you are interested in leading a working session on one of the topics above, or a different topic which is important to you, please send an email to the Workshop program committee at workshop...@ovirt.org We will keep you posted with schedule updates and more details as plannign advances during the coming weeks. Thanks for your interest, and for your support of oVirt! Regards, Dave Neary. -- Dave Neary - Community Action and Impact Open Source and Standards, Red Hat - http://community.redhat.com Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13 ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] stale gerrit patches
Hi, On 09/23/2013 12:36 PM, Itamar Heim wrote: we have some very old gerrit patches. I'm for abandoning patches which were not touched over 60 days (to begin with, I think the number should actually be lower). they can always be re-opened by any interested party post their closure. i.e., looking at gerrit, the patch list should actually get attention, and not be a few worth looking at, with a lot of old patches I'm coming late to this discussion, but I see that there were some dissenting views from people who want maintainers to be able to store in-progress patches in Gerrit. I am all in favour of treating Gerrit like we treat a bug tracker. If something is opened in the bug tracker, it should be a bug, an open bug is something to be fixed or closed, not to be left indefinitely. An open patch needs to be rejected, reviewed, revised or committed. I don't think Gerrit is the place for in-progress patches (use private branches for that). Cheers, Dave. -- Dave Neary - Community Action and Impact Open Source and Standards, Red Hat - http://community.redhat.com Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13 ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
