Re: Can we enforce beta release for the freeze
Hi, Noticed a question about a way to automate, GitLab CI could automate beta and stable releases for us, did some digging and found this Python package that could help with that. Don’t know it this will help any, but here is a link to that scrip. [https://pypi.org/project/gitlab-auto-release/](https://pypi.org/project/gitlab-auto-release/#:~:text=GitLab%20Auto%20Release%20This%20is%20a%20simple%20Python,so%20it%20can%20create%20the%20release%20for%20you.) Warm Regards, Eric On Tue, Feb 23, 2021 at 9:37 AM, Michael Catanzaro wrote: > FWIW I agree that freeze should apply to tarballs, i.e. any features or > UI changes not in a tarball release by the beta tarball deadline ought > to be delayed until the next release cycle. Dropping major changes a > week later isn't fair to Shaun and anyone else working on > documentation. But that's pretty harsh. > > On the other hand, a solution that requires cloning Georges is not > really a solution > > On Tue, Feb 23, 2021 at 1:53 pm, Emmanuele Bassi via desktop-devel-list > wrote: >> In the end, though, releases are manual labour; only the maintainer >> can say: "okay, this is good enough for other people to use" (where >> "people" defines different audiences depending on the stage of the >> development cycle). No amount of automation is going to solve that >> because if it did we would not need per-project maintainers in the >> first place, and we would only need people reviewing code and >> pressing the "Merge" green button. > > We... > > I think we *could* automatically tag the .alpha .beta .rc and .0 > tarballs, since I expect these to be created at specific predetermined > times regardless of whether the code is "ready" or not. This would > solve Shaun's problem. It would require a bunch of infrastructure work, > though. We would lose manually-written NEWS files. But automation would > probably not be able to handle library versioning, like libtool C:R:A > or the meson equivalent, so maintainers would need to handle that > manually in advance. > > For stable releases after .0, I agree only a human can judge when a > release is required. > > ___ > desktop-devel-list mailing list > [email protected] > https://mail.gnome.org/mailman/listinfo/desktop-devel-list___ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Can we enforce beta release for the freeze
On Sun, Feb 28, 2021 at 11:35 am, Michael Catanzaro wrote: And it turned that bad plumbing was at fault (Turns out bad things happen when drain pipes slope upwards instead of downwards) ___ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Can we enforce beta release for the freeze
On Sat, Feb 27, 2021 at 7:42 pm, Bastien Nocera wrote: It's like giving your mate a key to your place so they can do laundry while you're away. You don't expect them to have flooded the place when you get back. In fairness, the one time I flooded a laundry room, I caught it pretty quickly when it was still fixable with a large quantity of towels. And it turned that bad plumbing was at fault ___ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Can we enforce beta release for the freeze
On Sat, 2021-02-27 at 10:26 -0800, Philip Chimento via desktop-devel- list wrote: > On Tue, Feb 23, 2021 at 5:54 AM Emmanuele Bassi via desktop-devel-list > wrote: > > The release team can do "non maintainer" releases, of course; the > > problem is, of course, that maintainers can be *very* protective of > > their fiefdoms, so the release team has to wait for either being > > explicitly asked to do a release, or for an answer from maintainers > > as to whether they'll be able to do a release. We *cannot* have it > > both ways: either the release team can take over your project for a > > specific task—do a release, keep the build running—or we have to wait > > until we get an answer from the maintainer. > > The ideas about automating releases mentioned elsewhere in the thread > sound like great time-savers, but I primarily came here to add to what > Emmanuele said: I'd be quite happy for the release team to have the > power to take over releasing my module if I forget, but I've seen some > astonishing vitriol directed at the release team on this very mailing > list when they have done similar things in the past. > > I wouldn't blame them if they didn't even want to get near this topic. > > As a community, if we weight the autonomy of maintainers so heavily > that we're willing to tolerate mailing list flames about it, then we > don't also get to complain when nobody steps in to help with > maintainers' tasks. I'm pretty sure that most of us, myself included, wouldn't mind, as long as the job was done to a standard. It's like giving your mate a key to your place so they can do laundry while you're away. You don't expect them to have flooded the place when you get back. ___ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Can we enforce beta release for the freeze
On Tue, Feb 23, 2021 at 5:54 AM Emmanuele Bassi via desktop-devel-list < [email protected]> wrote: > The release team can do "non maintainer" releases, of course; the problem > is, of course, that maintainers can be *very* protective of their fiefdoms, > so the release team has to wait for either being explicitly asked to do a > release, or for an answer from maintainers as to whether they'll be able to > do a release. We *cannot* have it both ways: either the release team can > take over your project for a specific task—do a release, keep the build > running—or we have to wait until we get an answer from the maintainer. > The ideas about automating releases mentioned elsewhere in the thread sound like great time-savers, but I primarily came here to add to what Emmanuele said: I'd be quite happy for the release team to have the power to take over releasing my module if I forget, but I've seen some astonishing vitriol directed at the release team on this very mailing list when they have done similar things in the past. I wouldn't blame them if they didn't even want to get near this topic. As a community, if we weight the autonomy of maintainers so heavily that we're willing to tolerate mailing list flames about it, then we don't also get to complain when nobody steps in to help with maintainers' tasks. Cheers, -- Philip ___ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Can we enforce beta release for the freeze
Hi all, and long time no see, hope everyone is doing well... On Tue, 2021-02-23 at 08:37 -0600, Michael Catanzaro wrote: [...] > On Tue, Feb 23, 2021 at 1:53 pm, Emmanuele Bassi via desktop-devel-list > wrote: > > In the end, though, releases are manual labour; only the maintainer > > can say: "okay, this is good enough for other people to use" (where > > "people" defines different audiences depending on the stage of the > > development cycle). No amount of automation is going to solve that > > because if it did we would not need per-project maintainers in the > > first place, and we would only need people reviewing code and > > pressing the "Merge" green button. > > We... > > I think we *could* automatically tag the .alpha .beta .rc and .0 > tarballs, since I expect these to be created at specific predetermined > times regardless of whether the code is "ready" or not. This would > solve Shaun's problem. It would require a bunch of infrastructure work, > though. We would lose manually-written NEWS files. But automation would > probably not be able to handle library versioning, like libtool C:R:A > or the meson equivalent, so maintainers would need to handle that > manually in advance. I think this is a wonderful idea, I've been toying with something similar for years now, I never ended up taking it to d-d-l as I did not get much traction from within the release team yet. >From my perspective, the main pain point that I would like to solve, is that we are not running integrated builds of the same software we end up releasing, if we were releasing the same thing we were running integrated builds of, then we would obviously have much less issues at release time. Bringing releases inline with regular CI throughout the cycle would also make actual integration work more meaningful (i.e. work like testing pam setups for gnome-keyring, getting the ibus working properly, ensuring the GOA stuff is all working, etc). As this topic came up, I'll try to throw up a tentative outline of how I think this could work. * We would need to support opting in and opting out of this. For maintainers who want to keep manually tagging and releasing tarballs, we would only ever build tarballs for those in the integrated builds. Those maintainers are responsible for updating the tarball references in gnome-build-meta every time they release a tarball. Some policy would need to be drawn up on what happens when introducing an updated tarball of your platform library into the build causes the overall GNOME build to break. * For maintainers who opt in to the automation (which I would think would have to be more than 80%, ideally 95%, for this approach to be worthwhile), we would enforce a GNOME-wide standard release tag nomanclature. * Maintainers would be responsible for updating the `track` reference in gnome-build-meta for the active release cycle. With something like this, the release builds would just track the latest of every maintainer chosen branch at the time of release, and tag the modules which have changed in any way since the last release tag - tagging the module would result in automatically also generating a tarball and publishing it (possibly without any NEWS updates as Micheal pointed out) - the tarballs are only generated for the convenience of certain downstreams which still want to consume them. > For stable releases after .0, I agree only a human can judge when a > release is required. Once the first stable release is out, there are different ways we can handle things, but I don't think that it is entirely necessary to have the maintainer decide when to make a stable release of their modules - if any new commits are available on the active stable branch listed in the corresponding gnome-build-meta stable branch, they will be included in the next stable release and a release will be made for them automatically (tag + tarball published). Instead, if there are critical security patches which need to go out on a module in a stable series, the maintainer can just request that the release team make an additional releases for that exception (if the automation is good, this should not require effort on the part of the release team anyway). There are surely risks and downsides, like ensuring libtool versioning bumps happen correctly, and ensuring good enough communication (such that we select the correct branches for CI at the *beginning* of a new cycle as well as when the freezes start), but in general I think this would be a good avenue to pursue and would be happy to lend a hand where I can to help us get there. Cheers, -Tristan ___ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Can we enforce beta release for the freeze
FWIW I agree that freeze should apply to tarballs, i.e. any features or UI changes not in a tarball release by the beta tarball deadline ought to be delayed until the next release cycle. Dropping major changes a week later isn't fair to Shaun and anyone else working on documentation. But that's pretty harsh. On the other hand, a solution that requires cloning Georges is not really a solution On Tue, Feb 23, 2021 at 1:53 pm, Emmanuele Bassi via desktop-devel-list wrote: In the end, though, releases are manual labour; only the maintainer can say: "okay, this is good enough for other people to use" (where "people" defines different audiences depending on the stage of the development cycle). No amount of automation is going to solve that because if it did we would not need per-project maintainers in the first place, and we would only need people reviewing code and pressing the "Merge" green button. We... I think we *could* automatically tag the .alpha .beta .rc and .0 tarballs, since I expect these to be created at specific predetermined times regardless of whether the code is "ready" or not. This would solve Shaun's problem. It would require a bunch of infrastructure work, though. We would lose manually-written NEWS files. But automation would probably not be able to handle library versioning, like libtool C:R:A or the meson equivalent, so maintainers would need to handle that manually in advance. For stable releases after .0, I agree only a human can judge when a release is required. ___ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Can we enforce beta release for the freeze
On Mon, 22 Feb 2021 at 00:20, Shaun McCance wrote: > What I want is a discussion on how we can ensure beta releases happen in > the future. For example, can we do more to automate releases? Or (again, > for example), could we have an automated script that emails this list with > modules missing beta releases? Then even if releases are missed, people > like me would at least know what to expect from the beta. > "Automating releases" is a vast topic. In theory, we could simply ask maintainers to upload a (signed) tag to GitLab, and then our tools would be able to deal with that—of course, that requires some process change and some tool change from the release team perspective, but we've been trying to get towards that goal for a while now. That would get rid of the "upload a dist tarball to gnome.org" step, which is, frankly, the least involved step. We'd still require maintainers to run dist as part of the release checklist because otherwise how are they going to tag a release in the first place? Of course, we *should* also rely on CI to ensure that a `dist` operation always passes on the main development branch; it would be good to have a project-wide CI rule that runs the dist on a schedule, but maintainers can do this *today* in their projects. In the end, though, releases are manual labour; only the maintainer can say: "okay, this is good enough for other people to use" (where "people" defines different audiences depending on the stage of the development cycle). No amount of automation is going to solve that because if it did we would not need per-project maintainers in the first place, and we would only need people reviewing code and pressing the "Merge" green button. The delay on this beta release was caused by the fact that we have a shortage of maintainers, and too few people in key positions. This issue can only be solved by having redundancies in the *human* pipeline. Maintainers: *please*, mentor contributors to pick up the release process. Document what you do, and give out release duties to other people at least once per cycle, if you can. The release team can do "non maintainer" releases, of course; the problem is, of course, that maintainers can be *very* protective of their fiefdoms, so the release team has to wait for either being explicitly asked to do a release, or for an answer from maintainers as to whether they'll be able to do a release. We *cannot* have it both ways: either the release team can take over your project for a specific task—do a release, keep the build running—or we have to wait until we get an answer from the maintainer. Ciao, Emmanuele. -- https://www.bassi.io [@] ebassi [@gmail.com] ___ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Can we enforce beta release for the freeze
On Sun, Feb 21, 2021 at 4:20 PM Shaun McCance wrote: > Hi Georges, > > > What I want is a discussion on how we can ensure beta releases happen in > the future. For example, can we do more to automate releases? Or (again, > for example), could we have an automated script that emails this list with > modules missing beta releases? Then even if releases are missed, people > like me would at least know what to expect from the beta. > Seems to me that we could leverage gitlab here and create a more automatic process. The more automation the better. Maybe a conversation with Gitlab and see how other community projects are doing and explore whats possible for the next release. At a high level, I think if we were able to just label which components are beta we can create a "what's missing" kind of status. If all components are in "beta" then we are ready for beta releases. That way if we get busy and forget we can always check before going to the next phrase and give a gentle reminder or do something else. I will volunteer to help here - I just need some tacit agreement that you'll all be open to hearing a proposal when we're done. Cheers, sri > On Sun, 2021-02-21 at 20:41 -0300, Georges Basile Stavracas Neto via > desktop-devel-list wrote: > > Hi Shaun, > > I appreciate how frustrating it is to have someone else negatively > impacting your > day work, and I'm sincerely sorry about that. I'm usually responsible for > doing > the Settings unstable releases, and Robert usually takes care of stable > releases. > I should have asked Robert to do this unstable release this time. > Unfortunately, I > cannot offer you any solid reason for this delay - it just fell through > the cracks. > > I'd like to offer another perspective: as of lately, I'm struggling to > keep all these > plates spinning. This time, one fell. After waking up unusually early to > do a > Sunday morning release, I can't say that reading this email put a smile on > my > face. > > You can try and squeeze maintainers for more, for tight schedules, for no > mistakes, > but I'm afraid this one is already dry. > > With respect, > > Em dom., 21 de fev. de 2021 às 17:18, Shaun McCance > escreveu: > > Hi all, > > I just wasted a whole lot of time trying to figure out why I wasn't > seeing GNOME 40 settings in both Rawhide and Tumbleweed, only to > discover that gnome-control-center didn't get an upstream 40.beta > release until a few hours ago today. > > This is extremely frustrating. For all practical purposes, that means > the freeze actually started today, not last week, because we can't do > post-freeze work on unreleased software. > > The freeze is pointless without beta releases, so what can we do to > enforce that beta releases happen? > > Thanks, > Shaun > > > ___ > desktop-devel-list mailing list > [email protected] > https://mail.gnome.org/mailman/listinfo/desktop-devel-list > > ___ > desktop-devel-list mailing list > [email protected] > https://mail.gnome.org/mailman/listinfo/desktop-devel-list > > > ___ > desktop-devel-list mailing list > [email protected] > https://mail.gnome.org/mailman/listinfo/desktop-devel-list > ___ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Can we enforce beta release for the freeze
Hi Georges, I appreciate that, and I'm sorry my email was perhaps abrasive and that it upset you. I'll try to choose my words more carefully in the future. It really wasn't my intention to assign blame. I'm also struggling to keep plates spinning, and sometimes I drop them as well. What I want is a discussion on how we can ensure beta releases happen in the future. For example, can we do more to automate releases? Or (again, for example), could we have an automated script that emails this list with modules missing beta releases? Then even if releases are missed, people like me would at least know what to expect from the beta. On Sun, 2021-02-21 at 20:41 -0300, Georges Basile Stavracas Neto via desktop-devel-list wrote: > Hi Shaun, > > I appreciate how frustrating it is to have someone else negatively > impacting your > day work, and I'm sincerely sorry about that. I'm usually responsible > for doing > the Settings unstable releases, and Robert usually takes care of > stable releases. > I should have asked Robert to do this unstable release this time. > Unfortunately, I > cannot offer you any solid reason for this delay - it just fell > through the cracks. > > I'd like to offer another perspective: as of lately, I'm struggling > to keep all these > plates spinning. This time, one fell. After waking up unusually early > to do a > Sunday morning release, I can't say that reading this email put a > smile on my > face. > > You can try and squeeze maintainers for more, for tight schedules, > for no mistakes, > but I'm afraid this one is already dry. > > With respect, > > Em dom., 21 de fev. de 2021 às 17:18, Shaun McCance > escreveu: > > Hi all, > > > > I just wasted a whole lot of time trying to figure out why I wasn't > > seeing GNOME 40 settings in both Rawhide and Tumbleweed, only to > > discover that gnome-control-center didn't get an upstream 40.beta > > release until a few hours ago today. > > > > This is extremely frustrating. For all practical purposes, that > > means > > the freeze actually started today, not last week, because we can't > > do > > post-freeze work on unreleased software. > > > > The freeze is pointless without beta releases, so what can we do to > > enforce that beta releases happen? > > > > Thanks, > > Shaun > > > > > > ___ > > desktop-devel-list mailing list > > [email protected] > > https://mail.gnome.org/mailman/listinfo/desktop-devel-list > ___ > desktop-devel-list mailing list > [email protected] > https://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Can we enforce beta release for the freeze
On Sun, 2021-02-21 at 15:47 -0500, Matthias Clasen via desktop-devel- list wrote: > > > On Sun, Feb 21, 2021 at 3:18 PM Shaun McCance > wrote: > > The freeze is pointless without beta releases, so what can we do to > > enforce that beta releases happen? > > > > > Help out with the modules that are missing releases. > > It is a small group of people doing a lot of hard work. The control > center maintainer, > Georges, is also one of the main forces behind the gnome-shell > redesign. > > And days only have 24 hours. I am sympathetic to time constraints. I really truly am. And I know I've missed releases too. But the group of people doing documentation is also very very small, and we also only have 24 hours in a day. If I take on more release responsibilities, I will have zero time to do work on documentation, which is my only real motivation to have the beta releases done. Our infrastructure for putting beta releases in front of actual humans is *so* much better than it was 20 years ago. That's in large part because some awesome folks automated a lot of stuff. But there's still a lot of human work in releases. I rolled around 10 releases last weekend, and it took me a couple hours (In part because I have to log out and back in under Xorg to roll Yelp because of old colde I haven't made the time to update.) Can we reduce or eliminate that? -- Shaun ___ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Can we enforce beta release for the freeze
Hi Shaun, I appreciate how frustrating it is to have someone else negatively impacting your day work, and I'm sincerely sorry about that. I'm usually responsible for doing the Settings unstable releases, and Robert usually takes care of stable releases. I should have asked Robert to do this unstable release this time. Unfortunately, I cannot offer you any solid reason for this delay - it just fell through the cracks. I'd like to offer another perspective: as of lately, I'm struggling to keep all these plates spinning. This time, one fell. After waking up unusually early to do a Sunday morning release, I can't say that reading this email put a smile on my face. You can try and squeeze maintainers for more, for tight schedules, for no mistakes, but I'm afraid this one is already dry. With respect, Em dom., 21 de fev. de 2021 às 17:18, Shaun McCance escreveu: > Hi all, > > I just wasted a whole lot of time trying to figure out why I wasn't > seeing GNOME 40 settings in both Rawhide and Tumbleweed, only to > discover that gnome-control-center didn't get an upstream 40.beta > release until a few hours ago today. > > This is extremely frustrating. For all practical purposes, that means > the freeze actually started today, not last week, because we can't do > post-freeze work on unreleased software. > > The freeze is pointless without beta releases, so what can we do to > enforce that beta releases happen? > > Thanks, > Shaun > > > ___ > desktop-devel-list mailing list > [email protected] > https://mail.gnome.org/mailman/listinfo/desktop-devel-list > ___ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Can we enforce beta release for the freeze
On Sun, Feb 21, 2021 at 3:18 PM Shaun McCance wrote: > Hi all, > > I just wasted a whole lot of time trying to figure out why I wasn't > seeing GNOME 40 settings in both Rawhide and Tumbleweed, only to > discover that gnome-control-center didn't get an upstream 40.beta > release until a few hours ago today. > > This is extremely frustrating. For all practical purposes, that means > the freeze actually started today, not last week, because we can't do > post-freeze work on unreleased software. > > The freeze is pointless without beta releases, so what can we do to > enforce that beta releases happen? > Help out with the modules that are missing releases. It is a small group of people doing a lot of hard work. The control center maintainer, Georges, is also one of the main forces behind the gnome-shell redesign. And days only have 24 hours. ___ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
