On Fri, Feb 20, 2015 at 04:52:20PM +0000, Peter Robinson wrote: > >> >> > Sorry for the inconvenience and feel free to add bugs to the tracker, which are > >> >> > caused by systemd changes and have to be fixed in other components. > >> >> > >> >> Are you going to start notifying deve@ of upcoming changes that may > >> >> impact other areas of the distro too rather than just land them > >> >> without notification or discussion? > >> > > >> > Oh god, stop this, will you? > >> > >> No, I mean the above in general for general changes you make that > >> affect the distro as a whole. You generally land them without > >> notification. > > > > I "generally" do that? Can you be more precise? > > > >> > The folks in question knew I would drop the patch. In the original bug > >> > I even said I would remove the work-around from systemd.rpm after TC1 > >> > of the last cycle. I was nice, left it in for the whole cycle, only > >> > dropped it now. > >> > >> Yes, and it looks like it affects dhcpd too... just because you > >> notified one dev team on a single bug it's not the same as a wider > >> announcement to the wider community. There's all sorts of things that > >> this can affect, and while yes it may be a bug in their software, it > >> should be as widely notified as possible. People have priorities that > >> may not be the same as yours. > > > > Hey! Come on. Everything that systemd does is create a symlink for > > /etc/resolv.conf if nothing else has created on for that. If something > > else created and owned that file, it leaves the thing alone. That's > > all. It's very defensively written. Anaconda's file copy routine > > tripped up on it though, since it follows symlinks on the destination > > (which is a really bad idea, and needs to be fixed). > > > >> > There is no news in all of this, I just removed the work-around now, as > >> > indicated back then. > >> > >> Again, I'm not just referring to this single incident, it would be > >> nice if you notified people widely of changes. It's a community, > >> people don't all follow closely the upstream development of all > >> upstream components. > > > > Ok, then please list all those numerous incidents please. > > > >> > How many months would you like me to notify people in advance of a > >> > simple change like this? Isn't 6 month *ample* time? > >> > >> Likely not, not everyone has the same schedule as upstream systemd, in > >> a lot of cases they don't know it's broken until things land and teams > >> have other priorities. > > > > OK, got it, will let everybody know now of changes 5 years in > > advance. Would that suit your needs? > > Not what I'm saying at all. There's no need to throw toys to the > extreme just because someone is asking for a certain level of reason > and engagement. > > > Anyway, I have the suspicion you just want to make a fuss, and this is > > where it ends for me hence. > > Nope, I don't, I just want engagement, generally and overall I'm > actively positive for systemd and a big advocate for it. You just need > to engage in the community and if something isn't done in six months > because another team has other priorities and other deadlines and > people push back because it's actually breaking other areas of the > distribution there's no need to throw toys from the pram and storm > off. It's a large distro of moving parts and we need flexibility as a > result, things get pushed due to delays. It's not the end of the > world! I think we can do better than this level of communication. Yes, it would have been good to avoid a surprise here. There are issues on both sides. Blaming the situation on either impatience or sloth doesn't do any justice to the good efforts everyone makes. On one side, it may not be reasonable to expect that all teams track or follow up on every bug. It's right to expect some explicit notice and, more importantly, collaboration across teams -- talking to each other, not just filing a bug without clear expectations. On the other hand, Fedora is supposed to be innovative and we need to take a positive approach to change. When teams see a change coming up they know will cause them work or breakage, they can proactively reach out to engage. In fact, anyone can facilitate such a conversation. Also, a side note: A book I read on communication in relationships once (I think it was "That's Not What I Meant" by Deborah Tannen) said that when one universalizes statements, e.g. "you usually do <X>" or "you always do <Y>," it's unlikely to yield any positive results in a discussion. I've seen nothing in open source communication that gives evidence to the contrary. :-) The important thing is that we try to deal constructively with this specific situation, and in learning from it, we can mitigate similar situations in the future. -- Paul W. Frields <pfrields@xxxxxxxxxx> Manager, Fedora Engineering - Emerging Platform http://redhat.com -- http://opensource.com -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
