Sean P. DeNigris wrote:
EstebanLM wrote
our new release process...
two bug fix releases at month 4 and month 8...
During this year we'll also release bugfix versions of Pharo 1.4.
This is exciting because as soon as a version is released, everyone starts
pounding on it and inevitably finding bugs. It will be nice to have those
fixes go into the current version instead of instantly starting to focus on
the next major version months or a year away.
I noticed bug issues relevant to 1.4 getting tagged with 2.0 milestone. How
do we get fixes into the 1.4 bug release versions? If we make a slice off
the 1.4 package, there may be many conflicts merging into 2.0, but if we
merge in the future version, there will be many 2.0-only changes that have
nothing to do with the fix, won't there? What's the protocol? And now that
we're time-based, what's the date for the first bug fix release?
I have been considering asking similar questions for a while. First,
can someone confirm and clarify my understanding of the purpose of the
standard repositories...
* Pharo14 - Read Only. I see five admins who presumably are the only
integrators who can commit to the repository. I assume that at the time
Pharo 1.4 was released, the latest versions in this repository exactly
matched loaded into the released image. I assume this is now low
traffic, but browsing this repository I see some packages have updates.
Are these the ones that will form the basis of a Pharo 1.4.1 maintenance
release?
* PharoInbox - Read/Write. Anyone can submit packages here to await
review by testers and integrators.
* PharoTreatedInbox - Read Only. Squeaksource says "Repository for
packages from the inbox that are either released or reject by the
release team" but I am not clear on whether "released" means items
accepted into the mainline Pharo14 repository are copied to
PharoTreatedInbox as well as going to the Pharo14 repository.
* Pharo20 - Read Only. Active HEAD of Pharo development.
What I am not clear on is how the integrators know whether a submission
to PharoInbox is based off Pharo 1.4 or 2.0. From previous discussions
it seems a possibility that due to limited resources a community
submission to fix something in 1.4 might just be consumed into the
mainline 2.0 and not backported to 1.4. Not withstanding that I
understand and support the desire to push forward as fast as possible,
as a business user trying to stabilize a deployed product this would be
annoying. Note that I am referring here to user community contributions
and not how mainline developers choose which version in which to attack
ticketed issues.
So then, an uncertain proposal... to create a Pharo14MaintInbox
repository for contributions submitted from within a Pharo1.4 image.
Optionally, any package accepted from Pharo14MaintInbox into Pharo14
could incrementally copied at that time into the mainline 2.0
PharoInbox, so as not to lose any fixes that might carry over to
mainline 2.0. Alternatively, this might be done in one go when a tested
1.4.1 maintenance version is released.
cheers -ben
