On 12/08/2017 09:00 AM, Florian Weimer wrote: > On 12/08/2017 02:40 PM, Steve Dickson wrote: >> Hey, >> >> On 12/07/2017 02:31 PM, Florian Weimer wrote: >>> On 12/07/2017 04:31 PM, Steve Dickson wrote: >>>> Where committed to the master branch and not to any other >>>> branch make the maintenance of those branches a pain >>>> because I can no longer cherry-pick between branches. >>> >>> Maybe you can elaborate on how this causes problems for your >>> development process, and we can find a way to avoid that? > >> I think the best way to avoid these problems is have any all changes >> go through the maintainer... > > That doesn't work if the maintainer doesn't react in a timely fashion to bug reports, as it is the case for many maintainers unfortunately. For non-critical issues, this is quite understandable, too. Yes and No... If there is a bug report and the maintainer is unresponsive... that is one thing because the maintainer has gotten bugzilla email about it If the problem is that critical the maintainer usually gets pinged... I know I have been in the past. Define "non-critical issues" is changing dependencies on systemd non-critical? No! non-critical is too broad of a term and should be determined by the maintainer not somebody that has no or little knowledge... IMHO. > > If cleanups have to go through the maintainer, it's pretty much like saying that they should not happen, ever. This is not true with in every case. But in the cases this is true, maybe there should be a time limited? 48hrs?? > >> Now when something breaks from a change like this... Who are you going to call? :-) >> Not the Ghostbusters... the maintainer and if the maintainer didn't even know >> about the change... how fair that?? > > I don't understand the problem. If the change came with an upstream import, most maintainers would be surprised as well (because they are not upstream or have not reviewed any single upstream change). Upstream changes are not a problem... Its these random packaging changes that are not document (aka no bz) no reason why... Just done... That is not good... again IMHO.. We have this "new" push/pull mechanism that works just great! Why can't these non-critical fixed go through that? > > Again, if there is a Git proces issue here, we can provide guidelines to avoid that with bulk changes (and perhaps a minor Koji enhancement on top). But if you don't say what the technical problems are that you are dealing with, we can't make such improvements. Its not that... I just me whining about having to do more "cleanup" work.. ;-) steved. > > Thanks, > Florian _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
