Discussion:
[wdte-devel] Setting up the infrastructure
Christopher Lenz
2004-01-26 17:12:31 UTC
Permalink
Hi folks,

mailman tells me that most are subscribed, and posts to the mailing
list seem to finally get through to the subscribers. The archive will
hopefully also be activated by tomorrow.

Here's a list of basic stuff -- mostly infrastructure -- that we need
to agree on.

1. Create a 'wdte-cvs' mailing list and setup the SourceForge
'syncmail' script so that it sends email notifications on CVS changes
to that mailing list. Anyone who is listed as a project member will be
subscribed to that list. Anyone else can subscribe if they want to.
Note that the cvs list is only intended for messages from the
'syncmail' script and any discussion should be held on the devel list.

2. Set up a basic website. I propose that we take over the layout from
csseditor.sf.net, which is basically the Eclipse.org layout rewritten
with modern markup (no frames, CSS for layout, dada dada). The content
of the site should be checked into CVS. I propose the module name
'net.sf.wdte-site' for this. The content of the module should mirror
the content of the csseditor group home directory on the shell/web
servers (ie not only the 'htdocs' directory).

3. Set up a Wiki at http://wdte.sourceforge.net/wiki. I propose to
build on the work I've done for http://csseditor.sourceforge.net/wiki,
which is basically an instance of Tavi with an Eclipse.org-style
template. The Wiki would not replace the primary project documentation,
but rather serve as a whiteboard area where documentation can be
evolved collaboratively.

4. Disable the SourceForge Doc Manager. I've never used it, but I think
with the primary documentation in CVS, and other documentation on the
Wiki, we won't need it. We should generally remove/disable any SF
features that we don't use, if only to avoid confusion and
fragmentation.

5. For the same reason, disable the Task Manager. It will probably only
create confusion, too.

6. Disable the issue tracker for "Support Requests" and "Patches".
Support requests should be handled in the user forums, and patches
should be either sent to the devel mailing-list, or attached to
existing Bug reports.

7. Make the issue trackers "Bugs" and "RFE" send mails to a mailing
list on every change. That could be either this list, or a separate
wdte-issues mailing list. I don't care either way, as long as they are
sent somewhere I can subscribe to, and I don't need to "pull" the
information from the website.

8. Finally, I'd like the remove/disable the forums "Features" and
"Volunteering". In general, I think that at the current stage, the
fewer communication channels we have, the better. So I'd even be in
favor of removing/disabling the "Help" forum and keeping only "Open
Discussion" (possibly renamed?).

Okay, let's not turn this into a huge discussion. Write +1 if you're in
favor of a suggested item, and -1 if you object (with an explanation).
Only votes by project members are considered binding, although everyone
is invited to participate in the discussion (but again, let's not drag
this out please).

Cheers,
Chris
--
Christopher Lenz
/=/ cmlenz at gmx.de
Igor Malinin
2004-01-26 22:07:59 UTC
Permalink
Post by Christopher Lenz
Hi folks,
1. Create a 'wdte-cvs' mailing list and setup the SourceForge 'syncmail'
script so that it sends email notifications on CVS changes to that
mailing list. Anyone who is listed as a project member will be
subscribed to that list. Anyone else can subscribe if they want to. Note
that the cvs list is only intended for messages from the 'syncmail'
script and any discussion should be held on the devel list.
+1 in general
-1 for a requirement of every member to subscribe to it (it is useless
for me personally since I delete CVS messages blindly, dont want to
waste my mailbox with more messages; and when I really need to look at
CVS commits I could see it in arhives actually + diffs in "Synchronize
with repository")
Post by Christopher Lenz
2. Set up a basic website. I propose that we take over the layout from
csseditor.sf.net, which is basically the Eclipse.org layout rewritten
with modern markup (no frames, CSS for layout, dada dada). The content
of the site should be checked into CVS. I propose the module name
'net.sf.wdte-site' for this. The content of the module should mirror the
content of the csseditor group home directory on the shell/web servers
(ie not only the 'htdocs' directory).
-1 for 'net.sf.wdte-site'; Accorfding to eclipse.org naming conventions
the name for this module would be wdte-home...
+1 for 'net.sf.wdte-home' (just for keeping the module together with
other wdte modules in Navigator I agree on 'net.sf.' prefix)

PS! -1 is not strong, and I would agree on 'net.sf.wdte-site' too.
Post by Christopher Lenz
3. Set up a Wiki at http://wdte.sourceforge.net/wiki. I propose to build
on the work I've done for http://csseditor.sourceforge.net/wiki, which
is basically an instance of Tavi with an Eclipse.org-style template. The
Wiki would not replace the primary project documentation, but rather
serve as a whiteboard area where documentation can be evolved
collaboratively.
+1
Post by Christopher Lenz
4. Disable the SourceForge Doc Manager. I've never used it, but I think
with the primary documentation in CVS, and other documentation on the
Wiki, we won't need it. We should generally remove/disable any SF
features that we don't use, if only to avoid confusion and fragmentation.
+1
Post by Christopher Lenz
5. For the same reason, disable the Task Manager. It will probably only
create confusion, too.
-0 May be useful in collaborative development... but don't feel srtong
need in it
Post by Christopher Lenz
6. Disable the issue tracker for "Support Requests" and "Patches".
Support requests should be handled in the user forums, and patches
should be either sent to the devel mailing-list, or attached to existing
Bug reports.
+1
Post by Christopher Lenz
7. Make the issue trackers "Bugs" and "RFE" send mails to a mailing list
on every change. That could be either this list, or a separate
wdte-issues mailing list. I don't care either way, as long as they are
sent somewhere I can subscribe to, and I don't need to "pull" the
information from the website.
-0 I would prefer separate list if it is done... And Isn't it possible
to "subscribe" to trackers? If it is then my vote changes to -1.
Post by Christopher Lenz
8. Finally, I'd like the remove/disable the forums "Features" and
"Volunteering". In general, I think that at the current stage, the fewer
communication channels we have, the better. So I'd even be in favor of
removing/disabling the "Help" forum and keeping only "Open Discussion"
(possibly renamed?).
+1 And I don't feel a need to rename Open Discussion
Christopher Lenz
2004-01-26 22:37:48 UTC
Permalink
Post by Igor Malinin
Post by Christopher Lenz
Hi folks,
1. Create a 'wdte-cvs' mailing list and setup the SourceForge
'syncmail' script so that it sends email notifications on CVS changes
to that mailing list. Anyone who is listed as a project member will
be subscribed to that list. Anyone else can subscribe if they want
to. Note that the cvs list is only intended for messages from the
'syncmail' script and any discussion should be held on the devel list.
+1 in general
-1 for a requirement of every member to subscribe to it (it is useless
for me personally since I delete CVS messages blindly, dont want to
waste my mailbox with more messages; and when I really need to look at
CVS commits I could see it in arhives actually + diffs in "Synchronize
with repository")
Okay, let's make it optional for now. Personally, I think it's much
more convenient to quickly scan a commit mail than navigating through
the synchronize view, also because I can do it when offline :-)
Post by Igor Malinin
Post by Christopher Lenz
2. Set up a basic website. I propose that we take over the layout
from csseditor.sf.net, which is basically the Eclipse.org layout
rewritten with modern markup (no frames, CSS for layout, dada dada).
The content of the site should be checked into CVS. I propose the
module name 'net.sf.wdte-site' for this. The content of the module
should mirror the content of the csseditor group home directory on
the shell/web servers (ie not only the 'htdocs' directory).
-1 for 'net.sf.wdte-site'; Accorfding to eclipse.org naming
conventions the name for this module would be wdte-home...
+1 for 'net.sf.wdte-home' (just for keeping the module together with
other wdte modules in Navigator I agree on 'net.sf.' prefix)
PS! -1 is not strong, and I would agree on 'net.sf.wdte-site' too.
Hmm, yeah I actually like net.sf.wdte-home better, too.
Post by Igor Malinin
Post by Christopher Lenz
5. For the same reason, disable the Task Manager. It will probably
only create confusion, too.
-0 May be useful in collaborative development... but don't feel srtong
need in it
Note that it can also be reactivated if we ever decide we need it.
Post by Igor Malinin
Post by Christopher Lenz
7. Make the issue trackers "Bugs" and "RFE" send mails to a mailing
list on every change. That could be either this list, or a separate
wdte-issues mailing list. I don't care either way, as long as they
are sent somewhere I can subscribe to, and I don't need to "pull" the
information from the website.
-0 I would prefer separate list if it is done... And Isn't it possible
to "subscribe" to trackers? If it is then my vote changes to -1.
It is only possible to subscribe to individual tracker items AFAICT. I
think it would be important to provide pushing of issues into the mail
boxes of those who are interested and don't like pulling information
(like myself ;-) ). As with the CVS mailing list, we can make
subscription optional for now.

Cheers,
Chris
--
Christopher Lenz
/=/ cmlenz at gmx.de
Igor Malinin
2004-01-28 08:41:34 UTC
Permalink
Post by Igor Malinin
Post by Christopher Lenz
Hi folks,
1. Create a 'wdte-cvs' mailing list and setup the SourceForge
'syncmail' script so that it sends email notifications on CVS changes
to that mailing list. Anyone who is listed as a project member will
be subscribed to that list. Anyone else can subscribe if they want
to. Note that the cvs list is only intended for messages from the
'syncmail' script and any discussion should be held on the devel list.
+1 in general
-1 for a requirement of every member to subscribe to it (it is useless
for me personally since I delete CVS messages blindly, dont want to
waste my mailbox with more messages; and when I really need to look at
CVS commits I could see it in arhives actually + diffs in "Synchronize
with repository")
Okay, let's make it optional for now. Personally, I think it's much more
convenient to quickly scan a commit mail than navigating through the
synchronize view, also because I can do it when offline :-)
I am always online ;) And all my mail is on IMAP account, I couldn't
read it when I am offline anyway... and my mail is quite overloaded
already... So, it is really a question of personal preference ;)
Post by Igor Malinin
Post by Christopher Lenz
5. For the same reason, disable the Task Manager. It will probably
only create confusion, too.
-0 May be useful in collaborative development... but don't feel srtong
need in it
Note that it can also be reactivated if we ever decide we need it.
This is what I mean't vhen voted with zero... But if we swithch it off
today we probably will never use it even if we need it.
Post by Igor Malinin
Post by Christopher Lenz
7. Make the issue trackers "Bugs" and "RFE" send mails to a mailing
list on every change. That could be either this list, or a separate
wdte-issues mailing list. I don't care either way, as long as they
are sent somewhere I can subscribe to, and I don't need to "pull" the
information from the website.
-0 I would prefer separate list if it is done... And Isn't it possible
to "subscribe" to trackers? If it is then my vote changes to -1.
It is only possible to subscribe to individual tracker items AFAICT. I
think it would be important to provide pushing of issues into the mail
boxes of those who are interested and don't like pulling information
(like myself ;-) ). As with the CVS mailing list, we can make
subscription optional for now.
Ok! Then count my "+1" for separate mailing list (wdte-issues ?)
Matt Brozowski
2004-01-26 17:43:38 UTC
Permalink
Here are my votes....

Executive summary:
complete agreement for the short term.... None of the decision made cannot
be undone in the future when things are farther along. Decisions are the
most important thing we need right now until we build some real momentum on
the development
Post by Christopher Lenz
1. Create a 'wdte-cvs' mailing list and setup the SourceForge
'syncmail' script so that it sends email notifications on CVS changes
to that mailing list. Anyone who is listed as a project member will be
subscribed to that list. Anyone else can subscribe if they want to.
Note that the cvs list is only intended for messages from the
'syncmail' script and any discussion should be held on the devel list.
+1
Post by Christopher Lenz
2. Set up a basic website. I propose that we take over the layout from
csseditor.sf.net, which is basically the Eclipse.org layout rewritten
with modern markup (no frames, CSS for layout, dada dada). The content
of the site should be checked into CVS. I propose the module name
'net.sf.wdte-site' for this. The content of the module should mirror
the content of the csseditor group home directory on the shell/web
servers (ie not only the 'htdocs' directory).
+1
Post by Christopher Lenz
3. Set up a Wiki at http://wdte.sourceforge.net/wiki. I propose to
build on the work I've done for http://csseditor.sourceforge.net/wiki,
which is basically an instance of Tavi with an Eclipse.org-style
template. The Wiki would not replace the primary project documentation,
but rather serve as a whiteboard area where documentation can be
evolved collaboratively.
+1
Post by Christopher Lenz
4. Disable the SourceForge Doc Manager. I've never used it, but I think
with the primary documentation in CVS, and other documentation on the
Wiki, we won't need it. We should generally remove/disable any SF
features that we don't use, if only to avoid confusion and
fragmentation.
+1
Post by Christopher Lenz
5. For the same reason, disable the Task Manager. It will probably only
create confusion, too.
+1
Post by Christopher Lenz
6. Disable the issue tracker for "Support Requests" and "Patches".
Support requests should be handled in the user forums, and patches
should be either sent to the devel mailing-list, or attached to
existing Bug reports.
+1
Post by Christopher Lenz
7. Make the issue trackers "Bugs" and "RFE" send mails to a mailing
list on every change. That could be either this list, or a separate
wdte-issues mailing list. I don't care either way, as long as they are
sent somewhere I can subscribe to, and I don't need to "pull" the
information from the website.
+1
Post by Christopher Lenz
8. Finally, I'd like the remove/disable the forums "Features" and
"Volunteering". In general, I think that at the current stage, the
fewer communication channels we have, the better. So I'd even be in
favor of removing/disabling the "Help" forum and keeping only "Open
Discussion" (possibly renamed?).
+1. For the short term
Christopher Lenz
2004-01-27 12:29:11 UTC
Permalink
Post by Christopher Lenz
1. Create a 'wdte-cvs' mailing list and setup the SourceForge
'syncmail' script so that it sends email notifications on CVS changes
to that mailing list. Anyone who is listed as a project member will be
subscribed to that list. Anyone else can subscribe if they want to.
Note that the cvs list is only intended for messages from the
'syncmail' script and any discussion should be held on the devel list.
Okay, this is now in place.

--
Christopher Lenz
/=/ cmlenz at gmx.de
Fitzpatrick, Alex
2004-01-27 20:00:59 UTC
Permalink
Post by Christopher Lenz
Hi folks,
1. Create a 'wdte-cvs' mailing list and setup the SourceForge 'syncmail'
script so that it sends email notifications on CVS changes to that
-- snip --

Chris, can you repost "Setting up the infrastructure"?

I never got the original.
--
Alex

This message may contain privileged and/or confidential information. If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so. Thank you.
Christopher Lenz
2004-01-27 21:48:53 UTC
Permalink
Post by Christopher Lenz
Post by Christopher Lenz
Hi folks,
1. Create a 'wdte-cvs' mailing list and setup the SourceForge
'syncmail'
Post by Christopher Lenz
script so that it sends email notifications on CVS changes to that
-- snip --
Chris, can you repost "Setting up the infrastructure"?
I never got the original.
I've reposted the message.

I *would* have pointed you to the archive, but after it has been
available earlier today, it had suddenly disappeared again when I
looked. Now it's back again:

http://sourceforge.net/mailarchive/forum.php?forum=wdte-devel

I really hope all these problems with SF are temporary :-P

--
Christopher Lenz
/=/ cmlenz at gmx.de
Christopher Lenz
2004-01-27 20:55:44 UTC
Permalink
Hi folks,

mailman tells me that most are subscribed, and posts to the mailing
list seem to finally get through to the subscribers. The archive will
hopefully also be activated by tomorrow.

Here's a list of basic stuff -- mostly infrastructure -- that we need
to agree on.

1. Create a 'wdte-cvs' mailing list and setup the SourceForge
'syncmail' script so that it sends email notifications on CVS changes
to that mailing list. Anyone who is listed as a project member will be
subscribed to that list. Anyone else can subscribe if they want to.
Note that the cvs list is only intended for messages from the
'syncmail' script and any discussion should be held on the devel list.

2. Set up a basic website. I propose that we take over the layout from
csseditor.sf.net, which is basically the Eclipse.org layout rewritten
with modern markup (no frames, CSS for layout, dada dada). The content
of the site should be checked into CVS. I propose the module name
'net.sf.wdte-site' for this. The content of the module should mirror
the content of the csseditor group home directory on the shell/web
servers (ie not only the 'htdocs' directory).

3. Set up a Wiki at http://wdte.sourceforge.net/wiki. I propose to
build on the work I've done for http://csseditor.sourceforge.net/wiki,
which is basically an instance of Tavi with an Eclipse.org-style
template. The Wiki would not replace the primary project documentation,
but rather serve as a whiteboard area where documentation can be
evolved collaboratively.

4. Disable the SourceForge Doc Manager. I've never used it, but I think
with the primary documentation in CVS, and other documentation on the
Wiki, we won't need it. We should generally remove/disable any SF
features that we don't use, if only to avoid confusion and
fragmentation.

5. For the same reason, disable the Task Manager. It will probably only
create confusion, too.

6. Disable the issue tracker for "Support Requests" and "Patches".
Support requests should be handled in the user forums, and patches
should be either sent to the devel mailing-list, or attached to
existing Bug reports.

7. Make the issue trackers "Bugs" and "RFE" send mails to a mailing
list on every change. That could be either this list, or a separate
wdte-issues mailing list. I don't care either way, as long as they are
sent somewhere I can subscribe to, and I don't need to "pull" the
information from the website.

8. Finally, I'd like the remove/disable the forums "Features" and
"Volunteering". In general, I think that at the current stage, the
fewer communication channels we have, the better. So I'd even be in
favor of removing/disabling the "Help" forum and keeping only "Open
Discussion" (possibly renamed?).

Okay, let's not turn this into a huge discussion. Write +1 if you're in
favor of a suggested item, and -1 if you object (with an explanation).
Only votes by project members are considered binding, although everyone
is invited to participate in the discussion (but again, let's not drag
this out please).

Cheers,
Chris
--
Christopher Lenz
/=/ cmlenz at gmx.de
Geoff Longman
2004-01-27 21:59:47 UTC
Permalink
Post by Christopher Lenz
2. Set up a basic website. I propose that we take over the layout from
csseditor.sf.net, which is basically the Eclipse.org layout rewritten
with modern markup (no frames, CSS for layout, dada dada). The content
of the site should be checked into CVS. I propose the module name
'net.sf.wdte-site' for this. The content of the module should mirror
the content of the csseditor group home directory on the shell/web
servers (ie not only the 'htdocs' directory).
Use a cron job to pull the site out of cvs every so often so it's self
deploying.

Looking forward to following your progress!

Geoff

Geoffrey Longman
Intelligent Works Inc.
Christopher Lenz
2004-01-28 13:27:52 UTC
Permalink
Post by Geoff Longman
Post by Christopher Lenz
2. Set up a basic website. I propose that we take over the layout from
csseditor.sf.net, which is basically the Eclipse.org layout rewritten
with modern markup (no frames, CSS for layout, dada dada). The content
of the site should be checked into CVS. I propose the module name
'net.sf.wdte-site' for this. The content of the module should mirror
the content of the csseditor group home directory on the shell/web
servers (ie not only the 'htdocs' directory).
Use a cron job to pull the site out of cvs every so often so it's self
deploying.
Good idea. The web site is now automatically updated from CVS every 6
hours.

--
Christopher Lenz
/=/ cmlenz at gmx.de
Christopher Lenz
2004-01-28 23:22:08 UTC
Permalink
Post by Christopher Lenz
4. Disable the SourceForge Doc Manager. I've never used it, but I
think with the primary documentation in CVS, and other documentation
on the Wiki, we won't need it. We should generally remove/disable any
SF features that we don't use, if only to avoid confusion and
fragmentation.
Done.
Post by Christopher Lenz
5. For the same reason, disable the Task Manager. It will probably
only create confusion, too.
Done.
Post by Christopher Lenz
6. Disable the issue tracker for "Support Requests" and "Patches".
Support requests should be handled in the user forums, and patches
should be either sent to the devel mailing-list, or attached to
existing Bug reports.
Done.
Post by Christopher Lenz
7. Make the issue trackers "Bugs" and "RFE" send mails to a mailing
list on every change. That could be either this list, or a separate
wdte-issues mailing list. I don't care either way, as long as they are
sent somewhere I can subscribe to, and I don't need to "pull" the
information from the website.
Done. Notifications are sent to the mailing list
wdte-***@lists.sourceforge.net. Subscription is optional, although
project members are of course encouraged to "proactively" monitor the
issue tracker. If you can do this without receiving mail notifications,
fine.
Post by Christopher Lenz
8. Finally, I'd like the remove/disable the forums "Features" and
"Volunteering". In general, I think that at the current stage, the
fewer communication channels we have, the better. So I'd even be in
favor of removing/disabling the "Help" forum and keeping only "Open
Discussion" (possibly renamed?).
Done. The only enabled forum for now is "Open Discussion".

I know that this mailing-list has been seeing huge delays in delivering
messages, so your concerns about some of these changes may have gone
unnoticed until now. Let me just say that most of these changes can be
reverted if we decide so. I just thought it would be good to get this
stuff out of the way as quickly as possible and start with the fun part
-- code :-)

Cheers,
Chris
--
Christopher Lenz
/=/ cmlenz at gmx.de
Alex Fitzpatrick
2004-01-29 12:17:08 UTC
Permalink
Post by Christopher Lenz
Post by Christopher Lenz
4. Disable the SourceForge Doc Manager. I've never used it, but I
think with the primary documentation in CVS, and other documentation
on the Wiki, we won't need it. We should generally remove/disable any
SF features that we don't use, if only to avoid confusion and
fragmentation.
Done.
Post by Christopher Lenz
5. For the same reason, disable the Task Manager. It will probably
only create confusion, too.
Done.
Post by Christopher Lenz
6. Disable the issue tracker for "Support Requests" and "Patches".
Support requests should be handled in the user forums, and patches
should be either sent to the devel mailing-list, or attached to
existing Bug reports.
Done.
Post by Christopher Lenz
7. Make the issue trackers "Bugs" and "RFE" send mails to a mailing
list on every change. That could be either this list, or a separate
wdte-issues mailing list. I don't care either way, as long as they
are sent somewhere I can subscribe to, and I don't need to "pull" the
information from the website.
Done. Notifications are sent to the mailing list
project members are of course encouraged to "proactively" monitor the
issue tracker. If you can do this without receiving mail
notifications, fine.
Post by Christopher Lenz
8. Finally, I'd like the remove/disable the forums "Features" and
"Volunteering". In general, I think that at the current stage, the
fewer communication channels we have, the better. So I'd even be in
favor of removing/disabling the "Help" forum and keeping only "Open
Discussion" (possibly renamed?).
Done. The only enabled forum for now is "Open Discussion".
I know that this mailing-list has been seeing huge delays in
delivering messages, so your concerns about some of these changes may
have gone unnoticed until now. Let me just say that most of these
changes can be reverted if we decide so. I just thought it would be
good to get this stuff out of the way as quickly as possible and start
with the fun part -- code :-)
<sigh>

I'm yet to receive the proposal you just acted on... :-) No worries...
s'all good.

With a bit of luck I'll get the JSEditor code into CVS over the weekend.
--
Alex
Christopher Lenz
2004-01-30 17:17:20 UTC
Permalink
Post by Alex Fitzpatrick
Post by Christopher Lenz
I know that this mailing-list has been seeing huge delays in
delivering messages, so your concerns about some of these changes may
have gone unnoticed until now. Let me just say that most of these
changes can be reverted if we decide so. I just thought it would be
good to get this stuff out of the way as quickly as possible and
start with the fun part -- code :-)
<sigh>
I'm yet to receive the proposal you just acted on... :-) No worries...
s'all good.
Okay, but you are aware that you can read it in the archives:

https://sourceforge.net/mailarchive/message.php?msg_id=6973342
Post by Alex Fitzpatrick
With a bit of luck I'll get the JSEditor code into CVS over the weekend.
We still need to discuss how to partition the CVS repository. Let's
work this out in the Wiki:

http://wdte.sourceforge.net/wiki/?page=InitialCodeImportPlan

Cheers,
Chris
--
Christopher Lenz
/=/ cmlenz at gmx.de
Igor Malinin
2004-01-29 15:29:20 UTC
Permalink
Post by Alex Fitzpatrick
With a bit of luck I'll get the JSEditor code into CVS over the weekend.
Fine :-) But please don't commit until we agree on the whole plugin
layout and dependencies. I see one problem with proposed charter:

*Core* Core infrastructure (for example, to provide a Web project nature)
*UI* Common UI infrastructure
*XML* XML editor (XML editor, DTD editor, DTD/Schema validators)
*HTML* Tools for (X)HTML authoring (editor, validator, browser preview)
*CSS* Tools for CSS authoring (editor, validator)
*JS* Tools for JavaScript authoring (editor, interactive shell,
debugging support)

There is a problem with a dependencies... It is expected that global
Core/UI components should provide infrastructure and has no direct
dependencies on the other components... But things like WebNature could
depend on xml/html/css/js valitators etc. We should think about issues
like this as much as possible before committing something...
extension-points are our best friends, but... we all need to think
before coding :)

At least we should agree on a list of _plugins_. Since we all are having
UI only plugins (I could be mistaken though), it is the my proposal for
our migration:

net.sf.wdte.ui - SolarEclipse common UI stuff (others?)
net.sf.wdte.xml.ui - SolarEclipse UI
net.sf.wdte.css.ui - CSSEditor stuff
net.sf.wdte.js.ui - JSEditor stuff

Next our task would be wdte.ui improvemens and adaptation of
CSS/JS/(XML) plugins to use common stuff...

Probably we need a wiki page for development plan...
Christopher Lenz
2004-01-31 09:34:01 UTC
Permalink
Post by Igor Malinin
Post by Alex Fitzpatrick
With a bit of luck I'll get the JSEditor code into CVS over the weekend.
Fine :-) But please don't commit until we agree on the whole plugin
*Core* Core infrastructure (for example, to provide a Web project nature)
*UI* Common UI infrastructure
*XML* XML editor (XML editor, DTD editor, DTD/Schema validators)
*HTML* Tools for (X)HTML authoring (editor, validator, browser preview)
*CSS* Tools for CSS authoring (editor, validator)
*JS* Tools for JavaScript authoring (editor, interactive shell,
debugging support)
There is a problem with a dependencies... It is expected that global
Core/UI components should provide infrastructure and has no direct
dependencies on the other components... But things like WebNature
could depend on xml/html/css/js valitators etc. We should think about
issues like this as much as possible before committing something...
extension-points are our best friends, but... we all need to think
before coding :)
Dependencies between the plugins is an important topic. However, I
don't think it is something that should hold us back from importing the
code.

Another thing that would be nice to resolve, but can also be addressed
later is the target platform. I've been saying this a couple of times,
the CSS editor stuff relies on 3.0 features, so if you checkout the
code with 2.1.2 or whatever, it'll not build. OTOH, when I currently
checkout SolarEclipse, I get various build problems with 3.0M6 (mostly
plugin dependencies). Are you going to migrate the SolarEclipse
contributions to 3.0 before (or directly after) importing into CVS?
Post by Igor Malinin
At least we should agree on a list of _plugins_. Since we all are
having UI only plugins (I could be mistaken though), it is the my
net.sf.wdte.ui - SolarEclipse common UI stuff (others?)
net.sf.wdte.xml.ui - SolarEclipse UI
net.sf.wdte.css.ui - CSSEditor stuff
net.sf.wdte.js.ui - JSEditor stuff
Yeah, this is pretty much what is at the Wiki page, with the addition
of the tests module for css.ui.
Post by Igor Malinin
Next our task would be wdte.ui improvemens and adaptation of
CSS/JS/(XML) plugins to use common stuff...
Which brings us back to the inter-plugin dependencies problem ;-)
Post by Igor Malinin
Probably we need a wiki page for development plan...
Feel free to add anything you want to the Wiki.

Cheers,
Chris
--
Christopher Lenz
/=/ cmlenz at gmx.de
Igor Malinin
2004-01-31 11:12:50 UTC
Permalink
Dependencies between the plugins is an important topic. However, I don't
think it is something that should hold us back from importing the code.
I just wanted to say that we need to make some decisions before
committing... And the mail was actually sent before you created wiki
page... you know - mailing list problems :-P But now it's ok
Another thing that would be nice to resolve, but can also be addressed
later is the target platform. I've been saying this a couple of times,
the CSS editor stuff relies on 3.0 features, so if you checkout the code
with 2.1.2 or whatever, it'll not build. OTOH, when I currently checkout
SolarEclipse, I get various build problems with 3.0M6 (mostly plugin
dependencies). Are you going to migrate the SolarEclipse contributions
to 3.0 before (or directly after) importing into CVS?
SolarEclipse is targeted to Eclipse 2.1. I don't like working on top of
changing framework wery much... But hope with Eclipse 3M7 (should be
released soon as I know) it will stabilize more or less... So, I have no
objections against 3.0 at this time.
Yeah, this is pretty much what is at the Wiki page, with the addition of
the tests module for css.ui.
You made the proposal faster than I written that mail ;)
Post by Igor Malinin
Next our task would be wdte.ui improvemens and adaptation of
CSS/JS/(XML) plugins to use common stuff...
Which brings us back to the inter-plugin dependencies problem ;-)
No. Here is very clear dependencies. wdte.ui depends on nothing and all
wdte.<component>.ui plugins depends on it wdte.ui (as done in
SolarEclipse). Isn't it?
Christopher Lenz
2004-01-31 11:45:10 UTC
Permalink
Post by Igor Malinin
Post by Christopher Lenz
Another thing that would be nice to resolve, but can also be
addressed later is the target platform. I've been saying this a
couple of times, the CSS editor stuff relies on 3.0 features, so if
you checkout the code with 2.1.2 or whatever, it'll not build. OTOH,
when I currently checkout SolarEclipse, I get various build problems
with 3.0M6 (mostly plugin dependencies). Are you going to migrate the
SolarEclipse contributions to 3.0 before (or directly after)
importing into CVS?
SolarEclipse is targeted to Eclipse 2.1. I don't like working on top
of changing framework wery much... But hope with Eclipse 3M7 (should
be released soon as I know) it will stabilize more or less... So, I
have no objections against 3.0 at this time.
Yes, 3.0 being a moving target has created problems for the CSS editor,
so I've just made it work on the latest milestone. There have been
times where it would only compile/run against CVS HEAD of Eclipse :-P

I also hope that breaking changes to Eclipse will settle after the
release of M7.
Post by Igor Malinin
Post by Christopher Lenz
Yeah, this is pretty much what is at the Wiki page, with the addition
of the tests module for css.ui.
You made the proposal faster than I written that mail ;)
Hehe B-)

I really enjoy Wikis for this sort of stuff, and IMHO it makes the
writing of longer, proposal-style documents easier than using email, if
only because you don't need to get it perfect the first time around.
You can always go back and add stuff or fix mistakes.
Post by Igor Malinin
Post by Christopher Lenz
Post by Igor Malinin
Next our task would be wdte.ui improvemens and adaptation of
CSS/JS/(XML) plugins to use common stuff...
Which brings us back to the inter-plugin dependencies problem ;-)
No. Here is very clear dependencies. wdte.ui depends on nothing and
all wdte.<component>.ui plugins depends on it wdte.ui (as done in
SolarEclipse). Isn't it?
Yes, pretty much. What I haven't quite understood yet, is whether a
future project nature defined in net.sf.wdte.core would need to depend
on validators provided by the XML/HTML/CSS plugins (as you've indicated
in your mail). That would of course create a cyclic dependency. I was
thinking that the core plugin defines the project nature, and the other
plugins define project builders that are automatically
configured/enabled for projects that have the web nature set. I guess I
need to read the eclipse corner article about builders and natures
(again).

Cheers,
Chris
--
Christopher Lenz
/=/ cmlenz at gmx.de

Christopher Lenz
2004-01-29 13:13:27 UTC
Permalink
Post by Alex Fitzpatrick
Post by Christopher Lenz
I know that this mailing-list has been seeing huge delays in
delivering messages, so your concerns about some of these changes may
have gone unnoticed until now. Let me just say that most of these
changes can be reverted if we decide so. I just thought it would be
good to get this stuff out of the way as quickly as possible and
start with the fun part -- code :-)
<sigh>
I'm yet to receive the proposal you just acted on... :-) No worries...
s'all good.
Okay, but you are aware that you can read it in the archives:

https://sourceforge.net/mailarchive/message.php?msg_id=6973342
Post by Alex Fitzpatrick
With a bit of luck I'll get the JSEditor code into CVS over the weekend.
We still need to discuss how to partition the CVS repository. Let's
work this out in the Wiki:

http://wdte.sourceforge.net/wiki/?page=InitialCodeImportPlan

Cheers,
Chris
--
Christopher Lenz
/=/ cmlenz at gmx.de
Alex Fitzpatrick
2004-01-29 12:30:45 UTC
Permalink
For those, like me, who get the feeling they've missed something, the
list archives are working:

https://sourceforge.net/mailarchive/forum.php?forum_id=37381

I really don't know how I became a computer scientist... computers
clearly don't like *ME*!
--
Alex
Christopher Lenz
2004-01-27 17:41:21 UTC
Permalink
Post by Christopher Lenz
2. Set up a basic website. I propose that we take over the layout from
csseditor.sf.net, which is basically the Eclipse.org layout rewritten
with modern markup (no frames, CSS for layout, dada dada). The content
of the site should be checked into CVS. I propose the module name
'net.sf.wdte-site' for this. The content of the module should mirror
the content of the csseditor group home directory on the shell/web
servers (ie not only the 'htdocs' directory).
3. Set up a Wiki at http://wdte.sourceforge.net/wiki. I propose to
build on the work I've done for http://csseditor.sourceforge.net/wiki,
which is basically an instance of Tavi with an Eclipse.org-style
template. The Wiki would not replace the primary project
documentation, but rather serve as a whiteboard area where
documentation can be evolved collaboratively.
Assuming general agreement, and knowing everything can be still
changed/reverted, I've gone forward with these two tasks. I set up a
(very) basic web site with a functional although almost empty Wiki.

Cheers,
Chris
--
Christopher Lenz
/=/ cmlenz at gmx.de
Loading...