Posted by
EstebanLM on
May 15, 2012; 4:15pm
URL: https://forum.world.st/About-the-new-release-process-tp4574410p4630333.html
Hi,
I don't understand completely your question... PharoXX repositories are for integrated stuff (by version) and just integrators can access there.
PharoInbox is the place where stuff who need to be integrated goes... always tracked by an issue in the issue tracker. So, we can know if it belongs to 1.4 or 2.0 just because we have more information than just the packages commited.
Ideally, if you want to fix something, you need to do it, then create a slice, commit it to inbox, then announce in bugtracker "FixReviewNeeded", then we review and if everything is ok, we integrate it :)
(In fact, we are not going to integrate anything that is absent from tracker, because otherwise it is going to be really hard to see)
best,
Esteban
On May 15, 2012, at 5:45 PM, Ben Coman wrote:
> 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
>
>
>
>
>
>
>