Re: On cooperative work [Was: Re: newbus' ivar's limitation..]
On 08/02/2012 12:18, David Chisnall wrote: > Thank you for your thoughtful reply, You too ... I let some time go by to see what others had to say. I think it's disappointing that more people aren't concerned about this issue. > On 2 Aug 2012, at 19:33, Doug Barton wrote: > >> However, my point is that in spite of the fact that it's >> non-trivial, the mindset on this topic needs to change if the dev >> summits are going to continue to be significant focii of both work >> being done and decisions being made (which of course, they are). > > I believe that, before that decision can be made, there needs to be > some consensus on what the purpose of the DevSummits is. In my view, > DevSummits do not exist to set project policy. And yet, that's exactly what happens. It's easy to understand why ... you have a bunch of people together in the same place, they all agree on a topic, and after all, since they are the ones who are there, they should be the ones to make the decision, right? It's not necessarily that they are trying to do something malicious, it's just human nature. I know, I used to travel to conferences for a living. > They are places where: > > - People can talk face to face about their current and planned > projects. - Developers can meet on a social basis, making remote > working easier. > > The latter is very important - I've found in other projects that it's > far easier to work with someone on the other side of the world when > you've chatted with them over a few beverages-of-choice. I agree with these points as well. (Again, been there, done that.) In fact I'm quite confident that a lot of the "issues" people have with me are related to this deficiency. :) > Any official conversations happen on the mailing lists. This should be true, but it isn't. This is my point. > DevSummits > are for people working on similar things to meet and discuss their > plans, and for people to have a chance to get to know what everyone > else is doing, ... so far, so good .. > for a limited set of 'everyone else'. ... and this is where I call shenanigans. This is an open project. Anything that is going to be done is going to be seen. If there are problems with a proposal it's better to see them early. If it's a good proposal, there is no reason not to share it. > Slides and > summaries so on from the more structured parts of this are available > afterwards, which helps people who can't attend get the same benefit > - they know what other people are working on. In the IETF context proposals often benefit from the real-time focus of attention, from both local and remote participants, that the meetings provide. There is no reason to believe that this would not be true in FreeBSD as well. > The original complaint that spawned this long discussion was that > decisions about the project are made behind closed doors. This is > obviously true in the literal sense, as code always wins over chatter > in an open source project, and the person willing to sit down and > write the code gets the final say on how it should work, That's an oft-repeated maxim, especially around here. But we've already demonstrated that it isn't true. The only time that this is true is if the work being done is in line with what the PTB want. I've demonstrated this time after time by volunteering to do various projects "my way" and being told that my efforts weren't welcome. Not to mention having my finished, working code reverted by a core team member for an inferior, broken result. So can we please stop repeating that BS and focus on the real issues? > although > ideally with code review, design feedback and so on from others. > Even if we broadcast everything that happens in the official parts of > the DevSummits, that won't necessarily fix anything because a lot of > the most productive conversations happen over dinner or in the pub. The community needs to not be accepting of the status quo, and demand that things be publicized on the lists first before decisions are made. Once again, if they are good decisions, they won't be harmed by sharing them in advance. If they are less-good, we could be saving someone efforts that would be otherwise wasted. > If there is a real problem to address, then it is people making > policy decisions at DevSummits, without adequate consultation. I > have not observed this happening, but I would regard it as no > different to people making policy decisions via private email, and > something that should be subject to the same response: revisit the > decisions in public if there are legitimate concerns raised about it, > subject to the usual open source rule that the person actually > willing to do the work gets to make the final call. Exactly. > Finance is not the only obstacle. In some venues, bandwidth is a > problem (not at Cambridge hopefully - people will have stopped using > it all to stream the olympics by then), but in other venues we only > have WiFi, which is shared with a ro
Re: On cooperative work [Was: Re: newbus' ivar's limitation..]
> I suggest the starting point is a webpage with a link to the slides > being presented and a simple audio stream. two way, please. i am amazed that ietf had two-way back when it was the mbone. with multicast actually deployed, now it is one-way. randy ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: On cooperative work [Was: Re: newbus' ivar's limitation..]
On Thu, Aug 2, 2012 at 5:14 PM, Kevin Oberman wrote: > On Thu, Aug 2, 2012 at 5:37 PM, Julian Elischer wrote: >> On 8/2/12 9:53 AM, Doug Barton wrote: >>> >>> On 08/02/2012 09:44, Garrett Cooper wrote: The "Watson/Losh connection" worked really well in BSDCan 2010 :). >>> >>> I wasn't going to mention that, since I didn't want to tell tales out of >>> school. But the fact that remote participation actually was provided for >>> "the right people," even though I was told repeatedly that it wasn't >>> possible, actually highlights a big part of the problem. >> >> bandwidth was limited and a single 1:1 skype connection was all we really >> could do. >> >> I did broadcast sessions a few years ago using the apple quicktime server >> but it was a lot of work and I think one person looked at part of one >> session. >> >>> Doug > > First, too many of these posts assume way too much. I don't think > anyone should be thinking of any sort of what is commonly called > "teleconferencing". That would be nice, but is far more complex and > expensive, both in bandwidth and equipment, then should be considered > as a starting point. > > I suggest the starting point is a webpage with a link to the slides > being presented and a simple audio stream. This is trivially possible > with a FreeBSD system and open-source software. A bandwidth of only > about 70kbps would be needed. Less with reasonable codec choice. > Several streams could be broadcast via a single, unicast stream to a > well connected server which woild then stream to end users It might be > augmented with jabber other open IM technology with someone at the > meeting if procedures for this could be agreed to. (Some vetting is > desirable, but will result in calls of censorship.) > > For small rooms, microphones are fairly easy to handle and one-way > streams don't require echo cancellation. > As costs for video come down, that might be something to think about > some day, but is not required to allow remote "attendance". > > Of course, unless this is publicized, no one will come (which > eliminates any technical issues). :-) Nail -> head. Everything that Kevin just said. With so much collective technical experience and intelligence available, we can work out the minor kinks in a solved problem (one-to-many audio and slide sharing). Getting the word out is also a solved problem. Both are very high-leverage -- and very good for the project. If we think about live BSDCan streaming as a fun project with classic hack value, instead of "an amorphous cloud of undoability", things will just come together naturally. The next action I see is calling for boots-on-the-ground volunteers to coordinate the local setup, and maybe a wiki page to capture the state of the project. Royce ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: On cooperative work [Was: Re: newbus' ivar's limitation..]
On Thu, Aug 2, 2012 at 5:37 PM, Julian Elischer wrote: > On 8/2/12 9:53 AM, Doug Barton wrote: >> >> On 08/02/2012 09:44, Garrett Cooper wrote: >>> >>> The "Watson/Losh connection" worked really well in BSDCan 2010 :). >> >> I wasn't going to mention that, since I didn't want to tell tales out of >> school. But the fact that remote participation actually was provided for >> "the right people," even though I was told repeatedly that it wasn't >> possible, actually highlights a big part of the problem. > > bandwidth was limited and a single 1:1 skype connection was all we really > could do. > > I did broadcast sessions a few years ago using the apple quicktime server > but it was a lot of work and I think one person looked at part of one > session. > >> Doug First, too many of these posts assume way too much. I don't think anyone should be thinking of any sort of what is commonly called "teleconferencing". That would be nice, but is far more complex and expensive, both in bandwidth and equipment, then should be considered as a starting point. I suggest the starting point is a webpage with a link to the slides being presented and a simple audio stream. This is trivially possible with a FreeBSD system and open-source software. A bandwidth of only about 70kbps would be needed. Less with reasonable codec choice. Several streams could be broadcast via a single, unicast stream to a well connected server which woild then stream to end users It might be augmented with jabber other open IM technology with someone at the meeting if procedures for this could be agreed to. (Some vetting is desirable, but will result in calls of censorship.) For small rooms, microphones are fairly easy to handle and one-way streams don't require echo cancellation. As costs for video come down, that might be something to think about some day, but is not required to allow remote "attendance". Of course, unless this is publicized, no one will come (which eliminates any technical issues). :-) -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: On cooperative work [Was: Re: newbus' ivar's limitation..]
On 8/2/12 9:53 AM, Doug Barton wrote: On 08/02/2012 09:44, Garrett Cooper wrote: The "Watson/Losh connection" worked really well in BSDCan 2010 :). I wasn't going to mention that, since I didn't want to tell tales out of school. But the fact that remote participation actually was provided for "the right people," even though I was told repeatedly that it wasn't possible, actually highlights a big part of the problem. bandwidth was limited and a single 1:1 skype connection was all we really could do. I did broadcast sessions a few years ago using the apple quicktime server but it was a lot of work and I think one person looked at part of one session. Doug ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: On cooperative work [Was: Re: newbus' ivar's limitation..]
Thank you for your thoughtful reply, On 2 Aug 2012, at 19:33, Doug Barton wrote: > However, my point is that in spite of the fact that it's non-trivial, > the mindset on this topic needs to change if the dev summits are going > to continue to be significant focii of both work being done and > decisions being made (which of course, they are). I believe that, before that decision can be made, there needs to be some consensus on what the purpose of the DevSummits is. In my view, DevSummits do not exist to set project policy. They are places where: - People can talk face to face about their current and planned projects. - Developers can meet on a social basis, making remote working easier. The latter is very important - I've found in other projects that it's far easier to work with someone on the other side of the world when you've chatted with them over a few beverages-of-choice. Any official conversations happen on the mailing lists. DevSummits are for people working on similar things to meet and discuss their plans, and for people to have a chance to get to know what everyone else is doing, for a limited set of 'everyone else'. Slides and summaries so on from the more structured parts of this are available afterwards, which helps people who can't attend get the same benefit - they know what other people are working on. The original complaint that spawned this long discussion was that decisions about the project are made behind closed doors. This is obviously true in the literal sense, as code always wins over chatter in an open source project, and the person willing to sit down and write the code gets the final say on how it should work, although ideally with code review, design feedback and so on from others. Even if we broadcast everything that happens in the official parts of the DevSummits, that won't necessarily fix anything because a lot of the most productive conversations happen over dinner or in the pub. If there is a real problem to address, then it is people making policy decisions at DevSummits, without adequate consultation. I have not observed this happening, but I would regard it as no different to people making policy decisions via private email, and something that should be subject to the same response: revisit the decisions in public if there are legitimate concerns raised about it, subject to the usual open source rule that the person actually willing to do the work gets to make the final call. > What I'm *not* doing is demanding that any one person, or even any one > group take responsibility for solving the whole problem on their own. > Unfortunately, due to my inability to actually attend these meetings, I > won't be able to provide the kind of hands-on assistance that I'd like > to be able to. However it sounds like there may be financial resources > available through the foundation, which would go a long way towards > making a solution possible. Finance is not the only obstacle. In some venues, bandwidth is a problem (not at Cambridge hopefully - people will have stopped using it all to stream the olympics by then), but in other venues we only have WiFi, which is shared with a room full of developers. If we buy some equipment (decent microphones are not always available - we were unable to find one at FOSDEM for remote attendees, for example), then it would need to be transported between events, and someone would need to be responsible for looking after it and ensuring that it is set up correctly at each event. > The next step would be for people to agree that this is a problem that > *needs* to be solved, followed by willingness on the part of dev summit > organizers to support these efforts, which will hopefully lead to people > who are willing and interested to step up and actually provide > solutions. It's already been true in the past that various companies > have volunteered to do this. There is no reason to believe that it > wouldn't happen again if organizers are willing to be supportive. There are two proposals: Remote viewing and remote participation. Remote viewing, being non-interactive, does not have to be done via streaming, it can be done by recording the event and making it available online. Even this is not trivial: we've done it for the GNUstep devroom at FOSDEM most years, and it typically takes a long time to get the videos edited and uploaded. ARM sent a professional team to do it at EuroLLVM, and yet they didn't have enough equipment to cover everything (my tutorial, for example, was not recorded). I would say that this is something that is very useful for presentation-style events, but DevSummits are typically more round-table discussions and hacking sessions than presentations. Remote participation is bidirectional, and I am a lot more wary about that. The productivity of a meeting is usually inversely proportional to the number of attendees, and allowing a lot more people in does not ne
Re: On cooperative work [Was: Re: newbus' ivar's limitation..]
On 08/02/2012 11:12, David Chisnall wrote: > FreeBSD is a volunteer project. Yeah, I get that. I've been around quite a bit longer than you have, in case you didn't notice. :) I understand what you're saying, it's going to take work to change this mindset, and to provide these resources. If you read my posts on a factual basis, I'm not suggesting that the dev summits provide remote participation at the same level as groups like the IETF or ICANN do, and your point (and Warner's) that these groups have significant financial backing is well taken. However, my point is that in spite of the fact that it's non-trivial, the mindset on this topic needs to change if the dev summits are going to continue to be significant focii of both work being done and decisions being made (which of course, they are). What I'm *not* doing is demanding that any one person, or even any one group take responsibility for solving the whole problem on their own. Unfortunately, due to my inability to actually attend these meetings, I won't be able to provide the kind of hands-on assistance that I'd like to be able to. However it sounds like there may be financial resources available through the foundation, which would go a long way towards making a solution possible. The next step would be for people to agree that this is a problem that *needs* to be solved, followed by willingness on the part of dev summit organizers to support these efforts, which will hopefully lead to people who are willing and interested to step up and actually provide solutions. It's already been true in the past that various companies have volunteered to do this. There is no reason to believe that it wouldn't happen again if organizers are willing to be supportive. What I'm hearing so far is defensiveness, and an attempt to focus the discussion on me. Neither is helpful. :) Acknowledging that this is a problem that needs to be solved does not imply that by not solving it you personally have failed in some way. I apologize if anything I've written so far has implied otherwise. Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: On cooperative work [Was: Re: newbus' ivar's limitation..]
On 2 Aug 2012, at 18:47, Doug Barton wrote: > Cheap copout. And quite sad, especially coming from a newly elected core > team member. FreeBSD is a volunteer project. Our DevSummits are not run by a commercial organisation, they are run by volunteers. I am not being paid to organise the Cambridge DevSummit, I am doing it in my spare time, as are the other people here. The resources available are those that I can beg or borrow from the university and from other developers. The attendance fee is £50, which is just about enough to cover the costs (we hope). Comparing this to a professionally organised event like an IETF meeting, with large commercial sponsors (the IETF event you cite is hosted by Google), and complaining that it comes up short is insulting. Saying 'solutions exist, therefore you must have the time, expertise, and resources to deploy them' is insulting. It is not constructive. If you are willing to make a helpful contribution, then it is welcome. If you are going to complain, yet not offer anything constructive, then you are just trolling and I am wasting my time by reading your emails, let alone replying. We have arranged to borrow a decent microphone and camera from the video conferencing suite in the department and have planned to use Skype to allow remote participation in two sessions. If you wish to propose a more scalable solution that can be easily deployed here by people with no prior experience setting up such a system, then please do so. If you feel that you can do a better job organising a DevSummit than the people who have donated their free time to organise the ones in the past and the ones planned in the next few months, then I am certain that they would be very happy for you to assist in the organisation. If your attitude is 'well, I'm not going to do anything, but it must be easy because no effort from me is involved so you should do it' then I find your attitude personally insulting and unproductive. David ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: On cooperative work [Was: Re: newbus' ivar's limitation..]
On 08/02/2012 05:39, John Baldwin wrote: > I find this a bit ironic from you given that I've met you in person at > USENIX ATC which is an order of magnitude more expensive than BSDCan (and > in fact, one of the reasons the US-based BSDCon died and was effectively > supplanted by BSDCan was that BSDCan is far cheaper). Yep, back in 2004 when traveling to conferences was part of my job, and before my daughter was born. My life now is quite different. ... not to mention that this thread isn't about me. It's about the importance of remote participation to the FreeBSD community as a whole. Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: On cooperative work [Was: Re: newbus' ivar's limitation..]
On 08/02/2012 10:40, Warner Losh wrote: > One thing to remember about the IETF. There's many vendors that devote > significant resources to the IETF. While I was at Cisco, for example, I know > that we provided audio and video bridges to IEFT meetings to facilitate > remote attendance at the meetings. Cisco dedicated several engineers to > ensure that the audio and video quality remained good during the meetings and > were able to use facilities cisco normally used for things like WebEx and > MeetingPlace. With a global presence and infrastructure, they were able to > pull it off. I'm not aware of similar resources within the project. I'm not suggesting we need anything at the full WebEx audio/video/presentation/chat level. And apparently the Foundation has money to spend on dev summits. As I suggested in a previous message, this would be a good long-term investment that would benefit a lot of people, especially in comparison to the money set aside for travel grants which is now going begging. Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: On cooperative work [Was: Re: newbus' ivar's limitation..]
On 08/02/2012 10:37, David Chisnall wrote: > > Thank you for volunteering to organise this. It's good to see people with > both the motivation and experience required to do something well actively > contributing to the project. Cheap copout. And quite sad, especially coming from a newly elected core team member. Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: On cooperative work [Was: Re: newbus' ivar's limitation..]
On Thursday, August 02, 2012 12:30:16 am Doug Barton wrote: > On 8/1/2012 8:36 PM, Warner Losh wrote: > > I think this proves the point everybody has been saying: you are being needlessly contrary and confrontational. > > Actually if you take a step back and look at what Arnaud is saying > objectively, he's right. If anyone can attend the meeting by simply > getting an invitation from a committer, the only purpose the invitation > serves is to force the mere-mortal user to kiss someone's ring. That's > precisely the kind of elitist crap that I've been railing against for so > many years now. > > OTOH, currently the dev summits generally take place with limited > resources, so it's not really possible to have "everyone" attend. And > (TMK) the "invitation" process is really more like a restaurant with a > sign that says "we reserve the right to refuse service to anyone." The latter bits here are mostly true. The biggest constraint is space. Also, I don't know of anyone that has asked to attend the developer summit as a guest that wasn't invited. > But on the _other_ other hand, the problem of things being discussed > and/or decisions being taken exclusively at the dev summits, especially > BSDCAN, has gotten quite bad over the last several years. Even amongst > committers, the community has become divided between the "haves" who can > travel to the summit, and the "have nots" who can't. Note, I'm quite > sure that this statement will be met with howls of protest, from the > "haves," that this isn't the case. Even if they were sincere, it's > incredibly easy for the people with the privileges to see their > privileged state as "normal," and lose sight of how the world looks from > the cheap seats. I find this a bit ironic from you given that I've met you in person at USENIX ATC which is an order of magnitude more expensive than BSDCan (and in fact, one of the reasons the US-based BSDCon died and was effectively supplanted by BSDCan was that BSDCan is far cheaper). > I used to ask the PTB to provide *some* form of remote participation for > even a fraction of the events at the dev summit. I don't bother asking > anymore because year after year my requests were met with any of: > indifference, hostility, shrugged shoulders (that's a hard problem that > we can't solve), or embarrassment. Since if the right people around here > want something to happen, it happens; I finally came to the conclusion > that they didn't want remote participation to happen, so it won't. > That's a shame. To be honest, the preocuppations to date have been a bit more basic than that (figuring out a workable format, lots of effort on simple logistics like food and rooms). Also, in previous years we have often had breakout rooms in random conference rooms in what would be the equivalent of a dorm meeting area with no A/V equipment, etc. The last two years have cut down to fewer meetings in more reasonable rooms. The connectivity is now generally reliable as well. All that to say that now that some basic things are settled, we can probably make some forward progress on this. A first step might be to start recording the summit sessions (BSDCan already has a partner that does this). Live streaming I'm less sure of, mostly because I am completely ignorant of what is available. I do know that having a bunch of people skype in would not be feasible (not enough bandwidth to send video out in multiple streams). The video would need to go out in a single stream to a distributor of some sort. And, quite frankly, despite Doug's "haves" vs "have-nots" implications, we can't afford an expensive commercial solution (e.g. Cisco) AFAIK. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: On cooperative work [Was: Re: newbus' ivar's limitation..]
On Thu, Aug 02, 2012 at 09:46:42AM -0700, Doug Barton wrote: > > but there is > > certainly no active attempt to exclude people who can't attend. > > ... and here is where I need to push back. "No active attempt to exclude > people" is not the same thing as actively encouraging remote > participation. It's the latter that we're after. s/encouraging remote/encouraging constructive remote/ The last thing we need is more people trying to get things done their way because they know best. People need to be willing to accept that maybe some widget they want won't be part of the goal of the project under discussion, for whatever reason. I've seen too many ... heated debates start up largely because people were not discussing things face to face. I'm not saying that all of the debates wouldn't happen if people were all in the same room, but a lot of them wouldn't. Larger/longer term projects should probably have their own mailing list set up for discussion. Regards, Gary ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: On cooperative work [Was: Re: newbus' ivar's limitation..]
On Wed, Aug 1, 2012 at 7:05 PM, Arnaud Lacombe wrote: > Hi, > > On Wed, Aug 1, 2012 at 12:40 PM, Attilio Rao wrote: >> On Wed, Aug 1, 2012 at 5:32 PM, Arnaud Lacombe wrote: >>> Hi, >>> >>> On Tue, Jul 31, 2012 at 4:14 PM, Attilio Rao wrote: You don't want to work cooperatively. >>> Why is it that mbuf's refactoring consultation is being held in >>> internal, private, committers-and-invite-only-restricted meeting at >>> BSDCan ? >>> >>> Why is it that so much review and discussion on changes are held privately ? >> >> Arnaud, >> belive me, to date I don't recall a single major technical decision >> that has been settled exclusively in private (not subjected to peer >> review) and in particular in person (e-mail help you focus on a lot of >> different details that you may not have under control when talking to >> people, etc). >> > Whose call is it to declare something worth public discussion ? No one. > > Every time I see a "Suggested by:", "Submitted by:", "Reported by:", > and especially "Approved by:", there should to be a public reference > of the mentioned communication. > >> Sometimes it is useful that a limited number of developers is involved >> in initial brainstorming of some works, >> > Never. > >> but after this period >> constructive people usually ask for peer review publishing their plans >> on the mailing lists or other media. >> > Again, never. By doing so, you merely put the community in a situation > where, well, "We, committers, have come with this, you can either > accept or STFU, but no major changes will be made because we decided > so." > > The callout-ng conference at BSDCan was just beautiful, it was basically: > > Speaker: "we will do this" > Audience: "how about this situation ? What you will do will not work." > Speaker: "thank you for listening, end of the conference" > > It was beautiful to witness. > Well, my talk was mainly there to collect some opinion on how to continue my work. IIRC, the only one objection was on supporting callout execution from hw interrupt context. Mainly, the objection moved was that there were no practical applications for that. It turned out I found some, and in any case it wasn't "it will not work" but "probably it's not an effort you want to put because the consumers that can exploit some functionality are few". I wasn't really so familiar with that so I hesitated in answering. In any case, I liked a lot the objection moved by Attilio because it gave me the possibility to investigate and find out the right direction. As you may see, there's a branch in projects/ in which the feature that "won't work" is implemented, so, maybe you're missing something. If you had some concerns on it you can raise up your hand and tell: "hey, that sucks". It would be better than getting this feedback after 3 months of work honestly. I have nothing in contrary about getting feedbacks (negative or positive). But probably you belong to that kind of people that are able to tell only behind a monitor, so this is my last word on the topic. Get a life. >> If you don't see any public further discussion this may be meaning: >> a) the BSDCan meetings have been fruitless and there is no precise >> plan/roadmap/etc. >> > so not only you make it private, but it shamelessly failed... > >> b) there is still not consensus on details >> > Then the discussion should stop, public records are kept for reference > in the future. There is no problem with this. > >> and you can always publically asked on what was decided and what not. >> Just send a mail to interested recipients and CC any FreeBSD mailing >> list. >> > This is not the way "openness" should be about. > > - Arnaud > >> Attilio >> >> >> -- >> Peace can only be achieved by understanding - A. Einstein > ___ > freebsd-hack...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" Davide ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: On cooperative work [Was: Re: newbus' ivar's limitation..]
On Aug 2, 2012, at 10:46 AM, Doug Barton wrote: > Those all sound like nice steps forward, thank you for pointing them > out. Nothing would make me happier than to be proven wrong in this area. > What would be nice I think would be if these steps were formalized, and > shared more openly. Having things on the wiki is nice, but reporting > things in detail on the mailing lists puts it in the archives for future > reference, as well as making it more broadly available to start with. One thing to remember about the IETF. There's many vendors that devote significant resources to the IETF. While I was at Cisco, for example, I know that we provided audio and video bridges to IEFT meetings to facilitate remote attendance at the meetings. Cisco dedicated several engineers to ensure that the audio and video quality remained good during the meetings and were able to use facilities cisco normally used for things like WebEx and MeetingPlace. With a global presence and infrastructure, they were able to pull it off. I'm not aware of similar resources within the project. We don't have any such benefactor in the project, so we have to rely on the kindness of strangers. AsiaBSDcon live streams most of its talks, but uses a free service that changes from year to year and is quite good for talks, but can't do meetings at all. Other meeting things do meetings OK, but the video or audio quality sucks unless you have high end gear for the source. Mapping out what hardware, software and service combinations work would be very beneficial. I suspect this will vary based on geographic location (stuff that works good in the US won't work in EU or Asia and vice versa). These issues are what makes it hit or miss. While it is easy to skype one or two people into a meeting, that scales poorly to more than two. Plus if things are going poorly, the attempt to broadcast the meeting can derail or eat into the time available significantly. I guess this is a long way to say that while one to one, and one to many problems have relatively easy solutions, many to many like we need still remains fussy and difficult. Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: On cooperative work [Was: Re: newbus' ivar's limitation..]
On 2 Aug 2012, at 18:28, Doug Barton wrote: > Welcome to the 21st Century. :) There are widely available audio and > video conferencing solutions that easily scale into the thousands of > users, at minimal cost. > > Yes, "It takes effort." I get that. I've been part of the effort to > provide remote participation for other groups, on a much larger scale > than anything FreeBSD can dream of. > > My point, and I cannot emphasize this highly enough, is that your entire > mindset about this is all wrong. It needs to shift from "We'll do this > on a small scale, for those who ask" to "We'll make providing robust > remote participation a top priority, built into the planning from day > 1." It's as simple as that. Thank you for volunteering to organise this. It's good to see people with both the motivation and experience required to do something well actively contributing to the project. David___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: On cooperative work [Was: Re: newbus' ivar's limitation..]
On 08/02/2012 10:34, Doug Barton wrote: > BTW, for those who'd like to get a flavor of what the IETF model looks > like, the Vancouver meeting is in process now: > > https://datatracker.ietf.org/meeting/84/agenda.html > > Feel free to join in as a lurker. Sorry, this agenda makes it easier to see the remote participation stuff: https://tools.ietf.org/agenda/84/ -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: On cooperative work [Was: Re: newbus' ivar's limitation..]
BTW, for those who'd like to get a flavor of what the IETF model looks like, the Vancouver meeting is in process now: https://datatracker.ietf.org/meeting/84/agenda.html Feel free to join in as a lurker. -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: On cooperative work [Was: Re: newbus' ivar's limitation..]
On 08/02/2012 10:13, David Chisnall wrote: > On 2 Aug 2012, at 17:46, Doug Barton wrote: > >> Well that's a start. :) And where was this availability announced? >> If I missed it, that's on me. But providing remote access that you >> don't tell people about isn't really any better than not providing >> it at all. > > It's not widely advertised, because we're likely to be able to > support a limited number of remote participants (10 seems like the > upper limit for the technology that we're looking at, and I wouldn't > be surprised if it degrades before then). Welcome to the 21st Century. :) There are widely available audio and video conferencing solutions that easily scale into the thousands of users, at minimal cost. > As with all other things > in the project, we welcome people who are willing to make an effort > to engage. We provide it when people ask, not spontaneously, because > organising cameras and decent microphones requires effort on the bart > of the organisers. Yes, "It takes effort." I get that. I've been part of the effort to provide remote participation for other groups, on a much larger scale than anything FreeBSD can dream of. My point, and I cannot emphasize this highly enough, is that your entire mindset about this is all wrong. It needs to shift from "We'll do this on a small scale, for those who ask" to "We'll make providing robust remote participation a top priority, built into the planning from day 1." It's as simple as that. > The FreeBSD Foundation has also offered to fund new contributors who > want to attend but are unable to afford to do so on their own. In > spite of the fact that I spent some effort encouraging people to > apply for this, only one person actually did. It isn't just the financial cost of attending the summit. Often (as in my case) it's the lack of ability to take time away from personal, work, and/or family commitments. For others it may be the difficulty of doing the traveling at all. The fact that only 1 person took you up on this offer (and IIRC there have been similar results in the past) pretty clearly indicates that you're trying to solve the wrong problem. Given that the foundation has money to spend here, why not put 2 and 2 together and have the foundation invest in providing remote participation? That would benefit far more people, and almost certainly at less cost. Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: On cooperative work [Was: Re: newbus' ivar's limitation..]
On 2 Aug 2012, at 17:46, Doug Barton wrote: > Well that's a start. :) And where was this availability announced? If I > missed it, that's on me. But providing remote access that you don't tell > people about isn't really any better than not providing it at all. It's not widely advertised, because we're likely to be able to support a limited number of remote participants (10 seems like the upper limit for the technology that we're looking at, and I wouldn't be surprised if it degrades before then). As with all other things in the project, we welcome people who are willing to make an effort to engage. We provide it when people ask, not spontaneously, because organising cameras and decent microphones requires effort on the bart of the organisers. We only have one microphone available that will give good pickup over a whole room, for example, so we can't offer remote participation in parallel streams and we need to prioritise people who are willing to go to the massive effort of sending a one-line email saying 'I would like to make a contribution in this working group but am unable to attend'. The FreeBSD Foundation has also offered to fund new contributors who want to attend but are unable to afford to do so on their own. In spite of the fact that I spent some effort encouraging people to apply for this, only one person actually did. We make a considerable effort to ensure that DevSummits are easy to attend for anyone who wants to contribute to the projects. They are not intended as spectator events, but for anyone who wishes to engage with the community there are procedures in place for attending or participating remotely. I have very little sympathy with people who complain that the community isn't engaging with them, without making the effort to engage with the community. David ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: On cooperative work [Was: Re: newbus' ivar's limitation..]
On 08/02/2012 09:44, Garrett Cooper wrote: > > The "Watson/Losh connection" worked really well in BSDCan 2010 :). I wasn't going to mention that, since I didn't want to tell tales out of school. But the fact that remote participation actually was provided for "the right people," even though I was told repeatedly that it wasn't possible, actually highlights a big part of the problem. > Advertising the teleconferencing lines might be an issue (I would > have loved to have joined in some of the remote conferences, if for > nothing more than be a fly on the wall, this year), but that's a > separate thing aside. At various points when I was asking for remote participation at BSDCAN different people offered to provide this through their company's teleconferencing solutions, providing that the organizers could put a phone line in the room(s). They were told that it wasn't possible to do that. Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: On cooperative work [Was: Re: newbus' ivar's limitation..]
On 08/02/2012 05:54, David Chisnall wrote: > On 2 Aug 2012, at 05:30, Doug Barton wrote: > >> I used to ask the PTB to provide *some* form of remote >> participation for even a fraction of the events at the dev summit. >> I don't bother asking anymore because year after year my requests >> were met with any of: indifference, hostility, shrugged shoulders >> (that's a hard problem that we can't solve), or embarrassment. >> Since if the right people around here want something to happen, it >> happens; I finally came to the conclusion that they didn't want >> remote participation to happen, so it won't. That's a shame. > > You haven't asked for this for the Cambridge DevSummit, You did read the part where I gave up, right? > but others > have and so we have arranged for cameras and microphones to be > available for two of the sessions (the DocSummit and the ARM working > group) to allow those who can not attend in person for various > reasons to participate. Well that's a start. :) And where was this availability announced? If I missed it, that's on me. But providing remote access that you don't tell people about isn't really any better than not providing it at all. > I don't know how useful it will be (hopefully everything will work, > but my experience with video conferencing is that it stops working as > soon as you try to do something important with it), If I can offer some advice from the trenches ... focus on making the audio robust, and put efforts into the video as resources permit. The combination of solid audio, making presentations available on line, and a chat room (IRC, jabber, whatever) allows for a great deal of remote participation. Video is nice, but if the video going down takes the audio with it, you're no better off than when you started. > but there is > certainly no active attempt to exclude people who can't attend. ... and here is where I need to push back. "No active attempt to exclude people" is not the same thing as actively encouraging remote participation. It's the latter that we're after. > After each DevSummit, the results seem to appear on the wiki quite > promptly - often during the sessions. At BSDCan this year, two of > the working groups that I attended used OpenEtherPad to take minutes, > so they were available in real time for non-attendees and people > outside of the room were able to add things to them. There are > usually people in the room on IRC as well, who are willing to relay > things from people outside. Those all sound like nice steps forward, thank you for pointing them out. Nothing would make me happier than to be proven wrong in this area. What would be nice I think would be if these steps were formalized, and shared more openly. Having things on the wiki is nice, but reporting things in detail on the mailing lists puts it in the archives for future reference, as well as making it more broadly available to start with. Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: On cooperative work [Was: Re: newbus' ivar's limitation..]
On Aug 2, 2012, at 9:20 AM, Scott Long wrote: > > On Aug 2, 2012, at 12:23 AM, Kevin Oberman wrote: > >> Doug makes some good points. > > No, he doesn't. He and Arnould being argumentative and accusatory where none > of that is warranted. > > I used to run the devsummits, and we did tele-conference lines for remote > people to participate. After I stepped down, others took it up and did the > same thing. Usually, the lines were unused. I suspect that organizers > simply stopped thinking about them after a while because of poor interest. > There is no conspiracy of exclusion here, just simple human apathy. The "Watson/Losh connection" worked really well in BSDCan 2010 :). Advertising the teleconferencing lines might be an issue (I would have loved to have joined in some of the remote conferences, if for nothing more than be a fly on the wall, this year), but that's a separate thing aside. There's some misunderstanding, assumption, etc mixed together in this mailing chain that I think is probably better resolved with some face-to-face conversations or maybe just more rational (and less heated) discussion. Thanks! -Garrett___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: On cooperative work [Was: Re: newbus' ivar's limitation..]
On 08/02/2012 09:20, Scott Long wrote: > > On Aug 2, 2012, at 12:23 AM, Kevin Oberman > wrote: > >> Doug makes some good points. > > No, he doesn't. Yes I do! (So there) > He and Arnould being argumentative and accusatory > where none of that is warranted. > > I used to run the devsummits, and we did tele-conference lines for > remote people to participate. I singled out BSDCAN specifically since that's "where the action is" for the last several years. I do recall your efforts in this regard, but it so happened that I was able to attend most of them in person back then. No slight towards what you did was intended. > After I stepped down, others took it > up and did the same thing. Usually, the lines were unused. I > suspect that organizers simply stopped thinking about them after a > while because of poor interest. There is no conspiracy of exclusion > here, just simple human apathy. Here I have to disagree with you. Once again, speaking specifically about BSDCAN dev summits, I repeatedly asked the organizers to provide some sort of audio stream (phone, Internet, anything) and was repeatedly told it wasn't possible. This was not a case of lack of interest. This was a case of "We understand that it is something people want, but it isn't going to happen." > The invite system for the devsummit was, and still is, purely about > providing some order to the process. It ensures that people > attending are willing to demonstrate a minimum amount of interest, > more than just wondering by a room one day and dropping in for free > food and wifi. I specifically made allowances for this issue in my post. Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: On cooperative work [Was: Re: newbus' ivar's limitation..]
On Aug 2, 2012, at 12:23 AM, Kevin Oberman wrote: > Doug makes some good points. No, he doesn't. He and Arnould being argumentative and accusatory where none of that is warranted. I used to run the devsummits, and we did tele-conference lines for remote people to participate. After I stepped down, others took it up and did the same thing. Usually, the lines were unused. I suspect that organizers simply stopped thinking about them after a while because of poor interest. There is no conspiracy of exclusion here, just simple human apathy. The invite system for the devsummit was, and still is, purely about providing some order to the process. It ensures that people attending are willing to demonstrate a minimum amount of interest, more than just wondering by a room one day and dropping in for free food and wifi. If anyone feels that they are being excluded, it's because they are too lazy to go beyond being argumentative on a mailing list. Scott ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: On cooperative work [Was: Re: newbus' ivar's limitation..]
On 2 Aug 2012, at 05:30, Doug Barton wrote: > I used to ask the PTB to provide *some* form of remote participation for > even a fraction of the events at the dev summit. I don't bother asking > anymore because year after year my requests were met with any of: > indifference, hostility, shrugged shoulders (that's a hard problem that > we can't solve), or embarrassment. Since if the right people around here > want something to happen, it happens; I finally came to the conclusion > that they didn't want remote participation to happen, so it won't. > That's a shame. You haven't asked for this for the Cambridge DevSummit, but others have and so we have arranged for cameras and microphones to be available for two of the sessions (the DocSummit and the ARM working group) to allow those who can not attend in person for various reasons to participate. I don't know how useful it will be (hopefully everything will work, but my experience with video conferencing is that it stops working as soon as you try to do something important with it), but there is certainly no active attempt to exclude people who can't attend. After each DevSummit, the results seem to appear on the wiki quite promptly - often during the sessions. At BSDCan this year, two of the working groups that I attended used OpenEtherPad to take minutes, so they were available in real time for non-attendees and people outside of the room were able to add things to them. There are usually people in the room on IRC as well, who are willing to relay things from people outside. David___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: On cooperative work [Was: Re: newbus' ivar's limitation..]
Yep. In 18+ years of being subscribed to various freebsd lists, Arnaud has the honor of being only the 2nd person to earn a killfile entry. He's now sitting next to Jesus Monroy, Jr. it is not a proud from you to talk about who you are blocking. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: On cooperative work [Was: Re: newbus' ivar's limitation..]
On Wed, Aug 1, 2012 at 9:30 PM, Doug Barton wrote: > On 8/1/2012 8:36 PM, Warner Losh wrote: >> I think this proves the point everybody has been saying: you are being >> needlessly contrary and confrontational. > > Actually if you take a step back and look at what Arnaud is saying > objectively, he's right. If anyone can attend the meeting by simply > getting an invitation from a committer, the only purpose the invitation > serves is to force the mere-mortal user to kiss someone's ring. That's > precisely the kind of elitist crap that I've been railing against for so > many years now. > > OTOH, currently the dev summits generally take place with limited > resources, so it's not really possible to have "everyone" attend. And > (TMK) the "invitation" process is really more like a restaurant with a > sign that says "we reserve the right to refuse service to anyone." > > But on the _other_ other hand, the problem of things being discussed > and/or decisions being taken exclusively at the dev summits, especially > BSDCAN, has gotten quite bad over the last several years. Even amongst > committers, the community has become divided between the "haves" who can > travel to the summit, and the "have nots" who can't. Note, I'm quite > sure that this statement will be met with howls of protest, from the > "haves," that this isn't the case. Even if they were sincere, it's > incredibly easy for the people with the privileges to see their > privileged state as "normal," and lose sight of how the world looks from > the cheap seats. > > In spite of Kevin's concerns (and I don't know what working groups he's > been attending) the IETF model is really a good one to examine here. The > majority of the work gets done on the mailing lists, with working group > meetings serving as an opportunity for group discussion, presentations, > etc. The results of the meetings are then published to the mailing list > in the form of minutes, and the final decisions are made in public, on > the lists. Another incredibly important feature, the meetings are open > to remote participation in the sense that slide decks are published in > advance, the meeting audio is streamed live, and there are jabber rooms > for remote participants to interact with the people in the meeting. > > I used to ask the PTB to provide *some* form of remote participation for > even a fraction of the events at the dev summit. I don't bother asking > anymore because year after year my requests were met with any of: > indifference, hostility, shrugged shoulders (that's a hard problem that > we can't solve), or embarrassment. Since if the right people around here > want something to happen, it happens; I finally came to the conclusion > that they didn't want remote participation to happen, so it won't. > That's a shame. > > If the only large, open project you've ever participated in is FreeBSD, > what gets done around here feels "normal" to you. But don't be so quick > to dismiss the viewpoints of people who have experience in the wider world. > > Doug Doug makes some good points. The lack of any opportunity for remote participation in this day and age seems quite odd. Almost all conferences of more that half a dozen people are available remotely, at least for observers. Some are set up for full remote participation including presentations, questions (via chat) and voting/polling. It is surprising to me that something is not available for significant FreeBSD meetings. By the way, WGs that gave me major issues were SNMP and DNS. SNMP was dissolved and the DNS group finally accomplished its job about two years later than it should have by scheduling meetings, still open, outside of IETF meetings and thanks to the stubborn determination of Randy Bush. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: On cooperative work [Was: Re: newbus' ivar's limitation..]
On 8/1/2012 8:36 PM, Warner Losh wrote: > I think this proves the point everybody has been saying: you are being > needlessly contrary and confrontational. Actually if you take a step back and look at what Arnaud is saying objectively, he's right. If anyone can attend the meeting by simply getting an invitation from a committer, the only purpose the invitation serves is to force the mere-mortal user to kiss someone's ring. That's precisely the kind of elitist crap that I've been railing against for so many years now. OTOH, currently the dev summits generally take place with limited resources, so it's not really possible to have "everyone" attend. And (TMK) the "invitation" process is really more like a restaurant with a sign that says "we reserve the right to refuse service to anyone." But on the _other_ other hand, the problem of things being discussed and/or decisions being taken exclusively at the dev summits, especially BSDCAN, has gotten quite bad over the last several years. Even amongst committers, the community has become divided between the "haves" who can travel to the summit, and the "have nots" who can't. Note, I'm quite sure that this statement will be met with howls of protest, from the "haves," that this isn't the case. Even if they were sincere, it's incredibly easy for the people with the privileges to see their privileged state as "normal," and lose sight of how the world looks from the cheap seats. In spite of Kevin's concerns (and I don't know what working groups he's been attending) the IETF model is really a good one to examine here. The majority of the work gets done on the mailing lists, with working group meetings serving as an opportunity for group discussion, presentations, etc. The results of the meetings are then published to the mailing list in the form of minutes, and the final decisions are made in public, on the lists. Another incredibly important feature, the meetings are open to remote participation in the sense that slide decks are published in advance, the meeting audio is streamed live, and there are jabber rooms for remote participants to interact with the people in the meeting. I used to ask the PTB to provide *some* form of remote participation for even a fraction of the events at the dev summit. I don't bother asking anymore because year after year my requests were met with any of: indifference, hostility, shrugged shoulders (that's a hard problem that we can't solve), or embarrassment. Since if the right people around here want something to happen, it happens; I finally came to the conclusion that they didn't want remote participation to happen, so it won't. That's a shame. If the only large, open project you've ever participated in is FreeBSD, what gets done around here feels "normal" to you. But don't be so quick to dismiss the viewpoints of people who have experience in the wider world. Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: On cooperative work [Was: Re: newbus' ivar's limitation..]
On Wed, Aug 01, 2012 at 09:36:26PM -0600, Warner Losh wrote: > > I think this proves the point everybody has been saying: you > are being needlessly contrary and confrontational. > Yep. In 18+ years of being subscribed to various freebsd lists, Arnaud has the honor of being only the 2nd person to earn a killfile entry. He's now sitting next to Jesus Monroy, Jr. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: On cooperative work [Was: Re: newbus' ivar's limitation..]
On Aug 1, 2012, at 9:28 PM, Arnaud Lacombe wrote: > Hi, > > On Wed, Aug 1, 2012 at 7:28 PM, Warner Losh wrote: >> >> On Aug 1, 2012, at 3:39 PM, Arnaud Lacombe wrote: >> >>> Hi, >>> >>> On Wed, Aug 1, 2012 at 4:06 PM, Adrian Chadd wrote: Any interested party is very welcome to approach a developer and get added to the developer summits. Plenty of the people at the most recent developer summit weren't @freebsd.org committers - we had plenty of representation from companies using FreeBSD. If you want to participate, just ask a friendly developer who is going to the developer summit to sponsor you in going. You're pleasant in person, so I'd have no problem sponsoring you if I am going to an event. :) >>> I have a very deep, quasi-philosophical, trouble/problem with that >>> whole idea of sponsor-requirement to attend a such meeting. There is >>> just something which does not feel right about it. From my point of >>> view, this is a matter of common sense, focus is gonna be very narrow >>> and deeply technical. Attendee should go there only if they think they >>> will give positive feedback. As for myself, I would not attend a >>> developer meeting on the fiber-channel over infiniband optimization, >>> but would attend a developer meeting on next-generation mbuf. >>> >>> Now, maybe I'll just push the door of some developer meeting I'd be >>> interested in during next BSDCan, and see what happen :-) The outcome >>> might be interesting to study in a social interaction, prisoner >>> dilemma related, point-of-view. >> >> Given how ridiculously easy it is to get a proper invite, there's not need >> to be a jerk just to prove an obscure philosophical point about attendance. >> There's plenty of time to do that over the technical points being discussed. >> > Let me explain my thoughts: I do not recognize the committers > legitimacy to give such invite, and to some extend, I do not recognize > committers self-given legitimacy altogether. This do not mean I'd > praised a structure-less project; quite the opposite actually. > Starting from that, I will certainly not defer to anybody to request > such invite or commit bit. Feel free to kick me out of the meeting > room if you want to; I would have proved my point. I think this proves the point everybody has been saying: you are being needlessly contrary and confrontational. Warner > Now, if invites are so easy to get, just get rid of it. It's a > worthless, cumbersome item. > > - Arnaud > > ps: please, do not get me wrong, I would apply this policy to anybody > who propose to help. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: On cooperative work [Was: Re: newbus' ivar's limitation..]
Hi, On Wed, Aug 1, 2012 at 7:28 PM, Warner Losh wrote: > > On Aug 1, 2012, at 3:39 PM, Arnaud Lacombe wrote: > >> Hi, >> >> On Wed, Aug 1, 2012 at 4:06 PM, Adrian Chadd wrote: >>> Any interested party is very welcome to approach a developer and get >>> added to the developer summits. Plenty of the people at the most >>> recent developer summit weren't @freebsd.org committers - we had >>> plenty of representation from companies using FreeBSD. >>> >>> If you want to participate, just ask a friendly developer who is going >>> to the developer summit to sponsor you in going. You're pleasant in >>> person, so I'd have no problem sponsoring you if I am going to an >>> event. :) >>> >> I have a very deep, quasi-philosophical, trouble/problem with that >> whole idea of sponsor-requirement to attend a such meeting. There is >> just something which does not feel right about it. From my point of >> view, this is a matter of common sense, focus is gonna be very narrow >> and deeply technical. Attendee should go there only if they think they >> will give positive feedback. As for myself, I would not attend a >> developer meeting on the fiber-channel over infiniband optimization, >> but would attend a developer meeting on next-generation mbuf. >> >> Now, maybe I'll just push the door of some developer meeting I'd be >> interested in during next BSDCan, and see what happen :-) The outcome >> might be interesting to study in a social interaction, prisoner >> dilemma related, point-of-view. > > Given how ridiculously easy it is to get a proper invite, there's not need to > be a jerk just to prove an obscure philosophical point about attendance. > There's plenty of time to do that over the technical points being discussed. > Let me explain my thoughts: I do not recognize the committers legitimacy to give such invite, and to some extend, I do not recognize committers self-given legitimacy altogether. This do not mean I'd praised a structure-less project; quite the opposite actually. Starting from that, I will certainly not defer to anybody to request such invite or commit bit. Feel free to kick me out of the meeting room if you want to; I would have proved my point. Now, if invites are so easy to get, just get rid of it. It's a worthless, cumbersome item. - Arnaud ps: please, do not get me wrong, I would apply this policy to anybody who propose to help. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: On cooperative work [Was: Re: newbus' ivar's limitation..]
On Wed, Aug 1, 2012 at 2:39 PM, Arnaud Lacombe wrote: > Hi, > > On Wed, Aug 1, 2012 at 4:06 PM, Adrian Chadd wrote: >> Any interested party is very welcome to approach a developer and get >> added to the developer summits. Plenty of the people at the most >> recent developer summit weren't @freebsd.org committers - we had >> plenty of representation from companies using FreeBSD. >> >> If you want to participate, just ask a friendly developer who is going >> to the developer summit to sponsor you in going. You're pleasant in >> person, so I'd have no problem sponsoring you if I am going to an >> event. :) >> > I have a very deep, quasi-philosophical, trouble/problem with that > whole idea of sponsor-requirement to attend a such meeting. There is > just something which does not feel right about it. From my point of > view, this is a matter of common sense, focus is gonna be very narrow > and deeply technical. Attendee should go there only if they think they > will give positive feedback. As for myself, I would not attend a > developer meeting on the fiber-channel over infiniband optimization, > but would attend a developer meeting on next-generation mbuf. > > Now, maybe I'll just push the door of some developer meeting I'd be > interested in during next BSDCan, and see what happen :-) The outcome > might be interesting to study in a social interaction, prisoner > dilemma related, point-of-view. Arnaud, I suggest that you attend some Internet Engineering Task Force Working Group meetings. They are, by rule, open. There is no procedure for excluding anyone. While this may be open, it can be painfully wasteful of time as one person can tie up the entire meeting and ensure nothing is accomplished. It happens all too often and has resulted in working groups being shut down as they have no chance on reaching consensus. One person can't block consensus in theory. but he can tie up so much time that no actual work is done.This is one of the primary reasons I stopped attending IETF meetings as opposed to being active on WG mail lists where a lot of the real work is done and annoying messages can simply be ignored. For a much smaller endeavor, like FreeBSD, this is simply unacceptable as is a brainstorming type of meeting with too many people present. almost all really effective projects are done by one or two people and they need the input of a fairly small set of other concerned people to vet the work. This has worked well, if not perfectly, for FreeBSD and many other projects. It may not be perfect, but trying to accomplish something that comes under the heading of brainstorming in a truly open environment is a wonderful goal, but really is not efficient. And, no, I don't expect you to agree. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: On cooperative work [Was: Re: newbus' ivar's limitation..]
On Aug 1, 2012, at 3:39 PM, Arnaud Lacombe wrote: > Hi, > > On Wed, Aug 1, 2012 at 4:06 PM, Adrian Chadd wrote: >> Any interested party is very welcome to approach a developer and get >> added to the developer summits. Plenty of the people at the most >> recent developer summit weren't @freebsd.org committers - we had >> plenty of representation from companies using FreeBSD. >> >> If you want to participate, just ask a friendly developer who is going >> to the developer summit to sponsor you in going. You're pleasant in >> person, so I'd have no problem sponsoring you if I am going to an >> event. :) >> > I have a very deep, quasi-philosophical, trouble/problem with that > whole idea of sponsor-requirement to attend a such meeting. There is > just something which does not feel right about it. From my point of > view, this is a matter of common sense, focus is gonna be very narrow > and deeply technical. Attendee should go there only if they think they > will give positive feedback. As for myself, I would not attend a > developer meeting on the fiber-channel over infiniband optimization, > but would attend a developer meeting on next-generation mbuf. > > Now, maybe I'll just push the door of some developer meeting I'd be > interested in during next BSDCan, and see what happen :-) The outcome > might be interesting to study in a social interaction, prisoner > dilemma related, point-of-view. Given how ridiculously easy it is to get a proper invite, there's not need to be a jerk just to prove an obscure philosophical point about attendance. There's plenty of time to do that over the technical points being discussed. Warner > - Arnaud > >> And/or, work with warner to get improvements into the tree and someone >> will sponsor a commit bit for you. >> >> Perhaps we as developers should more openly publish the results of >> developer summits. But as I said, they're not "closed" - they're just >> "invite only for non-developers." We're not going to exclude anyone >> from coming unless they really ARE going to just sit there and troll. >> You're motivated, you're enthusiastic and you want to see things >> change for the better. You're also not confrontational in person. I >> have no problem with you coming along. >> >> >> Adrian > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: On cooperative work [Was: Re: newbus' ivar's limitation..]
On 8/1/12 12:45 PM, Arnaud Lacombe wrote: Hi, On Wed, Aug 1, 2012 at 2:18 PM, Attilio Rao wrote: As for the mbuf meeting, all I can find from it online is: http://lists.freebsd.org/pipermail/freebsd-arch/2012-June/012629.html actually nothing has happenned on this yet that I know of, which is why there has been no action to see. We all agree that it is an item to put on our agenda but until there is someone who gets the free time it's just a "sanctioned priority item" which is not worth much... Rather than doing things internally, maybe it is time to open up... oh, wait, you will certainly come to the community with a design plan, figure out it's not gonna work while doing the implementation, change the design plan while implementing, go public with a +3k/-2k loc change patch, ask for benediction, go ahead and commit it up until someone comes with an obvious design flaw which would render the change pretty much useless, but there will be man-month of work to fix it, so it's never gonna be done. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: On cooperative work [Was: Re: newbus' ivar's limitation..]
Hi, On Wed, Aug 1, 2012 at 4:06 PM, Adrian Chadd wrote: > Any interested party is very welcome to approach a developer and get > added to the developer summits. Plenty of the people at the most > recent developer summit weren't @freebsd.org committers - we had > plenty of representation from companies using FreeBSD. > > If you want to participate, just ask a friendly developer who is going > to the developer summit to sponsor you in going. You're pleasant in > person, so I'd have no problem sponsoring you if I am going to an > event. :) > I have a very deep, quasi-philosophical, trouble/problem with that whole idea of sponsor-requirement to attend a such meeting. There is just something which does not feel right about it. From my point of view, this is a matter of common sense, focus is gonna be very narrow and deeply technical. Attendee should go there only if they think they will give positive feedback. As for myself, I would not attend a developer meeting on the fiber-channel over infiniband optimization, but would attend a developer meeting on next-generation mbuf. Now, maybe I'll just push the door of some developer meeting I'd be interested in during next BSDCan, and see what happen :-) The outcome might be interesting to study in a social interaction, prisoner dilemma related, point-of-view. - Arnaud > And/or, work with warner to get improvements into the tree and someone > will sponsor a commit bit for you. > > Perhaps we as developers should more openly publish the results of > developer summits. But as I said, they're not "closed" - they're just > "invite only for non-developers." We're not going to exclude anyone > from coming unless they really ARE going to just sit there and troll. > You're motivated, you're enthusiastic and you want to see things > change for the better. You're also not confrontational in person. I > have no problem with you coming along. > > > Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: On cooperative work [Was: Re: newbus' ivar's limitation..]
On Wed, Aug 1, 2012 at 1:05 PM, Arnaud Lacombe wrote: > Hi, > > On Wed, Aug 1, 2012 at 12:40 PM, Attilio Rao wrote: > > On Wed, Aug 1, 2012 at 5:32 PM, Arnaud Lacombe > wrote: > >> Hi, > >> > >> On Tue, Jul 31, 2012 at 4:14 PM, Attilio Rao > wrote: > >>> > >>> You don't want to work cooperatively. > >>> > >> Why is it that mbuf's refactoring consultation is being held in > >> internal, private, committers-and-invite-only-restricted meeting at > >> BSDCan ? > >> > >> Why is it that so much review and discussion on changes are held > privately ? > > > > Arnaud, > > belive me, to date I don't recall a single major technical decision > > that has been settled exclusively in private (not subjected to peer > > review) and in particular in person (e-mail help you focus on a lot of > > different details that you may not have under control when talking to > > people, etc). > > > Whose call is it to declare something worth public discussion ? No one. > > Every time I see a "Suggested by:", "Submitted by:", "Reported by:", > and especially "Approved by:", there should to be a public reference > of the mentioned communication. > > > Sometimes it is useful that a limited number of developers is involved > > in initial brainstorming of some works, > > > Never. > > > but after this period > > constructive people usually ask for peer review publishing their plans > > on the mailing lists or other media. > > > Again, never. By doing so, you merely put the community in a situation > where, well, "We, committers, have come with this, you can either > accept or STFU, but no major changes will be made because we decided > so." > > The callout-ng conference at BSDCan was just beautiful, it was basically: > > Speaker: "we will do this" > Audience: "how about this situation ? What you will do will not work." > Speaker: "thank you for listening, end of the conference" > > It was beautiful to witness. > > > If you don't see any public further discussion this may be meaning: > > a) the BSDCan meetings have been fruitless and there is no precise > > plan/roadmap/etc. > > > so not only you make it private, but it shamelessly failed... > > > b) there is still not consensus on details > > > Then the discussion should stop, public records are kept for reference > in the future. There is no problem with this. > > > and you can always publically asked on what was decided and what not. > > Just send a mail to interested recipients and CC any FreeBSD mailing > > list. > > > This is not the way "openness" should be about. > I attended the developer summit, and attended the mbuf working group ... I'm also not a committer. My ASCII transcription of the results of the white-board session were posted to freebsd-arch in june, the post is available for viewing here: http://lists.freebsd.org/pipermail/freebsd-arch/2012-June/012629.html When the information is readily available (as it is in this case), there is a clear case of confusing one's inability to engage the entirety of FreeBSD with "openness". If you are concerned about the mbuf decisions, you should be subscribed to (and reading) the arch list. > - Arnaud > > > Attilio > > > > > > -- > > Peace can only be achieved by understanding - A. Einstein > ___ > freebsd-hack...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" > -- regards, matt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: On cooperative work [Was: Re: newbus' ivar's limitation..]
On 8/1/12, Arnaud Lacombe wrote: > Hi, > > On Wed, Aug 1, 2012 at 2:18 PM, Attilio Rao wrote: [ trimm ] >> You are forgetting one specific detail: you can always review a work >> *after* it entered the tree. This is something you would never do, but >> sometimes, when poor quality code is committed there is nothing else >> you can do than just raise your concern after it is in. >> > Unfortunately, not. First, the developer will certainly have moved on > after the commit, API may have been changed tree-wide, etc. Then, time > is likely to have passed between the time you figure potential > regression or bugs, which makes the first point even more problematic. > Finally, if my point of view is being ignored *before* it goes to the > tree, do you really expect it will be considered *after* ? There is one thing you are not considering: committers are as powerless as non-committers in face of someone stuck on his own buggy ideas/implementations. Often people are just convinced their idea is better than your and they won't change their mind, regardeless their status in the opensource community. And there is nothing more you can do apart from learning how to deal with such situations. Granted, there are projects blowing up and people abbandoning successful opensource community because of this. > From my external point of view, committers not only have the > possibility, but *do* commit mess in the tree without non-committers > could say or do anything, just as well as committers being able to > arbitrarily close PR even if the original reporter disagree. You should look at svn-src@ more often I suspect. You will see how many discussions are in there. >> And so? I think you have a wrong point of view of what is >> shamelessly... I'm working on the same project since 6 months, i >> thought I could finish it in 1 but then I understood that in order to >> get the quality I was hoping I had to do more work... does it qualify >> as failed, according to your standard? >> > not specifically, but at the end of that project of your, I would run > a post-mortem meeting to see what went correctly and where things got > out-of-control. Arnaud, my friend, I have a new for you: this stuff is hard. I see the brightest people I've ever met stuck for weeks on problems, thinking about how to fix them in elegant way. Sometimes things get understimated, sometimes not, this is just part of the game. But an important thing is accepting critics in costructive way and learn. This makes things much easier. > As for the mbuf meeting, all I can find from it online is: > > http://lists.freebsd.org/pipermail/freebsd-arch/2012-June/012629.html > > which is not worth much... Rather than doing things internally, maybe > it is time to open up... oh, wait, you will certainly come to the > community with a design plan, figure out it's not gonna work while > doing the implementation, change the design plan while implementing, > go public with a +3k/-2k loc change patch, ask for benediction, go > ahead and commit it up until someone comes with an obvious design flaw > which would render the change pretty much useless, but there will be > man-month of work to fix it, so it's never gonna be done. > > One obvious problem in FreeBSD is that committers are prosecutor, > judge and jury altogether. That's not the first time I point this out. You are drammatizing. As I already told, please, if you are interested in this topic, ask for the state of the discussion and ask politely to be included from now on. Nobody will reject you only because you don't have a @freebsd.org. b) there is still not consensus on details >>> Then the discussion should stop, public records are kept for reference >>> in the future. There is no problem with this. >>> and you can always publically asked on what was decided and what not. Just send a mail to interested recipients and CC any FreeBSD mailing list. >>> This is not the way "openness" should be about. >> >> There is not much more you can do when people don't share details and >> discussions automatically. >> > keep reporting regressions, interface flaws, POLA violations, ABI > breakages, bugs, etc. I agree. But with the correct and humble mindset and avoiding aggressive behaviour. Attilio -- Peace can only be achieved by understanding - A. Einstein ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: On cooperative work [Was: Re: newbus' ivar's limitation..]
Any interested party is very welcome to approach a developer and get added to the developer summits. Plenty of the people at the most recent developer summit weren't @freebsd.org committers - we had plenty of representation from companies using FreeBSD. If you want to participate, just ask a friendly developer who is going to the developer summit to sponsor you in going. You're pleasant in person, so I'd have no problem sponsoring you if I am going to an event. :) And/or, work with warner to get improvements into the tree and someone will sponsor a commit bit for you. Perhaps we as developers should more openly publish the results of developer summits. But as I said, they're not "closed" - they're just "invite only for non-developers." We're not going to exclude anyone from coming unless they really ARE going to just sit there and troll. You're motivated, you're enthusiastic and you want to see things change for the better. You're also not confrontational in person. I have no problem with you coming along. Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: On cooperative work [Was: Re: newbus' ivar's limitation..]
Date: Wed, 1 Aug 2012 15:45:35 -0400 From: Arnaud Lacombe One obvious problem in FreeBSD is that committers are prosecutor, judge and jury altogether. As a user, I accept this. I think if you can make a meaningful contribution to FreeBSD developments in the design stages, then become a committer. Otherwise contribute as a user - testing and bug reports mainly. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: On cooperative work [Was: Re: newbus' ivar's limitation..]
Hi, On Wed, Aug 1, 2012 at 2:18 PM, Attilio Rao wrote: > On 8/1/12, Arnaud Lacombe wrote: >> Hi, >> >> On Wed, Aug 1, 2012 at 12:40 PM, Attilio Rao wrote: >>> On Wed, Aug 1, 2012 at 5:32 PM, Arnaud Lacombe >>> wrote: Hi, On Tue, Jul 31, 2012 at 4:14 PM, Attilio Rao wrote: > > You don't want to work cooperatively. > Why is it that mbuf's refactoring consultation is being held in internal, private, committers-and-invite-only-restricted meeting at BSDCan ? Why is it that so much review and discussion on changes are held privately ? >>> >>> Arnaud, >>> belive me, to date I don't recall a single major technical decision >>> that has been settled exclusively in private (not subjected to peer >>> review) and in particular in person (e-mail help you focus on a lot of >>> different details that you may not have under control when talking to >>> people, etc). >>> >> Whose call is it to declare something worth public discussion ? No one. >> >> Every time I see a "Suggested by:", "Submitted by:", "Reported by:", >> and especially "Approved by:", there should to be a public reference >> of the mentioned communication. > > Not necessarilly. Every developer must ensure to produce a quality > work, with definition of "quality" being discretional. Some people > fail this expectation, while others do very good. As a general rule, > some people send patches to experts on the matter and they just trust > their judgment, others also full-fill testing cycles by thirdy part > people, others again ask for public reviews. Often this process is > adapted based on the dimension of the work and the number of > architectural changes it introduces. > > As a personal matter, for a big architectural change things I would > *personally* do are: > - Prepare a master-plan with experts of the matter > - Post a plan (after having achived consensus) on the public mailing > list for further discussions > - Adjust the plan based on public feedbacks (if necessary) > - Implement the plan > - Ask the experts if they have objections to the implementation > - Ask testers to perform some stress-testing > - Ask testers to perform benchmark (if I find people interested in that) > - Send out to the public mailing list for public review > - Integrate suggestions > - Ask testers to stress-test again > - Commit > > I think this model in general works fairly well, > I agree. > but people may have > different ideas on that, meaning that people may want to not involve > thirdy part for testing or review. This is going to be risky and lower > the quality of their work but it is their call. > >>> Sometimes it is useful that a limited number of developers is involved >>> in initial brainstorming of some works, >>> >> Never. >> >>> but after this period >>> constructive people usually ask for peer review publishing their plans >>> on the mailing lists or other media. >>> >> Again, never. By doing so, you merely put the community in a situation >> where, well, "We, committers, have come with this, you can either >> accept or STFU, but no major changes will be made because we decided >> so." > > You are forgetting one specific detail: you can always review a work > *after* it entered the tree. This is something you would never do, but > sometimes, when poor quality code is committed there is nothing else > you can do than just raise your concern after it is in. > Unfortunately, not. First, the developer will certainly have moved on after the commit, API may have been changed tree-wide, etc. Then, time is likely to have passed between the time you figure potential regression or bugs, which makes the first point even more problematic. Finally, if my point of view is being ignored *before* it goes to the tree, do you really expect it will be considered *after* ? >From my external point of view, committers not only have the possibility, but *do* commit mess in the tree without non-committers could say or do anything, just as well as committers being able to arbitrarily close PR even if the original reporter disagree. >> The callout-ng conference at BSDCan was just beautiful, it was basically: >> >> Speaker: "we will do this" >> Audience: "how about this situation ? What you will do will not work." >> Speaker: "thank you for listening, end of the conference" >> >> It was beautiful to witness. > > Not sure if you realized but I was what you mention "Audience". I > think you are referring to a specific case where a quick heads-up on a > summer of code project has been presented, you cannot really believe > all the technical discussion around FreeBSD evolve this way. > indeed, but that was still the case back then. >>> If you don't see any public further discussion this may be meaning: >>> a) the BSDCan meetings have been fruitless and there is no precise >>> plan/roadmap/etc. >>> >> so not only you make it private, but it shamelessly failed... > > And so? I think you have a wrong point of view of what
Re: On cooperative work [Was: Re: newbus' ivar's limitation..]
On 8/1/12, Arnaud Lacombe wrote: > Hi, > > On Wed, Aug 1, 2012 at 12:40 PM, Attilio Rao wrote: >> On Wed, Aug 1, 2012 at 5:32 PM, Arnaud Lacombe >> wrote: >>> Hi, >>> >>> On Tue, Jul 31, 2012 at 4:14 PM, Attilio Rao >>> wrote: You don't want to work cooperatively. >>> Why is it that mbuf's refactoring consultation is being held in >>> internal, private, committers-and-invite-only-restricted meeting at >>> BSDCan ? >>> >>> Why is it that so much review and discussion on changes are held >>> privately ? >> >> Arnaud, >> belive me, to date I don't recall a single major technical decision >> that has been settled exclusively in private (not subjected to peer >> review) and in particular in person (e-mail help you focus on a lot of >> different details that you may not have under control when talking to >> people, etc). >> > Whose call is it to declare something worth public discussion ? No one. > > Every time I see a "Suggested by:", "Submitted by:", "Reported by:", > and especially "Approved by:", there should to be a public reference > of the mentioned communication. Not necessarilly. Every developer must ensure to produce a quality work, with definition of "quality" being discretional. Some people fail this expectation, while others do very good. As a general rule, some people send patches to experts on the matter and they just trust their judgment, others also full-fill testing cycles by thirdy part people, others again ask for public reviews. Often this process is adapted based on the dimension of the work and the number of architectural changes it introduces. As a personal matter, for a big architectural change things I would *personally* do are: - Prepare a master-plan with experts of the matter - Post a plan (after having achived consensus) on the public mailing list for further discussions - Adjust the plan based on public feedbacks (if necessary) - Implement the plan - Ask the experts if they have objections to the implementation - Ask testers to perform some stress-testing - Ask testers to perform benchmark (if I find people interested in that) - Send out to the public mailing list for public review - Integrate suggestions - Ask testers to stress-test again - Commit I think this model in general works fairly well, but people may have different ideas on that, meaning that people may want to not involve thirdy part for testing or review. This is going to be risky and lower the quality of their work but it is their call. >> Sometimes it is useful that a limited number of developers is involved >> in initial brainstorming of some works, >> > Never. > >> but after this period >> constructive people usually ask for peer review publishing their plans >> on the mailing lists or other media. >> > Again, never. By doing so, you merely put the community in a situation > where, well, "We, committers, have come with this, you can either > accept or STFU, but no major changes will be made because we decided > so." You are forgetting one specific detail: you can always review a work *after* it entered the tree. This is something you would never do, but sometimes, when poor quality code is committed there is nothing else you can do than just raise your concern after it is in. > The callout-ng conference at BSDCan was just beautiful, it was basically: > > Speaker: "we will do this" > Audience: "how about this situation ? What you will do will not work." > Speaker: "thank you for listening, end of the conference" > > It was beautiful to witness. Not sure if you realized but I was what you mention "Audience". I think you are referring to a specific case where a quick heads-up on a summer of code project has been presented, you cannot really believe all the technical discussion around FreeBSD evolve this way. >> If you don't see any public further discussion this may be meaning: >> a) the BSDCan meetings have been fruitless and there is no precise >> plan/roadmap/etc. >> > so not only you make it private, but it shamelessly failed... And so? I think you have a wrong point of view of what is shamelessly... I'm working on the same project since 6 months, i thought I could finish it in 1 but then I understood that in order to get the quality I was hoping I had to do more work... does it qualify as failed, according to your standard? >> b) there is still not consensus on details >> > Then the discussion should stop, public records are kept for reference > in the future. There is no problem with this. > >> and you can always publically asked on what was decided and what not. >> Just send a mail to interested recipients and CC any FreeBSD mailing >> list. >> > This is not the way "openness" should be about. There is not much more you can do when people don't share details and discussions automatically. Attilio -- Peace can only be achieved by understanding - A. Einstein ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/l
Re: On cooperative work [Was: Re: newbus' ivar's limitation..]
Hi, On Wed, Aug 1, 2012 at 12:40 PM, Attilio Rao wrote: > On Wed, Aug 1, 2012 at 5:32 PM, Arnaud Lacombe wrote: >> Hi, >> >> On Tue, Jul 31, 2012 at 4:14 PM, Attilio Rao wrote: >>> >>> You don't want to work cooperatively. >>> >> Why is it that mbuf's refactoring consultation is being held in >> internal, private, committers-and-invite-only-restricted meeting at >> BSDCan ? >> >> Why is it that so much review and discussion on changes are held privately ? > > Arnaud, > belive me, to date I don't recall a single major technical decision > that has been settled exclusively in private (not subjected to peer > review) and in particular in person (e-mail help you focus on a lot of > different details that you may not have under control when talking to > people, etc). > Whose call is it to declare something worth public discussion ? No one. Every time I see a "Suggested by:", "Submitted by:", "Reported by:", and especially "Approved by:", there should to be a public reference of the mentioned communication. > Sometimes it is useful that a limited number of developers is involved > in initial brainstorming of some works, > Never. > but after this period > constructive people usually ask for peer review publishing their plans > on the mailing lists or other media. > Again, never. By doing so, you merely put the community in a situation where, well, "We, committers, have come with this, you can either accept or STFU, but no major changes will be made because we decided so." The callout-ng conference at BSDCan was just beautiful, it was basically: Speaker: "we will do this" Audience: "how about this situation ? What you will do will not work." Speaker: "thank you for listening, end of the conference" It was beautiful to witness. > If you don't see any public further discussion this may be meaning: > a) the BSDCan meetings have been fruitless and there is no precise > plan/roadmap/etc. > so not only you make it private, but it shamelessly failed... > b) there is still not consensus on details > Then the discussion should stop, public records are kept for reference in the future. There is no problem with this. > and you can always publically asked on what was decided and what not. > Just send a mail to interested recipients and CC any FreeBSD mailing > list. > This is not the way "openness" should be about. - Arnaud > Attilio > > > -- > Peace can only be achieved by understanding - A. Einstein ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: On cooperative work [Was: Re: newbus' ivar's limitation..]
On Wed, Aug 1, 2012 at 5:32 PM, Arnaud Lacombe wrote: > Hi, > > On Tue, Jul 31, 2012 at 4:14 PM, Attilio Rao wrote: >> >> You don't want to work cooperatively. >> > Why is it that mbuf's refactoring consultation is being held in > internal, private, committers-and-invite-only-restricted meeting at > BSDCan ? > > Why is it that so much review and discussion on changes are held privately ? Arnaud, belive me, to date I don't recall a single major technical decision that has been settled exclusively in private (not subjected to peer review) and in particular in person (e-mail help you focus on a lot of different details that you may not have under control when talking to people, etc). Sometimes it is useful that a limited number of developers is involved in initial brainstorming of some works, but after this period constructive people usually ask for peer review publishing their plans on the mailing lists or other media. If you don't see any public further discussion this may be meaning: a) the BSDCan meetings have been fruitless and there is no precise plan/roadmap/etc. b) there is still not consensus on details and you can always publically asked on what was decided and what not. Just send a mail to interested recipients and CC any FreeBSD mailing list. Attilio -- Peace can only be achieved by understanding - A. Einstein ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
