[RFC] Communicating within the community [was Re: [ovirt-users] I wrote an oVirt thing]
Moving to devel since this needs developer attention On Tue, Nov 29, 2016 at 2:50 PM, Logan Kuhn <logank@wolfram.com> wrote:
Is this something that was officially announced and I've missed? This is the first time I'm hearing about the removal of the cli
I tend to agree with Logan here, we have a lack of communication on what's going on. We haven't weekly status meetings anymore, the experiment on office hours didn't work and progress reports to mailing lists are not sent anymore. We need to rethink the way we propagate information. Up to now the only way we have to give info on coming deprecation is the release notes page which is built from bugzilla doctext so if no other way is used to communicate changes, at least please use a bug.
Regards, Logan
-- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com
I actually checked the oVirt 4.0.0 and 4.0.5 release notes and I do not see anything mentioning ovirt-cli or REST v3 deprecation. This will (removal of RESTv3 support) affect the optimizer and quite possibly even hosted engine setup. Martin On Tue, Nov 29, 2016 at 3:26 PM, Sandro Bonazzola <sbonazzo@redhat.com> wrote:
Moving to devel since this needs developer attention
On Tue, Nov 29, 2016 at 2:50 PM, Logan Kuhn <logank@wolfram.com> wrote:
Is this something that was officially announced and I've missed? This is the first time I'm hearing about the removal of the cli
I tend to agree with Logan here, we have a lack of communication on what's going on. We haven't weekly status meetings anymore, the experiment on office hours didn't work and progress reports to mailing lists are not sent anymore. We need to rethink the way we propagate information.
Up to now the only way we have to give info on coming deprecation is the release notes page which is built from bugzilla doctext so if no other way is used to communicate changes, at least please use a bug.
Regards, Logan
-- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
--6vO7XPX410tGIdeaDd8vHPHiFWq9KBsQt Content-Type: multipart/mixed; boundary="DBF1W8S4vdnL8lF9uOrtGKNJqlgfbXBci"; protected-headers="v1" From: Sven Kieske <s.kieske@mittwald.de> To: devel@ovirt.org Message-ID: <67209bda-e448-39f5-b480-4a499eb2327a@mittwald.de> Subject: Re: [ovirt-devel] [RFC] Communicating within the community [was Re: [ovirt-users] I wrote an oVirt thing] References: <CAPQRNT=UT4rcfW12R7K=xXOhXgdXFMae_U1wNy0ZrNn-AXuFzw@mail.gmail.com> <CAF0zDV4j4vPCYUGpc_LwUvQA3bNXcXuFwxdx2zXHZR-VoiQ1Ug@mail.gmail.com> In-Reply-To: <CAF0zDV4j4vPCYUGpc_LwUvQA3bNXcXuFwxdx2zXHZR-VoiQ1Ug@mail.gmail.com> --DBF1W8S4vdnL8lF9uOrtGKNJqlgfbXBci Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 29/11/16 15:54, Martin Sivak wrote:
I actually checked the oVirt 4.0.0 and 4.0.5 release notes and I do not see anything mentioning ovirt-cli or REST v3 deprecation. This will (removal of RESTv3 support) affect the optimizer and quite possibly even hosted engine setup.
Hi, this seems to indicate that even core ovirt devs do not know about every feature which gets deprecated. Maybe this could be solved by sandro's suggestion to at least create an BZ for each deprecation. I would agree with that, but also like to propose an alternative way, because at the stage of bug creation the deprecation is already set in stone and can't be discussed further (I fear). So my proposal would be to mail to the devel list at least the proposal: "I/we want to get rid of feature/implementation X, use Z instead". This would give developers and users enough time to engage with the community, replacing dependencies or start a discussion if removal can't be done later. A clear deprecation guideline would also be helpful, I guess. Something like: Features will get marked as deprecated in release X.Y and removed in X.Y+2 (or whatever number you might chose). This would allow for much better preparation in the community and lead to less unpleasant surprises. HTH & keep up the good work! --=20 Mit freundlichen Gr=FC=DFen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG K=F6nigsberger Stra=DFe 6 32339 Espelkamp T: +495772 293100 F: +495772 293333 https://www.mittwald.de Gesch=E4ftsf=FChrer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhause= n Komplement=E4rin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynha= usen --DBF1W8S4vdnL8lF9uOrtGKNJqlgfbXBci-- --6vO7XPX410tGIdeaDd8vHPHiFWq9KBsQt Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJYPa3hAAoJEMby9TMDAbQRHMYQAIhOHRbFGf/Tw5NYwL97/IQ7 KRklKLCiJWdYa8YF4EzzKkAZyk7UgaoP8RzRS75aZzDi3lPnxVSuKcO6I6RolKtF YuULn6o9swPypmtop5ifq67xgClK/t0P3u4tB6gt6Hz1FWRreNtVE/0H50eYusqs vYZUeUOJmOkpAH5EWcNFkj8n/r3/cIswlQm/TNEVN8gDXiwNVSQ9nEdlFFdUkFNA NUNEpAvg4bm1ip6iyp0UyH1xQnqICJEbm3Y+OShUMO+pw7bzpy7b36Nlzt016Tuz leoKyyDhx4e1Yt/rXt0WLqdspkWPS6QNeoaCWbQY56AfpAgYO7zvTLmtOn3wGrSF IjPeR+oE3WYb7ek0d53Gqcjo/aDTRyIJR5ZKW7+EbM1Ue9UuXLHC1uM6L/hCIWYU JtAbVkqF0t9NDuz3Xl/cQ+x7jKv/DeLi1KdYcxRlb7lRjX+0hbopqTci94hIEVf1 lDjMh8hyGS1Kf4ApMffI375YZwEacY3EOz+ITQEbbi4jzUIwy+k3fpYFsS3fZvTs ZgnTCd+c3vwIzkGAJ8yJdQ4vrVCxvYttWI/ZGLQBSthE3X0rMlzaEHUyL8SPkn/5 Cb6nSZH5PE7yfCMm/e1dwRoxgyx/7zAY4ZHgMzQWaQ1ttmnsW+H6n7/a/4C4Cmpa CPk871vfcGE5G3kSzRuL =9EJ1 -----END PGP SIGNATURE----- --6vO7XPX410tGIdeaDd8vHPHiFWq9KBsQt--
On Tue, Nov 29, 2016 at 6:33 PM, Sven Kieske <s.kieske@mittwald.de> wrote:
On 29/11/16 15:54, Martin Sivak wrote:
I actually checked the oVirt 4.0.0 and 4.0.5 release notes and I do not see anything mentioning ovirt-cli or REST v3 deprecation. This will (removal of RESTv3 support) affect the optimizer and quite possibly even hosted engine setup.
Hi,
this seems to indicate that even core ovirt devs do not know about every feature which gets deprecated.
Maybe this could be solved by sandro's suggestion to at least create an BZ for each deprecation.
Makes sense, even as a Tracker BZ, because there's the work to remove the code, and it might be in several components, as well as Documentation. Y.
I would agree with that, but also like to propose an alternative way, because at the stage of bug creation the deprecation is already set in stone and can't be discussed further (I fear).
So my proposal would be to mail to the devel list at least the proposal: "I/we want to get rid of feature/implementation X, use Z instead".
This would give developers and users enough time to engage with the community, replacing dependencies or start a discussion if removal can't be done later.
A clear deprecation guideline would also be helpful, I guess.
Something like: Features will get marked as deprecated in release X.Y and removed in X.Y+2 (or whatever number you might chose).
This would allow for much better preparation in the community and lead to less unpleasant surprises.
HTH & keep up the good work!
-- Mit freundlichen Grüßen / Regards
Sven Kieske
Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +495772 293100 F: +495772 293333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
participants (4)
-
Martin Sivak -
Sandro Bonazzola -
Sven Kieske -
Yaniv Kaul