On Mon, Dec 29, 2025 at 4:00 AM Christoph Cullmann <[email protected]> wrote:
> Hi, > > On Sunday, December 28th, 2025 at 13:06, Friedrich W. H. Kossebau < > [email protected]> wrote: > > > > > > > > > Am Sonntag, 28. Dezember 2025, 12:34:26 Mitteleuropäische Normalzeit > schrieb > > Albert Astals Cid: > > > > > > I ended up in https://invent.kde.org/system/xwaylandvideobridge the > other > > > day and I was wondering "Why was this archived?". > > > > > > > Most of our stuff gets archived because "It's old and no one cares", > but > > > that means that if someone cares we would not mind unarchiving it. > > > > > > > Some other things (like let's say KF5 only frameworks and possibly this > > > xwaylandvideobridge) are archived because better technologies exist. > > > > > > > I think it would be good if from now on we added a small note in the > > > > > readme > > > > > > explaining why the project was archived and if there's possibility of > > > unarchiving it. > > > > > > > What do you think > > > > > > > > Documenting those two things would be nice to have, ++. > > > > > Instead of seeing to add that info to any existing README or README.md or > > creating new ones, with the risk of people still missing it out (who > reads > > docs, even one with possibly lots of info) or potentially deleting old > yet > > once again still useful info while editing such README, would like to > offer > > an alternative: > > > > > Not sure where I had come across that, but for archived projects they > set up > > a special branch with just a single README file, holding the basic info > > "Archived project, for reason A. If interested to revive, do B. Etc.". > That > > special branch was set up as default branch. > > > > > So anyone navigating to the default repo web view or doing a default repo > > clone without further checks would be exposed to only that very README, > so > > could not miss the state and the info. > > > > > While the old master/main branch then would not be mangled with any > > "archived" info, like also any latest release/stable branches would not > need > > to be. And when someone adopts and revives the repo, they do not need to > > undo any "Its archived info" from the docs in the min/master branch. > > I personally would prefer the note added just to the README. > > That has a lot less steps to do and undo on the admin side of GitLab. > No default branch changing and Co. > But that is just my 2c. > Default branches also don't propagate across our mirroring logic, so it would have to be changed in two places, and then undone in two places. > > Greetings > Christoph > > > > > > Cheers > > Friedrich Cheers, Ben
