From: Jeroen De D. <jer...@gm...> - 2012-07-16 18:25:11
|
Hey, During this years Wikimania I discussed the possibility of bundling extensions more closely together with their base software with some fine folks. I think it might be helpful to do this for SMW to some extend, so would like to get your feedback. My proposal is putting SMW and some of it's extensions into a single git repository, and releasing them together. Having important extensions bundled in releases in something that we're already doing with MediaWiki itself since a while :) Advantages for developers: * Less hassle with moving code around as it's in the same repo * We could just require having these extensions from the same release, making compatibility a whole lot easier * Easier to track what others are doing (and having more visibility yourself) * Less of a barrier to working on other parts of the extended SMW codebase, hopefully increasing the amount of people caring about particular components Advantages for users: * Everything is released together, so fewer points at which one needs to upgrade * Guarantee that the extensions in such a release work together nicely * Having a clearer overview of which extensions in this release are stable, beta, experimental, ect (since unmaintained extensions often don't include a notice they are unmaintained) Extensions this could initially include: * SMW * Semantic Result Formats * Semantic Forms * Semantic Compound Queries * Semantic Maps * Semantic Forms Inputs * Semantic Image Input * Semantic Watchlist * Semantic Tasks * Semantic Drilldown * Semantic Internal Objects * and others Anyone against such a change? Suggestions? in any case, we already have a lot of upcoming stuff for SMW 1.8, so if we do this, it's probably better to wait till after that release. Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. -- |
From: Niklas L. <nik...@gm...> - 2012-07-16 18:53:21
|
On 16 July 2012 21:24, Jeroen De Dauw <jer...@gm...> wrote: > My proposal is putting SMW and some of it's extensions into a single git > repository, and releasing them together. Are you suggesting moving all SMW extensions to single repo (on WMF or elsewhere) in addition to the current repos or also deprecating the current repositories? -Niklas -- Niklas Laxström |
From: Jeroen De D. <jer...@gm...> - 2012-07-16 18:55:46
|
Hey, > Are you suggesting moving all SMW extensions to single repo (on WMF or > elsewhere) in addition to the current repos or also deprecating the > current repositories? Moving all of the code into the current SMW repo and deprecating the others. Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. -- |
From: Yaron K. <ya...@wi...> - 2012-07-16 22:18:50
|
Hi Jeroen, I don't think this is a good idea as you've described it. It would certainly increase convenience, for all the reasons you mention. But on the other hand, it would automatically set up a "two-class system" for extensions: those that are grouped in with Semantic MediaWiki, and those that aren't. In some cases, this wouldn't be controversial: I think everyone would agree that Semantic Result Formats is the right extension to use if you want to display semantic data in charts, calendars and the like, and that Semantic Maps is the right extension to use if you want to display it in map form. However, there are various cases where it's not so obvious: for instance, Semantic Watchlist provides notifications about changes to SMW data, but there are two other extensions that, at least in theory, can be used for the same thing. And the Semantic Image Input extension provides a useful input for Semantic Forms, but there are various other extensions that provide just one or two form input types: what are the criteria for deciding which of them get included and which don't? There are some technical issues as well: you didn't include the Validator and Maps extensions in that list, even though they're required by SMW and Semantic Maps extension, respectively; presumably because there are people who would want to install those without installing SMW. But at that point, the whole thing starts to feel a little like a hack. Let me make a counter-suggestion, then: the Semantic Bundle package already does essentially the same thing, of holding a curated group of extensions. Is it possible to make a Git repository for Semantic Bundle, that just holds symbolic links (or whatever the term is) to all of its extensions, in a way that can be downloaded all at once, either via Git or as a tar file? That's essentially what happens with Semantic Bundle already, although the SVN part of it doesn't work that well. Maybe with Git it can function better, given Git's greater flexibility. Tied in with that, maybe it makes sense to upgrade Semantic Bundle to a recommended download solution for SMW, so that, for instance, instructions on how to get it are right on the SMW download page, instead of on a linked page. That seems like a good idea to me, though others might disagree. -Yaron |
From: Daniel S. <da...@da...> - 2012-07-16 23:13:40
Attachments:
smime.p7s
|
I think, before bundeling any extensions, there could be something like a compatibility check. Wordpress for example has something like this, and even allows to install plugins directly. So I think something like a compatibility and dependency check would be better. But on mediawiki side, not especially for SMW. Am 17.07.2012 um 00:18 schrieb Yaron Koren <ya...@wi...>: > Hi Jeroen, > > I don't think this is a good idea as you've described it. It would certainly increase convenience, for all the reasons you mention. But on the other hand, it would automatically set up a "two-class system" for extensions: those that are grouped in with Semantic MediaWiki, and those that aren't. In some cases, this wouldn't be controversial: I think everyone would agree that Semantic Result Formats is the right extension to use if you want to display semantic data in charts, calendars and the like, and that Semantic Maps is the right extension to use if you want to display it in map form. However, there are various cases where it's not so obvious: for instance, Semantic Watchlist provides notifications about changes to SMW data, but there are two other extensions that, at least in theory, can be used for the same thing. And the Semantic Image Input extension provides a useful input for Semantic Forms, but there are various other extensions that provide just one or two form input types: what are the criteria for deciding which of them get included and which don't? > > There are some technical issues as well: you didn't include the Validator and Maps extensions in that list, even though they're required by SMW and Semantic Maps extension, respectively; presumably because there are people who would want to install those without installing SMW. But at that point, the whole thing starts to feel a little like a hack. > > Let me make a counter-suggestion, then: the Semantic Bundle package already does essentially the same thing, of holding a curated group of extensions. Is it possible to make a Git repository for Semantic Bundle, that just holds symbolic links (or whatever the term is) to all of its extensions, in a way that can be downloaded all at once, either via Git or as a tar file? That's essentially what happens with Semantic Bundle already, although the SVN part of it doesn't work that well. Maybe with Git it can function better, given Git's greater flexibility. > > Tied in with that, maybe it makes sense to upgrade Semantic Bundle to a recommended download solution for SMW, so that, for instance, instructions on how to get it are right on the SMW download page, instead of on a linked page. That seems like a good idea to me, though others might disagree. > > -Yaron > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Semediawiki-devel mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel |
From: Markus K. <ma...@se...> - 2012-07-17 11:15:09
|
Hi, as I understand Jeroen, this is mainly a proposal about code maintenance, not about deployment. Somebody who pulls the whole repo will have the code for all extensions that are in there, but that does not mean that they are all enabled (or even mutually compatible). It seems to me that a joint repository would not work very different for people who run wikis with code from git (development or not). You still need many individual pull commands, since you need many parallel directories that are not in a joint super-directory that is in the SMW-repository (the MW extension directory is part of MW's repository). I suppose that you cannot pull many extension directories into ./extensions with one git command in this case. So what people would do is still to check out each extension that they want to use individually. Similarly, we would not automatically have a different distribution than we have now. Maybe work on SemanticBundle would be simplified by a joint repo, but the SMW package will look as before. So there is no change for the final user. If this is all true, the proposal is mainly a decision about simplifying some of our development processes. I would support this. A possible problem that I can see is with automated testing: if some of the other extensions break due to some SMW change, then the maintainers of these extensions need to fix it; they may not do this, or at least not do this immediately. We cannot quickly move extensions out of the joint repo, so this might be a nuisance once automated tests are enabled on pushs (SMW changes will not get auto-verified). Is that an issue? Markus On 16/07/12 23:48, Daniel Schuba wrote: > I think, before bundeling any extensions, there could be something like a compatibility check. Wordpress for example has something like this, and even allows to install plugins directly. So I think something like a compatibility and dependency check would be better. But on mediawiki side, not especially for SMW. > > Am 17.07.2012 um 00:18 schrieb Yaron Koren <ya...@wi...>: > >> Hi Jeroen, >> >> I don't think this is a good idea as you've described it. It would certainly increase convenience, for all the reasons you mention. But on the other hand, it would automatically set up a "two-class system" for extensions: those that are grouped in with Semantic MediaWiki, and those that aren't. In some cases, this wouldn't be controversial: I think everyone would agree that Semantic Result Formats is the right extension to use if you want to display semantic data in charts, calendars and the like, and that Semantic Maps is the right extension to use if you want to display it in map form. However, there are various cases where it's not so obvious: for instance, Semantic Watchlist provides notifications about changes to SMW data, but there are two other extensions that, at least in theory, can be used for the same thing. And the Semantic Image Input extension provides a useful input for Semantic Forms, but there are various other extensions that provide just one or two form input typ es: what are the criteria for deciding which of them get included and which don't? >> >> There are some technical issues as well: you didn't include the Validator and Maps extensions in that list, even though they're required by SMW and Semantic Maps extension, respectively; presumably because there are people who would want to install those without installing SMW. But at that point, the whole thing starts to feel a little like a hack. >> >> Let me make a counter-suggestion, then: the Semantic Bundle package already does essentially the same thing, of holding a curated group of extensions. Is it possible to make a Git repository for Semantic Bundle, that just holds symbolic links (or whatever the term is) to all of its extensions, in a way that can be downloaded all at once, either via Git or as a tar file? That's essentially what happens with Semantic Bundle already, although the SVN part of it doesn't work that well. Maybe with Git it can function better, given Git's greater flexibility. >> >> Tied in with that, maybe it makes sense to upgrade Semantic Bundle to a recommended download solution for SMW, so that, for instance, instructions on how to get it are right on the SMW download page, instead of on a linked page. That seems like a good idea to me, though others might disagree. >> >> -Yaron >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> Semediawiki-devel mailing list >> Sem...@li... >> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel >> >> >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> >> >> _______________________________________________ >> Semediawiki-devel mailing list >> Sem...@li... >> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel |
From: Yaron K. <ya...@gm...> - 2012-07-17 14:23:39
|
Hi, I still think that this is a bad idea, due to the fact that it sets up a two-tier system of extensions, with somewhat arbitrary criteria over what gets included. The only extension that I think can be included without any controversy or complications is Semantic Result Formats. Any other extension either has additional requirements, or has spinoff extensions, or has "competitors", or is not widely in use, etc. I admit, though, that I don't really see the advantage of putting more than one extension in the same repository in the first place, if it doesn't make download easier and it doesn't enforce any sort of compatibility. Whatever the advantage is, is it enough to outweigh the negatives? -Yaron On Jul 17, 2012 7:15 AM, "Markus Krötzsch" <ma...@se...> wrote: > Hi, > > as I understand Jeroen, this is mainly a proposal about code > maintenance, not about deployment. Somebody who pulls the whole repo > will have the code for all extensions that are in there, but that does > not mean that they are all enabled (or even mutually compatible). > > It seems to me that a joint repository would not work very different for > people who run wikis with code from git (development or not). You still > need many individual pull commands, since you need many parallel > directories that are not in a joint super-directory that is in the > SMW-repository (the MW extension directory is part of MW's repository). > I suppose that you cannot pull many extension directories into > ./extensions with one git command in this case. So what people would do > is still to check out each extension that they want to use individually. > > Similarly, we would not automatically have a different distribution than > we have now. Maybe work on SemanticBundle would be simplified by a joint > repo, but the SMW package will look as before. So there is no change for > the final user. > > If this is all true, the proposal is mainly a decision about simplifying > some of our development processes. I would support this. > > A possible problem that I can see is with automated testing: if some of > the other extensions break due to some SMW change, then the maintainers > of these extensions need to fix it; they may not do this, or at least > not do this immediately. We cannot quickly move extensions out of the > joint repo, so this might be a nuisance once automated tests are enabled > on pushs (SMW changes will not get auto-verified). Is that an issue? > > Markus > > > On 16/07/12 23:48, Daniel Schuba wrote: > > I think, before bundeling any extensions, there could be something like > a compatibility check. Wordpress for example has something like this, and > even allows to install plugins directly. So I think something like a > compatibility and dependency check would be better. But on mediawiki side, > not especially for SMW. > > > > Am 17.07.2012 um 00:18 schrieb Yaron Koren <ya...@wi...>: > > > >> Hi Jeroen, > >> > >> I don't think this is a good idea as you've described it. It would > certainly increase convenience, for all the reasons you mention. But on the > other hand, it would automatically set up a "two-class system" for > extensions: those that are grouped in with Semantic MediaWiki, and those > that aren't. In some cases, this wouldn't be controversial: I think > everyone would agree that Semantic Result Formats is the right extension to > use if you want to display semantic data in charts, calendars and the like, > and that Semantic Maps is the right extension to use if you want to display > it in map form. However, there are various cases where it's not so obvious: > for instance, Semantic Watchlist provides notifications about changes to > SMW data, but there are two other extensions that, at least in theory, can > be used for the same thing. And the Semantic Image Input extension provides > a useful input for Semantic Forms, but there are various other extensions > that provide just one or two form input typ > es: what are the criteria for deciding which of them get included and > which don't? > >> > >> There are some technical issues as well: you didn't include the > Validator and Maps extensions in that list, even though they're required by > SMW and Semantic Maps extension, respectively; presumably because there are > people who would want to install those without installing SMW. But at that > point, the whole thing starts to feel a little like a hack. > >> > >> Let me make a counter-suggestion, then: the Semantic Bundle package > already does essentially the same thing, of holding a curated group of > extensions. Is it possible to make a Git repository for Semantic Bundle, > that just holds symbolic links (or whatever the term is) to all of its > extensions, in a way that can be downloaded all at once, either via Git or > as a tar file? That's essentially what happens with Semantic Bundle > already, although the SVN part of it doesn't work that well. Maybe with Git > it can function better, given Git's greater flexibility. > >> > >> Tied in with that, maybe it makes sense to upgrade Semantic Bundle to a > recommended download solution for SMW, so that, for instance, instructions > on how to get it are right on the SMW download page, instead of on a linked > page. That seems like a good idea to me, though others might disagree. > >> > >> -Yaron > >> > ------------------------------------------------------------------------------ > >> Live Security Virtual Conference > >> Exclusive live event will cover all the ways today's security and > >> threat landscape has changed and how IT managers can respond. > Discussions > >> will include endpoint security, mobile security and the latest in > malware > >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > >> _______________________________________________ > >> Semediawiki-devel mailing list > >> Sem...@li... > >> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > >> > >> > >> > ------------------------------------------------------------------------------ > >> Live Security Virtual Conference > >> Exclusive live event will cover all the ways today's security and > >> threat landscape has changed and how IT managers can respond. > Discussions > >> will include endpoint security, mobile security and the latest in > malware > >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > >> > >> > >> _______________________________________________ > >> Semediawiki-devel mailing list > >> Sem...@li... > >> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Semediawiki-devel mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > |
From: Jeroen De D. <jer...@gm...> - 2012-07-18 15:02:39
|
Hey, > as I understand Jeroen, this is mainly a proposal about code > maintenance, not about deployment. It's about both. > I still think that this is a bad idea, due to the fact that it sets up a > two-tier system of extensions, with somewhat arbitrary criteria over what gets included First of all I'd like to point out that MediaWiki itself already has this, and no one is complaining there, nor has it created any two-class system. The criteria would not be arbitrary - pretty much all code that developers want to put in there could go in, only when there are serious issues with it, it can't. If something ends up getting unmaintained or unstable, it would be appropriately marked as such, and only at a point where it starts causing problems somehow it would get thrown out. The people working on the code / maintaining it would decide on this, and any developer could join this process. It'd be pretty much the same as what we have now for code changes to SMW itself, but then on extension level. And in case of extensions, two competing extensions can actually both be in the repository, where two competing pieces of code obviously could not both go into SMW :) > There are some technical issues as well: you didn't include the Validator and Maps extensions > in that list, even though they're required by SMW and Semantic Maps extension, respectively How is this an issue? They are not in the same repo now and they would not be then. The workflow for including them would remain the same. Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. -- |
From: Yaron K. <ya...@wi...> - 2012-07-18 20:03:58
|
Hi Jeroen, Ah, I was confused - your specific listing of extensions at the beginning made me think that this was going to be a curated list of extensions, in the manner of the Semantic Bundle. But if essentially any SMW-based extension can get added, then I don't see what the big benefit is. It seems very difficult to make sure that an arbitrary number of extensions can all work together when it's time to do a release - at the very least, it would take a lot of time and coordination. And even if you accomplish that, there are still other extensions, like Validator and Maps, that would require coordinating outside of the SMW repository. Instead of a centralized solution, why not have a distributed approach, where various repositories, like for Semantic Bundle and anything else, can have symbolic links to the right version/tag/branch of each extension, so that downloading that package will always get you a set of extensions that work with another? (Is such a thing even possible in Git? I hope so, but I have no idea.) But perhaps I'm missing something in this whole thing. -Yaron On Wed, Jul 18, 2012 at 11:02 AM, Jeroen De Dauw <jer...@gm...>wrote: > Hey, > > > > as I understand Jeroen, this is mainly a proposal about code > > maintenance, not about deployment. > > It's about both. > > > > I still think that this is a bad idea, due to the fact that it sets up a > > two-tier system of extensions, with somewhat arbitrary criteria over > what gets included > > First of all I'd like to point out that MediaWiki itself already has this, > and no one is complaining there, > nor has it created any two-class system. > > The criteria would not be arbitrary - pretty much all code that developers > want to put in there could go in, > only when there are serious issues with it, it can't. If something ends up > getting unmaintained or unstable, > it would be appropriately marked as such, and only at a point where it > starts causing problems somehow > it would get thrown out. The people working on the code / maintaining it > would decide on this, and any > developer could join this process. It'd be pretty much the same as what we > have now for code changes > to SMW itself, but then on extension level. > > And in case of extensions, two competing extensions can actually both be > in the repository, where > two competing pieces of code obviously could not both go into SMW :) > > > > There are some technical issues as well: you didn't include the > Validator and Maps extensions > > in that list, even though they're required by SMW and Semantic Maps > extension, respectively > > How is this an issue? They are not in the same repo now and they would not > be then. The workflow > for including them would remain the same. > > > Cheers > > -- > Jeroen De Dauw > http://www.bn2vs.com > Don't panic. Don't be evil. > -- > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Semediawiki-devel mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > > -- WikiWorks · MediaWiki Consulting · http://wikiworks.com |
From: Jeroen De D. <jer...@gm...> - 2012-07-18 20:27:54
|
Hey, > But if essentially any SMW-based extension can get added, then I don't see what the big benefit is. > ... > have symbolic links to the right version/tag/branch of each extension > ... > But perhaps I'm missing something in this whole thing. I think so - if you go back to my initial list of advantaged you'll see that they are not all obtained with the Semantic Bundle approach (or having links to git tags, which is essentially the same). > at the very least, it would take a lot of time and coordination Yes, it forces the maintainers of the extensions to manage their code properly or have it end up being disabled by default (if it was not already) and tagged as unstable/unmaintained/foobar. Having things work will not be more difficult then it's now, people will just be more incentivezed to have their code working with the latest SMW release. If you consider that everything is released together, it's actually easier for maintainers to have their stuff working property due to much simpler compatibility requirements. > And even if you accomplish that, there are still other extensions, like Validator > and Maps, that would require coordinating outside of the SMW repository. I shall repeat: this is our current situation. Yes, we'll still need this coordination. I fail to see how the proposed change has any negative impact on this. The only (little) impact I can see it have is this coordination being simpler since you'll only need to check compatibility between these extensions and (extended) SMW rather then against all individual components. Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. -- |
From: Markus K. <ma...@se...> - 2012-07-19 09:40:22
|
My two technical questions remained open, and I have a third one: (1) Would it even be possible to deploy many MW extensions that are in different top-level directories in one git repo without pulling subdirectories from the repo individually? If not, then the deployment of git-code on sites would be essentially the same as before. (2) Won't there be inconveniences with automated testing if some extensions are not compatible with SMW changes (yet)? (3) Who will be able to approve (or even self-approve) code in gerrit? Could I commit to every extension without review then? Can others do the same for SMW? I agree with all the development advantages, esp. making it easier for people to contribute across extensions. It would also help with sharing work during code review. I am not convinced about the compatibility thing as being a real advantage. If we want to make releases at the same time (as one big snapshot of the repo), then we will have to wait with releasing SMW until other extensions have caught up. This would lead to delays, and extra work for the person who does the release. We would also need some process to check if an extension is still compatible to know if it needs to be tagged as unstable/unmaintained etc. Extension developers would not be happy if we flag their code as unmaintained in a new release just because they did not react to an email for a week or so. Somebody would need to be responsible for this. Having improved compatibility would be great, but I think this needs more than just copying files to one git repo. This does not speak against Jeroen's suggestion, it just means that we will not automatically get all the advantages right away by simply copying files into a joint repo. Markus On 18/07/12 21:27, Jeroen De Dauw wrote: > Hey, > > > But if essentially any SMW-based extension can get added, then I > don't see what the big benefit is. > > ... > > have symbolic links to the right version/tag/branch of each extension > > ... > > But perhaps I'm missing something in this whole thing. > > I think so - if you go back to my initial list of advantaged you'll see > that they are not all obtained with the Semantic Bundle approach (or > having links to git tags, which is essentially the same). > > > at the very least, it would take a lot of time and coordination > > Yes, it forces the maintainers of the extensions to manage their code > properly or have it end up being disabled by default (if it was not > already) and tagged as unstable/unmaintained/foobar. Having things work > will not be more difficult then it's now, people will just be more > incentivezed to have their code working with the latest SMW release. If > you consider that everything is released together, it's actually easier > for maintainers to have their stuff working property due to much simpler > compatibility requirements. > > > And even if you accomplish that, there are still other extensions, > like Validator > > and Maps, that would require coordinating outside of the SMW repository. > > I shall repeat: this is our current situation. Yes, we'll still need > this coordination. I fail to see how the proposed change has any > negative impact on this. The only (little) impact I can see it have is > this coordination being simpler since you'll only need to check > compatibility between these extensions and (extended) SMW rather then > against all individual components. > > Cheers > > -- > Jeroen De Dauw > http://www.bn2vs.com > Don't panic. Don't be evil. > -- > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > > > _______________________________________________ > Semediawiki-devel mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > |
From: Jeroen De D. <jer...@gm...> - 2012-07-19 11:38:32
|
Hey, > Would it even be possible to deploy many MW extensions that are in different top-level directories in one git repo without pulling subdirectories from the repo individually? Yes, you can get the whole repo in one go. So it'd be easier to get the extensions, although this really is just a very minor advantage. > Won't there be inconveniences with automated testing if some extensions are not compatible with SMW changes (yet)? I suspect not much, and it's probably cancelled out by the convenience of having them together when you actually want to test compatibility. But before we worry to much about this, let's first write some actual tests? :D Just to be certain there is no confusion: I'm proposing on having all these extensions in a single git repo, and not have primary or secondary copies in random other repos. > Who will be able to approve (or even self-approve) code in gerrit? Could I commit to every extension without review then? Can others do the same for SMW? Since the gerrit rights are rep repo (at least AFAIK), there would be no distinction between SMW and the bundled extensions. I suggest to be liberal with (non-self-approve) merge rights and hand them out to anyone who requests them unless there is good reason not do. If they break stuff, the rights can always be revoked. And even while this would be liberal (definitly more so then what we have now), I'd be more restricted then what we had just a few months ago on SVN, where anyone with extension commit access could push stuff directly into SMW. > I do not see the advantage of having SMW > extensions maintained outside the normal MW git repo Me neither. Did not suggest using an alternate repo. > by installing from this repo the user would not be done, i.e. they would still need to manually get e.g. Validator. Please read previous mails - I replied to this twice already. > To simplify deployment and ensure compatibility: What about setting up a PEAR server? This tackles a subset of the problems my proposal covers and comes from a completely different angle. Having such a things would be great, I even did a GSoC project towards it in 2010, but it's very much non-trivial to get it right. > They already are in one repo, aren't they? No. Each extension is in it's own git repo. > Also, moving code from one extension to another is probably not the > most common thing to do. I know of quite some code that got moved around. Sometimes you start writing a feature somewhere and then want to split it of in it's own extension. Or you have an experimental extension that stabilizes and can then just be added as a feature in another one. But yes, it's not something you do every day. I am consciously avoiding doing it now since the code is in different repo's, as moving stuff would appear as code magically disappearing from one repo and appearing in another, without any links or version history between the two. >> * Easier to track what others are doing (and having more visibility yourself) > How so? Can you give me a list of all changes that got pushed to any SMW or Semantic* repo recently? Can you give me a list of all changes pending review on gerrit? Can you give me a list of all branches? None of those you can trivially do for multiple repos, they'd all involve writing some script that does various queries to gerrit. All of those you can trivially do for a single git repo. Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. -- |
From: Stephan G. <s7...@gm...> - 2012-07-19 10:22:48
|
Hi, I am sceptical about this. I do not see the advantage of having SMW extensions maintained outside the normal MW git repo. It creates yet another system to be aware of. On top of it, by installing from this repo the user would not be done, i.e. they would still need to manually get e.g. Validator. By the way, on the point of forcing developers to maintain their code: It might help if SMW's interface would not break all the time. Just saying. To simplify deployment and ensure compatibility: What about setting up a PEAR server? Then wiki admins could just install/update Semantic Maps and would get compatible versions of Validator, Maps, and SMW installed automatically. On 16 July 2012 20:24, Jeroen De Dauw <jer...@gm...> wrote: > Advantages for developers: > > * Less hassle with moving code around as it's in the same repo They already are in one repo, aren't they? Also, moving code from one extension to another is probably not the most common thing to do. > * We could just require having these extensions from the same release, > making compatibility a whole lot easier What's the difference with Semantic Bundle? > * Easier to track what others are doing (and having more visibility > yourself) How so? > * Less of a barrier to working on other parts of the extended SMW codebase, > hopefully increasing the amount of people caring about particular components How so? > Advantages for users: > > * Everything is released together, so fewer points at which one needs to > upgrade > * Guarantee that the extensions in such a release work together nicely > * Having a clearer overview of which extensions in this release are stable, > beta, experimental, ect (since unmaintained extensions often don't include a > notice they are unmaintained) Again, where is the difference with Semantic Bundle? Cheers, Stephan |
From: Markus K. <ma...@se...> - 2012-07-19 12:53:28
|
On 19/07/12 11:22, Stephan Gambke wrote: > Hi, > > I am sceptical about this. I do not see the advantage of having SMW > extensions maintained outside the normal MW git repo. It creates yet > another system to be aware of. On top of it, by installing from this > repo the user would not be done, i.e. they would still need to > manually get e.g. Validator. Jeroen did not suggest to move outside of MW git. The idea is just to combine several closely related repos into one. > > By the way, on the point of forcing developers to maintain their code: > It might help if SMW's interface would not break all the time. Just > saying. > Suggestions are always welcome. I think the last big change to any API in SMW was the introduction of DI classes over a year ago. Compatibility classes and extensive emails have been provided to simplify the transition. Deprecated methods are marked as such for at least one release cycle until being removed. So what's breaking all the time for you? > To simplify deployment and ensure compatibility: What about setting up > a PEAR server? Then wiki admins could just install/update Semantic > Maps and would get compatible versions of Validator, Maps, and SMW > installed automatically. That would be nice and require some work. Like so many things. Not sure if this is of sufficient priority to anybody to get done. But we can provide some infrastructure if somebody wants to do it. OTOH, this might be an activity that would be just as relevant for other MW extension, so one could also ask around the MW lists for volunteers and host the server at WMF. Markus > > > > On 16 July 2012 20:24, Jeroen De Dauw <jer...@gm...> wrote: >> Advantages for developers: >> >> * Less hassle with moving code around as it's in the same repo > > They already are in one repo, aren't they? > Also, moving code from one extension to another is probably not the > most common thing to do. > > >> * We could just require having these extensions from the same release, >> making compatibility a whole lot easier > > What's the difference with Semantic Bundle? > > >> * Easier to track what others are doing (and having more visibility >> yourself) > > How so? > > >> * Less of a barrier to working on other parts of the extended SMW codebase, >> hopefully increasing the amount of people caring about particular components > > How so? > > >> Advantages for users: >> >> * Everything is released together, so fewer points at which one needs to >> upgrade >> * Guarantee that the extensions in such a release work together nicely >> * Having a clearer overview of which extensions in this release are stable, >> beta, experimental, ect (since unmaintained extensions often don't include a >> notice they are unmaintained) > > Again, where is the difference with Semantic Bundle? > > > > Cheers, > Stephan > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Semediawiki-devel mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > |
From: Stephan G. <s7...@gm...> - 2012-07-19 20:03:17
|
Hi. On 19 July 2012 14:53, Markus Krötzsch <ma...@se...> wrote: > Jeroen did not suggest to move outside of MW git. The idea is just to > combine several closely related repos into one. Yes, but would it be a _normal_ repo? How would the workflow be? Now you clone MW, then you get into the extensions dir and clone the extensions. Would this still work? How would you pull only some extensions of the package? Would this even be possible? If at some point an extension is deemed to be unmaintained, would it just be dropped from the HEAD version? Exported to its own repo again? I admit, I am always a bit suspicious of "package deals". I would rather decide myself, which extensions I need. But that is of course a personal preference. >> By the way, on the point of forcing developers to maintain their code: >> It might help if SMW's interface would not break all the time. Just >> saying. >> > > Suggestions are always welcome. I think the last big change to any API in > SMW was the introduction of DI classes over a year ago. Compatibility > classes and extensive emails have been provided to simplify the transition. And this was done very well, indeed. You did a great job there. The problem are not the big structural changes, but the small insignificant. One case I had lately was a function that just disappeared from the codebase (SMW_QueryPrinter.php::getValidatorParameters). Another example is a case where a function got introduced in 1.6 (I think) only to be marked as deprecated in 1.7 or 1.8. (And no, I do not remember which function that was.) Anyway, this got to much attention already. I never meant to discuss it in that much depth. Just wanted to point out that it is not always easy top keep up with the development of SMW. And I am not sure putting extensions in a common repo would improve this. Cheers, Stephan |
From: Jeroen De D. <jer...@gm...> - 2012-07-19 20:21:00
|
Hey, > One case I had lately was a function that just disappeared from the > codebase (SMW_QueryPrinter.php::getValidatorParameters). Looks like that's my fault - that function is now obsolete. I can add it back in if that really helps you. Probably removed it figuring no one was using it anyway. Would have spotted this was not the case if I had your extension checked out - one more point for my proposal :) > I admit, I am always a bit suspicious of "package deals". I would > rather decide myself, which extensions I need. Having it in one repo would not force you in any way to use any of the extensions in there. Initially I suggest only having SMW on by default, and only adding other to the list of "default on" if there is no controversy over it. Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. -- |
From: Stephan G. <s7...@gm...> - 2012-07-19 20:31:25
|
Hi, On 19 July 2012 22:20, Jeroen De Dauw <jer...@gm...> wrote: >> One case I had lately was a function that just disappeared from the >> codebase (SMW_QueryPrinter.php::getValidatorParameters). > > Looks like that's my fault - that function is now obsolete. I can add it > back in if that really helps you. Probably removed it figuring no one was > using it anyway. Would have spotted this was not the case if I had your > extension checked out - one more point for my proposal :) No need to have it back, found another solution. >> I admit, I am always a bit suspicious of "package deals". I would >> rather decide myself, which extensions I need. > > Having it in one repo would not force you in any way to use any of the > extensions in there. Initially I suggest only having SMW on by default, and > only adding other to the list of "default on" if there is no controversy > over it. Having to sift through all the extensions downloded with the package and now cluttering my extensions dir is already to much for me. But as I said, this is my personal pet peeve. Others may not have that problem. Hmm, would it be possible to have a combined approach where extensions are still maintained in separate repos and are pulled into a combined repo regularly? This would still not allow to transfer code between extensions, but it should allow creating lists of changes on several extensions and it would leave the user with the choice to pull extensions separately or combined in a package. Cheers, Stephan |
From: Jeroen De D. <jer...@gm...> - 2012-07-19 20:38:52
|
Hey, > Having to sift through all the extensions downloded with the package and now cluttering my extensions dir You could always just get only those extensions you want from the release distribution. And when using git, I'm sure there is a way to only have some dirs visible to you :) > would it be possible to have a combined approach where extensions > are still maintained in separate repos and are pulled into a combined repo regularly? Yeah, but it'd not provide the development benefits I want to gain with this change at all. You'd just be able to get aggregated statistics more easily. Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. -- |