How do base commits get released?

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

How do base commits get released?

George Plymale II
Hi all,

Recently, I was trying to use some features that had been committed to
Macports' base recently. One of them was my own feature which was
accepted in this PR: https://github.com/macports/macports-base/pull/99

However, as I tried to use this feature it simply would not work. At
first, I was scared that I'd stumbled on some sort of hideous heisenbug;
that my code actually wasn't working even though it had already been
accepted and I tested it previously. Upon further investigation, though,
it seems that actually my Macports' base is missing some commits, even
though it's on the latest version 2.5.4.

According to porthier(7), the sources of my base are located under:
/opt/local/var/macports/sources

By following the directory tree, I found the folder I was interested in:
/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/base/src/pextlib1.0

As I looked in this folder, I noticed that many files had timestamps of
2017, including readline.c which is the specific file I was interested
in. I confirmed that this file really was not up-to-date with the master
branch. Here is the file's commit history:
https://github.com/macports/macports-base/commits/master/src/pextlib1.0/readline.c

As you can see, the most recent change since 2017 was the rebranding of
"OS X" to "macOS." My version of readline.c does not even have this
update; the file contains many references to "OS X" and no references to
"macOS." Clearly, some commits are missing from my base tree.

Furthermore, upon examining the commits between 2.5.3 and 2.5.4 it is
apparent that some commits on the master branch are missing:
https://github.com/macports/macports-base/compare/v2.5.3...v2.5.4

So what's going on? I guess this must be part of Macports' release
system and only certain commits are picked for release. I can't think of
any other explanation, at least. Why is this done? How long does it take
(and what are the criteria) before a base commit is actually released? I
don't see any documentation describing the release process. I'm glad at
least to know that my changes were not infected with any heisenbugs, but
after all this investigation I'd like to know what's going on! Consider
my curiosity piqued, I guess :)

Thanks,
- George Plymale II
Reply | Threaded
Open this post in threaded view
|

Re: How do base commits get released?

Ryan Schmidt-24
On Nov 1, 2018, at 21:41, George Plymale II wrote:

> Hi all,
>
> Recently, I was trying to use some features that had been committed to
> Macports' base recently. One of them was my own feature which was
> accepted in this PR: https://github.com/macports/macports-base/pull/99
>
> However, as I tried to use this feature it simply would not work. At
> first, I was scared that I'd stumbled on some sort of hideous heisenbug;
> that my code actually wasn't working even though it had already been
> accepted and I tested it previously. Upon further investigation, though,
> it seems that actually my Macports' base is missing some commits, even
> though it's on the latest version 2.5.4.
>
> According to porthier(7), the sources of my base are located under:
> /opt/local/var/macports/sources
>
> By following the directory tree, I found the folder I was interested in:
> /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/base/src/pextlib1.0
>
> As I looked in this folder, I noticed that many files had timestamps of
> 2017, including readline.c which is the specific file I was interested
> in. I confirmed that this file really was not up-to-date with the master
> branch. Here is the file's commit history:
> https://github.com/macports/macports-base/commits/master/src/pextlib1.0/readline.c
>
> As you can see, the most recent change since 2017 was the rebranding of
> "OS X" to "macOS." My version of readline.c does not even have this
> update; the file contains many references to "OS X" and no references to
> "macOS." Clearly, some commits are missing from my base tree.
>
> Furthermore, upon examining the commits between 2.5.3 and 2.5.4 it is
> apparent that some commits on the master branch are missing:
> https://github.com/macports/macports-base/compare/v2.5.3...v2.5.4
>
> So what's going on? I guess this must be part of Macports' release
> system and only certain commits are picked for release. I can't think of
> any other explanation, at least. Why is this done? How long does it take
> (and what are the criteria) before a base commit is actually released? I
> don't see any documentation describing the release process. I'm glad at
> least to know that my changes were not infected with any heisenbugs, but
> after all this investigation I'd like to know what's going on! Consider
> my curiosity piqued, I guess :)
>
> Thanks,
> - George Plymale II

Hi George,

Commits to the macports-ports repository are distributed to users automatically, without further review, as quickly as the content can be synchronized to the rsync servers, which usually happens within an hour of each change.

Commits to the macports-base repository on the other hand are tested by developers first, then accumulated into manually-created releases, which are published on our web site and distributed to users via selfupdate. You can see our prior release history here:

https://github.com/macports/macports-base/releases

and here:

https://github.com/macports/macports-base/blob/master/ChangeLog


If your PR is a bug fix, we could consider it for inclusion in the next bugfix release of MacPorts; if we make such a release it will be 2.5.5. If your PR is a new feature, it would go into the next feature release, which would be 2.6.0 (or conceivably 3.0.0 if we feel such a jump in version number is warranted). That's also why you'll find commits on master that were not released in 2.5.4. We only backport specific changes, designed to fix specific bugs, from master to the current release branch. Other changes have to wait for the next feature release.

New releases of MacPorts base are made by portmgr (Joshua, Rainer, and me) when it seems like a good time to do so. We collectively make the decision to release a new version, usually asking the community if any other changes should be included in the upcoming release, and then one of us actually makes the release (that's been Joshua lately). For example, we needed to make a change for better compatibility with Mojave, so we released 2.5.4 recently for that reason. If another critical bug were found, that would probably motivate us to release a new version quickly. Less critical changes will probably have to wait until several changes can be released together at once. There is no set schedule for MacPorts base releases.

It would be good if we could make more frequent releases to get fixes out there, even if they're smaller or not super critical. One reason we don't do this is because our release process involves a great deal of manual labor. I hope to automate more of the process using our buildbot, but we're not there yet.

Reply | Threaded
Open this post in threaded view
|

Re: How do base commits get released?

Rainer Müller-4
In reply to this post by George Plymale II
In addition to what Ryan already said, let me add a few more pointers.

On 2018-11-02 03:41, George Plymale II wrote:
> Furthermore, upon examining the commits between 2.5.3 and 2.5.4 it is
> apparent that some commits on the master branch are missing:
> https://github.com/macports/macports-base/compare/v2.5.3...v2.5.4

These tags point to commits on the release-2.5 branch. The release
branch is created when master is deemed to be stable. Afterwards,
changes from master will only be backported (with git cherry-pick) to
release branches when we need them in a release, for example bug fixes.

https://github.com/macports/macports-base/tree/release-2.5

> So what's going on? I guess this must be part of Macports' release
> system and only certain commits are picked for release. I can't think of
> any other explanation, at least. Why is this done? How long does it take
> (and what are the criteria) before a base commit is actually released? I
> don't see any documentation describing the release process. I'm glad at
> least to know that my changes were not infected with any heisenbugs, but
> after all this investigation I'd like to know what's going on! Consider
> my curiosity piqued, I guess :)

The release process documentation is kept in the macports-base repository:

https://github.com/macports/macports-base/blob/master/portmgr/ReleaseProcess.md

Rainer
Reply | Threaded
Open this post in threaded view
|

Re: How do base commits get released?

George Plymale II
In reply to this post by Ryan Schmidt-24
Thanks for explaining all that, Ryan! I really appreciate having some
better insight into the release process. Makes a lot more sense now and
I see that it's more work than I expected.

Ryan Schmidt <[hidden email]> writes:

> It would be good if we could make more frequent releases to get fixes out there, even if they're smaller or not super critical. One reason we don't do this is because our release process involves a great deal of manual labor. I hope to automate more of the process using our buildbot, but we're not there yet.

I'm curious; what parts could be easily automated? The whole release
process sounds a bit tedious as it is currently. It'd be nice to know
what could possibly be improved by members of the community.

Thanks,
- George Plymale II
Reply | Threaded
Open this post in threaded view
|

Re: How do base commits get released?

George Plymale II
In reply to this post by Rainer Müller-4
Rainer Müller <[hidden email]> writes:

> These tags point to commits on the release-2.5 branch. The release
> branch is created when master is deemed to be stable. Afterwards,
> changes from master will only be backported (with git cherry-pick) to
> release branches when we need them in a release, for example bug fixes.
>
> https://github.com/macports/macports-base/tree/release-2.5

Got it. Thanks for adding the extra specificity; I suspected
cherry-picking was used and it makes even more sense now.

> The release process documentation is kept in the macports-base repository:
>
> https://github.com/macports/macports-base/blob/master/portmgr/ReleaseProcess.md

Doh! Thanks for pointing me to that. Great document and I'm embarrassed
that I didn't already see it.

Thanks,
- George Plymale II
Reply | Threaded
Open this post in threaded view
|

Re: How do base commits get released?

Joshua Root-8
In reply to this post by George Plymale II
On 2018-11-3 02:09 , George Plymale II wrote:

> Thanks for explaining all that, Ryan! I really appreciate having some
> better insight into the release process. Makes a lot more sense now and
> I see that it's more work than I expected.
>
> Ryan Schmidt <[hidden email]> writes:
>
>> It would be good if we could make more frequent releases to get fixes out there, even if they're smaller or not super critical. One reason we don't do this is because our release process involves a great deal of manual labor. I hope to automate more of the process using our buildbot, but we're not there yet.
>
> I'm curious; what parts could be easily automated? The whole release
> process sounds a bit tedious as it is currently. It'd be nice to know
> what could possibly be improved by members of the community.

It really isn't that manual or tedious. Most of the time I spend
building a release is waiting for 10 VMs to load up and then run 'port
pkg MacPorts'. One script syncs, builds, and copies the pkg to a central
location with the correct name.

The manual parts are ensuring that we have all the commits we want
cherry-picked, tagging the release, signing the packages, and uploading
the release files to GitHub.

There are also release-adjacent tasks like news posts.

- Josh
Reply | Threaded
Open this post in threaded view
|

Re: How do base commits get released?

Ryan Schmidt-24


On Nov 2, 2018, at 17:06, Joshua Root wrote:

> On 2018-11-3 02:09 , George Plymale II wrote:
>> Thanks for explaining all that, Ryan! I really appreciate having some
>> better insight into the release process. Makes a lot more sense now and
>> I see that it's more work than I expected.
>>
>> Ryan Schmidt writes:
>>
>>> It would be good if we could make more frequent releases to get fixes out there, even if they're smaller or not super critical. One reason we don't do this is because our release process involves a great deal of manual labor. I hope to automate more of the process using our buildbot, but we're not there yet.
>>
>> I'm curious; what parts could be easily automated? The whole release
>> process sounds a bit tedious as it is currently. It'd be nice to know
>> what could possibly be improved by members of the community.
>
> It really isn't that manual or tedious. Most of the time I spend
> building a release is waiting for 10 VMs to load up and then run 'port
> pkg MacPorts'. One script syncs, builds, and copies the pkg to a central
> location with the correct name.

Right: You've automated it to some extent on your own infrastructure, but if you were for some reason unavailable to do a release and someone else had to do it, it would be more tedious. This automation could be moved into the buildbot where we already have such VMs running. We already automatically build each commit of base for testing purposes. We could extend that and also build an installer of each commit and store it on a staging server where we or anyone could test it. Then once we've decided we have all the commits we want in a release, the release manager could just download the package from the staging server, sign it, and release it.


> The manual parts are ensuring that we have all the commits we want
> cherry-picked,

Yes, that we can't automate.


> tagging the release, signing the packages, and uploading
> the release files to GitHub.

We could automate this; many projects do.


> There are also release-adjacent tasks like news posts.

We could automate this too.

Reply | Threaded
Open this post in threaded view
|

Re: How do base commits get released?

Joshua Root-8
On 2018-11-3 16:52 , Ryan Schmidt wrote:
>
>
> On Nov 2, 2018, at 17:06, Joshua Root wrote:
>
>> tagging the release, signing the packages, and uploading
>> the release files to GitHub.
>
> We could automate this; many projects do.

How would you automate tagging a release?

Signing the packages with my Developer ID is not something I want
automated. It's just one simple command + entering a passphrase anyway.

Uploading the files is about 3 clicks.

- Josh