Re: The review process for new "complicated" stuff (Re: DriverDisc v3 integration)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi David,

I didn't know the git add -i feature and so I didn't see any way how to handle this "nicely". I agree that review process is needed so I did submited the patches by-file at least and tried to explain what is going on. Jeremy's comment was just too aggresive for my taste. So I might have responded without enough thinking about the answer.

> This is true, but if those mistakes are the responsibility of another
> component, we don't have to pull out our hair.  While cpio is a simple
> format,
> there's no reason we should get in to the business of owning cpio
> code.

The wrapper will be still ours to fix.. I was merely comparing the complextity of wrapper to the cpio code itself. Also my memory concerns still apply. Also, we should be careful in making stage1 bigger by adding another libraries.

> Personally, I've been using stacked git (stgit) to manage patches. 
> What I
> like about it is I can manage revisions to patches during review more
> easily.
> I have my own local workflow for noting when patches are reviewed or
> not (I
> move them to another local branch).  Whatever is left in the original
> branch
> is still out for review.
> 
> For me, the emails on the list contain useful information but are
> throw-away
> once I process them.

So you sync all the patches to your git repo? Do you use git am for that? stgit is nice idea though, I might try that.

Martin

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

[Index of Archives]     [Kickstart]     [Fedora Users]     [Fedora Legacy List]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]
  Powered by Linux