Ralf's Remove CVS Id Commits

Chris Johns chrisj at rtems.org
Sat May 5 00:42:36 UTC 2012


On 5/05/12 9:48 AM, Joel Sherrill wrote:
> I don't care on the head if a revert patch shows up. Sebastian and I both committed afterwards so nuking them would be back.
>
> On 4.10 nuking them is desirable if not too risky.
>

I support the removal of all the change Id commits by Ralf. I have 
review all of Joel's changes [1] and I also reviewed Ralf's commits plus 
the related email threads.

It is an unfortunate incident and shows poor judgement and a lack of 
consideration to others in the project by Ralf. I expect a higher level 
of responsible behaviour from those with commit access and think this 
behaviour is not acceptable.

Chris

[1] http://www.rtems.org/pipermail/rtems-devel/2012-May/000991.html

> --joel
>
> Gedare Bloom<gedare at rtems.org>  wrote:
>
>> On Fri, May 4, 2012 at 7:06 PM, Gedare Bloom<gedare at rtems.org>  wrote:
>>> This CVS Id business is a mess. I'd prefer that Ralf clean-up / revert
>>> what he did with a single change to both the head and the 4.10 branch.
>>> Then we can proceed in a more friendly way.
>>>
>>> The following commands will revert all the various patches for the git
>>> head in a single patch.
>>>
>>> git checkout -b revert-ids 27272db3363cce157e83e484f9f89cc41fc0752c
>>> git revert HEAD~61 -n
>>> git commit -m "Ids: revert"
>>> git push upstream revert-ids:master
>>>
>> It might be necessary to create  patch and then apply it to a
>> checked-out head. I'm not sure about pushing from a checked-out
>> previous commit.
>>
>>> See http://git.rtems.org/gedare/rtems.git/commit/?h=revert-ids
>>>
>>> A similar formula can be made for 4.10 if we like, or we could reset
>>> the repository to get rid of them entirely... For the 4.10 branch I
>>> think we can 'reset' the repository since (likely) no one has checked
>>> it out and started to work from where the removals took place.
>>> git checkout upstream/4.10 -b 4.10
>>> git pull
>>> git reset --hard f29ab47c93619c705c82d096c6d2cb85e95247ba
>>> git push -f
>>>
>>> That's not very nice to do but as long as no one has based any work
>>> off the 4.10 head since these Remove Id commits occurred then
>>> everything should be fine and the history will be cleaner.
>>>
>>> -Gedare
>>>
>>> On Fri, May 4, 2012 at 1:55 PM, Joel Sherrill<joel.sherrill at oarcorp.com>  wrote:
>>>> On 05/04/2012 11:34 AM, Ralf Corsepius wrote:
>>>>>
>>>>> On 05/04/2012 05:07 PM, Thomas Doerfler wrote:
>>>>>>
>>>>>> Ralf,
>>>>>>
>>>>>> Am 04.05.2012 16:44, schrieb Ralf Corsepius:
>>>>>>>
>>>>>>> On 05/04/2012 04:10 PM, Thomas Doerfler wrote:
>>>>>>>>
>>>>>>>> These changes belong together. Nobody wants this change to be done in
>>>>>>>> one BSP and NOT done in a different one.
>>>>>>>
>>>>>>> Did you actually have a look into the patches?
>>>>>>
>>>>>> Yes and no. I read some at the beginning, some in the middle and some at
>>>>>> the end of your two patch sequences. I saw that each patch performs
>>>>>> similar modifications for different directories or dir trees. I saw that
>>>>>> you have committed separate patches with similar changes for each BSP or
>>>>>> group of BSPs.
>>>>>
>>>>> Correct ...
>>>>>
>>>>>> I am sure you don't want the community to inspect each patch separately?
>>>>>
>>>>> Pardon, I am the original author of all the files and probably nobody
>>>>> knows these better than me. I had applied many much more intrusive
>>>>> patches in similar ways many times before.
>>>>
>>>> I'm the author of a lot of the source in the tree and I don't trust
>>>> anyone's script enough to commit the result without a review.
>>>>
>>>> I don't care who edits the damned files. The issue is that I
>>>> posted (1) complete patches for most of the tree and
>>>> (2) I asked for review.
>>>>
>>>> You ignored (1) and by "nibbling" are making my work
>>>> "hard". You didn't want anyone to do that to you but it
>>>> was OK to do that to me.
>>>>
>>>> When I ask for review on something, I think it is something
>>>> that needs review. I don't care who wrote it or how it
>>>> was generated. Why is your script any less suspect than mine?
>>>>
>>>>
>>>>
>>>>> I am surely not perfect and surely do not want exclude something might
>>>>> have gone wrong somewhere, but this request of yours makes me sad.
>>>>
>>>> This isn't about how you feel. This is about cooperating.
>>>>
>>>> You ignored my near work which eliminated ALL CVS Ids
>>>> in most of the tree. It was available for review and
>>>> I had specifically asked for review. If anyone has
>>>> reason to have their feelings hurt, it is me.  You obviously
>>>> think my changes were not worthy of your review time
>>>> and it didn't matter if you "nibbled" and caused me
>>>> extra work.
>>>>
>>>> Somehow your changes were above needing to be
>>>> reviewed while mine were unworthy of your review.
>>>>
>>>>
>>>>>> I assume that the goal/intention of each patch is quite silimar. Am I
>>>>>> right here? Or do they have different goals/intentions?
>>>>>
>>>>> ... these changes were script-generated ,. the spots changed were
>>>>> trivial to parse comment blocks.
>>>>
>>>> So were mine. What makes your "nibbling" so superior that
>>>> it could conflict with my complete work which was available
>>>> for review?
>>>>
>>>>>>>> Maybe you should get familiar with the idea that git does apply patches
>>>>>>>> in an atomic way and not in a uncorrelated file-by-file basis as CVS
>>>>>>>> does.
>>>>>>>
>>>>>>> The mashing up of the commit messages wasn't done by CVS. It was the
>>>>>>> tool being used to produce the commit messages, which was polling at 1
>>>>>>> hour intervals and glueing together independent commits.
>>>>>>
>>>>>> Why did you let it glue independent commits?
>>>>>
>>>>> I did not do anything - This was the tool somebody (I think it was
>>>>> Chris) had installed on rtems.org to send CVS commit logs.
>>>>
>>>> That is an operator error on your part.  That's why I did the
>>>> work on a git branch on my personal repo. It could be reviewed,
>>>> the patches squashed into a single "automatic" and a
>>>> single "manual" if that was what the community wanted.
>>>>
>>>> The review was for both "correctness" and to ensure
>>>> that the community was happy with the edits.
>>>>
>>>>> Ralf
>>>>> _______________________________________________
>>>>> rtems-devel mailing list
>>>>> rtems-devel at rtems.org
>>>>> http://www.rtems.org/mailman/listinfo/rtems-devel
>>>>
>>>>
>>>>
>>>> --
>>>> Joel Sherrill, Ph.D.             Director of Research&     Development
>>>> joel.sherrill at OARcorp.com        On-Line Applications Research
>>>> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>>>>     Support Available             (256) 722-9985
>>>>
>>>>
>>>> _______________________________________________
>>>> rtems-devel mailing list
>>>> rtems-devel at rtems.org
>>>> http://www.rtems.org/mailman/listinfo/rtems-devel
>
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel



More information about the devel mailing list