[gnome-calculator] Created branch gnome-3-26
The branch 'gnome-3-26' was created pointing to: d7f820d... [L10N] Update Persian translation ___ release-team@gnome.org https://mail.gnome.org/mailman/listinfo/release-team Release-team lurker? Do NOT participate in discussions.
[gnome-backgrounds] Created branch gnome-3-26
The branch 'gnome-3-26' was created pointing to: 3fe7a40... [l10n] Updated Catalan (Valencian) translation ___ release-team@gnome.org https://mail.gnome.org/mailman/listinfo/release-team Release-team lurker? Do NOT participate in discussions.
[gnome-system-monitor] Created branch gnome-3-26
The branch 'gnome-3-26' was created pointing to: 9224515... Fix inaccurate %CPU values in the Processes table ___ release-team@gnome.org https://mail.gnome.org/mailman/listinfo/release-team Release-team lurker? Do NOT participate in discussions.
Re: GNOME Modulesets in BuildStream - Baby Steps
On 31 October 2017 at 17:34, Michael Catanzaro wrote: > > One more thing. At GUADEC, we discussed removing all the apps currently in > the gnome-apps moduleset, and moving all the apps from gnome-core into > gnome-apps. We could call it gnome-core-apps, or not. Anyway, the goal is to > greatly reduce the scope of what release team is responsible for. I think > Javier was going to make that happen, but it never happened to the jhbuild > modulesets, at least. Yes, I forgot to do this after we start the 3.28 cycle. The branch is here [1] I will merge it in a couple of days if nothing important is missing Cheers, Javier [1] https://git.gnome.org/browse/jhbuild/log/?h=jjardon/reorganization ___ release-team@gnome.org https://mail.gnome.org/mailman/listinfo/release-team Release-team lurker? Do NOT participate in discussions.
Re: GNOME Modulesets in BuildStream - Baby Steps
On 31 October 2017 at 10:36, Tristan Van Berkom wrote: > I'm hoping that we can take a different strategy with a converted > BuildStream project than we had with JHBuild, i.e. using git. > > I would suggest that we keep a 'gnome-modulesets' git repository where > we always build master of everything, on the master branch, and that we > branch for every stable release. > > We can also tag stable releases in such a way that we know that builds > from the gnome-modulesets repo at a given tag, produce exactly the same > results when one attempts to build it elsewhere (could potentially do > this for dev releases too if that's interesting). > > Probably this is going to need a bit more thought, but I think it's > approximately correct and will be cleaner than supporting every version > of GNOME in the same master branch. That was exactly the reason why [1] was created; split jhbuild from the modulesets itself and use git to track ther gnome versions as you describe Unfortunatelly it never happened because [2] was never finish Maybe makes sense to use that repo to push the converted bst recipes? Cheers, Javier PS: Thanks for the quick BuildStream fix btw! [1] https://git.gnome.org//browse/gnome-modulesets [2] https://bugzilla.gnome.org/show_bug.cgi?id=675873 ___ release-team@gnome.org https://mail.gnome.org/mailman/listinfo/release-team Release-team lurker? Do NOT participate in discussions.
Re: GNOME Modulesets in BuildStream - Baby Steps
On Tue, 2017-10-31 at 20:24 +, Javier Jardón wrote: > On 31 October 2017 at 10:36, Tristan Van Berkom > > wrote: > > > > I'm hoping that we can take a different strategy with a converted > > BuildStream project than we had with JHBuild, i.e. using git. > > > > I would suggest that we keep a 'gnome-modulesets' git repository where > > we always build master of everything, on the master branch, and that we > > branch for every stable release. > > > > We can also tag stable releases in such a way that we know that builds > > from the gnome-modulesets repo at a given tag, produce exactly the same > > results when one attempts to build it elsewhere (could potentially do > > this for dev releases too if that's interesting). > > > > Probably this is going to need a bit more thought, but I think it's > > approximately correct and will be cleaner than supporting every version > > of GNOME in the same master branch. > > That was exactly the reason why [1] was created; split jhbuild from > the modulesets itself and use git to track ther gnome versions as you > describe > Unfortunatelly it never happened because [2] was never finish > Maybe makes sense to use that repo to push the converted bst recipes? Couple things... A.) No - We should not push the automatically converted BuildStream project to a repository that people can push to (this will lead to people making changes in an autogenerated branch, or thinking that that might be acceptable, it's not a great idea and will probably break things, or lose peoples commits at best). Instead, lets wait for the cut off, and take the last conversion and create an initial commit on a new repo with that. B.) Ahem gitlab anyone ? I know the dust has not settled and the decision is not official for GNOME - largely because most maintainers just wont find time to manually migrate their own projects to gitlab.gnome.org for the incubation period (but also because of some fair concerns regarding possible data loss in bug database migration). It would however, be awesome I think if we could transition from JHBuild modulesets maintained in JHBuild git.gnome.org, directly to a BuildStream project maintained on gitlab.gnome.org This can let us, almost immediately start leveraging gitlab features for the purpose of automating builds for releases. Of course, if this would be too dramatic of a move, we could stay with git.gnome.org for a time... Cheers, -Tristan ___ release-team@gnome.org https://mail.gnome.org/mailman/listinfo/release-team Release-team lurker? Do NOT participate in discussions.
