On Mon, Mar 14, 2016 at 08:48:44PM +0300, Yauhen Kharuzhy wrote: > On Thu, Mar 10, 2016 at 05:40:56PM +0100, David Sterba wrote: > > On Thu, Mar 10, 2016 at 11:09:29AM +0800, Anand Jain wrote: > > > > > > > Please send any followup changes on top of the current devel patch. > > > > > > I kind of missed this point at the wiki. > > > -- > > > The git repositories on kernel.org are not used for development > > > or integration branches. > > > -- > > > Thanks for the update on how things work at your end, which helps > > > to keep loss of productive at low. > > > > The development branch workflow in progs has been used for months, I > > don't know why that would be news for you. > > > > > Suggest that we need to update similar for the kernel > > > section as well. I see some of the inactive branches > > > being mentioned there. And its bit confusing as of now. > > > > That's probably the section about btrfs-next tree that is not active for > > a long time. Apparently nobody cared enough to fix it which just > > underlines lack of active wiki editors. > > > > I don't understand why you bring it up now, you're a long-term > > contributor so you're supposed to know how the patches get merged. > > This is actual question for me too. Now I track Chris Mason's git tree > for latest integrated changes but if any other active git repositories > exist, please say. We are like to use btrfs actively in future (and use > it now) in our customer's products, so I intend to be involved in > development. Partially covered at https://btrfs.wiki.kernel.org/index.php/Btrfs_source_repositories depends if you want btrfs-progs or kernel. > And last question about development process: can I hope that btrfs > maintainers will use the patchwork.kernel.org for patches tracking? We've tried. I had to script around patchwork heavily to make it usable but it's still not my priority to keep the patchwork status up to date. I do run some scripts after releases to mark the done and actually merged, but this may miss patches that got renamed subject. > It's sometimes very difficult to track status of patches sent to > mailing list. For instance, I am trying to get Anand's patches for > 'global hot spare' functionality working, they depends from two > another patchsets which were re-sent few times with changes and > introduced new bugs etc... Well, the number of submitted patchsets is larger than the review bandwidth required to get them merged. From my personal standpoint, I monitor patches from areas close to me or features I'd like to get merged. And I don't manage to cover all of them, unlikely in the timeframe they're submitted. Most patchsets have impact on various internals and introduce/modify the interfaces, such things need review from people who understand the code or the problematics. Sending a patchset repeatedly helps, it's kind of a reminder for us and that the author cares about it. Separating patches to small reviewable pieces is basically considered a good practice, sending preparatory patchsets that do cleanups or introduce stuff that would be used later helps to focus on the core changes when they come. It's considered ok in btrfs community to send emails or ping on IRC and ask people privately about the plans or status. HTH. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
