[xwiki-devs] [Proposal] Remove xwiki-debug-eclipse git repository + rules for git repositories
17 Apr
2011
17 Apr
'11
9:14 p.m.
Hi devs,
I see you've added a new git repo called xwiki-debug-eclipse. I don't quite agree
with it.
I'd like to propose to move it as a tool (since that's what it is - it's a
build/debug tool) inside xwiki-enterprise/ (https://github.com/xwiki/xwiki-enterprise)
I'd also like to propose that:
1) we always vote when creating git repositories
2) we agree that as a rule git repositories should match top level xwiki projects (as we
used to have for svn). I don't see a need for more git repositories. If you see valid
use cases other than when creating top level projects please let me know here. I propose
this rule to be the default but of course it could be violated (with a vote mail, see 1))
if we find a valid use case.
Thanks
-Vincent
17 Apr
17 Apr
9:16 p.m.
New subject: [xwiki-devs] [Proposal] Remove xwiki-debug-eclipse git repository + rules for git repositories
Note that the previous name of this module had XEM in the name so it's possible
it's related to XEM. If so, I'd propose it to be moved to xwiki-manager/ as a
tool.
Thanks
-Vincent
On Apr 17, 2011, at 9:14 PM, Vincent Massol wrote:
Hi devs,
I see you've added a new git repo called xwiki-debug-eclipse. I don't quite agree
with it.
I'd like to propose to move it as a tool (since that's what it is - it's a
build/debug tool) inside xwiki-enterprise/ (https://github.com/xwiki/xwiki-enterprise)
I'd also like to propose that:
1) we always vote when creating git repositories
2) we agree that as a rule git repositories should match top level xwiki projects (as we
used to have for svn). I don't see a need for more git repositories. If you see valid
use cases other than when creating top level projects please let me know here. I propose
this rule to be the default but of course it could be violated (with a vote mail, see 1))
if we find a valid use case.
Thanks
-Vincent
18 Apr
18 Apr
7:18 a.m.
+1
Could be also moved to xwiki-platform-tools inside xwiki-platform.
Thanks,
Marius
On 04/17/2011 10:14 PM, Vincent Massol wrote:
Hi devs,
I see you've added a new git repo called xwiki-debug-eclipse. I don't quite agree
with it.
I'd like to propose to move it as a tool (since that's what it is - it's a
build/debug tool) inside xwiki-enterprise/ (https://github.com/xwiki/xwiki-enterprise)
I'd also like to propose that:
1) we always vote when creating git repositories
2) we agree that as a rule git repositories should match top level xwiki projects (as we
used to have for svn). I don't see a need for more git repositories. If you see valid
use cases other than when creating top level projects please let me know here. I propose
this rule to be the default but of course it could be violated (with a vote mail, see 1))
if we find a valid use case.
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
8:41 a.m.
On 04/17/2011 09:14 PM, Vincent Massol wrote:
Hi devs,
I see you've added a new git repo called xwiki-debug-eclipse. I don't quite agree
with it.
I'd like to propose to move it as a tool (since that's what it is - it's a
build/debug tool) inside xwiki-enterprise/ (https://github.com/xwiki/xwiki-enterprise)
I don't think I agree. Unlike other tools, which contribute to the
project (either as resources that end up in the distribution, or as
tools used while building the distribution), this does not produce
anything. It is not supposed to be compiled or built, it is just a
static set of files and symlinks supposed to ease the debugging of
various parts of XEM.
One disadvantage of this "tool" being unreleasable is that the correct
version needed for debugging a certain version of XE/XEM can't be easily
discovered. A way around this is to include it as a submodule of
xwiki-trunks or xwiki-enterprise, so whenever a tag is created (and more
generally for each commit), the right version of the debug project will
be included in the tag as well.
I'd also like to propose that:
1) we always vote when creating git repositories
OK.
2) we agree that as a rule git repositories should
match top level xwiki projects (as we used to have for svn). I don't see a need for
more git repositories. If you see valid use cases other than when creating top level
projects please let me know here. I propose this rule to be the default but of course it
could be violated (with a vote mail, see 1)) if we find a valid use case.
Not convinced. Let's look at what others are doing, and try to determine
what is a best practice (or at least most often used) on github.
For example, https://github.com/jenkinsci has almost 500 repositories.
so they don't seem to be that reluctant to creating repositories at will.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
10:46 a.m.
New subject: [xwiki-devs] [Proposal] Remove xwiki-debug-eclipse git repository + rules for git repositories
On Apr 18, 2011, at 8:41 AM, Sergiu Dumitriu wrote:
On 04/17/2011 09:14 PM, Vincent Massol wrote:
Actually I was the one who introduced the notion of tools and the idea was a category of
modules for things that don't produce anything at runtime (helpers to produce runtime
code but not runtime code themselves).
Then we started adding stuff such as jetty resources, license, configuration resources,
root webapp to it (and even foxwiki which has nothing to do there), which contribute
runtime things.
Personally I'd be fine to separate again runtime resources from non runtime resources
since I don't consider any of the runtime resources as "tools". IMO
that's a wrong location for them.
OTOH the xwiki-debug-eclipse module is a perfect tool and doesn't contribute anything
runtime.
Hi devs,
I see you've added a new git repo called xwiki-debug-eclipse. I don't quite agree
with it.
I'd like to propose to move it as a tool (since that's what it is - it's a
build/debug tool) inside xwiki-enterprise/ (https://github.com/xwiki/xwiki-enterprise)
I don't think I agree. Unlike other tools, which contribute to the
project (either as resources that end up in the distribution, or as
tools used while building the distribution), this does not produce
anything. It is not supposed to be compiled or built, it is just a
static set of files and symlinks supposed to ease the debugging of
various parts of XEM. One disadvantage of this "tool" being
unreleasable is that the correct
version needed for debugging a certain version of XE/XEM can't be easily
discovered. A way around this is to include it as a submodule of
xwiki-trunks or xwiki-enterprise, so whenever a tag is created (and more
generally for each commit), the right version of the debug project will
be included in the tag as well.
And that's really awkard and bad. try filtering them out on the github page and
you'll see what I mean ;)
GitHub is lacking a way to organize the list of repositories.
But in any case that's not really my point. My point is more to have a consistency in
our git repositories and to continue what we have so far till we find it's not good
anymore. What we had so far in SVN was that top level projects had top level directories.
IMO it's a good starting point for our git repository rule too FTM (till we find we
need something different).
Thanks
-Vincent
I'd also like to propose that:
1) we always vote when creating git repositories
OK.
2) we agree that as a rule git repositories
should match top level xwiki projects (as we used to have for svn). I don't see a need
for more git repositories. If you see valid use cases other than when creating top level
projects please let me know here. I propose this rule to be the default but of course it
could be violated (with a vote mail, see 1)) if we find a valid use case.
Not convinced. Let's look at what others are doing, and try to determine
what is a best practice (or at least most often used) on github.
For example, https://github.com/jenkinsci has almost 500 repositories.
so they don't seem to be that reluctant to creating repositories at will.
5030
days inactive
5031
days old
4 comments
3 participants
participants (3)
-
Marius Dumitru Florea -
Sergiu Dumitriu -
Vincent Massol