Re: [ Revised Proposal ] Continuous Builds in GNOME
First, I've been on vacation this week and have been able to put time into this, with the hope that next week I will be able to focus on $dayjob without regretting too much not being able to take part in this important debate. I hope we are going somewhere. Also, in closing in this mail, I will just highlight my motivations for bringing up this proposal in the first place. Sri, Please just gloss over the technical stuff and read the end, I think you are in a position to effect change and this is written with you in mind (from the "Why do I think..." heading). On Fri, 2016-06-17 at 15:17 +0200, Milan Crha wrote: > On Fri, 2016-06-17 at 17:11 +0900, Tristan Van Berkom wrote: > > > > I dont believe you have any such functionality in jhbuild. > > > > At best, you can specify the sha1 of the commit you want to build > > of > > a given module, this would not let you single out one commit, > > omitting it from history in integration and at least attempt to > > apply > > subsequent commits without that one included, re-including that > > commit in the correct place in history only when CI infrastructure > > would find integration unbroken. > Hi, > I never thought of a single commit removal from a set of commits. To > be > honest, that sounds even more crazy (not 'crazy' like 'insane'). :) > We are talking about master, the development version of the software. > If you'd like to tell me that you are at commit X and feature which I > added at commit X-3 does not work for you, then trying to figure out > why exactly you do not see that feature is a real nightmare and waste > of time for both the reporter and the developer, especially when you > want to remove only single commit from a history. Not talking that > following commit can "build on top of the previous commit", which is > quite usual. > > > > > The thing is, either way; your work flow will not be interrupted at > > all with this approach, ... > See above. Milan, I think that if your commit broke integration with the wider GNOME ecosystem, that will matter to you and you will be quite aware of which commit in master broke it and why until it is fixed. I think we have to ensure that people take integration breaking commits seriously and ultimately, an integration breaking commit would block any stable release. That said, in your above scenario; a disparity between master and integration is a serious issue, but consider the alternative: If a new comer wants to get involved in GNOME, they probably have a specific itch to scratch, say with Evolution or EDS; they will either be able to build everything up to EDS & Evolution easily; have an easy experience, and be able to submit a patch to bugzilla, or, they will fail to build and get side tracked because the bleeding edge of master for all GNOME modules doesn't build. In other words (and this has absolutely nothing to do with using jhbuild or not) when you build everything from master and it breaks before you are even able to work on the issue you wanted to work on, this is discouraging; this means that we are offloading our technical debts to newcomers, forcing them to deal with our bugs before being able to even submit a patch they wanted to contribute. Would you prefer that a potential EDS contributor be able to submit a patch to bugzilla, even if it does not match up *exactly* against master ? Or would you prefer that your potential contributor get discouraged while trying to build EDS against the latest gcr, libsecret, libgdata or such, or just get bogged down trying to fix an EDS bug to adjust to some API churn in a dependent GNOME library ? I think receiving a patch for what the contributor wanted to work on is preferable, even if you happen to fall on a patch that doesn't apply exactly against master, in the 1% of the time that EDS integration is broken and lagging behind. [...] > I said earlier in the thread that the current situation works for me > the best. There is clearly stated what the continuous builds from, at > which exact commit it "stopped updating" certain module, because of > some breakage, and everything references the real master branch. That > the continuous uses jhbuild might be just a coincidence, even it > sounds > like the moduleset is targeted for the Continuous builds, when it can > influence an environment for any developer using the jhbuild (I do > not > use it, this is how I understood how it works in the jhbuild world). I'll just note again this is not about jhbuild particularly, jhbuild in master tries to build everything from master, sometimes it breaks and I think that's natural in the present state of affairs. gnome-continuous does *not* build jhbuild modulesets, it uses it's own json format for, also building everything from master: https://git.gnome.org/browse/gnome-continuous/tree/manifest.json This is about getting the bleeding edge, or something as close as possible to the bleeding edge to be always buildable; for two reasons: a.)
Re: GNOME 3.21.3 unstable tarballs due (responsible: mcatanzaro)
On Fri, 2016-06-17 at 00:00 +, Release Team wrote: > Tarballs are due on 2016-06-20 before 23:59 UTC for the GNOME 3.21.3 > unstable release, which will be delivered on Wednesday. Modules which > were proposed for inclusion should try to follow the unstable > schedule > so everyone can test them. Please make sure that your tarballs will > be uploaded before Monday 23:59 UTC: tarballs uploaded later than > that > will probably be too late to get in 3.21.3. If you are not able to > make a tarball before this deadline or if you think you'll be late, > please send a mail to the release team and we'll find someone to roll > the tarball for you! Hi all, Please take note of the Monday deadline. If you got a mail from me earlier this week that I could not build the latest tarball release of your module, please try to address the issue with a new tarball release no later than Monday. Michael ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [ Revised Proposal ] Continuous Builds in GNOME
On Fri, 2016-06-17 at 17:11 +0900, Tristan Van Berkom wrote: > I dont believe you have any such functionality in jhbuild. > > At best, you can specify the sha1 of the commit you want to build of > a given module, this would not let you single out one commit, > omitting it from history in integration and at least attempt to apply > subsequent commits without that one included, re-including that > commit in the correct place in history only when CI infrastructure > would find integration unbroken. Hi, I never thought of a single commit removal from a set of commits. To be honest, that sounds even more crazy (not 'crazy' like 'insane'). :) We are talking about master, the development version of the software. If you'd like to tell me that you are at commit X and feature which I added at commit X-3 does not work for you, then trying to figure out why exactly you do not see that feature is a real nightmare and waste of time for both the reporter and the developer, especially when you want to remove only single commit from a history. Not talking that following commit can "build on top of the previous commit", which is quite usual. > The thing is, either way; your work flow will not be interrupted at > all with this approach, ... See above. > I realize my answer is quickly written and I would like to keep my > mind open and receptive, but I would also like to hear a more > detailed counter proposal on your end too, weighing the benefits of > managing this in a jhbuild moduleset vs a unified project wide git > branch I didn't think of my workflow changes in any deep way, also because I do not use jhbuild (that's not a tool for me). I just want to keep things simple as much as possible. Not only for me, but for the others too. Adding a new branch adds some non-trivial complexity. Consider the early adopters, whom will fill bugs against the developer version of some module. The developer will not only ask "what steps to do to reproduce the issue", but also "which branch was used and with what commits". And it happens often that the developers do not react on bugs "quickly", thus the commit numbers in the integration branch can be easily lost (branch rebuilt), thus making the bug report more or less useless. I said earlier in the thread that the current situation works for me the best. There is clearly stated what the continuous builds from, at which exact commit it "stopped updating" certain module, because of some breakage, and everything references the real master branch. That the continuous uses jhbuild might be just a coincidence, even it sounds like the moduleset is targeted for the Continuous builds, when it can influence an environment for any developer using the jhbuild (I do not use it, this is how I understood how it works in the jhbuild world). I do not care about the new branch, if you (plural 'you') will decide to use it, then I've nothing significant against. I only think it'll add too much confusion for the developers, that it'll strike back in some way in the future. I only do not like the idea of random reverts, the master branch is the pure bleeding edge, thus if the automatically managed branch is a way to go for you (plural 'you'), to avoid those reverts, then feel free to do it. Maybe, only, it would be ideal if the new branch won't influence daily `git pull` on the projects, due to bandwidth limitation, connection speed and similar constraints. That would, maybe, better fit to create a new project for the automatic builds, with the "interesting" git sub-modules there at certain commits. There might not be much difference between the new project with submodules and 10K branches in each module, right? Your new tool would still work on the git commits. That's still too complex, too limiting for a daily work on the master (not for me, but for jhbuild users to whom some modules will automatically stop updating at certain commit which can break other modules, like with the API changes, but the developer of the affected module might not ever notice, because he/she will stay at the commit which precedes the API change). There had been said in this thread already that having a continuous integration (automatic builds) is not easy, especially for such a large project like GNOME. Whenever a "Continuous" was said in this thread a shortly after followed "jhbuild". It's understood. The jhbuild is the current tool for the automatic builds. Supporting random automatic build systems, which is what you said could be done with the 'integration' branches, is not needed from my point of view, due to the GNOME project complexity. Thus target jhbuild only. Using modulesets (it's called like that, right?) for jhbuild and writing an export/import utility to transform the jhbuild's moduleset into another automated build integration could be also doable, hypothetically speaking. If any such thing would be needed in the future. That is, let's target jhbuild first. The jhbuild already has a functionality
