Hi Richard,

> >> 2. Mercurial is slow
[...]
> That proposal is similar to another that was made to us off list, it's
> being thought about, for cdm.

Is there CR to which we could subscribe to ?


> Whether we can get it, and everything else, done in 2 weeks may be
> another matter.

That's understood, it's just that we are slowly trying to really use
mercurial.



> >> 3. history (comments) is aggregated. this means doing most of the  
> >> backports will be time consuming/difficult.
> >>    - level of annoyance: painful
> >
> > We had some discussion about this one. The problem is that if you have
> > several CRs fixed in one changeset, you are not able to distinguish
> > which file was modified on behalf of which CR, it might complicate your
> > task while backporting just this one CR.
> 
> The Suggested Fix note in bugster is, I'm told, *meant* to only
> contain the diffs for the specific bug in question (unless utterly
> inseperable from others).  That may help you.

Yes, but filling in bugster is extra step, which not everyone must
follow. Admittedly, having people separate the putback into several
changesets is extra step too + people are not used to work on several
changesets at the same time (using mercurial queues, or other means).
It's just something we have to get used to.



> > Now the question is, shouldn't the original putback be split into
> > several smaller ones if possible ? Can we have several changesets per
> > one RTI ? If yes, I would say that we should encourage people to do so,
> > and explain how it can be done. If no, backports will be more difficult
> > than before.
> 
> I have no useful comment regarding that.

This is probably question to our (RPE) process creators.



> >> 4. lack of backporting guide from ONNV to ON10
> >>    - level of annoyance: mild, will become high after snv_97

To me, it's a question of getting the list of changed, deleted and moved
files, and somehow move the changes to teamware workspace. Maybe someone
writes script :)


Thank you for your comments

-- 
        Vlad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 193 bytes
Desc: not available
URL: 
<http://mail.opensolaris.org/pipermail/scm-migration-dev/attachments/20080718/61278fc1/attachment.bin>

Reply via email to