GSoC 2023 Proposal

Help / Discuss
#1

Hey Guys,
I would love to improve upon my GSoC 2022 project. Would also like to know if the XWiki committers were interested in officially supporting the XWiki snap package.

Currently, it has :

  • 1700+ monthly installs
  • 55+ weakly active users
  • active in 21 different territories
    teroteries_xwiki

I would like to propose the following tasks as my GSoC 2023 project -

  • to get the XWiki Snap package officially supported by XWiki.
  • Creating the required documentation for the snap package to be supported officially
  • Integrating it into the release process using automation ( currently the XWiki snap is fairly easy to update (example). This process could be easily automated .)
  • expanding the snap scope to include other architectures like arm64, armhf, ppc64el, and s390x. (currently, only an amd64 architecture-based machine can run the snap package )
  • Any other task required for the snap package to be officially supported.

If time permits I would also like to publish XWiki to the Arch User Repository (AUR) .

Interested in hearing your opinion on the following.
Thank You :slight_smile:

1 Like
#2

Hi @Pol,

Yes, I feel it would be nice to finish the last things that are preventing to push the snap package as first citizen distribution of XWiki which I think are mainly:

  • improve how data files are handled as I feel there is way too much right now (the entire XWiki WAR) in what is supposed to contain data and configuration, and it could make upgrades quite a pain
  • integrate it to the release process, ideally fully automated as part of the release build

That would be a different GSOC project proposal, probably.

#3

hey @tmortagne ,
would love to make the snap package as a first citizen distribution of XWiki and maintain it further :slight_smile:

could you suggest certain tips that would help me design the upgradation process? A basic outline of how it should be ideally upgraded would help. ( Currently, the new version installs over the old one with the config and other files which have been changed not being replaced to keep the old data intact.)

I guess this could be achieved fairly easily

I hope the following qualifies as a valid GSoC project : )

#4

Here is what is happening in the Debian package: you get a 3 ways merge of xwiki.cfg, xwiki.properties, hibernate.cfg.xml and web.xml and the user is warned about customization in other configuration files (everything in /etc/xwiki) which are a lot less likely to change often but could make sense for others too in the case of the snap package: in short, you should ideally get a merge of any configuration file which has a good chance of being customized by the user and regularly change in the standard version

Even without talking about upgrades, it really seems wrong to me to copy JAR files since it does not make much sense to modify them (it can make sense to add more of those, but there is no need to copy all the standard ones for that) and it means constantly copying about 300MB for no reason (snap packages are already slow enough to start…). And even for other non data files (js, css, vm), even if those are text files I don’t think it makes much sense to copy them all constantly in the case of such a package.

#5

hey @tmortagne ,
I will try to make the upgrade more like the Debian package. But the entire snap package is pulled from the store every time you upgrade. All the .jar and other files come pre-packaged with it. I would look into it further to see if there is a way to not copy almost all the files. (just copy most files once during the first install )

We could use the pre-refresh hook or the post-refresh hooks to make the upgrade feel more intuitive and Debian package-like.
Are there any more features you would like the snap package to have that I could add to the GSoC-2023 proposal?

All suggestions would be highly appreciated .
Thanks :slight_smile:

#6

It does not have to be exactly like Debian as those have very different constraints, I was just indicating how configuration files upgrade are handled as example.

I’m not really sure what you mean, all I’m saying is that it does not make much sense for standard JAR files to end up in what is supposed to be the data storage.

1 Like
#7

okay, will keep that in mind and work on it accordingly.

lastly, does the following count as a valid GSoC proposal? Even if it doesn’t would love to make the XWiki snap package an official XWiki distribution : )

#8

The devil is in the details, I’m expecting that this will need enough time for a GSOC (even if it will be time spent more on design, discussions and convincing others that it’s easy enough to maintain to become official than pure coding) even if you may feel now that it’s not that big :slight_smile:

1 Like
#9

Seems like a lot of work outside of pure coding. Would love to work on this project outside of GSoC then. Excited to work on it :grin: