LGM 25 Nuremberg: HELP REQUIRED Online Resources

[Lasse Fister]

Here's an update:

* From my efforts, that I described in my mail before, I published the
archive and a placeholder landing page
at https://libregraphicsmeeting.strong-type.systems so it can be
inspected.
* Stefan Huber contacted tuxfamily.org and
now https://libregraphicsmeeting.org is back online. Thanks!
* Manuel Schmalstieg added me to the libregraphicsmeeting organization
on github. https://github.com/libregraphicsmeeting so it seems like I
can create repositories there now. I can now see that Ale is also an
owner of that organization

What's missing is:

* a decision how we want to progress (KDE, GitHub)
* the DNS setup
* Maybe the quality of the archive can be improved by fetching the
website with another tool. It's not too bad though, I believe.

I can for now work
into https://libregraphicsmeeting.strong-type.systems and get an
initial website up for 2025.

Lasse



On Mon, 2024-12-09 at 19:53 +0100, Lasse Fister wrote:
> Hi all,
> 
> and many thanks for getting the conversation going!
> 
> My primary issue would be to get the website situation solved. 
> 
> I would suggest to serve the website via GitHub pages. There's no
> dynamic server side scripting on GH-pages, but with "workflows"
> static site generation can be controlled pretty well (e.g. with
> Jekyll or Eleventy it's great to use). It's also possible to point a
> DNS entry to that service and GitHub doesn't charge anything.
> We could also use another host (KDE) and still build the website
> using the GitHub workflows mechanism then upload to the server e.g.
> via sftp.
> 
> My approach would be something like this:
> 
>  * The archive /20xx websites would be included in the static site at
> libregraphicsmeeting.org, basically as it is right now.
>  * Each new year would directly publish to its final destination
> /20xx. Only the main /index.html would be outside of that structure
> and change accordingly. So no big move is required to create the
> archive of each year.
>  * For dynamic needs (i.e. registration form etc. where direct action
> for input is expected) I would suggest a new sub domain, e.g.
> dynamic.libregraphicsmeeting.org that would handle those. The
> integration into the static web-site could be very transparent.
> However, to be able to e.g. send emails for confirmation etc.
> requires also a mail-server, so there are non-trivial challenges,
> depending on what we want to be able to do. The dynamic contents
> could also be served from a totally different domain.
> 
> I think the separation of static vs dynamic content is nice as the
> dynamic requirement is rather short lived, around half a year before
> the conference. In my case, I would now be happy to set up a dynamic
> server anywhere and keep it active just until this years edition is
> over. We can still share the server code between each edition, but
> shutting it down again also should have a good effect on code hygiene
> and the burden of maintenance.
> 
> As far as emails are concerned, I'd be happy using emails from my
> companies domain for this year, as the company is in the role of
> hosting the event and I can control its mailserver/DNS without
> hassle.
> We could also set up a mail-server for
> dynamic.libregraphicsmeeting.org
> 
> On the weekend, I wrote a script that can take the old archived pages
> and transform them in so far as they can be served very simply be a
> basic http-server.
> It rewrites file-names if they are complicated to serve from static
> server (e.g. the ?query part which `wget` would save to disk when
> scraping a page) and it removes e.g. the
> `http://libregraphicsmeeting/` from hrefs/srcs etc. so that another
> domain can serve the pages. I don't think it's perfect but I have a
> version on my http://localhost that is better than the online version
> right now (which is down). I'm pushing the whole thing as it is to
> github now for sharing ...
> here: https://github.com/strong-type-systems/libregraphicsmeeting
> 
> About the other topics in this thread:
> 
> I think the matrix chat might be a nice idea. I try to be in the IRC
> chat when I'm at my computer, but I agree with Ale that it is
> complicated.
> Mailinglist is OK for me.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On Mon, 2024-12-09 at 10:19 -0300, farid abdelnour wrote:
> > Hello all, long time! Hopefully I'll be able to join you next year.
> > 
> > The KDE community can provide support by hosting the LGM website if
> > you like. But we'd have to sort some technical things out first
> > like:
> > 
> > On Sun, Dec 8, 2024 at 3:19 PM ale rimoldi <ale at graphicslab.org>
> > wrote:
> > > This having been said, i think that there are four important
> > > topics
> > > about the online resources and all of them need some discussion:
> > > 
> > > - DNS
> > > 
> > 
> >  
> > Would it be acceptable to have this pointed at the KDE DNS
> > provider? (CloudNS.net)
> > 
> > > - website
> > > 
> > 
> > 
> > - For the current year, what sort of website would we be taking on
> > the hosting of?- For the historical archives, is this anything
> > other than a static site?
> > - Hosting wise, is there anything else needed aside from the
> > website(s)?
> > 
> > > - mailing list (archived messaging)
> > > 
> > 
> > 
> > We also have some mail servers, would you also need to use those? 
> >  
> > > - messaging platform (real time messaging)
> > > 
> > 
> > 
> > If it also helps, KDE has an irc <-> matrix bridge that the
> > sysadmins can help setup from your irc channel to a matrix room. 
> > 
> > Please let me know what you think and I can get you in touch with
> > the KDE sysadmins so you can organize things. 
> > 
> > Cheers :)
> > 
> >  
> > > I will start here with my thoughts but, if other people agree
> > > that a
> > > discussion is worth to be conducted, it's probably better if the
> > > replies go to one thread per topic (or some topics can go into a
> > > common
> > > thread).
> > > 
> > > 
> > > TLDR:
> > > 
> > > and before going into the details, here my proposition for the
> > > next
> > > (urgent) steps:
> > > 
> > > - AFGRAL gets in touch with louis and takes control of the
> > > LGM.org
> > >   domain
> > > - we find a new place where to host our archive with the static
> > > files
> > >   (if nothing better is proposed, i can temporary host them on
> > > "my"
> > >   shared web space; i guess that the AFGRAL can do the same; i
> > > can
> > >   participate in rebuilding the sites from the git repositories)
> > > 
> > > and now, a lot of details!
> > > 
> > > 
> > > 
> > > # DNS
> > > 
> > > Luis Desjardins is the "owner" of the DNS entries.
> > > 
> > > He already asked for the ownership to be transferred.
> > > 
> > > Since the LGM itself has no way to own them by itself, i'm very
> > > comfortable with the idea of having them in the hands of the
> > > AFGRAL
> > > (or any other entity around the AFGRAL if cedric's "we" did not
> > > refer
> > > to the account he has used for sending his email)
> > > 
> > > If nobody disagree with this, I think that there is not much
> > > discussion
> > > needed and the AFGRAL is welcome to do get in touch with louis
> > > and get
> > > the name transferred.
> > > (probably, we only need libregraphiscmeeting.org , if louis still
> > > has
> > > other similar domains.)
> > > 
> > > 
> > > 
> > > # Hosting the "main" website with the landing page and the
> > > archive
> > > 
> > > We need to move.
> > > urgently.
> > > 
> > > personally, i haven't noticed that tuxfamily has been down for
> > > such a
> > > long time.
> > > we were very lucky that it was online during the latest LGM.
> > > 
> > > we have a bunch of static web sites, each in its own directory,
> > > that are
> > > very rarely (or never) updated.
> > > 
> > > my suggestion is to go for one of two solutions:
> > > 
> > > - we are not picky at all, anybody can host them and we make sure
> > > that
> > >   it's easy for us to migrate to a new host at any time, or
> > > - we try to find a stable host that can host us (for free). like
> > >   tuxfamily used to be.
> > > 
> > > if we can make sure that at the end of each LGM a static site is
> > > checked into our github repository, we can be somehow more
> > > relaxed
> > > about this issue:
> > > we have very low requirements!
> > > 
> > > since tuxfamily is currently down, i would suggest that we need a
> > > solution that can be online before the end of the christmas
> > > holidays.
> > > (or at least before the organization for the next LGM 2025 wants
> > > to go
> > > public with their information!)
> > > 
> > > in the wors case, i can probably host it myself on my shared
> > > server, if
> > > no better solution is proposed (in such a short time).
> > > 
> > > during the christmas holidays, i can reserve some time for
> > > recreating
> > > the websites.
> > > 
> > > 
> > > 
> > > 
> > > # the yearly LGM site
> > > 
> > > for the last few years, we had a rather good experience with a
> > > static
> > > site that could be "automatically" updated by pushing to the
> > > github
> > > repository.
> > > 
> > > if the organizers want / need a dynamic site (wordpress, django,
> > > ...), hosting them on a common server becomes a bit harder.
> > > with tux family we had the constraint that it only supported PHP
> > > and
> > > we mostly went for wordpress.
> > > that's all we could do.
> > > often, it was enough.
> > > 
> > > i've already seen that somebody suggested creating subdomains
> > > that can
> > > be hosted by the organizers (and their partners).
> > > i'm fine with that, but it makes a bit harder to later host the
> > > static
> > > copy.
> > > (probably, not a big issue, though. but it's worth to check about
> > > it
> > > before deciding to use sub domains! it's an additional
> > > requirements for
> > > the host of the static sites)
> > > 
> > > then we would have all lgm up to 2024 in lgm.org/20xx and the
> > > following
> > > ones in 20xx.lgm.org.
> > > maybe there is also an easy way to create a redirect. it needs to
> > > be
> > > tested. and documented.
> > > 
> > > as i said at the beginning of this email, for me the only hard
> > > condition
> > > is:
> > > 
> > > at the end of the lgm a static version of the site (with all the
> > > public
> > > content!) is checked into the git repository.
> > > 
> > > (of course, you can disagree with me also about that! what i want
> > > to
> > > say, is that all the rest is open for discussions and we can
> > > probably be
> > > rather flexible!)
> > > 
> > > 
> > > 
> > > # archived messages: the mailing list
> > > 
> > > currently, the "official" communication canal of the LGM is this
> > > mailing list.
> > > 
> > > i've not seen many critical voices about this, but those who are
> > > not
> > > comfortable with it do not really have a place to complain.
> > > (i guess that most people who have not got into mailing list
> > > before the
> > > mid of the years 2010 are not used to register to mailing lists!
> > > (forums, facebook, statckoverflow, slack, ... have won the race)
> > > 
> > > the advantage of this mailing lists:
> > > 
> > > - it's very easy for us to use. (and everybody can use it)
> > > - freedesktop seems to manage it in a very stable way.
> > > 
> > > the minus points:
> > > 
> > > - many people are not used to mails and mailing lists anymore
> > > - no visual elements
> > > - (personally, i don't get a notification if there are mails i
> > > should
> > >   read...)
> > > 
> > > is there any need for discussions here?
> > > 
> > > 
> > > 
> > > 
> > > # real time messaging
> > > 
> > > officially, we are using the #lgm channel on libera chat.
> > > 
> > > the advantages:
> > > 
> > > - it works.
> > > - it has very low (no) maintenance costs for us.
> > > 
> > > do i need to talk about the issues?
> > > 
> > > - no persistence of the messages (it's not possible to get home
> > > in the
> > >   evening and check what has happened during the day (or during
> > > the
> > >   week)).
> > > - almost none of us is permanently / often in the channel
> > > anymore.
> > > - many people have never heard of irc
> > > - most LGM projects do not (actively) use irc (anymore).
> > > - no fancy / visual content
> > > 
> > > personally, i'm all for finding a new platform.
> > > if possible one that is completely based on free software.
> > > 
> > > i've proposed to switch to element chat (matrix) in the past, but
> > > the
> > > the response was not very positive.
> > > 
> > > personally, i'm not 100% convinced by element myself, but i've
> > > been
> > > using it in for another project for years and it works "well
> > > enough".
> > > 
> > > the biggest issue is, for me, that many people still don't use it
> > > /
> > > don't know about it.
> > > the onboarding is rather painless, but:
> > > - for many people, it's one more platform
> > > - it's not the same as other platforms they are using.
> > > 
> > > but i don't see any better solution that is completely (at least
> > > theoretically) open source and is as easy to use (for the end
> > > users!).
> > > and at least a bit popular (among our pairs).
> > > 
> > > if i recall correctly, at the time i proposed it, the biggest
> > > concerns
> > > were about hosting (which is indeed hard, but i don't see how it
> > > can be
> > > an issue for the lgm: we don't even manage to easily host a
> > > static
> > > website) and about encryption (again, not an issue for me, but i
> > > respect that other people have fundamentally different opinions
> > > on
> > > this!).
> > > 
> > > 
> > > 
> > > 
> > > that's was a long mail.
> > > 
> > > hopefully, i was not too boring, and i really hope that we can
> > > find
> > > good solutions to the issues we are facing!
> > > and i can invest some time in finding those solutions...
> > > 
> > > 
> > > have a wonderful start to the week
> > > a.l.e
> > 
> > 
> > -- 
> > 1111.1010.r.i.1101|n.o.i.s.1110|i.m.1010.g.1110|مقاومة
> > fsf member #5439
> > usuario GNU/Linux #471966
> > |_|0|_|
> > |_|_|0|
> > |0|0|0|
> > <a href="http://www.gunga.com.br">gunga</a>
> > <a href="http://www.tempoecoarte.com.br">tempoecoarte</a>
> > <a href="http://www.atelier-labs.org">atelier-labs</a>
> > <a href="http://www.mocambos.net">rede mocambos</a>
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libre-graphics-meeting/attachments/20241210/336d5ef2/attachment-0001.htm>