new modules consensus

[Mark McLoughlin <markmc redhat com>]

Hey,
	Due to everyone on the release-team's lack of time, we haven't made the
new modules decision yet, nor even discussed making the decision.
Shucks, I didn't even talk to anyone before sending this mail. This was
supposed to be finalised a month ago so we're sucking pretty badly :-)

	Anyway, the new modules decision is a community decision - all the
release team is supposed to do is figure out what the consensus is and
rubber stamp it. 

	So, lets do it here - the intent here is just to figure out what the
consensus is, rather than restart the discussion about any particular
module. If you want to restart the discussion, go back to the original
thread. If the consensus is that there is no consensus, then the
original discussion needs to be restarted.

	Briefly skimming over the discussions that took place, here's how it
looks to me:

- Cantus

    Discussion centred around whether we should be adding a tag editor
    to the desktop, and if we should, whether it should be a standalone
    app or integrated to Nautilus and/or Rhythmbox.

    Consensus seemed to be a "no".   


 - libsoup
   gal
   gtkhtml
   evolution-data-server
   evolution
   evolution-exchange

     (No make sense to considering any of these independently, right?)

     Discussion on i18n issues, lots of strings, big database of strings
     for Location names and the like. Seems that these issues have been 
     greatly reduced, people are relatively happy and the Evolution team
     work well with the i18n team on such issues.

     People would like to see Evolution move to GNOME bugzilla, but 
     there is a recognition that it is a big task. This should happen,
     though, and the sooner the better but no-one seems to consider a
     blocker.

     Some discussion on removing the Evolution "brand" from the 
     interface, what its menu entry should be and the like ... The
     debate seemed to peter out with no agreement, but it also didn't
     look like an issue which would block Evolution's acceptance.

     Evolution 1.5 doesn't use the new fileselector because it doesn't 
     want to depend on GTK+ 2.4. There was discussion about adding a 
     #ifdef patch and the Evolution team was happy to have that happen
     so long as someone was willing to do the work. However, that
     doesn't seem to have happened. I think it was obvious that most
     people found this a huge disappointment, but that most were willing
     to accept it so long as it is indicative of a trend for the future.

     Discussion over Evolution's copyright assignment policy start out
     as "its relatively harmless and not a huge issue" to a gigantic 
     flamewar. I haven't followed the discussion closely enough to be 
     confident that I'll do a good job of summarising the issues, but 
     briefly:

       - Issues with the actual text of the contract which need 
         resolving in order for people to be confident that a future
         Evil Novell couldn't ship their code solely under a proprietary
         license
 
       - Worries that the requirement to sign the contract will turn 
         people away from hacking on Evolution because of concerns about
         the contract itself or sheer laziness ("I just want to hack, I 
         don't want to sign this")

       - Concerns that including Evolution with these issues would set a
         dangerous precedent.

     If there is any consensus on this particular issue, I think it is 
     that:

       - There are serious concerns here that need to be properly 
         addressed

       - That if the issue cannot be resolved, nothing prevents GNOME 
         from creating a non Copyright requiring fork which would track 
         the Novell version


     Its clear there is yet no overwhelming consensus on whether or not 
     we should include Evolution in GNOME 2.8. What I think is clear, 
     though, is that there is a huge *desire* to include it - both from
     the GNOME community and the Evolution team. I think we need to 
     decide on whether 

       a) whether any of the issues listed above absolutely need to 
          resolved before inclusion, or 

       b) whether we are confident that the Evolution team and the GNOME
          community will resolve these issues post inclusion

     If we decide (a), then we must hope that the people will continue 
     to work hard to resolve the problems and at some point in the
     future we'll be able include Evolution. If we decide (b), we then
     hope that Evolution's inclusion will actually boost peoples desire
     to resolve the problems rather than give people the impression that
     no problems remain.

     I vote (b)


 - evolution-webcal

     There was good agreement about the inclusion of this, barring some 
     suggestions that since its independent of evolution it could be 
     renamed.

     Only issue here is that unless evolution-data-server is included, 
     then it doesn't make sense to include evolution-webcal.

     Consensus: yes, if we have e-d-s


 - gnome-keyring-manager

     There wasn't a huge amount of discussion, but the discussion that 
     did happen centred around the application being very difficult to 
     understand and that it would benefit from being left out for now 
     and the authors working with the usability team over the next 
     months to improve its interaction model.

     Consensus: no, but only for now.


 - gnome-nettool

     The discussion about this could basically be summarised as:

       A: its a geek tool, it doesn't belong in the desktop
       B: user's are really only expected to use this with an admin's 
          guidance, so its not a problem

     Jody, Seth, Calum and I seemed to find this argument fairly weak. 
     However, the authors, Jeff and Bastien that it should be included.

     I don't think you could say there's consensus here, and I'm 
     certainly not going to try and call it. I'd lean towards its 
     inclusion, though, unless it was obvious that other people felt
     strongly that it shouldn't be included.


 - gnome-system-tools

     There was some useful discussion on how to move forward on 
     integrating some of the system tools into the desktop, but at this 
     point we need to choose between include g-s-t as it is now, or not 
     including it at all.

     The consensus, then, would seem to be that we don't include g-s-t.


 - gnome-volume-manager

     Concerns about what happens with a 2.4 kernel, agreement that it 
     should be resolved before inclusion. Has it?

     Discussion about merging its configuration UI with the control 
     centre. Agreement that this isn't a blocker, though.

     Consensus: yes


 - vino

     Concern about the lack of a VNC client in GNOME, suggested that 
     Vino should have a vncviewer launcher dialog like tsclient, but 
     that hasn't happened.

     I started to try and summarise the rest of the discussion, but 
     realised that, as the author, I probably shouldn't.



	Anyway, we need to reach agreement here quickly and we need to work
under the assumption that, for each module, we're deciding between
either including the module as it stands right now, or not including it
all.

Thanks,
Mark.