Could gNewSense and Trisquel share a GitLab instance?
- Inicie sesión ou rexístrese para enviar comentarios
I've just been reading Matt Lee's manifesto for the rejuvenation of the gNewSense distro:
http://www.gnewsense.org/next-steps/
One of the things he mentions is shifting development onto GitLab CE and he's take steps towards using the git.gnu.io instance for that. The one that GNU social and GNU FM have been developed on. I note that Trisquel development is now taking place on a self-hosted GL instance too. Looking ahead, maybe the two projects could look at pooling their efforts and sharing one GL instance, reducing the sysops work for each project group?
Obviously getting Trisquel 9.0 shipped takes priority over rejigging the dev infrastructure (again) and there would need to be discussions between the two communities to see if there is enough common ground to play in one sandbox. But something to think about for the medium term.
> I've just been reading Matt Lee's manifesto for the rejuvenation of
> the gNewSense distro: http://www.gnewsense.org/next-steps/
I'm not sure what's happening with this. After reading the announcement
I emailed mattl offering to modify Trisquel's package helpers to be used
for gNewSense, but did not receive a response. I also asked some
questions on the Gitlab issue tracker, which have gone unanswered.
There have been no commits in any of the gNewSense repositories or any
other sign of activity on the Gitlab instance,[1] and no recent
discussion on the mailing list.[2] Until there is some evidence that
gNewSense is actually happening, I don't think it would be a good idea
to share infrastructure or otherwise become invested in the future of
that project.
I completely agree.
But still, it's good news. I look forward to the developer's edition of new gNewSense.
> But still, it's good news. I look forward to the developer's edition
> of new gNewSense.
I think the developer edition could be a very good idea, if it is based
on Debian unstable or testing (preferably unstable). Apart from
providing a rolling release for the users who want it, I think it would
also speed of the release cycle of each stable release. The reason for
the delay of each Trisquel release after its upstream Ubuntu release, is
that changes made upstream require many of the package helpers to be
rewritten all at once. With a rolling branch based on unstable, all of
the necessary changes could be made one-at-a-time as they pop up in the
unstable branch, so that by the time there is a new stable release the
package helpers can be ready to go.
It's unclear that this is what mattl means though. One interpretation
of these issues[1][2] is that the developer edition would just backport
select packages like "GNU development tools." I asked for clarification
on the tracker for issue #1, but there has been no response.
There are so much works to do, so just be patient.
> There are so much works to do
I'm am aware of how much work goes into creating a FSDG-compliant
Debian-based distro which is why I attempted to reach out offering to
help.
> so just be patient.
With a progress rate of 0 commits/day, I worry I'd be waiting a long
time.
Puttting an GUI installer on Hyperbola (they use LTS editions) and a GUI package/service manager on top on that would be an easier option.
You already have a deblobbed base and packages to work with.
Chaosmonk:
> With a rolling branch based on unstable, all of the necessary changes could be made one-at-a-time as they pop up in the unstable branch, so that by the time there is a new stable release the package helpers can be ready to go.
This sounds really promising, especially since all this work has to be done eventually anyway. Given that Trisquel seems to be the more active project, would it be possible to do this as a Trisquel developer's edition instead?
Since Trisquel-Mini is essentially obsolete now that vanilla Trisquel is using Mate, perhaps the time and energy that is spent on that could be redirected into such a developers' edition? I know I've mentioned this many times, but I'm running Trisquel 8 on one of the oldest, lowest powered 32-bit netbooks still in use by anyone on the planet, and Trisquel with Mate works fine. I would never swap the UX of Mate for LXDE and I doubt I would experience much performance improvement if I did.
> This sounds really promising, especially since all this work has to be
> done eventually anyway. Given that Trisquel seems to be the more active
> project, would it be possible to do this as a Trisquel developer's
> edition instead?
Possibly, but we are still catching up to Ubuntu's current stable
release. I think we should focus on Etiona development for now.
> Since Trisquel-Mini is essentially obsolete now that vanilla Trisquel is
> using Mate, perhaps the time and energy that is spent on that could be
> redirected into such a developers' edition? I know I've mentioned this
> many times, but I'm running Trisquel 8 on one of the oldest, lowest
> powered 32-bit netbooks still in use by anyone on the planet, and
> Trisquel with Mate works fine. I would never swap the UX of Mate for LXDE
> and I doubt I would experience much performance improvement if I did.
The default desktop environment is not the only difference between
Trisquel and Trisquel Mini. They also use different default
applications, Trisquel Mini's being generally lighter. Trisquel
Mini also avoids Qt dependencies in its default application set,
avoiding the need to have both the Gtk and Qt toolkits on disk and (when
a Qt application is in use) in memory.
Yes, you've mentioned the application set on other occasions when I've brought this up, but the point remains:
> I'm running Trisquel 8 on one of the oldest, lowest powered 32-bit netbooks still in use by anyone on the planet, and Trisquel with Mate works fine.
.... including the default application set. Here's the current specs of that netbook, the only things I've upgraded is doubling the RAM from 1GB to 2GB, and replacing the default HDD with a SSD, and Flidas was already running nicely before I performed either of these hardware upgrades:
https://www.coactivate.org/projects/disintermedia/bishop
Continuing with Trisquel-Mini is honestly a waste of resources, that could be redirected into getting Etiona-Mate out faster.
> > I'm running Trisquel 8 on one of the oldest, lowest powered 32-bit
> netbooks still in use by anyone on the planet, and Trisquel with Mate
> works fine.
How long does it take for MATE to load? I've installed Trisquel on two
laptops (they weren't mine, so I don't have access to the full specs) on
which MATE took about 45 seconds to fully load after logging in.
Installing Trisquel Mini fixed this.
> Continuing with Trisquel-Mini is honestly a waste of resources, that
> could be redirected into getting Etiona-Mate out faster.
We have not worked at all on Trisquel Mini for Etiona. We have been
focusing on the repositories, installers, and MATE desktop. Trisquel
Mini has not delayed any other tasks, and I don't think there will be
much to be done to build the Trisquel Mini ISO after the MATE ISO is
done. The MATE desktop has needed some work due to MATE's Gtk2->Gtk3
migration, but I think that the LXDE desktop should be relatively
straightforward.
- Inicie sesión ou rexístrese para enviar comentarios