Re: [Gimp-developer] Second try
hmm...Agreeded. I'd suggest 10 days instead of 5 (if I, for an example, am on a heavy workload week, 5 days could not be enough to make my points, if they need soem expermenting on the codebase), But since the decision was taken, so mote it be - it's not gonna hurt. later it was agreed that 7 would be more reasonable since some people only work on it part of the week. 10 could be made for the same reason. I'll make sure it it brought up. Also, nothing has been set in stone. We are very informal around here, as always. As for the foundation., I'd be happy if it was in Europe. USA is getting more and more of those stuppid laws, including states passing super-DMCAs¨ , that if enforced would stop the Internet alltogether. It could be in both. I still need to talk to a lawyer. As was brought up at the meeting, FSF has two seperate and associated groups. FSF America and FSF Europe. Both with different monies and slightly different goals. The foundation has to care off one other thing I did not see on the summary: most, or all of the codebase must be owned by it. It would legally allow small adjusts in the license, like the recently one that clarified that there could be proprietary plug-ins for the GIMP. (Strictly in terms of the GPL, as currently the copyright holder is each individual author, there would be the need to have express permission from each author for this change). Also, there is the GNU motive - if the need arises to defend GIMP's IP in court, it is easier if the foundation is the owner, and not a lot of people spread over the world. This is a very good point. Off course there must be foolproof safeguards to keep the foundation from doing non-wanted things to the codebase. So, that GIMP should be free software should be specified in the reason of beingof such a foundation. yes, well, in america, when you incorporate as a public-benefit NPO, you can include that concept in the reason of being. Thus any move away from free software would require a dissolving of the corporation. Even if that happened, public-benefit NPO assests must be sold to another public-benefit NPO, so a hostile takeover of an NPO isn't really possible. -- Daniel Rogers ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Second try
hmm...Agreeded. I'd suggest 10 days instead of 5 (if I, for an example, am on a heavy workload week, 5 days could not be enough to make my points, if they need soem expermenting on the codebase), But since the decision was taken, so mote it be - it's not gonna hurt. As for the foundation., I'd be happy if it was in Europe. USA is getting more and more of those stuppid laws, including states passing super-DMCAs¨ , that if enforced would stop the Internet alltogether. The foundation has to care off one other thing I did not see on the summary: most, or all of the codebase must be owned by it. It would legally allow small adjusts in the license, like the recently one that clarified that there could be proprietary plug-ins for the GIMP. (Strictly in terms of the GPL, as currently the copyright holder is each individual author, there would be the need to have express permission from each author for this change). Also, there is the GNU motive - if the need arises to defend GIMP's IP in court, it is easier if the foundation is the owner, and not a lot of people spread over the world. Off course there must be foolproof safeguards to keep the foundation from doing non-wanted things to the codebase. So, that GIMP should be free software should be specified in the reason of beingof such a foundation. These are my points so far. Cheers, JS -- - Decisions --- Not too many of these... we will have a release manager, but we need to define exactly what his/her remit will be. And who it will be. We agreed that the 5 days and it's dead rule for threads makes sense, so that will be done. - Future 1) Roadmap - rough release schedule, we will have a first draft today. 2) GIMP Foundation - we need to define its responsibilities, set up election rules, and get this set up. The principle of the foundation is more or less agreed. 3) Communication 4) Release Manager - what'll he do, who'll he be. This should be short once we have discussed communication channels a bit. 5) Technie stuff - Sven and mitch are going to talk to us about the re-organisation of the code, GObjectification of everything, and other stuff. Daniel and Calvin are going to talk to us about Gegl and how they feel the GIMP could use it. This will probably be a two-way discussion about what kind of things we expect gegl to furnish as well. 6) GIMP tutorials - jimmac and nomis are going to do some presentations for people, which should be good. 7) Plug-in distribution - 3 years ago this was discussion, yosh has been working on something as a proof-of-concept, it would be nice to address this and get something in place soon. So there you go. Hello everyone from camp. Cheers, Dave. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Second try
Hi, Seems like the attachment got stripped by the mail software, so I'm sending this again, only this time inline. As before, these discussions are going to be posted here to give people a chance to give feedback, even if they can't be here. Thanks for your time, Dave. The First Big Serious Meeting - 7 Aug 03, around 8pm Discussion was led by Daniel Rogers (dsrogers) but stuff said is for the most part anonymous. Partly because there shouldn't be any ad hominem attacks that way, and partly because I didn't take down any names. Present: Dan Rogers, Raphael Quinet, Dave Neary, Sven Neumann, Mitch Natterer, Hans Brix Anderssen (brix), Jakub Steiner (jimmac), Simon Budig (nomis), Marc Lehmann, Ville Patsi (drc), Oyvind Kolas (pippin), Calvin Williamson, Roman (romanofski). Absent but at camp: Maurits Rijk, Branko Collins. Topic discussion, in approximate chronological order: - - The GIMP foundation - Release manager - Decision making (or lack of it) - General stuff about CVS, Bugzilla - Communication - The GIMP Foundation - The idea of a foundation was proposed. Lots of ideas were thrown about as to what kind of remit it would have. If created, the foundation would certainly have 2 thinsg we don't have at the moment - a bank account people could donate to, and a focus on marketing in the broadest sense of the word. Some of the issues were whether the foundation would be set up in Europe or in the US (in the US it might make it easier to get donations from US companies, but in Europe we're not as litigious, so setting up would certainly cost less, but then we probably wouldn't have NPO status in the US), whether it would have any technical aspect (that is, would the foundation act as a kind of steering committee for the general direction of the GIMP?), and how, if the issue came up, we might pay someone. This led onto a discussion of whether the foundation would be responsible for setting release dates, or whether we would have a separate... - Release Manager - The general concensus (more on that later) was that a release manager is a good thing. There do seem to be a few different ideas of what the role would entail. The general idea would be that the release manager would be responsible for following CVS and know at what stage a given feature is at, follow bugzilla making sure that bugs got milestoned for some release in order of their priority, would annoy people to get commits in before feature freeze dates or postpone mercilessly features which are not finished. It was agreed that a release schedule would be helpful to define the perimeters of responsibility of the release manager - basically, some way to set up large milestones to aim for with things to go into those milestones. This release schedule would be subject to revision, and would be no more realistic than any other release schedule, but it would serve as a guide for development. Dan agreed to draw up a first draft of this, and we'll have something more concrete before the end of the weekend. The questions that came up about the release manager were things like where his authority comes from, how does he decide which bugs are important and which features can be postponed and so on. In other words, how do decisions get made. Is the release manager a benevolent dictator, or does he answer to the larger developer and user community? If so, to what extent? Is backing out CVS commits OK, for example? So we started talking about how to get contentious decisions made. - Decision making (or lack of it) - Currently, there are two ways to get something done in the gimp. First, you can write decent code and patches for a while, until you get CVS commit access, then you write whatever feature you're interested in, and commit it. If no-one backs it out, then it's in. Second, you can bring it up on the mailing list, or in bugzilla, or in IRC (more on communication later), and discuss it until there is a concensus. However, we tend to be pretty bad at reaching concensus on anything even slightly contentious. The important questions to be answered any time a discussion like this comes up are what's going to be done, and who's going to do it. It was agreed that beyond a certain point, there is generally very little technical merit to these types of discussions. It was felt that about 5 days was enough for everyone with an opinion on a given matter to make that opinion known, and that after that point, it would be an idea to have a summary of the salient points and close the discussion. That means, the people here would stop posting to the discussion. Of course, if other people want to keep on flaming, they're free
