[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: Google Online document Plugin for KOffice
From:       Thomas Zander <zander () kde ! org>
Date:       2010-07-06 22:13:52
Message-ID: 201007070013.53166.zander () kde ! org
[Download RAW message or body]

On Tuesday 6. July 2010 22.09.08 Boudewijn Rempt wrote:
> On Tuesday 06 July 2010, Mani N C wrote:
> > I was travelling and couldn't access my mail.
> > Let me add my 2 cents,
> > 
> > I personally don't mind to put my code inside trunk or outside, if it
> > goes with the application.
> 
> If it isn't in koffice/trunk, it won't be part of the release, so in that
> sense it won't go with the application.

This is misrepresenting the concept of 'staging' area.
While technically you are correct, it is quite important to point out that a 
choice of location is not permanent. Also the kofficeplugins repo is new, it 
might very well be released.
In other words; it would be wrong to conclude that the only way to get released 
you need to commit in koffice/plugins.
 
> > I just have one question, Does plugin code in Kofficeplugin will remain
> > there forever or After sometime should it be moved to trunk/plugin again
> > ?
> 
> There's no process defined for that yet, so that's all a gray area.

this is misrepresenting the concept of a staging area; which is quite well 
defined by many usages inside and outside of koffice. That the KOffice community 
has not started to copy such a process and draft actual rules for agreement is 
indeed true. The rules will not be a big surprise to anyone that has insight in 
how plasma or others use this concept successfully already.
In other words; it would be wrong to conclude that it will be impossible or 
even hard to move a plugin into the koffice repository if you choose to go for 
the kofficeplugins now.
 
> > Only thing i'm worried about is, I don't want my work to go wasted since
> > it is inside the source repo. I would be really happy If this will also
> > go with the official koffice package, even from kofficeplugin.
> 
> Just commit it to koffice/plugins, then. There is no objection to that at
> all.

The wording of 'no objections' is entirely correct, but your wording its 
misrepresenting the situation. There are better alternatives that were 
suggested and reasons offered for those alternatives.
In other words; please consider the location to put the new plugin based, not 
on objections or fears, but based on the suggestions and their rationale.

Also you and Inge were suggesting something else just earlier. A staging 
subdir. Lets not loose that again.

For Mani;
we suggested kofficeplugins for plugins that are part of the koffice community, are 
under heavy development and will not have to deal with the freezes and other 
limiting factors.
New plugins that need to be part of the koffice repository should go into 
plugins/staging where they can mature to a releasable state. You most likely 
need to update/compile all of koffice more often while working on the plugin if 
you choose this option. Also you have to abide by the freezes and release 
schedule.

Cheers
-- 
Thomas Zander
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]